| General > General Technical Chat |
| Review: Hantek DDS 3X25. Anyone own one? |
| << < (55/108) > >> |
| torch:
--- Quote from: marmad on August 06, 2011, 05:45:44 pm ---Hmm... I'm pretty sure Mecha's software did the exact same sine at that frequency. --- End quote --- 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:
--- Quote from: torch on August 06, 2011, 10:11:09 pm ---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: --- End quote --- 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 :P), if you choose the right phase. --- Quote from: onlooker on August 06, 2011, 11:56:05 am ---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. --- End quote --- 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". --- Quote from: marmad on August 06, 2011, 03:39:43 pm ---but PLEASE stop publishing these comparison charts - it feels like some contest - and a bit strange. --- End quote --- 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:
--- Quote ---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? --- End quote --- 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 :P 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |