Conversation
Fix FIFO reset sequence. Still not perfect (I get 6-7 broken samples at 1 MSamples/s) but at least the 4 kb FIFO is cleared. Also fix some minor compiler warnings.
Use raw data (otherwise python is too slow add high-speed to keep up and this leads to an infinite loop). Choose more sensible sample rate. Always flash firmware (to get single channel support).
|
I'm testing with a 1MHz triangle wave, sampled at 24Msps with a single channel, expecting no sudden changes in value. I'm using a single libusb transfer with 8 iso packet descriptors, each of 3072 bytes. With multiple attempts, I see in about 80% of the cases a jump after first 4 bytes, and in 80% of the cases a jump after first 4096 bytes. With 12Msps, the same thing, about 60% of the time. With 4Msps, only on byte 4, 20% of the time. Hope that helps. |
|
actually, let me test it once more, I only merged your particular commit. I'll try again with the .hex from your repo. |
|
yup, with your .ihx it's the same, 60% of the time at 12Msps I see an abrupt change after 4kB. |
|
FTR, this is how the data from the scope looks like, I'm capturing first 12k samples or so, at 24Msps, the wave is a 125kHz triangle 10Vpp. You can see the two points where there's a sudden shift in values. |
|
@jhoenicke will you merge this branch? I think a better reset sequence is better than unsubmitted perfect sequence :) |
2 participants
This fixes the FIFO reset sequence to ensure that FIFO is cleared when starting a new capture. This should avoid sending 2048 - 4096 bytes from the last capture run.
@zagrodzki: Since you have some test setup, can you check that this is working as expected? For me it works.