If you really want to do the proving, you need to test the (psuedo) program below in real life

I don't understand... didn't I do this with my sweep test already? I cracked the formula days ago, and have been testing sweeping, changing frequencies without downloading, various combinations of sample points and clock settings, etc, ever since.

Anyone know what is happening on the device side when a freq resetting request is received?

Again, you can see clearly in my sweep software and .png that there is no pausing or glitch when changing just the frequency. There is a newer version of it back at the original post.

you have extended the possibility of stable sweep at lower frequency, great work!

Thanks. Yes, glitch-free sweeping from 1 - 40kHz is relatively easy to do. The difficulties begin above that frequency.

i can see different usage of data type in your code, i suspect rounding off error

Yes, I looked at your version of my code - and it's certainly incorrect. I use all Doubles until sending data to the device - Long does not work properly. The formula is VERY susceptible to if/when you drop decimals or round. It's been tested for much more than just a day.

Trust me - I've spent MANY hours on this. I looked at every doubler crossover frequency, e.g. 48282.13, 24414.07, 16272.05, 12207.04, 9765.626, etc., as well as every frequency that caused a change in logic behavior, such as 195312.5 - mentioned in my original post - and many others. I KNOW how the device decodes extremely well.

I would be happy if you can prove me wrong in general

I'm not really sure if it's worth my time to try to prove you wrong - I think it would have to be the other way round since I am ahead in this area

My software is already at the point of reverse calculating any parameter, such as the next actual frequency from a change in the number of points plus the last set frequency.

My sweep software starts by downloading 2500 points to the device. Why 2500? Because I already know, after tests, that for the most accurate frequency-only sweeping, it's best to start with the sample length of the highest multiple frequency (40kHz = 2500pts) - not 4000. I then reverse calculate what 'fake' frequency to give the Hantek in order to generate each desired frequency in the sweep with the same 2500 points (such as 12.205Hz in order to generate 10Hz).

When I ask your code to calculate the actual output frequency for 100Hz, it says the output frequency will be exactly 100Hz (which is wrong). But, even if that were correct, how exactly is that possible? As mentioned, the DAC clock rate is normally created by dividing 200MHz by the SetFrequency. This is easily provable - and supported by the specs - which list a programmable DAC clock rate of the device of 2kHz - 200MHz. So how does the 3X25 generate 1Hz - 2kHz?

When I ask my software to calculate what frequency the Hantek will ACTUALLY output when asked to do 100Hz - it returns 100.008801Hz - which is EXACTLY what my frequency counter reports - and my math and logic support.

Another example: when you set the device and download a 10kHz frequency, the Hantek uses 2500 points. What is the new frequency when you then only download 100 points? And what happens to the Sync line when you do that?

Anyway, these are the things I've been working on over the last couple of weeks, and I'm sorry you've been so busy

and missed my post of 4 days ago (which onlooker read, tested and extrapolated from), but this nut was cracked already

So I'm not sure it's really worth it for me to continue pouring time into something I've already done, if you know what I mean - and I've already moved on to other problems to solve - such as an alternate scheme for the Sync Out problem that I'm working on - and more complex sweep logic - and... well, you understand.

My formula seems to work perfectly in every task I use it for, and it's easy to reverse calculate any parameter. If you need any clarification or help with anything just let me know.