I have a system in which I am attempting to gather data from 2 transducers (measuring pressure drop across a component), and a Hall effect sensor to measure flow rate. I am needing to collect data at higher frequencies than what is available in call response mode, so am using the U3 streaming. I have the portion of the code that takes readings from the transducers working, however I am having trouble making sense of how the 16-bit rising edge timer operates in stream mode.
In my code, I have my timer configured to FIO4, mode 12, channel 200, with a clock base of 48MHz and clock divisor of 48 (sample every milisecond). The thing I do not understand is when observing the timer using LJControlPanel, I am getting frequencies from the flow sensor that make sense but when trying to get readings from my code I get frequency=0 for each recorded reading over a 10+ second test. Once the timer is started in stream mode, shouldn't it give me back the time in miliseconds between rising edges until the next edge appears? The only way I can get a value, is if I use the timer.sleep() function, but even then it just gives me the same value over and over. Not sure what I need to do to get the timer to give me consistent readings for each time I pull data from the transducers. Code and readout are attached, first part of readout is with timer.sleep() enabled, second part without.
Any help is appreciated!
.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")
Your call:
ticks = d.getFeedback(cmd)[0]
Is setting ticks to the read timer value, and the rest of your code is just using that one value and not getting new readings. Two solutions:
1. You need to perform the getFeedback call and get its reading in your code where you were using ticks.
2. The more accurate solution is to use the timer readings from your stream which aligns with your scans. For example, r["AIN200"][0] is the timer value reading for your first scan. Currently, it looks like you had intention to read the timer with a command-response mode read (getFeedback) after your stream reads (buffered).
Appreciate the response. I see what you mean and have updated the script to pull values from the flowmeter the same way I am from the transducers, sum(r['AIN200'])/len(r['AIN200']), and while that has fixed the issue of me getting the same values over and over, I am still getting values that are vary similar to each other regardless of the flow I am actually putting through the system. Additionally, I get those readings even when I do not have the flow sensor hooked up to the U3-HV? Not sure why this is the case.
Also, could you elaborate a bit on the last sentence of your previous response? "Also, keep in mind that stream mode is buffer based, so your timer reading that the timer readings in your stream are data in your stream Keep in mind."
Thanks for the help. New code and output are attached.
If you look at the individual readings, do you see more of a change? Currently you are getting the average.
I removed that last part of my previous post as I meant to scrap it but left it in by mistake. By "buffer based" I meant that when you start stream mode, the U3 will sample on its own at its configured rate and put it in a buffer. Your application is reading from this buffer. I was mentioning this for timing reasons and for using the timer readings from the stream data, which I simplified to solution 2. For more details on stream mode look here in the datasheet:
https://labjack.com/support/datasheets/u3/operation/stream-mode
To add, when your sensor stops the Timer will report the last known value until you reset it or get a signal again. When streaming, channel 230 is Timer0 with reset.
https://labjack.com/support/datasheets/u3/operation/stream-mode/digital-...
Yes, when looking at the individual readings they jump around quite a bit. I have attached the code for how I checked this and the read out. The attached read out is without the hall effect sensor connected, so why is it that I am seeing these values that are all over the place (looks the same with the sensor connected to FIO4) instead of zeros, an error, or the same value repeated continuously? From what I understand, for timers shouldn't the values stored in the buffer be the number of time increments (however the user decides to set it up), since the LJ detected the last rising edge? So for example if I were to have a relatively slow flow rate and did not see a pulse for a second or two, I would expect to see the same value over and over again in my stream until that next pulse was detected.
Appreciate all the help on this.
It looks like you are using a 16-bit measurement with the source clock set to 1 MHz. That means the maximum measurable period is 65.5 ms. Any period that takes more than 65.5 ms will produce an invalid (aliased) result. We either need to switch to a 32-bit measurement or slow down the clock.
Switching to a clock of 1 MHz with a 100 divider would allow us to measure periods up to 6.5 seconds.
That makes sense. I updated my clock configuration to d.configTimerClock(3,100), and tested with the sensor connected and still got an output that jumped around quite a bit. Also checked the output using the LJControlPanel, and was seeing values around 2000 or .2 second periods. With that being the case, should I be expecting an output that repeats the same value for chunks of the stream if things are working properly, or is it expected to jump around from reading to reading?
The period data is the fourth item in the scan list, so it is the fourth item in the data etc.
So our period data is:
32465
40466
48469
56469
64469
6929
14929
22931
30929
38933
46931
54931
2930
We can see that the value is increasing by about 8000 every time (rolling back to zero after 65535). That looks like the data is still aliased.
What is the frequency of the test signal?
What frequency range are you expecting?
I am expecting a frequency between 8-11Hz, dependent on flow rate.
A couple of clarifying questions:
1. You state "period data is the fourth item in the scan list," is that always the case for this timer mode or timer use in general? Or is there a way you determined how many data points would make up a single period based off the settings defined in the code?
2. What does the "Scanfrequency" define when configuring the stream? I read section 3.2 and tried values of 2000 and 3000 trying to identify a trend, however all I see is that the values in the scan list vary while still increasing 8000 every 4 items. Just different intervals between each of those 4 items.
3. Can you give me an idea of what good, unaliased data might look like given I expect to see roughly 10 rising edges per second from the sensor? As I mentioned in an earlier post, my impression for how timers work is the values stored in the buffer be the number of time increments (however the user decides to set it up), since the LJ detected the last rising edge? So for example if I were to have a relatively slow flow rate and did not see a pulse for a second or two, I would expect to see the same value over and over again in my stream until that next pulse was detected. I'm just not really sure how I should be interpretting the data I am receiving.
1) It is the fourth item because of the setup of the stream scan list.
2) Scan frequency is how often the scan list will be read. In other words, if the scan frequency is 1kHz then every 1 ms the U3 will measure every channel in the scan list.
3) You are correct. The data returned is the last complete reading. You can use the read with reset register to clear the reading to zero.
1.) So it is the fourth item in the data since it is the fourth item in the stream config?
d.streamConfig(NumChannels=4, PChannels=[0, 1, 2, 230], NChannels=[31, 31, 31, 31], Resolution=0, ScanFrequency=2000)
If I only stream the timer, I still get the same output.
3.) So if my understanding is correct, why am I not seeing large chunks of my printed output of r['230'] being the same value over and over when my input signal has such a low frequency? I still do not understand how the printed output can be interpretted to determine time between rising edges.
The data still looks like something is wrong. The value is increasing by ~2000 every sample, so the actual value is some multiple of our maximum measurable period plus 2000.
We need to create a test that we can replicate. Try enabling two timers, set one of them to 8-bit PWM (mode 1) with 50% duty cycle. Then connect the two timers (FIO4 to FIO5). This way FIO4 is measuring the signal from FIO5, which will be easy for us to replicate.
I ran a jumper wire between FIO4 and FIO5, and configured the two timers to those pins (Timer0=mode 1 and Timer1=mode12). When running the script, I still see the same result as before, increasing by 2000 every sample. The only way I don't get values that increase by 2000 for every sample is when I change my sampling frequency. Is there something in the code I am setting up wrong that is making me read the timer incorrectly? I'm brand new to python and this type of data acquisition, so I'm really not sure why I am seeing that values I'm getting.
I see the problem in code. You are not configuring the timer modes, so they are defaulting to the system timer lower 32-bits, so the increasing values make sense. In your last code, change:
u3.Timer0Config(TimerMode=1, Value=32578)
u3.Timer1Config(TimerMode=12, Value=0)
To:
# Build list of commands
cmds = [u3.Timer0Config(TimerMode=12, Value=0),
u3.Timer1Config(TimerMode=1, Value=32578)]
d.getFeedback(cmds) # Send commands
Note that I changed the Timer0 to mode 12 and Timer1 to mode 1 so that the stream is reading the the period measurement input. Jumper FIO5 to FIO4, and the stream is reading from FIO4. You should see readings of 256 with your current settings.
Regarding your previous code, make sure it is something like this before starting stream mode:
cmds = [u3.Timer0Config(TimerMode=12, Value=0)]
d.getFeedback(cmds)