Hello,
I am using the U3-HV for a Solar logging project. I am trying to use the python lib and Stream mode for acquiring a few signals. I have been somewhat successful, but receive some errors from the stream that I don't understand. Is there a holdoff requirement from the time you start the stream, to calling streamData?
Also, can you provide some clarification to exactly how the stream works? My understanding is that I provide a list of channels to scan along with the scan rate and some other parameters, but exactly how those parameters effect the stream are not clear.
From the data I have collected it appears the scan rate is actually the sample rate and each channel is sampled once per scan. For example, I am using a scan frequency of 2KHz, so does each scan sample each channel once and there are multiple scans for a MAX_REQUESTS of 1?
How do I know how many samples will be collected per channel being requested to scan? Can I set the number of samples. I assume the samples per packet have something to do with it, but how many packets will there be.
A little clarity on the fx will help.
My code, log file showing the errors I am receiving from streamData and collected data is attached for reference.
Thanks,
Stream mode is a continuous hardware timed input mode. You configure the scan rate and the scan list (channels). The U3 hardware samples these channels at the configured scan rate, and buffers the samples on the device. Each channel is sampled once per scan as you pointed out. Hardware sampling starts immediately after calling streamStart. You call streamData to read the samples from the U3's stream buffer. When calculating timestamps for scans, use the scan rate to calculate the time between scans (1/scanrate).
For further stream details, including how sample, scan and sample rate are defined for stream mode, look here:
https://labjack.com/support/datasheets/u3/operation/stream-mode
The amount of samples read is automatically set in the streamConfig for best throughput. It is based on packetsPerRequest and SamplesPerPacket in method's code which you can see in the source for details:
https://github.com/labjack/LabJackPython/blob/master/src/u3.py
Without looking at the u3.py code though, it is mostly set to 1200 samples per streamData call (packetsPerRequest=48, SamplesPerPacket=25) for most scan rates, which in your case with 5 channels is 240 scans. streamData will wait a bit for the samples to be available on the U3, otherwise None is returned when there is no data. If you only need a certain amount of samples, it is easiest read in these 1200 samples chunks, stop stream mode when you have at least the number of samples required and trim off the unneeded samples.
You can tweak the amount with SamplesPerPacket. If this value is under 25, then only one packet of data is read and returned, so SamplesPerPacket amount of samples per streamData call. Adjusting packetsPerRequest is more hacky in that you need to adjust the u3 object variable packetsPerRequest after calling streamConfig. Note that packetsPerRequest can only be greater than 1 when SamplesPerPacket is 25.
MAX_REQUESTS in the example is controlling how many streamData calls to perform.
errors indicates how many packets had errors which is 48 in your log. Here is a forum post from our old forums where we discuss how to get the errorcodes out the results:
https://forums.labjack.com/index.php?showtopic=7126&p=24083
It also provides a link to a list of error codes to help us trouble shoot that issue further. If you are not streaming at a fast enough, that can lead to a stream buffer overflow on the U3 which is a common cause for errors, but I would expect "+++ Missed" lines in your log when that occurs.
Thanks a bunch for the info and confirmation on how samples are done.
I will take a look at implementing the error code analysis and get back to you.
Thanks for the help,
Hello,
I am getting error code 55, STREAM_SCAN_OVERLAP.
Does this mean the previous scan hasn't finished by the time the next one starts? I am going to reduce my scan rate and see what happens. The signals I am trying to capture are only 50Hz, so I really don't need 2K. I think 500Hz should be adequate, >2x :). I was just trying to get a really good data set with the 2K.
I will let you know.
Thanks,
Hello,
Reducing the scan rate didn't help. Any ideas?
Thanks,
STREAM_SCAN_OVERLAP is how you put it. Usually it occurs when the scan rate is too high for the U3 to handle. At resolution 3, the max. sample rate is 50kHz and you are only doing 10kHz (#Channels * ScanRate), so I wouldn't expect that error. Looking over your code and testing the same configuration, I am currently unsure what the issue is. To troubleshoot:
First, power cycle (USB disconnect/reconnect) your U3, run your code again and see if that helps.
Second, power cycle your U3, run the attached file's code, and see if it has problems. It is your code simplified to only LabJack calls with some of my modifications (configuration is the same). I ran this code to try to reproduce your issue, and it ran fine without issue.
Thrid, make sure you are running the latest U3 firmware. You can check the version with code like.
import u3
dev = u3.U3()
print("Running firmware %s" % dev.configU3()["FirmwareVersion"])
The latest non beta version is 1.46. If you are under that, try updating your firmware and see if that helps.
https://labjack.com/support/firmware
Hello,
Getting closer and thanks for the script. Your script ran fine without resetting anything, or any extra effort.
So, that lead me to start isolating parts of my code until I found what caused the error.
What I found, is my fx call that reads the U3-HV internal temperature causes the problem for some reason. If I remove the fx call from the loop, the errors go away. If I add it back in, they come back. Not sure why, because the stream is stopped at this time.
I thought I remembered reading something about stream and reading the internal temp that conflicted. I will try to dig it up, maybe nothing, but I thought I read something.
The fw is up to date.
Any other ideas are appreciated.
Thanks,
I was able to reproduce the issue by adding in your getLabJackTemp call after the streamStop call. I'm not sure exactly why that would be causing the errors since it is done after stream mode has stopped, but I have found that if you put your streamConfig call in your loop so that it is called before every streamStart there are no STREAM_SCAN_OVERLAP (55) errors. Try that out.
Thanks,
I will give it a try.
That worked.
I also noticed that the internal temp sensor can be read via stream as channel 30. Would the neg ch be 31?
Thanks,
Yes, the negative channel will be 31, single-ended, for the temperature sensor, positive channel 30.