Hi Johnny B G .
I thought this FY had died . All said and done. Great time waster
No one will get rid of the jitter until the c¥clone chip is replaced with a real Cyclone . Instead of the installed C¥clone . And also the bad design of the pcb between c¥clone & dac's.
I had quite a few tabs open on almost zero activity forum threads which I was in the process of setting them to give me an email notify alert before closing them when, after refreshing each page to check for any new replies, I spotted Trader's contribution to this rather moribund thread. Naturally, I viewed the youtube video which lead me to check out the Robert's Smorgasboard video both of which were irritating enough for me to pass comment on.
The irritation stems from the fact that they both lack experience of the product they're attempting to review, one of the reasons why I don't attempt to post any youtube vids in response to set the record straight - by the time I've gained a more thorough (not necessarilly complete) understanding of a T&M's quirks, the urge to contribute has been tempered by the realisation that doing so would be giving google yet more data than they've already gleaned from my internet activities thus far.
Trying to stop google from data mining the hell out of my existence is almost certainly a lost cause by now but I'm a man of principle, largely about the one relating to that truism "Knowledge is Power" of which google is a shining example - the less detail about my life that I'd be obliged to give to them in order just to 'put the record straight', the better.
Even signing up to contribute to the comments is a big no no, quite apart from the fact that my contribution would be drowned out by all the AOL responses and the downright misleading contributions - it would be a lost cause not worth the sacrifice of my privacy to google. Privacy is not so much a matter of 'having
something to hide so much as having
everything to hide, hence my contribution here to a more targeted audience where, for the most part, the misleading and AOL type responses are mercifully rare aberrations.
I'm glad I gave the 1202 a break from monitoring the 64Hz PWM gate drive pulses controlling the cooling fan that regulates the LPRO-101's base plate temperature to within +/- 0.2 deg C of the 36 deg setting in order to compare my FY6600's 60MHz sine wave output against Robert's Rigol traces otherwise I'd have been dissing his Rigol more than it was actually deserving of.
The only reason I
knew why my initially poor traces were down to the DSO and not the FY6600 was because I knew from past experience that they should have been a lot better and also that I had seen the 1202 get itself, in the dim and distant past, into a state of confusion (something that had been exclusively the prerogative of the operator in the days of CRO technology) leading to this result.
In this case, I knew it was merely a matter of giving the 1202 a chance to sort itself out by pressing the "Auto" button in the trigger panel. Using the "Default" button was an unnecessary 'icing on the cake' measure (but if in doubt, worth resorting to for 'good measure' in such cases since it's not an entirely 'Bad Thing'
).
It wasn't just the business of "DSO confusion" that irked me, it was also, for instance, the inept way he kept pressing the waveform button to cycle through the options when he should have been using the rotary encoder knob and pressing the OK button twice to jump straight back to the sine wave option along with missing the trick of long pressing the ok button prior to a power down in order to preserve the current settings (which is why I put up with the beeps since the resulting long beep confirms that I'd held it down long enough to store the settings).
If he'd taken more time to acquaint himself with the control feature set, he could not only have shortened the video, he could also have passed this useful knowledge on as as a 'Value Add' service to his viewers.
Moving on, I think the reason for my initial poor looking 60MHz trace is down to a minor timebase configuration bug (seemingly one common to the Rigol 'scope) which seems related to changing from seconds or milliseconds per division to the microseconds per division settings. Most likely unaddressed as a minor bug easily worked around by judicious use of the 'Auto' button and/or the 'default' button if required.
As I mentioned above, I'd been monitoring the 64Hz PWM signal in the thermal fan controller breadboard lashup I've been experimenting with to stabilise the LPRO's base plate temperature so I guess the adjustment from a 2ms to a 2ns per division setting must have invoked the timebase instability issue in this instance.
My earlier attempts to stabilise the rubidium oscillator (RFS) by tight base plate temperature control had been less than stellar due to undesired changes of temperature gradient from ambient temperature variations through insufficient insulation of the other five surfaces of the RFS for lack of space in my initial choice of enclosure. As a consequence, my modified FY6600 was used as a proxy for the RFS, allowing me to trim the frequency in calibrated 10μHz steps avoiding the need to try tweaking the RFS's trimpot, thus saving needless wear and tear.
The SDG2000X just wasn't up to this task in spite of having its own (unfortunately bi-directional) external 10MHz reference socket since its UI prevented such fine tuning control. It was therefore relegated to a supporting role as a plinth for the FY6600 as you can observe in the attached photo.
About a fortnight ago, I decided to correct this by enclosing all but the fan cooled heatsink in a 20mm layer of polystyrene foam and ditch the enclosure entirely until I could acquire or build a more suitable one. I figured that with enough insulation, an enclosure would become almost but not entirely, redundant (at least for the purposes of further thermal stability testing). As a result of this improvement (and a well padded out heli-pot connected to the C field adjustment interface pin), I've been able to remove the FY6600 out of the circuit, allowing the RFS to 'fly solo' as it were.
The results over the past week or so of testing now seem to have borne out my hypothesis regarding the lack of insulation. I think I've almost reached the limits of what tight thermal regulation can achieve (obviously a suitable enclosure will provide a final refinement) and it looks like I'm now seeing the effect of barometric pressure variations starting to make its presence known - the weather station is currently reporting a figure of 1016mBars (a slight drop from the 1017mBar peak of an hour or three ago). Over the past fortnight it had ranged from a low of 984 to a high of 1007 mBars, generally hovering within +/- 5mBar of a 1000mBar average for a large part of that time.
This is the hottest day so far this year in my part of the UK (early afternoon temperature reaching a high of 28.5 deg C (currently now a mere 25 deg at 17:30 BST (16:30 UTC) and I've closed the windows to my office come workshop to raise the room temperature to 30 deg or higher in order to test the RFS's performance against a wider temperature swing. The room is already at 27.6 deg from the 25 deg it had been just half an hour back when I shut the windows and I'm already starting to feel the heat.
I've been taking scope screenshots of the GPSDO and the RFS 10MHz sine wave traces with infinite persistence enabled to track the phase variations between them. I've been seeing phase shifts of less than 100ns per 24 hour period - the last, current run, allowing for the ever present 7ns pk-pk phase shifts in the GPS signal due to ionospheric disturbance and other system errors produced a shift of just 31ns over an observation interval of 19 hours and 40 minutes before starting the high room temperature test to check the limits of my temperature management of the RFS.
With the aid of a 2.5KW heater, I managed to zoom the room temperature right up to 33 deg C before switching it off - it had done its job, stressing my thermal control setup beyond its current limit which was now running the fan full bore without let up. It only managed to regain control when the temperature had dropped to 32 C - the heatsink had gotten up 36.6 C before settling back to the 36 deg set temperature. Even so, this temperature excursion had taken its toll on the frequency stability of the RFS as can be seen in the final two screenshots
I've attached a photograph of the RFS test setup, along with 9 screenshots depicting that aforementioned observation period. Whilst some may consider this an off-topic posting, it does have relevance in demonstrating how useful these cheap and easily modifiable AWGs can be when you upgrade the XO to an OCXO with an external 10MHz reference input socket by which to phase lock (or, in my case, injection lock) the OCXO to an atomic derived frequency standard. Besides, you can see my FY6600 sat on top of its Siglent made plinth in that picture.
In the foreground you see a breadboarded thermal regulator for the heatsink fan seen attached to the baseplate of the LPRO-101 encased in a 20mm thick polystyrene foam overcoat. Just to the left of the breadboard lash up can be seen a 5K Bournes heli-pot padded out with a pair of 22k resistors connecting to the 0v and 5v rails on the breadboard which is powered from a separate 12v wallwart which also supplies power to the fan, feeding the 5 and 3,3v regulators on the power adapter module plugged into the right hand end.
The RFS and breadboard grounds are tied together since the RFS is powered directly with a separate 19.5v laptop charging brick. The 10MHz half volt sine wave output from the RFS feeds CH2 of the SDS2000X Plus behind the RFS with the GPSDO (perched on top of the FY6600) feeding CH1. I'm triggering from the RFS on CH2. The SDS1202X-E that can be seen on the shelf above the 2000X+ is displaying the PWM pulses driving the gate of the FET which feeds the fan.
The two DMMs to the left are, from left to right, displaying the thermistor and 33k potential divider voltage going to a 5v cmos rr opamp (located beneath the blue electrolytic cap in the middle of the board) configured as a comparitor comparing the setpoint voltage from the black multiturn trimpot at the left hand end of the breadboard. The DIP to the right of the hidden opamp is a 32KHz clock oscillator and divider chain IC I'm using to get a stable 64Hz triangle wave for the PWM (using a schmitt trigger oscillator just didn't cut the mustard in this application).
The second Mestek DM91A is displaying the voltage difference in millivolts between the VFC monitor output from the GPSDO and a temperature stabilised 2v reference derived from its OCXO's reference voltage pin. This allows me to get the same 100μV resolution as a rather more expensive 5 digit bench voltmeter would provide. It might not match the absolute accuracy of a 5 digit bench DMM but it does provide the 100μV resolution needed to detect the smaller voltage variations that would otherwise remain hidden by using a 10000 counts DMM to directly measure the VFC. The absolute accuracy of the 2v reference is of little to no consequence in this application just as long as any offset error remains unchanged for reasonably long periods of time against ambient temperature changes. My experience over the past 12 months or so indicates that both this two volt reference and the DMM's internal reference have been very stable indeed.
The 'scope screenshots helpfully provide a real time date/time stamp in the bottom RH corner, a feature sadly lacking in the SDS1202X-E which would otherwise have done the job. It lacks any form of RTC or a built in webmin interface, limiting its usefulness in documenting the results from this method of data acquisition by screenshots for periods longer than an hour or two. The 1202 only uses 22W versus the 54W of the 2000X+ which has become a bit of an irritation after running it 24/7 for near on the past two weeks
The screenshots should be self explanatory so I'll quit whilst I'm ahead. This been a very long post already but, hopefully one of some interest to whoever may still be watching this topic thread.