Last modified: 2024-12-02 22:51:56
< 2024-12-01 2024-12-03 >First thing is wind the clock back up and run it without making any changes, start it off around 250 degrees amplitude.
Averaged:
Non-averaged:
So averaging over an escape wheel rotation, it stayed within about 0.8 milliseconds for almost an hour! Good.
We still have the "hunting amplitude" thing, but only in a range of about 4 degrees. We still have the amplitude trending upwards over the course of the hour.
In the non-averaged data, the amplitude is hunting with a period of aboput 175 seconds, which is a rotation of the escape wheel.
In the averaged data, the amplitude is hunting with a period of about 450 seconds. The margin of error on locating the peaks is still too wide. I can't tell whether this is the same hunting amplitude period as before, or whether it is 4.75/4.0 times as long, i.e. whether it is synced with the period of the clock or whether it is environmental.
Catching the remontoire arm is quite violent, I should put a fly on it so that it is slowed down, and make the fly able to keep spinning for a bit after the arm stops, either by friction fit or a ratchet. Make sure the fly has the majority of the moment of inertia, and then you get to dump the majority of the energy into slowing down the fly rather than slamming the arm to a dead stop.
I realised that I have charts from 2024-11-26 that can tell me whether the amplitude hunting is synced with the clock or not:
2.1 second period:
4.0 second period:
And it looks like the hunting amplitude period is about twice as long when the period of the clock is twice as long, so that settles it. It is synced to the ticking of the clock somehow.
And, further, it is synced to the clock in some way that the remontoire is not able to properly shield the escapement from.
With the remontoire and 4.75-second period, the hunting amplitude varies by about 4 degrees, whereas with the 4.0-second period and no remontoire, the hunting amplitude varied by about 5 degrees, so no substantial difference.
Could it be parasitic oscillations from the drive weight falling to different heights??
That could explain why it kind of looks synced to the rotation of the ratcheting drum.
Looking at the 4.75-second period...
If we say the length of the pendulum is maybe 50mm at t=0s, and each revolution of the
ratcheting drum lets out 125mm of string and takes 4.75 * 37 * 43/7 = 1080 seconds.
Then at what points does the length of the string give us a pendulum with a period that is some harmonic of 4.75 seconds?
Obvious harmonics are at 4.75/2, 4.75/3, 4.75/4, etc.
Then from some spreadsheet maths (harmonic => period => pendulum length => implied time of clock running), I think we should have harmonics at 44 seconds, 127 seconds, 242 seconds, 411 seconds, 670 seconds, 1101 seconds, 1895 seconds. Which doesn't really seem to line up with what we see. What we see has a much more constant interval between peaks.
The moving average code recalculates the entire array of moving averages on every update, I should make it just insert the new datapoint whenever one is added.
Done.
I want to switch to running the data logging on the Raspberry Pi now, along with monitoring the environmental data.
I still want to be able to conveniently work on the code though, probably just hook up Cursor via SSH?
For the time being the BMP180 hooked up with jumper wires will be OK:
Helpfully, all 3 of the BMP180, BMP390, and SHT85 connect by I2C. So it might be enough for me to get some kind of connector that allows "stacking" (like banana plugs) and not have to make any custom PCB? Or alternatively I make a PCB that just runs out the I2C pins to 3+ identical sockets.
I2C addresses are:
So no collisions, just wiring them together should work.
For some reason the GPD MicroPC power supply doesn't work on the Pi? How can the Pi be drawing more power than the GPD? I've ordered an official Raspberry Pi one.
An eBay search for "M8 sensor connector" comes up with promising results, like this sort of thing:
Panel-mount sockets are available, so I could easily put 3 or 4 of these on the case for the Pi, wired to the I2C pins of the GPIO header, and then put a cable on each sensor.
This listing has lots of variations: https://www.ebay.co.uk/itm/256562285091
It has panel mount, cable mount, 3 pin, 4 pin, and comes pre-wired, although it doesn't say how much wire you get.
Quite expensive for what they are. To get 4x female panel mount connectors and 4x male right-angle connectors I have spent just over £50.
Long-term, I could maybe do with a basic UPS for the Pi (just a good USB power bank?), and something that will periodically sync all the data with some Internet-accessible server.
For now I have the web interface running on the Pi, and I want to make it read the BMP180 and plot its data on the web page.
So, first, a go program to read the sensor.
OK, great success, I now have temperature and pressure displayed on the web UI.
This is what it looked like when I briefly and gently touched the sensor with my finger:
I'll let the clock run and see if there look to be any correlations with temperature or pressure.
No obvious correlation here. That's good probably? Seems unlikely though. Maybe just needs monitoring for longer.
I've combined the "computed" and "averaged" charts into just one section, with a checkbox to enable/disable the averaging.
Also the position/velocity plot looks like this:
The position reversing and the velocity reversing don't happen at the same place!
I think this is because the velocity is averaged over 10 points or so. So I should either lose the averaging on velocity and start interpolating position instead, or I should make the averaging window for velocity centre on the datapoint it is inserting.
I made it centre on the datapoint it is inserting, that has fixed it:
I experimented with doing the quadratic interpolation but it doesn't look like it's obviously an improvement.
I made it only make Plotly redraw if the data has actually changed, and wait 100ms between redraws, instead of trying to redraw every 100ms, so that if it is lagging it doesn't stack up and get worse.
I considered switching to uPlot because I thought it was much more performant than Plotly, but I'm not really convinced. I left it alone.
https://markwhen.com/ - this was on HN today! How convenient, I've been thinking of making a timeline of interesting inventions/discoveries/creations, I'll give it a go.
Meh, it doesn't look like this is really what I want.
It makes an interactive editable page, zooms into the wrong level, and doesn't turn URLs into links.
I will get Cursor to write me some custom tooling.
OK, I persisted for a bit. It doesn't have a way to enter dates before 0 AD.
Why is the spot for 1769 visually to the right of the end of 1772?
I got Cursor to write custom tooling. https://incoherency.co.uk/timeline/