Last modified: 2024-11-30 14:42:50
< 2024-11-28 2024-11-30 >I remember reading in "Harrison Decoded" that the Burgess Clock B is a non-linear or "Van der Pol" oscillator. Which I think means it doesn't stabilise at a single point in period/amplitude space, but instead stabilises in a ring.
More on https://en.wikipedia.org/wiki/Van_der_Pol_oscillator
Could that be the reason for the hunting amplitude problem? Maybe it's not a problem at all, it's just the nature of the thing?
Actually I think this is wrong. The "ring" is in position/velocity space, not period/amplitude space.
But, for that matter, I could add a position/velocity plot and see what it looks like!
This might look smoother if we applied the quadratic interpolation to the position data.
And would be good to see what it looks like while the amplitude is ramping up/down, I think we'd expect to see several laps closing in on the steady state loop.
And I think maybe the pointy ends is because of the thing where the values are basically offset sideways by 2 degrees when the balance wheel is swinging in the reverse direction.
I'll try to fix that and see if it looks smoother. That might also explain the lumpiness in the velocity & acceleration plots. Meh, doesn't seem to help.
Ramping up looks like this:
Lots of laps, converging on the stable state.
Next up is solving the problem with the back corner of the inactive pallet's resting surface contacting the escape wheel at large amplitudes.
I've increased the angle of the gap from 90 deg. to 140 deg., in CAD this looks like it allows for about +/- 170 deg. rotation, or 340 deg. total amplitude.
Broadly the same as before, but at least now it can go to higher ampltiudes without hitting the wheel.
So now to take out the amplitude coefficient, I want to try making the resting surface not concentric with the shaft.
If the balance wheel ticks faster in the long arcs then I need to slow it down in the long arcs, which means I need to make the escape wheel push it further and slow its return, so I think the radius needs to decrease as amplitude increases, like on H4.
I'll start by making the radius change as extreme as I can manage, hopefully that will invert the amplitude-period relationship, and then we can go somewhere in between to make it isochronous??
It starts out with a constant radius for the first ~40 degrees of the resting surface, then slowly decreases from 4.5mm radius to 3mm radius. So that means the effect only applies for amplitudes greater than about 170 degrees, which I think should be fine.
This skips teeth if the amplitude is too high, because 0.45mm from the balance shaft is not enough to prevent the escape wheel from slipping past.
Fortunately it seems to run at a lower amplitude than before, so in a stable state it is not skipping teeth.
So I think that looks like an improvement! After the initial ramp it stayed within about 1.25ms. It looks like we could do with a more extreme version of the same effect though, because it still looks like period goes down as amplitude goes up.
And another of same, but after I fixed the amplitude vs period chart (see below):
This is within 1.2ms over 55 minutes.
Interestingly, although the overall variation is better due to the new resting surface shape, the period-amplitude relationship seems worse than it did yesterday.
Look at this for example, from yesterday:
Ignoring the initial ramp, the period stays within 1.75ms over 45 minutes. That is worse overall, but just look at how tight the period-amplitude relationship is!
What has got worse since then?
You'd think the first 3 of those would make it better if anything, not worse.
Temperature and pressure monitoring
I'm going to get a Raspberry Pi hooked up to this BMP180 and see how to read data off it.
I have:
The Pi 3 has heatsinks on it, the Pi 4 does not.
The original Pi has no WiFi but mine has a USB wifi dongle in it. I'll just go with the Pi 4.
There's an rpi-imager in apt, apparently this is the best way to install Raspbian now.
Quite good, it lets you easily configured username, password, SSH keys, and WiFi.
It took 15 minutes to write the image to the microSD card, which is unmarked. Is this a bad microSD card or is that normal?
To find the Pi:
sudo nmap -p 22 --open -sV 192.168.1.0/24
Hmm, can't find it.
The power light is going out a few seconds after plugging it in.
Switched to a different power supply, now the light is staying on but still can't find it with nmap.
I put the microSD card back in the PC and the root partition won't mount, I think the microSD card is just bad. I only have one other spare, and I have written "bad?" on it in pen. It is labelled as SanDisk but I think it is a fake. I'll try that one.
This time it only took 8 minutes to write the image.
And now I've found it on the network with nmap!
Looking at https://tutorials-raspberrypi.com/raspberry-pi-and-i2c-air-pressure-sensor-bmp180/
I used raspi-config to enable the I2C bus, and then i2cdetect -y 1 scans the bus. Now
I need to wire it up. I'm using female-to-female jumper cables.
Great success, i2cdetect found it on the first try.
And then the example code is in https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code
Lol, no it isn't. Deprecated, classic.
Replaced with a "Blinka" Python library that you're meant to install with pip, except of course pip doesn't want to do it because of "system-managed python libraries", and apt doesn't have the library.
There is example code on https://www.pibits.net/code/raspberry-pi-bmp180-sensor.php but it is for Python2 instead of Python3.
OK, porting it to Python3 was easy, and now it is working:
jes@raspberrypi:~/bmp180 $ ./bmp180.py
Altitude : 29.23 m
Pressure : 1009.74 hPa
Temperature in Celsius : 23.83 C
Temperature in Fahrenheit : 74.89 F
That temperature seems a bit on the warm side, it is not really that warm here. Maybe just the electroncis are warm.
I have a loop running in screen logging temperature and pressure to a CSV, so that I can
potentially compare it with recorded clock data in the future.
The SHT85 has arrived and it is absolutely tiny. Probably I will solder wires directly to the pins and put a 3d-printed holder on it.
I found this pic online describing the pinout:
And the eBay listing I bought says "Supply voltage range from 2.15 to 5.5V", so it is fine with either 3.3v or 5v.
I think there is a bit of an error in here!
If we don't have an equal number of period samples and amplitude samples (e.g. we get the odd spurious amplitude sample), then the x/y coordinates end up not actually lining up properly.
So you get the most recent period sample plotted against an amplitude sample 10 steps behind.
I need to make it add a sample for the most recent period and the most recent amplitude, every time either one of them changes.
One good part is this means we get twice as many points on the amplitude-period chart, because we get 4 per cycle: 2 each for the amplitude peaks, and 2 each for the zero-crossings.
Means I now need to average over 142 data points for the period-amplitude chart, but only 74 for the period and amplitude ones individually. Hmm. I've made it just double the window size in the averaging code, that'll do.
Actually this is still no good. If we are getting spurious amplitude values then the averaging window will no longer line up with the escape wheel rotation.
So maybe I just keep track of what was the maximum balance wheel extent, and only update the amplitude and period data at the zero crossings?
Looks like the period/amplitude plot is much closer to following repeated tracks now, instead of drifting over time. So that should be a good improvement. But all of my previous averaged period/amplitude plots are somewhat suspect.
I've had another look at this. I think it is definitely to do with the rotation of the winding drum shaft.
Here's a non-averaged trace:
Note I started messing with it around t=1550s.
The distance between repeating cycles is about 455 seconds, which is within the margin of error for half a revolution of the winding drum shaft.
But why half! What happens twice per revolution?
The ratcheting drum has 2 click springs engaged at any one time... could it be to do with that? High amplitude when the click springs are horizontal and low when they're vertical, or something?
The ratcheting drum is pretty tight though, doesn't feel like it has enough play in it to have any effect.
I tried removing the balance weights, and it keeps skipping teeth, even at low-ish amplitudes (like 230 degrees). Why is it more prone to skipping teeth without the balance weights on? I don't see why that would make any difference.
Update: it's because when the balance is moving faster, the escape wheel moves faster while giving the impulse, so it has more momentum at the time of landing on the resting face, which makes it easier for it to skip over.
OK, well I want balance weights anyway to make it run slowly, so I'll just put them back.