The documentation suggests in spots that the ScansPerRead have to fit into a buffer not greater than 32764 bytes in size. The topic is not consistently treated and I'm a bit confused. If I only read analog input, I believe each read buffer is 2 * numch * ScansPerRead bytes long.
If I ask for 50000 scans/read I seem to get sensible answers. I'm confused about where the 32K limit comes in and whether or not I have to worry about it.
(Your documentation is very useful and filled with helpful remarks. I have some problems with it's organization and trying to relocate material I've read earlier. Is there a well-defined root point that covers everything?)
Thanks for your help.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
The 32764 byte buffer is the stream buffer on the T7 (STREAM_BUFFER_SIZE_BYTES). It is mentioned in the T7 datasheet here:
https://labjack.com/support/datasheets/t7/communication/stream-mode
If you are using LJM, you do not need to configure this setting. The LJM library configures it for you when using the stream functions and reads stream samples from the T7 in a background thread. The LJM library itself has its own software stream buffer that is larger than 32764 bytes. When using LJM_eStreamStart, we don't limit ScansPerRead. If we mention a 32764 bytes limit for ScansPerRead in documentation somewhere, please point us to it.
Thank you. I think I understand this now. I had forgotten that LJM actually resides on the host computer. So the constraint is only important to the user if I directly access the onboard buffer in the T7. In normal usage with the LJM library, the library manages the onboard buffer as well as it's own on-host buffer and the LJM library can provide much larger buffer chunks for the application program to read.
Thanks, again.