General > General Technical Chat
Review: Hantek DDS 3X25. Anyone own one?
<< < (52/108) > >>
marmad:

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

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.


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

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.


--- Quote ---you have extended the possibility of stable sweep at lower frequency, great work!
--- End quote ---

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


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

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.


--- Quote ---I would be happy if you can prove me wrong in general
--- End quote ---

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 :D  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  :o 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.
Mechatrommer:
Another test in a fresh new day with a good sleep:
- My previous report is bogus (the attachment is deleted), its bug in my test program, so sorry for misinformation, now its corrected.
- New report is attached (zip) for test freq 1KHz - 1MHz step 100Hz, i've change name from "onlooker method" to "my method" to avoid conspiracy
- code for both estimation function are provided in code.txt. my marmad's function has been changed due to wrong data type implementation (late night job)
- code for my test setup/loop is in tester.txt, but i dont include all class needed such as CsvClass and awg Hantek325 Class. by request.

conclusion from test data set: refer to dPts, dPr column (d stand for delta or deviation, blank means zero)
both estimation function are 100% accurate at low frequency ~100KHz
for all frequency, marmad's accurately estimate "period" where mine is not due to "period otimization" included
even though periods are correct, marmad's records highest point length deviation at frequency 990100Hz (deviate at 19 points). its confirmed from his original DDSClockSource.zip and the translated version by me. other (larger than 1) deviations are also scattered mostly on higher frequency set > 100KHz


--- Quote from: marmad on August 06, 2011, 03:33:44 am ---
--- Quote ---Anyone know what is happening on the device side when a freq resetting request is received?
--- End quote ---
Again, you can see clearly in my sweep software and .png that there is no pausing or glitch when changing just the frequency. 

--- End quote ---
we cannot be sure since we (or me only?) used cheapo dso to measure, there's blind time during trigger. but looking at your owon picture, the sweep is pretty promising. about the square, i believe its marmad's implementation of square wave, since i havent seen like that in my square wave. even at highest frequency of his sweep, zooming in reveals slight rise time abberation.

edit: i just noticed, DDSClockv2.exe can accurately estimate point length (esp at 990100Hz), but in DDSClockSource.zip is not. so they are not the same code/compilation.
onlooker:
marmad,

I am not here to fight for credits, instead, if I can, I would just like to promote more openness. Indeed, your code motivated me to start experimenting and make "educated" guesses, since I am too laze to start from scratch and do the coding, but interested enough when something can be play with and, at the same time, that something does not have enough openness (and is also easy enough for "guess" making).

If you have published your code or steps before my 1st post, I probably would not be even interested to spend any time on posting, instead of, just waiting a little longer for the matured code from all, including yours. I guess I am lucky in that I did not spend more than several hours so far and not coded a single line yet.

A related quastion is: did you or can you publish your SweepTest code? Or Could you add to your Sweeping code  two more fields one for the data length and the other for the number of periods in the data. Your code then can setup the data points accordingly.

some more comments:

1). I had just realized I had a obvious mistake in an eqn. in my earlier post, the step c) should be just another version of my item 2.2). 

2). In my last post, one can as well do DDSDownload(waveform,4) with just 0,v,0-v in the data. On this point, I feel we are still not understanding each other.

You said you can sweep 1-40kHz glichless and using 2500 pts. May I ask how many periods (of a given "frequcecy") have you placed in this 2500 pts waveform? One?

Did you try placing 2 or more periods  (upto >1000) from the same "frequency" and waveform into your 2500 pts data set. If you put 2 periods there,  the sweeping range will be 2-80kHz. Right?  Then, you see glitchs? 

Along a similar line,  what one can also try or maybe you have already tried is to use short data length when calling DDSDownload() assuming, for example, 1000 periods placed in 4000 data points is indeed equivalent to 1 period placed in 4 data points. In this setting, one can do one DDSSetFreq() call, then do multiple DDSDownload() calls. With properly selected freqencies, all the data sets can be short (say < 50 pts), and one may be able to do a proper sweeping with a range of one decade.

ADD: "frequency" was used to qualify the word 'period' to avoid misunderstanding. But, it is actually a confusing term on itself. Ok, "frequency" (in double quotas) here is the one in data points domain, not the usual one in the time domain.
Mechatrommer:

--- Quote from: onlooker on August 06, 2011, 08:16:55 am ---Along a similar line,  what one can also try or maybe you have already tried is to use short data length when calling DDSDownload() assuming, for example, 1000 periods placed in 4000 data points is indeed equivalent to 1 period placed in 4 data points. In this setting, one can do one DDSSetFreq() call, then do multiple DDSDownload() calls. With properly selected freqencies, all the data sets can be short (say < 50 pts), and one may be able to do a proper sweeping with a range of one decade.

--- End quote ---
this is the essence of my "stable synch" concept, and hence faster and more efficient sweep (and signal generation as a whole) at high frequency. let say DDSSetFrequency returns 4011 data point, 100 period. i will just round off to integer to get the "stable synch length"... myLength = Int(4011 / 100) = 40 data point, and period become 1. if we try to fit 100 period of a wave, say sine in 4011 data points and send to hantek, what we get is nonsynchronized signal.

this is the reason why i've included period optimization in "modified onlooker" function, to watch out for multiple integer (exact integer division of data point /period) and reduce the data points to (data points / period and period become 1) to efficiently send signal to hardware during DDSDownload call. (opps did i just say "modified onlooker" function?, it should be "my" function right? :D :P)
onlooker:
Mecha,

Thanks for the explaination. I had naver gotten to understand the essence of this "stable sync" vs non-"stable sync" thing. I thought it was a software bug, instead of, a hardware limitation(?). At 1st when I saw the discussion, I did not have the device. After I got the device, the problem was already remidied and the method was published. Then, I just took what is there and did a few tests to see the phenomeno and the remidied results, and afterwards, placed the device aside until a few days ago.

What you were saying was that N_use must be an integer multiple of Pr to avoid any problem. Interesting. From a harware point of view, do you have an explaination as to why placing 100 periods in 4011 points should cause problems. I always thought any data set both starting and "ending" at phase zero should work without needing any complicated exoatic hardware in its design. Then I am not an expert on hardware either.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod