Irregular Acquired Speed

Post Reply
priack
Posts: 3
Joined: Thu May 28, 2015 7:47 am

Irregular Acquired Speed

Post by priack »

Hi,

I am trying to write a program to get data from the ActiveTwo in C++. This program also synchronize the data with other two devices (EMG and MotionTracking). I am having a few problems, but the mos important is the following.

If I write something like this:

while (1){
READ_POINTER(usbHandle,&point)
if(point!=lastpoint){
fprintf(file,"%d\n",point-lastpoint);
lastpoint=point;
}
}
So basically what I am saving is how many bytes I receive each time. For this I was expecting around 282*4 = 1128 bytes. Because each packet are 282 integers.But what I get is between 131072 and 131584 bytes, so basically each time that the ActiveTwo sends data sends around 116 packets. Not that the while loop is executed way faster, if I erase the If clause the file is full with the same number over and over, and only time to time there is a step.

The ActiveTwo is working in the speed mode 4, so this means that I get a group of packets every 0.05s, is this normal? If so, the real acquisition speed is not 2048Hz but 14Hz.

Here is the only part from my code that I think is important for this is the initialization, I got it from this forum, I think. There is not much information about the C++ API anyway...
(In my case BUFFERSIZE is 34652160 =282 chanels*2048 samples/s * 15 s * 4 bytes/chanel)


if ((usbHandle=OPEN_DRIVER_ASYNC()) == (HANDLE)NULL){
printf("Can't open device driver!\n");
WSACleanup();
return;
}

INT_PTR bytes2Use = BUFFERSIZE;


if ((samBuffer=(PUCHAR)malloc(bytes2Use)) == 0){
printf("VirtualAlloc returns 0, GetLastError = %d\n",GetLastError());
WSACleanup();
return;
}

READ_MULTIPLE_SWEEPS(usbHandle, (PCHAR)samBuffer, bytes2Use);

CHAR controlBuffer[64];
for (int i=0; i<64; i++)
controlBuffer[i] = 0;
controlBuffer[0] = (CHAR)(-1);
if(USB_WRITE(usbHandle, &controlBuffer[0]) == FALSE){
printf ("usb_write for enable handshake trouble\n");
}

Thank you in advance

Jacobo

priack
Posts: 3
Joined: Thu May 28, 2015 7:47 am

Re: Irregular Acquired Speed

Post by priack »

Ok. Just read about the stride. Sorry about that.

allendukes
Posts: 3
Joined: Wed Jun 20, 2018 3:22 pm

Re: Irregular Acquired Speed

Post by allendukes »

What does the stride do and how might it have solved priack's problem? I have encountered a similar problem in that every ~116 packets there is a slow-down in the acquisition in Speed-mode 4. I have syncpointer set to false, and I don't configure stride: it's at its default (0.00 msec, as reported by the call to GET_DRIVER_INFO). I found this post by searching for 116, but I think the questions, and ultimately the answer, might apply more broadly.

***Background***
In my custom acquisition software, I have 2 threads running. One thread polls READ_POINTER to update the file pointer, and another that checks that value of the file pointer to see if a whole packet is received. Once a whole packet is received, I then proceed to memcpy that packet from the ring buffer into another buffer for further processing.
This approach works for the first 115 packets at an average rate of ~0.00120ms, but the 116th packet averages ~56.05ms.

When calculated separately, the first 115 packets are well above 2048Hz, around ~780000Hz, and the 116th packet is ~18Hz.

However, when I aggregate the time between every 116th packet, I get an average of 56.51ms total for every 116 packets. That yields (56.51ms/116 packets) => 0.48715687ms per packet. This effective value is ~2052Hz, much closer to the specified 2048Hz of the system. Close enough that I believe my timings are accurate.

***Questions***
I believe this effective frequency is a result of how the hardware ADC digitizes the signal, writes the data to the buffer, then updates the file pointer. Is that assumption about the sequence of events correct?

My goal is to calculate the precise timestamp of each packet, but how do I do that exactly? I foresee 2 possible approaches.

Approach 1: Capture the timestamp of the 116th packet and backdate the previous 115, by intervals of 1/2048 seconds.
Approach 2: Capture 116th packet as my initial time, then add 1/2048 seconds to the subsequent 115 packets.

Either way, it appears that processing the data in larger chunks of multiple packets would be the logical next step, but I want to ensure my timing calculations are as accurate as possible.

Would configuring stride/syncpointer effect this? How might I read the data with more consistent timings between packets?

Thanks in advance for the help. These forums are a great resource!

Coen
Site Admin
Posts: 1024
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Re: Irregular Acquired Speed

Post by Coen »

Accurate timing is only possible by supplying timestamps to the trigger port on the USB receiver (triggers are sampled synchronously with the EEG data).

Best regards, Coen (BioSemi)

Post Reply