Problems with first x samples

[KimBP]

In openhantek I now have a stable SW trigger implementation. openhantek provides your latest mod_fw_01.ihex

Unfortunately I see some instability in the first samples in the received dataset. My guess is that it somehow relates to samples from previous run and that the problem relates to the driver. (circular buffer with left overs or something)

Unfortunately I have been able to test it only with the test square wave from the device it self. A triangle or sinus signal would maybe give some more

I can't tell exactly how many samples are fluctuating, but with a samplerate of 1M/s and timebase of 500us I can position my trigger at pos 22% (= 1.1ms) and get a fully stable image to the right of the trigger.

Two screenshots provided.

[jhoenicke]

I never found out, how to clear the fifo and start/stop sampling cleanly.

The fifo is 4 * 1kB for isochronous transfer and 4*512 byte for bulk transfer. So maybe the easiest way is to just ignore the first 4 kB.

[KimBP]

Since I'm using mod_fw_01 firmware I guess only the 4x512 bytes are of interest.
Why do you mention 4x512. Are each channel using one fifo (of 512 bytes) for new samples, while the other fifo (for each channel) is being transmitted?
Are you thus also saying that the two first fifo's per channel are unreliable because they may contain data from another sample sequence (10240 samples/channel)?
And isn't this what the fixfiforeset (mentioned in #40) is supposed to handle?

Is this problem taken care of in your custom driver implementation?

[jhoenicke]

I added the fixfiforeset, when I saw in the reference manual, that the bytes written to the fiforeset register didn't conform the spec. I'm not sure if it fixes anything.

The chip uses quad-buffering and it really helps to get transfers more reliable, as USB interrupt transfers and frame borders can delay bulk transfers. With isochronous you also need quad-buffering, since three buffers are send per frame.

I think the samples you see are from the previous run, but if you want you can try to check it. Do you have different signal generators to check?

I never bothered to fix this problem, since I only used it for long-term recording and analysis and then I just ignored the first few wrong samples. So it is not fixed in the custom driver.

[jhoenicke]

I finally found out how to empty the FIFO:
jhoenicke@a538ba5

Is it possible for you to use the custom firmware? It would be possible but not so easy to mod the original firmware to do the same (not so easy, because the new code is a bit larger and one cannot just patch the function in place).

There are still seven wrong samples at the beginning. I'm not sure where they come from, but it seems to be in the analog circuit or the ADC.

[KimBP]

Sounds great.
I would love to give it a try but must admit I have never looked into the fx2lib API, so don't know how it is compared to the original firmware and thus can't tell how it will fit into the openhantek model.

Unless somebody else volunteers I will give it a try, but based on my current schedule I can't promise any deadlines.

[jhoenicke]

As long as OpenHantek doesn't use the eeprom feature (command A2), it should run with the custom firmware. The original driver uses the eeprom to store calibration information but the format is undocumented.

[zagrodzki]

FWIW, I've documented the reverse-engineered calibration protocol here:
https://github.com/zagrodzki/goscope/blob/master/docs/calibration.txt
But that "calibration" sucks, it only sets the 0 point, doesn't even adjust scale.