Review: Hantek DDS 3X25. Anyone own one?

[marmad]

for few frequencies it work!

Great! Thanks! That's all I was looking for. I already logged many many frequency tests on my own machine and it worked well every time; I just needed some confirmation from other devices.

you havent share it yet. thats only between you two.

Sorry, I posted the formula I used here along with a changed version of SweepTest (minus the ActiveX problem) - then realized it made more sense back with the original DDSClock and SweepTest software in the previous post.  But I will put the source code here as well - it's just a modified version of the demo software that came with the 3X25 (uncommented too    ...sorry!).

pls check whether this is your app mistake generating square wave or artifact from the hardware

Oh, that is just a leftover from my previous non-glitch attempts.  When you use DDSSetSingleWave to stop output - the voltage output stops exactly at the end of the waveform - if it's the crossover (like a natural sine wave), that makes 0 volts out - if it's the top of the square wave, that makes ~ +1.75V.  So I adjusted the waveform creation of the square to start and stop on 0 volts for testing - so it's just slightly offset - my fault - easy to correct.

[Mechatrommer]

i've made testing to both "modified" onlooker and marmad report in attached zip file, 2 csv 1 code.txt file. it doesnt took me long to come up with my conclusion, maybe its just my system got different "number round off" method compared to marmad's. dPts & dPr column show how much calculation deviates from value returned by DDSSetFrequency, blank means spot on (0 deviation).

ps: the previous code will be deleted to avoid messy thread, the code is in the zip file.
edit: report file deleted for INVALID (BOGUS) report.

[marmad]

i've made testing to both "modified" onlooker and marmad report in attached zip file, 2 csv 1 code.txt file.

I don't understand how you generated these numbers, but they're not correctly related to my formula - unless of course, every 3X25 is slightly different with the output frequencies - which would seem odd     If you like, I can publish numbers later - I can't get to it at the moment  - but I have been testing this for almost 7 days now.

But what is "onlooker"?  Oh, you mean the poster?  But his code was clearly incorrect:   n = INT( 100MHz  /  ( F_user*4096) )  is provably wrong - as is the idea of sweeping from 1kHz to 10MHz with < 20% frequency step.

[Mechatrommer]

ok ok, "modified onlooker" i prefer because his quote gave me idea for the code earlier that i tested and improved this whole night. i can see different usage of data type in your code, i suspect rounding off error, will try next "night". now is almost dawn, time to sleep

[onlooker]

marmad,

I would be happy if you can prove me wrong in general (of course, typos  or small details or any other non-conceptual level omitions  do not count).  If you really want to do the proving, you need to test the (psuedo) program below in real life and say: "the necessory tweaks are done and the idea can't work for sure".  I will accept that I too can be wrong (just kidding ).

In fact, I have already outlined the idea in my early post, but I guess detials do help sometimes to make sure we are talking about the samething.


a). create a waveform of 4000 data points that repeat the sequence (0, v, 0, -v) 1000 times (v is the peak voltage value of your choice).

b). call DDSDownload(waveform, 4000);

c). loop calling DDSSetFrequency(F_user) with F_user stepping through the freq sequence listed in your post: 
 10 20 30 40 50 60 70 80 90 100 200 300 400 500 606 701 800 909 1000 2000 3076 4000 5000 6666 8000 10000 20002 40008

d). tweak these steps to make it glich-less.

About:

i saw this picture. it happened for square wave while sweeping at 10-50 Hz.

I just realised it was answered already, but still it rised interesting quastions about the hardware limitations. Anyone know what is happening on the device side when a freq resetting request is received? Will the device pause? For how long? Will it interupt the data point set stepping (say, start over again from point 0) or will it wait until a full set of data points are through?

[marmad]

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.

[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

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. 

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]

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.

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? )

[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.

[torch]

Ok, I the little guys were still asleep so I downloaded the DDS3X25Ctl_0_9_1 version from page 16, hooked the output to the count in and to my Rigol and started to play. Unfortunately, they didn't stay asleep long, so I had limited time to play, but this is what I noted:

The count often differs from the generated frequency slightly. EG: 1.00000kHz produced 1.00016khz with the occasional flicker to 1.00017kHz. The Rigol displays 1.000kHz, but flickers betweeen .992 to 1.004. 3MHz produces 3.03030MHz. (Rigol displays 3.030MHz) But 4MHz produces 4.00000MHz and the Rigol agrees.

The Rigol does not agree with the voltage setting. EG: 3.5v p-p is measured as 3.6v p-p.

There is an error in setting the RMS amplitude function: Parameter input of 1.72 produced a "Human Error" message informing me that "RMS amplitude must be between 0.035355V and 3.5355V"

I think a digit gets lost when setting the sweep step. Set to 100.0Hz, it seems to climb by 1000.0Hz instead, according to the Sweep Data log.

There is a slight distortion during the transition between certain frequencies, but nothing like the earlier screenshots posted, and not detectable between some frequencies.

"Reset All" cause an error message then program crash. Couldn't catch the error message -- something not found, I think.

I tried entering "48828.125" for frequency 1, but it displayed 97.6562 kHz and output 48.8400kHz.

Ok, now I have a 2 year old d`rivi`ng his truck on my k24eyboar988d.

[marmad]

we cannot be sure since we (or me only?) used cheapo dso to measure, there's blind time during trigger.

Yes, I can see with my 10Mpt scope that the entire sweep is glitch-free.

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.

This has been answered once already, but here is the square wave sweep with 2 fixed bits - see attached .png.

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.

Yes, when you asked me to release the code for the DDSClock, I tried to quickly clean it up a little bit for you (it was a mess) - and I see now that a small piece was accidentally deleted - I didn't have time for re-testing the cleaned code.  But if you understood the logic - or had compared it to my code posted yesterday - you would have seen the error immediately:
yesterday: lpLength = Fix(lpPeriod * lpLength)
source:    dLength = Fix(dLength)
I will make sure I release ONLY bug-free, test-resistant source in the future. 

You didn't respond to any of my thoughts or answer any of my questions from my previous post, and your code still gives me (for my device) the wrong answer for such things as, for example, actual output frequency at 1kHz.  I haven't heard from any other user that says my DDSClockv2 delivers incorrect answers about anything.  But if you want to duplicate/improve/develop previous work with newer versions of code, fine, but PLEASE stop publishing these comparison charts - it feels like some contest - and a bit strange.  Thanks.

Ok, I the little guys were still asleep so I downloaded the DDS3X25Ctl_0_9_1 version from page 16, hooked the output to the count in and to my Rigol and started to play. Unfortunately, they didn't stay asleep long, so I had limited time to play, but this is what I noted:
The count often differs from the generated frequency slightly. EG: 1.00000kHz produced 1.00016khz with the occasional flicker to 1.00017kHz. The Rigol displays 1.000kHz, but flickers betweeen .992 to 1.004. 3MHz produces 3.03030MHz. (Rigol displays 3.030MHz) But 4MHz produces 4.00000MHz and the Rigol agrees.

Thanks very much, Torch. I will go through your bug-list later. Please note however, that the DDS3X25 doesn't always provide perfect frequencies - if you ask for 1.000kHz, you actually get 1.00016kHz due to the clocking formula and the logic of the device.  I have been trying to explain this to Mecha to no avail. The frequency counter on the Hantek is more accurate than the one in the Rigol - because it's easier to count frequencies if that's all you're doing with a hardware input.  The Hantek corresponds perfectly with my Fluke counter - trust the count on the 3X25 - not the Rigol.

Edit:  Whoops - forgot the CSV files... 

Edit:  Got rid of the stupid stuff... 

[marmad]

I am not here to fight for credits, instead, if I can, I would just like to promote more openness.

Absolutely, I thought that's what it was about as well.

A related quastion is: did you or can you publish your SweepTest code?

The Sweep Test is a big mishmash of un-commented, altered code from the DDSControl software I published even earlier - I think it is 175k with 2k being actually used  So it's worthless to try to sift through all of it.  But I can publish the relevant sections if you'd like - but I need some time to extract it and make it bullet-proof - once bitten twice shy    But given the info in the thread, it's really easy to make your own.

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?

Yes.

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.

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?

Ok, yes, sorry, I wasn't getting your meaning until now.... yes, it's totally possible to increase the number of periods and get glitch-free sweeping above >50kHz in this fashion - it's just that the Sync Output would not correspond.

I will do a sweep like that for you now. 

Edit:  @onlooker - So here is a .png of a small portion of glitch-free log sweep from 1kHz to 800kHz using extra periods to increase the DAC frequency - it works fine, but notice the Sync out is locked to total periods, not frequency.   But in this regard, your original proposal was technically correct - and I was wrong - I stand corrected 

Edit2:  @onlooker - Here it is finally - now that I finally understand what was asked of me  - a portion of your requested sweep with 4000 points and 1000 periods - it sweeps from 100kHz to 50MHz glitch-free, but with the Sync locked to periods.  The .png shows the changeover from 100kHz to 200kHz.

[torch]

Just stole a few minutes while SWMBO had the boys outside. It won't accept 1,000,000 but rounds up to 100.000MHz if you enter 999,999. The really cool thing is that it actually displays a fairly decent sine wave at that frequency -- something that didn't happen with the Mechatrommer software! The display on the Rigol is a bit jittery when set to real time aquisition but pretty stable when averaged 16x. The counter shows "0.00000 Hz" at that frequency, but the Rigol measures it to be 100.0MHz with the odd flicker to 99.9MHz.

[marmad]

It won't accept 1,000,000 but rounds up to 100.000MHz if you enter 999,999.

He,he... yeah - sorry - that's just lazy coding to avoid dealing with > 8 digit numbers 

The really cool thing is that it actually displays a fairly decent sine wave at that frequency -- something that didn't happen with the Mechatrommer software!

Hmm... I'm pretty sure Mecha's software did the exact same sine at that frequency.

The counter shows "0.00000 Hz" at that frequency, but the Rigol measures it to be 100.0MHz with the odd flicker to 99.9MHz.

Yes the Hantek counter starts to craps out above 50MHz - I think the logic is sampling the input pin at master clock (200MHz) / 2.  Which would give it the Nyquist limit of 50MHz accuracy.

[onlooker]

marmad,

Thanks for checking it out. Hopefully, the device can be eventually hacked to be more useful for everyone.

The other thing is : instead of, using square waves to show sweeping to check for glichs, using sine waves could also be useful to see if the waves are really transitioning at zero voltage and zero phase crossings. For square wave, small changes in modulation factor are hard to see graphically.

[marmad]

The other thing is : instead of, using square waves to show sweeping to check for glichs, using sine waves could also be useful to see if the waves are really transitioning at zero voltage and zero phase crossings. For square wave, small changes in modulation factor are hard to see graphically.

True... I had it set to square waves from previous post.  I'll redo the 4000/1000 sweep right now with sine wave.  Well, actually, that will be only a 4 point sine - kind of a Empire state building shape instead.  I'll leave that .png and instead add one here with slightly less periods for a reasonable sine shape.

[marmad]

Here is a sweep from 10kHz to 5MHz, using total points of 4000 with 100 periods (i.e. 40 point sine wave shape).  First .png is start of sweep - output starts at 0v - sync starts at ~+3.5v. The second .png is a close-up of a transition.  You can actually count the points on the sine wave 

[onlooker]

madmad,

Very good and promising. Hopefully this will be held true to the highest frequency setting. I guess now I can sit back and wait for your software release with all other tweakes and hacks.

Thanks

[marmad]

Very good and promising. Hopefully this will be held true to the highest frequency setting. I guess now I can sit back and wait for your software release with all other tweakes and hacks.

Thanks onlooker.  I'm happy to release the source when I get it cleaned-up and commented a bit.  I'm a sloppy coder - old school and bad form

[torch]

Hmm... I'm pretty sure Mecha's software did the exact same sine at that frequency.

Ooops. Yes, you are right, it was square waves that got seriously un-square at high frequencies.

I am seeing a strange modulation that I don't understand:

[torch]

I should add that this only occurs following a sweep from a lower frequency up to a higher frequency, and varies in intensity depending on the frequencies -- most noticable above 75MHz final frequency.

But if I start from 99,999,999MHz and go to 99,999,999MHz, it doesn't happen. Then I get a stable output with no modulation:

[Mechatrommer]

But if I start from 99,999,999MHz and go to 99,999,999MHz, it doesn't happen. Then I get a stable output with no modulation:

if you input 71.0134e6, ie 71.0134MHz in hantektest.exe and press start, you'll see data points length and periods as follow:

data length: 4095
period: 1454
point/period: 2.816

if you do your own calculation to fit evenly 1454 periods of sine wave in 4095 data points, you'll get modulation in the picture you posted. if wave is sampled at near nyquist sampling frequency (~>2), without proper reconstruction (sincx) algorithm, you'll start to see the effect of aliasing.

for frequency 100MHz (or near it), its only 2 points for 1 wave cycle (2 points / period), so i've decided to choose one point at sine peak, and another one at sine bottom, and then they will keep repeating that nice sequence (peak-bottom) over and over. thats why you'll get better at near 100MHz. another word 2points / period is in harmonics or resonance with 100MHz sine (my term ), if you choose the right phase.

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.

yes N_use must be integer multiple of Pr to get in synched. from hardware point of view i'm not sure but i suspect the implementation of FPGA, maybe it cannot divide fractional and just round off to output "synch signal", but how exactly the hardware generate "synch" is still a mystery. things like "dajones" glitch and "leap year" effect mentioned long time ago still unexplained. if you try frequency of 0.5 > f > 1 in hantektest.exe, let say f = 0.86Hz, and show both "output" and "synch" signal on your scope, you'll see funny "synch signal".

but PLEASE stop publishing these comparison charts - it feels like some contest - and a bit strange.

i'm not competing, i'm only looking for a better formula and hope someone can help, if not then i will just shut up. you think i am?

[marmad]

i'm not competing, i'm only looking for a better formula and hope someone can help, if not then i will just shut up. you think i am?

Mechatrommer, if that's true, your methodology seems a little odd from my point of view.

I noticed that your Hantek software did not report the actual correct output frequency (e.g. input freq = 3.300000MHz; your software reports freq: 3.300000MHz, stable freq: 3.332592MHz; instead of correct = 3.300492MHz, stable freq: 3.333333MHz).

I wrote a post on July 23 detailing the formula for frequencies above > 48.828125kHz, and saying that I was working on the entire formula. On July 30 I released Control software that includes that formula - and returns the correct output frequency (stable or non-stable) for every frequency > 48.828125kHz.  I did not mention your incorrect formula, or release CSVs detailing your software vs mine.  I did, in fact, the opposite: I gave you credit in the post for being the one to come up with the idea and formula for making the sync out stable.

Then, on August 2, I posted software saying that I cracked the whole formula, asking for confirmation from another user. I had already tested my formula for a few days; not just one.  On August 5, 3 days after this, you have an idea for a formula and then start posting comparison spreadsheets, 5 hours later, of my one-week old, well-tested formula (incorrectly implemented by you!) vs your 5-hour old formula - posting that my formula isn't as accurate as yours!

My friend, that does not seem to me to be the cool way to go about supporting, appreciating, and building on other's work here.  If the situation was reversed, I would have just assumed you had the correct formula unless/until I saw data that proved otherwise. And then I would go about trying to improve it quietly, and then just release code with the fix - which is exactly what I did, as mentioned above, on July 30.  But perhaps thats just me.

[Mechatrommer]

ok ok! dont take it seriously pal. ok i admit my formula is incorrect. it was very sloppy! btw, i've spotted the bug in the code you gave that you said you've cleared things up but infact screwing things up cool man! now with the corrected formula, i dont have to post another report file, all i have to say is... your formula is perfect! only its miss at 550KHz (4000 vs 3999 points). errr, just skip that, the bottom line is... YOUR FORMULA IS PERFECT! no doubt about it! savvy? what next?

btw i dont know how you get the line "If calcWavePointNum < 2000 Then" i think thats the magic in your formula. and FWIW, the correction i made in you code is "calcWavePointNum = Fix(calcWavePointNum)" -> "calcWavePointNum = Fix(calcWavePointNum * periods)"... you know... GIGO thing.