General > General Technical Chat
Review: Hantek DDS 3X25. Anyone own one?
tinhead:
--- Quote from: marmad on August 01, 2011, 02:17:41 pm ---That is even 10 times slower than the rated low-bandwidth speed of USB 1.1 (why can't these companies implement USB 2.0???). That points out the big problem with not having a lookup table built-in to the device.
--- End quote ---
maybe it is time to write new firmware for the STM32.
Btw, the DSO8060 does have complette DDS 3x25 on board, did someone tried this software with 8060 too already?
marmad:
--- Quote ---maybe it is time to write new firmware for the STM32.
--- End quote ---
That would be nice :)
--- Quote ---did someone tried this software with 8060 too already?
--- End quote ---
I don't know about that, but I did take a look inside the DLL for the 8060 to see if I could find any undocumented commands I might use with the 3X25, and I noticed that they only implemented 4 functions for the AWG: DDSSetFrequency, DDSDownload, DDSSetPowerOn, and DDSSetSyncOut (which isn't implemented on the 3X25).
marmad:
After much data-sifting, I think I've finally cracked the internal logic and formula for exactly how the DDS-3X25 sets the DAC clock and decides on the number of points for any given frequency. I've written a little piece of software to demonstrate.
Normally, to generate a certain frequency, you first send the desired frequency to the DDS-3X25 with the DDSSetFrequency command - which causes the MCU to set the DAC clock rate, and returns to you the number of points you should use to create the waveform and the number of cycles of the wave within that given number of points (since, as discussed previously, the DDS-3X25 is missing a built-in lookup table of simple waveforms). Once you create the waveform sample, you download it to the device with the DDSDownload command, specifying again the number of points, which in turn sets the actual frequency generated by the device (DAC clock rate / (points / cycles)).
But once you do the above, you can actually change frequencies again by just altering one or the other settings, but up until now, I've been unable to figure out exactly how to do this predictably.
To test the software, just hook the Output to the Count In (no 50ohm termination required):
1) Enter a number in 'Current frequency'
2) Click 'Calculate data based on current frequency' - this will cause the software to calculate the real frequency, number of points, and DAC clock rate the 3X25 will use.
3) Click 'Set frequency and download points' to send the data to the device and see the actual output in the Frequency Counter box.
4) Then play around with either changing only the frequency or the number of points, clicking the associated 'Calculate' button first before sending to the device, then downloading only that new frequency or new number of points to see the actual change.
To test the precision of the calculation, enter 195312.49 as 'Current Frequency' and calculate. Note the real frequency and number of points, then download to the device. Then unlock and enter 195312.5 as 'Current Frequency' and calculate. You'll notice that the real frequency produced by the device is exactly the same, but the number of points which will be requested by the Hantek has changed, based on it's internal logic.
Notes:
1) On my Hantek, it appears that the DAC clock divider drops one bit on frequencies < 60kHz (@Mecha - this has nothing to do with the number of points returned by DDSSetFrequency - it's internal to the FPGA) or else my Count In is drifting on those frequencies. In any case, I've included a setting (Drop Bit < 60kHz) to include that in the calculation. It's off by default, but the software starts with a nice slow test frequency of 100Hz already entered and calculated. Download it to the device and check the Counter box; test by clicking the Drop Bit On and re-calculate to see if it is more precise.
2) Some combinations of frequency and points will cause some drifting of the frequency - this is just inherent in the design of the hardware.
3) Some changes of frequency and/or points will not change the output frequency because they are not altering the DAC clock rate; for example, if you start with a frequency > 48828.125Hz then the DAC clock will be set to full speed (200MHz) - so trying to change the frequency by only giving the device another frequency > 48828.125Hz won't work since the clock is already running at full speed. Instead, change the frequency < 48828.126Hz or change the number of points.
4) I'd appreciate feedback from anyone who tries this - just let me know if it's working correctly on your device or not - and if the Drop Bit was needed for precision. Thanks!
Edit: Added another small piece of software that tests running an (almost) logarithmic sweep (using the technique detailed above) by just changing the DAC clock rate - not the points - so no delay, no pauses, and perhaps no glitches. I'm currently without a scope, so I can't look at the output, but perhaps Mecha or someone else can check what it looks like when it changes frequency. Just start, chose a waveform, and click 'Run Sweep' (use 'Repeat Sweep' for continuous).
SweepTest.zip (73.7 kB - downloaded 2 times.)
Edit2: Refined the sweep test - it now does an almost perfect audio logarithmic sweep - from 10Hz to 40kHz - by reverse calculating dividers to set the DAC clock to in order to generate the desired output frequency, but without downloading points (which causes delays and glitches). It gets as close as possible given the hardware limitations, and only misses a couple of frequencies. Hopefully it will be glitch free.
DDSClock.zip (15.64 kB - downloaded 5 times.)
Edit3: Fixed a bug I just noticed in my clock test software which overwrote the original number of points (internally) when downloading just the frequency - causing subsequent changes to just the frequency being calculated incorrectly. I think (err... hope ;) ) it's bug-free now.
SweepTest2.zip (74.33 kB - downloaded 5 times.)
Edit4: Attached working... um, I think ;) SweepTestv3. Also, accuracy of clock formula hack confirmed by another 3X25 user - so here it is:
To get the DAC clock rate for any frequency:
HantekClock = 200000000
divisor = Int((HantekClock / freq) / 4096) * 2
If divisor = 0 Then divisor = 1
DACclock = HantekClock / divisor
'To get the number of points and periods which the Hantek will return for a given frequency - and the real frequency the device will output (not what you give it):
periods = 1
points = DACclock / freq
If points < 2000 Then periods = Fix(4096 / points )
points = Fix(periods * points )
realFrequency = DACclock / (points / periods)
'The following code corrects the drop bit error (if your device has it) in the software output, and gives me an exact frequency count at any setting. The code is done this way because sometimes the real frequency calculated is > 59988Hz, while the original frequency requested was below:
If realFrequency < 59988.003 And periods = 1 Then realFrequency = HantekClock / (points * divisor - 1)
If realFrequency >= 59988.003 Then realFrequency = HantekClock / (points * divisor)
onlooker:
I have been following this thread for a while and bought the device based on the recommendations here. I really appreciate all the info provided here.
But, I also feel the info here is a little scattered, often implied or side tracked by off topics. For this, I am here trying to summarize my understanding of what is said/known in terms of software control of the device with some of my takes (Please correct).
1). The two functions that really matter are
DDSSetFrequency(F_user/*IN*/,N_use_a/*OUT*/,Pr/*OUT*/);
and
DDSDownload(N_use_b/*IN*/);
The two are independent in that N_use (and Pr) from DDSSetFrequency() do not have to be used in any way in DDSDownload.
In fact, the key role of DDSSetFrequency() is to set the clock frequency (F_clock), while the role of DDSDownload() is to a). upload a waveform to the device and b) tell it the data length (N_use). There are no builtin waveforms of any sort.
At all times, the device is just repeatedly running through the N_use data points with N_use and waveform set by the last call to DDSDownload(). Each data point consumes one clock tic, where the clock frequency (F_clock) is set by the last call to DDSSetFrequency().
2). Now, what do we know about the calculation part of DDSSetFrequency():
--Terminologies:
F_user -- (real) frequency the user wants. MAX 100MHz.
N_full -- (int) MAX num of data points of the device(=4096).
F_clock -- (real) clock frequency. MAX 200MHz.
N_use -- (int) DDSSetFreq suggested num of data points to use.
Pr -- (int) DDSSetFreq suggested num of periods in N_use pts.
F_out -- (real) effective frequency the device is outputing.
--The calculations done in DDSSetFrequency():
2.1). First, based solely on F_user, DDSSetFrequency() sets F_clock (detail later). F_clock can only take its value from the set below,
200MHz, and (100/n) MHz for n=1 to something > 50k
2.2). Then, the set of equations
F_out * N_use = F_clock * Pr
and,
2000(?)>Pr>=1
are solved in a special set of steps (note, the equation set is under-defined).
2.3). Solving steps
a). Pr = INT(N_full * F_user / F_clock);
b). N_use = INT(Pr * F_clock / F_user);
c) F_out = F_user * N_use / Pr;
F_out = F_clock*Pr /N_use; //should be just a rewrite of 2.2)
2.4). Error analysis:
(F_out - F_user) / F_user ~< 1 / N_use
3). The F_clock setting part of DDSSetFrequency().
The value must be 200MHz, or one of (100/n) MHz for n=1 to something > 50k as mentioned.
Apparently, the F_clock shift-down was driven by the requirment of fitting at least one period in 4096 data points, and I actually expect to see the transition value of F_use being where 1 period of F_use fits exactly 4096(5) data points for the current F_clock. I did not yet do a detailed check, other than just listed the empirical transition locations from DDSClockv2.exe
OUT="F_clock" IN="F_user"
200MHz >48,829Hz
100MHz (24,415Hz<->48,828Hz)
50MHz (16,277Hz<->24,414Hz)
(100/3)MHz (12,208Hz<->16,278Hz)
25MHz ( 9,766Hz<->12,207Hz)
20MHz ( 8,139Hz<-> 9,765Hz)
(100/6)MHz ( 6,976Hz<-> 8,138Hz)
(100/7)MHz ( 6,104Hz<-> 6,975Hz)
(100/8)MHz ( 5,426Hz<-> 6,103Hz)
(100/9)MHz ( 4,883Hz<-> 5,425Hz)
10MHz ( 4,439Hz<-> 4,882Hz)
.........
(100/n)MHz ~ (44,390/nHz<->44,390/(n+1)Hz)
.........
(100/100) =1MHz ( 484Hz<-> 488Hz)
(100/1000) =100kHz ( 48.78Hz<-> 48.82HZ)
(100/10000)=10kHz (4.88233Hz<->4.88281HZ)
4). Implications to frenquency sweeping:
4.1). If one can accept <20% frenquency step as good enough, one can use F_clock (<)2k to 20MHz for sweeping with the same waveform. This means a sweeping range of 4 decades.
4.2). A single waveform can have 1 to (>)1000 periods. That is for a single waveform one can either sweep from 1Hz to 10kHz, or from 1kHz to 10MHz or any 4 decades range in between. For example, to sweep (1k to 10MHz), one needs to
a). call DDSDownload() to upload a waveform of 1000 periods.
b). seqentially calling DDSSetFrequency(F_use), with a set of F_use's that each sets a new F_clock according to the table above.
4.3). if 20% steping is too big, one can always use a small number of waveforms with different offsets to fill the gap.
marmad:
--- Quote --- 4.1). If one can accept <20% frenquency step as good enough, one can use F_clock (<)2k to 20MHz for sweeping with the same waveform. This means a sweeping range of 4 decades.
--- End quote ---
No, this is incorrect.
I'd be happy to answer all questions and post all of the data for how I calculate the DAC clock/frequency/points/periods exactly like the device - if someone else would post:
a) whether my clock test software correctly calculates the frequencies and periods on their 3X25. I believe it does, but I've gotten no confirmation or contradiction here - which is frustrating.
b) whether my sweep test software correctly performs a glitch-free sweep.
Even though my test software has been downloaded >12 times, I have gotten zero responses about it - which does not encourage continued effort here.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version