FIFO queue seems not to be supplemented in 5.1.24 vs 3.2.45

[gchassink]

The code below runs in 3.2 but not 5.1 it seems that if quesize is set to 100000 and blocksize to 25000, after the 3rd attempt to read the buffer only ~24851 samples per channel ar left and not refilled as wif the FIFO queu stopped being refilled. ( I added loop and FR for bug tracking reasons) device.SetSelectedChannels(channelsinblock, queuesize, blocksize, Mcs.Usb.SampleSizeNet.SampleSize16Unsigned, channelsinblock); cleanupObj = onCleanup(@()mea_cleanup(device)); device.StartDacq() ..... while(1) % endless loop

for i = 0 :channels-1                              

    number = device.ChannelBlock_AvailFrames(i); %Checks the amount of sample ( frames)available in the buffer of channel i

    if (number >= blocksize) && (framesready(i+1)==0)
        framesready(i+1)=1;
        [frames, ~] = device.ChannelBlock_ReadFramesUI16(i, blocksize); %Read frame of samples
        data(i+1,:)=double(frames);
    end
    if framesready==ones(channels,1); % if not all channels have an amount of frames >= blocksize repeat the cycle
        %loop
        %figure;imshow(FR);
        return
    end

end
FR=[FR framesready];
loop=loop+1;
if loop>1000
    loop
    figure;imshow(FR);
    number
    return
end

end end

[armwal]

Hi Gerco,

this is an indication that the the queue fills up to its max size of 100000 and then the data acquisition stops with an error. Is channels equal to channelsinblock? If not, some channels aren't retrieved from the queue, so the queue fills up for these channels and then stops once it has reached its max size. Make sure that you call ChannelBlock_ReadFramesUI16 for all channelsinblock.

Another possibility is a performance issue, the code might simply not run fast enough to retrieve data from the queue. Some ideas for performance improvements:

• Use SetSelectedData instead of SetSelectedChannels. This allows you to retrieve the data from all channels at once instead of one channel after the other and might help with the performance.
• Use a separate thread for data acquisition that just pulls the data from the queue and makes sure that the queue never gets full. This thread could place the data in a processing queue where it gets handled by another thread. All of our software uses this workflow internally, so this is definitely the recommended way to go, although unfortunately not that easy to implement in Matlab.

I hope this helps.

Armin

[gchassink]

solved it

When I use the loop counter is that for the first 3 blocks of 25000 samples per channel, it loops 300-400 times, meaning that the script is about 300 times faster than the data recorded by the device. So I think in that respect I am on the safe side. However separate threading is always a good Idea, also for later when more other tasks are asked from the application.

But indeed the real problem was in the channels not equal to channelsinblock 60 vs 64. I’ve split the variable in ChannelsUsed and ChannelsAvailable for future use. The difference is apparently not relevant in 3.2 since it has channelsinblock of 64 while my program assumes 60

Thanks again!

From: armwal @.> Sent: donderdag 21 april 2022 13:12 To: multichannelsystems/McsUsbNet_Examples @.> Cc: Hassink, Gerco (UT-TNW) @.>; Author @.> Subject: Re: [multichannelsystems/McsUsbNet_Examples] FIFO queue seems not to be supplemented in 5.1.24 vs 3.2.45 (Issue #7)

Hi Gerco,

this is an indication that the the queue fills up to its max size of 100000 and then the data acquisition stops with an error. Is channels equal to channelsinblock? If not, some channels aren't retrieved from the queue, so the queue fills up for these channels and then stops once it has reached its max size. Make sure that you call ChannelBlock_ReadFramesUI16 for all channelsinblock.

Another possibility is a performance issue, the code might simply not run fast enough to retrieve data from the queue. Some ideas for performance improvements:

• Use SetSelectedData instead of SetSelectedChannels. This allows you to retrieve the data from all channels at once instead of one channel after the other and might help with the performance.
• Use a separate thread for data acquisition that just pulls the data from the queue and makes sure that the queue never gets full. This thread could place the data in a processing queue where it gets handled by another thread. All of our software uses this workflow internally, so this is definitely the recommended way to go, although unfortunately not that easy to implement in Matlab.

I hope this helps.

Armin

— Reply to this email directly, view it on GitHubhttps://github.com/multichannelsystems/McsUsbNet_Examples/issues/7#issuecomment-1105070871, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYVFLOPMNRSH7HMAYB74X3DVGEZX7ANCNFSM5T6UDRUA. You are receiving this because you authored the thread.Message ID: @.**@.>>

[armwal]

Glad to hear that it worked!