Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Sensor data goes out of sync in stream mode


  • Please log in to reply
7 replies to this topic

#1 anon82

anon82
  • Members
  • 11 posts

Posted 02 December 2013 - 12:04 PM

Hi Labjack support,

 

I'm reading data from Labjack in stream mode from encoder and linear sensor.

 

I'm able to read the data correctly for a while until the data starts giving some weird results. Here the values jump from ~3000 to 65 and then drops to ~1900. Data should change slowly. Also AIN224 gives some value, while I think it should stay on zero.

 

DEBUG: ProcessedData defaultdict(<type 'list'>, {'AIN200': [3483, 3482, 3482, 3481, 3480, 3480, 65535, 1891], 'AIN0': [4.972959999999999, 4.972959999999999, 4.967935999999998, 4.977983999999999, 4.977983999999999, 4.972959999999999, 10.277989999999999,

1.5315199999999987], 'AIN224': [0, 0, 0, 0, 0, 0, 65535, 0]})

 

Could the error relate to overflowed Labjack buffer or something similar?

 

The reading is done in a loop using:

 

while True:

    readData = self.dev.streamData(convert = False).next()

    processedData = self.dev.processStreamData(readData['result'])

    time.sleep(0.1)

 

 

And I configure labjack, as follows:

 

 

self.dev.getFeedback([u3.TimerConfig(timer = 0, TimerMode = 8, Value = 0), 

u3.TimerConfig(timer = 1, TimerMode = 8, Value = 0)])

 

self.dev.streamConfig( NumChannels = 3

                        PChannels = [ 0, 200, 224 ], 

                        NChannels = [ 31, 31, 31 ], 

                        Resolution = 0

                        SampleFrequency = 100,

                        SamplesPerPacket = 24 )

 

I appreciate any ideas you have.



#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 02 December 2013 - 12:58 PM

It looks like you are getting 1 scan with all FFFFs.  What O/S are you using?



#3 anon82

anon82
  • Members
  • 11 posts

Posted 02 December 2013 - 01:07 PM

It's Windows 7.



#4 anon82

anon82
  • Members
  • 11 posts

Posted 02 December 2013 - 01:56 PM

Here's a demonstration video.

 



#5 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 02 December 2013 - 02:35 PM

It looks like your U3's stream buffer filled and auto-recovery mode kicked in. The all 0xFFFF scan (~10, 65535, 65535) you are seeing is a dummy scan indicating auto-recovery mode has ended and separates new data from pre auto-recovery mode data. Check the returned readData['missed'] value for how many scans were discarded during auto-recovery. Note that stream time after auto-recovery is still correct.

 

The reason for the stream buffer filling is that you are reading stream data from the U3 at a rate of about 80 scans per second though have the scan rate set to 100 scans per second. When you set SamplesPerPacket to less than 25, streamData only reads SamplesPerPacket samples per call. So in your case you are reading 24 samples (8 scans) every 100 ms. Either remove the sleep in your loop or set SamplesPerPacket to 25 (or don't set the parameter so it defaults to 25) which will make the streamData call read in multiples of 25 samples.



#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 02 December 2013 - 02:44 PM

Another option is to keep SamplesPerPacket at 24 and make your sleep less then 80 ms.



#7 anon82

anon82
  • Members
  • 11 posts

Posted 02 December 2013 - 11:03 PM

Thank you.

 

I thought I should have used 24 samplesPerPacket in order to keep the streamed data in sync, or am I misunderstood? At least, now I always get equal amount of samples from all sensors.

 

"which will make the streamData call read in multiples of 25 samples." What does this mean? I thought it would only read one sample more to buffer in comparison to value 24. And as I'm getting 3 sensor values, one of them would always return one value more than others.

 

 



#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 03 December 2013 - 02:02 PM

Setting SamplePerPacket to 24 will ensure each streamData call will have 8 full scans of data with your settings. If the scan's channels cannot fit evenly into the samplesPerPacket size, the following streamData read will contain the rest of scan's samples. Your application will need to take that into account when managing stream data in that case.

 

When you set it to 25, the streamData call will read more than one StreamData packet in a single USB read and one packet contains 25 samples maximum. So streamData will return 25*x samples where x is determined by the scan rate in code. Doing this provides the best USB data transfer efficiency and is necessary for faster scan rates. For your scan rate setting samplesPerPacket to 24 will be fine.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users