I just ordered a DPOX180H, and noticed those weird plots radiolistener was showing:
But 5 GS/s looks crazy even if they used equivalent time sampling, so I'm not sure if I decoded it properly...
Very interesting! I decided to download some of the .wav data shared here. I'm no professional but I have a crazy idea about what's going on.
If you plot the .wav files in e.g. Python (try
plt.plot(np.fromfile("foo.wav", dtype=np.uint16))), you will see that the noise seems to be an exact offset of 256 counts, up or down. See my attachment for an example.
In fact, it seems that
bits 8:15 tend to flip too early. For example, here's an ascending sequence:
julia> string.([5323, 5631, 5428], base=2, pad=16)
3-element Vector{String}:
"0001010011001011"
"0001010111111111" # <-- bit 8 flipped before it was supposed to!
"0001010100110100"
where we can see that if we didn't flip bit 8 preemptively, it would've been a reasonable value. Similarly, a descending sequence:
julia> string.([10249, 9986, 10230], base=2, pad=16)
3-element Vector{String}:
"0010100000001001"
"0010011100000010" # <-- bits 8, 9, 10, 11 flipped too early!
"0010011111110110"
Hmm! My guess is that actually, somehow they are only
measuring eight bits at a time of the uint16, starting at the least significant byte, and so there is a sort of race-condition where they check the lower byte, then the signal transitions to flip some bits in the upper byte, and then they check the upper byte. As a result you have a uint16 that is 256 too high or too low, depending on if the signal was increasing or decreasing at the time.
Is this a known trick? Maybe this is something that's happening in the FPGA? Or maybe they are using 8-bit ADCs and doing some clever switching?
Once my scope arrives I'll test and see if the same happens. If so I'll email FNIRSI, but I'm sure they already know about this. Maybe this is why they don't release info on the file format, and why they laser etch the ADC model....
In any case, for the purposes of data analysis on a signal much slower than your sample rate, this is probably trivial to fix in post—just scan along the data, and any time the upper byte increments, check if the lower byte is bigger than the lower byte of the next sample. If it is, decrement the upper byte. And same for the reverse.