Some useful tweaks to the frequency standard and power supply
The FY6900 is a very versatile while relatively low-cost function generator. It has two independent signal sources each with a plethora of output waveforms and it also provides a frequency counter facility. The version I bought was specified to 60MHz and the cost was sub GBP100. It has a somewhat clunky user interface with a single-entry knob for settings but this can be supplemented with a USB PC graphical interface. While not the most sexy of instruments I have grown to appreciate it as a really useful cost effective addition to my electronics workshop.
While working on a clock related project, I had the feeling that the FY6900 displayed frequency did not necessarily accurately match other sources. As the unit does not have an input for an external frequency standard this made cross checking analysis difficult. Download the PDF below to read my notes on fitting an external reference input socket and also upgrading the 10MHz internal reference.
Of late I have been going round in circles on a project to keep our local church clock roughly on time. I say roughly as my idea of timekeeping does not accord with the aspirations of the village residents. Quote ‘ I only need to know when it is the time to go inside for a brew’ / ‘knock off for the day’ / ‘get my skates on or I will be late for work’ etc. I was thinking sub seconds and they were thinking a minute or so as being perfectly adequate. The exception is at 11am on the 11th of November when it has to be exact.
That as it may be, the project is moving along. The first problem was what to measure on the clock to reference the time adjustment. The pendulum (1.25s rate) is clearly the easiest choice and a sensor beam being broken by the pendulum swing will solve this problem. The slight problem is that the sensor will not necessarily ‘switch’ at the same time when being approached from the two directions of the pendulum swing. My Arduino skills might struggle to come up with some code to discriminate this so I reverted to simple CMOS logic. An ICM7555 acts as a monostable that has a period greater than one swing. This is triggered by the falling edge of the swing pulse derived from a simple differentiator network. The monostable extended period pulse is then gated with the incoming pulse using a CD4001 Quad NOR to always give me half the pulse rate regardless of the swing direction. That probably makes no sense at all so here is my back of an envelope waveform diagram and circuitry.
The circuit has turned out quite useful for other applications. I also refined it to have a CD4024 ripple counter fed from the output at E. This allowed extended logging periods to be achieved. I also utilised the unused gates on the CD4001 to provide an isolating buffer on the input signal. This meant the differentiating network would always see the same drive signal regardless of the incoming waveform and its source impedance.
Progress indeed. I now had a pulse train representing the clock beat period. All I had to do was measure the time taken between pulses and I could compare and adjust the pendulum rate.
Having got a reliable 2.5s pulse it was time to reverted to an Ardiuno UNO to measure the period. With some help from a friend we ran a sketch using millis to record the time between pulses. This minimalist sketch did not seem all that repeatable. I also did some tests with Frequency.h sketch code from the PJRC website (very useful source) and had similar poor results. I was using a FY6900 as my reference 1.25Hz signal and to get a 1.25Hz reading I had to offset the FY6900 quite a way from nominal. What to believe?
In a bid to get a known good reference I powered up my Arduino GTU-7 GPS module and measured the 1 second output pulse using both of the above sketches and the results were not much closer to the truth. I tried an Arduino MEGA instead of the UNO and got a different set of inaccurate results
This led me to think that the UNO and the MEGA must be the cause. Looking at these two boards, both have a 16MHz crystal which I (foolishly) believed was the processor reference and therefore could not be that much off frequency. Totally wrong. The crystal is for the USB interface, not the processor. Instead the processor has a basic 16MHz resonator – not a crystal. I got out the magnifying glass and discovered this piece of surface mounted wizardry. Low and behold if I put my finger on the resonator to warm it up, off it went into dodgy stability land. It was pretty awful. I could make my readings whatever I wanted them to be just by timing how long my finger was in contact with the surface mount resonator package. Chocolate fire guard indeed.
What to do ?
I downloaded the ATmega258P datasheet and found that I could replace the resonator with a crystal. This looked complicated with references to fusible links and reprogramming of the processor all of which made me twitch. The processor had been running on a wobbly 16MHz source so why not a less wobbly one?
Rather than hack the UNO board, I eased the processor out of its socket and bent pins 8 (ground),9 (xtal) and 10 (xtal) out horizontally and plugged the processor back into its socket. Using a three pin socket pushed onto the pins as a mounting, I assembled the crystal across pins 9 and 10 and two shunt capacitors (approx 33pF) to the ground pin. The crystal came from RS Components (#8149440) and was a 30ppm spec. This socket mounted lash up was then pushed into place on the floating process legs – very healthy, no damage done to the processor or the board. Here is the ugly mess.
Switched on. It worked.
Suddenly all my test source readings took on a very stable repeatability and the readings were very close to what I expected. The GPS referenced 1s pulse was reading 0.999936 and my SY9600 was reading 0.999958. It looked like my new crystal reference must be slightly off frequency but a tweak of the shunt capacitor values will fix this. I think the SY9600 has a 10MHz TCXO so it should be good but I think I tend to believe the GPS pulse as being more accurately delivering a 1Hz rate.
The experts will tell me I should be adjusting the fusible links but I am inclined to stick with what I have got, it is working.
The result is I now have an ability to measure the pendulum rate and from this I can derive an advance and retard flag.
I am currently designing the front end circuitry as shown above into a PCB ‘shield’ to plug into the UNO. This will take the sensor input and give a slow or fast command pin output. More on this and general progress to follow.
Update (30/9/2024)
I changed the two crystal oscillator shunt capacitors to be a 22pFSMD in parallel with 1p8 caps when using the RS crystal as mentioned. Below is a suitable layout for the crystal and shunt caps. There are positions for two caps on each leg of the crystal. 15pF in parallel with 6.8pF would also work. I checked the frequency was close using a GPS derived 1pps signal feeding pin 8 on the UNO while running the frequency.h demo sketch.
The board can be connected using the mounting holes or it can be cropped and the residual pcb tracks used as direct connections using pins 10 and 9 both of which are bent out from the IC body. Pin 8 was left plugged into the IC socket and bridged and soldered across with a wire clipping to the crystal board. The crystal mounts on the rear. The board is so simple you could mill it on single sided copper clad with a burr in a Dremel.
The picture below shows the first milled version in place on the UNO. The layout above is a later tweaked version to better match the pcb pads to pins 9 and 10.
Links to similar or related post are listed below : –
I had received a clock to repair and wasn’t sure if the mainspring was correctly dimensioned. I remembered that William Smith had described a gauge for checking this in his book ‘Clockmaking & Modelmaking Tools and Techniques’ (pages 21 – 26). This gauging tool consists of two profiled plates that slide together to overlay the end view into the clock barrel. Bill’s design used 1/16″ brass plate but it struck me that a 3D printed version would be equally suitable and much quicker and easier to make.
In use the gauge is overlaid on the end view of the barrel as shown below. The point A is aligned with the outer diameter of the barrel arbor. The top plate is then slide until the inside edge of the barrel wall is aligned with point B. For a correctly chosen mainspring it should align with the corners C and D.
I sketched Bill’s design in Fusion 360 and extruded the two component parts to have a 2mm thickness before printing on my Qidi X Smart 3 in PLA. The two parts are fastened together to be a sliding fit with two M4 screws. The threads for these are modelled in the 3D print. A handling knob can be added in a similar fashion.
Here is my PLA printed equivalent.
The STL print files can be downloaded on the link below. It is not something that you will use every day but just a ‘useful to have when needed’ item. “Better to have it and not need it, than need it and not have it” (Jimmy Diresta).
One of my X Smart 3 printers suddenly started to show an error message that the temperature sensor on the hot end was not rising correctly.
I emailed Qidi support and talked with Annie. She said it was a hot end failure and would get a replacement hot end assembly shipped to me. This was on Monday. The replacement hot end arrived last night (Wednesday) and I fitted it this morning. Printer fixed and back up and running. I was staggered by the service.
Qidi might not be as well recognised as Bambu Labs but Qidi’s Technical Support certainly know how to look after their customers. Lovely machines and superb back up.
Links to similar or related post are listed below : –
As ever this started off with a need and from the need came some learning. In my experience such needs are always welcome for the resulting learning benefit but inevitably lead to a few hours of frustration.
We have a small Jacuzzi spa at our home in France. It has two cartridge filters that are screw mounted into the sump of the spa. The threads on the cartridges are plastic and are loosely defined as 2” SAE spec. (I think SAE is a fine pitch thread (?) and as the filter threads are around 5mm thread to thread pitch, they don’t seem to me to be fine pitch).
When filling the spa from empty, Jacuzzi recommended that the filters are removed and the filler hosepipe nozzle is wedged into the outer vacated of the two filter holes. The nozzle has to be jammed in place by packing a cloth or sponge around it. Filling via the filter mounting ensures the spa fills from the bottom up with minimal potential for an airlock in the pipework.
The problem with this is that the filler hose tends to have a mind of its own and when your back is turned it will liberate itself from the filter hole and whiplash round like a demented cobra and give you an unexpected bath.
After one such soaking I resolved to stop this happening. What was needed was an adapter plug to fit into the “2” SAE” socket that would accept a standard hose push fit connector. This would hopefully keep the rampant serpent retained during the filling process.
I opted to use a standard commercial male hose connector for the interface to the filler hosepipe. These have a DIN Pipe thread specification (G26.441 x 1.814 mm). This left me with the need to model the 2” SAE from scratch which on inspection appeared to take the form of a pseudo Acme profile but with an asymmetric thread to valley ratio.
Having failed to find anything helpful on the Internet I set about creating a custom thread in Fusion 360. New experience ….
Here is the resulting adapter.
The attached ZIP file below has the full write up, the STL file and the source Fusion file.