2025-02-02

Last modified: 2025-02-02 19:55:23

Clock

So I'm putting the small escape wheel back on. This time I am taking the wobble out of it by putting fibre washers between the escape wheel and the boss, and then I can tighten the screws more to squash the fibre washers down. Will be interesting to see if this reduces the "hunting amplitude" effect.

It is working, changes from before are just that the escape wheel is maybe trued up better now, and the pallets are smaller.

This does mean the drop is larger so we're wasting more energy, but also the slowing torque from the friction is reduced.

We were at about 270 deg. amplitude before, only 220 deg. now, so this looks to be worse. There are confounding factors from the alignment of the remontoire gears etc. though.

I've wound it all the way and set it going at about 4pm.

I did have the idea that clockwatcher could auto-tare once it sees it's in a steady state.

The clockwatcher got disconnected part way through. I should work out if this is happening because the USB device is disconnecting or because the data is getting out of sync in some way and the go program rejects it.

There's nothing in dmesg about the device going away or coming back.

And the timestamp on /dev/ttyACM0 is 30th of December. This suggests the issue is with the go program?

2025/02/02 15:56:27 Timestamp overflow detected! Count: 1
panic: runtime error: index out of range [-1]

goroutine 33 [running]:
receiver.(*DataRecorder).writeToDatabase(0x4000192070?)
        /home/jes/clockwatcher/receiver/data.go:263 +0x2c4
receiver.(*DataRecorder).AddReading(0x4000192070, {0x400019bd44?, 0x0?, 0x0?}, 0x5?)
        /home/jes/clockwatcher/receiver/data.go:104 +0xc8
receiver.(*Server).broadcastMessages(0x4000192000)
        /home/jes/clockwatcher/receiver/server.go:128 +0x40c
created by receiver.(*Server).Start in goroutine 1
        /home/jes/clockwatcher/receiver/server.go:102 +0x184
exit status 2

OK, so it was my fault all along. Should be fixed now.