Streaming and capturing time stamp
Posted 12 June 2013 - 09:52 AM
Posted 12 June 2013 - 11:56 AM
Does the unmodified stream example work fine for you?
I don't quite understand what you mean by timestamp. The relative time (elapsed time from the start of the stream) is known from scan number and scanrate.
Posted 12 June 2013 - 12:21 PM
Posted 12 June 2013 - 12:46 PM
Posted 12 June 2013 - 01:07 PM
Posted 12 June 2013 - 03:43 PM
private double numScans = 300000; //2x the expected # of scans (2*scanRate*delayms/1000) = 2 * 50000 * 3000/1000 private double numScansRequested; private double adblData = new double; //Max buffer size (#channels*numScansRequestedNote that the example sets a five second buffer for 2 channels by default. "numScans" is the number of scans you are reading every "delayms". At a 50000 scan rate for 1 channel (50000 samples/second) in 3 seconds you will have 150000 samples to read. Your old settings were only reading 20000 samples every 3 seconds. The settings I suggest will try to read 300000 samples but will probably only get around 150000 samples. You ask for more than needed and it will help ensure the driver's stream buffer is being cleared and prevent an overflow.
Posted 12 June 2013 - 03:57 PM
Posted 13 June 2013 - 07:39 AM
Posted 13 June 2013 - 08:35 AM
No, LJ_chSTREAM_READS_PER_SECOND and LJ_chSTREAM_SAMPLES_PER_PACKET are advanced config parameters typically used for lower-speed low-latency streaming. For example, if someone wants to stream at 1k, but they want 1 scan or sample transferred at a time in the background, rather than the more efficient large packets. The default values are good for streaming at 50k.
does the LJ_chSTREAM_READS_PER_SECOND need to be increased from the default of 25?
Delay: Switch to SLEEP mode, so you will not use any delay at all. The read function will wait until the desired amount of data is ready.
What are good choices for the delay, buffer size, etc for running the streaming at faster rates, such as 10K, 20K, and 50K?
UD Buffer Size: 10 seconds is typical if you are reading data once per second. That gives you some buffer in case the computer is temporarily busy and not reading data fast enough, but not too much buffer to where you are falling behind and don't notice. You could just make the buffer huge if you don't want to think about it. If you just fix it at 1000000, that equates to 20 seconds at the max sample rate of 50k, so you know the buffer is always 20s or more.
The pseudocode in Section 4.3.7 shows a typical SLEEP wait mode stream. You typically read data once or twice a second, so if scanrate is 50k then numScans might be set to 25k before each read call. After each read call I suggest you display STREAM_BACKLOG_UD so you can make sure it is staying near 0 and not growing.
If you still have trouble, I suggest you attach a file or zipped project for us to check out.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users