2023-09-22

Last modified: 2023-09-22 21:44:43

• Captive lever escapement
• Blued pivot steel
• Next steps
• Ceiling
• Bangle.js commute timer
• Timegrapher

Captive lever escapement

I realise I am essentially speed-running the development of the Swiss lever escapement here, but this is a simple modification to my lever escapement that would give it the behaviour of "locking", and decoupling the escape wheel from the balance wheel.

But we still don't need banking pins or the safety guard pin thing.

We modify the tooth form to add a locking face (like on the Roskopf pin pallet escapement), but we let the pallet pin bank against the wheel, instead of adding a banking pin for the lever, and we keep the roller pin captive inside a slot in the lever so that it can't fall out.

Here's a quick sketch:

So let's try and CAD this. We can use the current frame and balance wheel, just need a new lever and escape wheel.

I'm finding it hard to find a configuration that is actually going to work. So, back to the simulator...

I came up with this escape wheel:

Down to only 14 teeth instead of 20 now. Not necessarily a problem, but means we need 10/7 the ratio in the train.

The lever is the same as before for now, which makes it quicker to test, but if it looks promising I can make a lever with more space relieved in the "slot", to allow the balance wheel to swing freely while the escapement is locked.

The thickness holding the tooth to the wheel is only 3mm, which turns into 0.5mm at 1/6 of the size, not sure if that is going to be strong enough.

First impression is pretty good. It seems to run nice and regular, as long as it has enough weight to run. But how is the isochronicity?

Doubling the weight from 4 to 8 nuts has almost no effect on the tick rate. Wow! Doubling it from (interpolated) 7 to 14 increases tick rate by about 10%. Not as good. So I really need to be plotting torque-vs-rate curves instead of just taking 2 datapoints.

It doesn't seem to be getting drawn into the "lock" as hard as I had expected. Does the locking angle need to be greater? Or does the slot in the lever need to allow more free motion? Let's try and make an improved lever.

Not very optimised at all, it is much wider than necessary and could maybe do with being longer, but let's see how it behaves. I also wonder if it would help to put the pin on the lever and the slot in the balance wheel?

I made a slow-motion video showing how it works: https://www.youtube.com/watch?v=RHnJ65SRCAg

The video very clearly shows the issue with the locking behaviour.

Blued pivot steel

I've ordered a selection of blued pivot steel for making pins etc. out of, because it's not expensive and more convenient than turning down the silver steel rod. Ordered from Cousins UK, I spent £40 and am getting a tiny amount of metal, this is maybe not great value.

Next steps

• review the video showing how the lever escapement works, and fix the tooth profile
• make a metal prototype of a lever escapement, and with a separate driving barrel as well?
• make a 3d-printed prototype of the case, allowing winding and setting
• make a 3d-printed prototype of anything driven by a coiled spring
• find a way to do timegraphing without counting video frames

Ceiling

Good progress:

But ran out of screws now, ugh. Only a tiny bit more to go.

Bangle.js commute timer

I'll copy over the json log to commute.json and try and work out why the delta time is so wrong. It must be something to do with the formatting, not the variable, because display_delta_secs is used to find the ETA and that looks fine.

OK, one dodgy bit is it is called display_delta_secs but the ETA has a comment saying it is in milliseconds, and no conversion factor is applied.

Errr... or maybe the fact that the ETA is meant to be in milliseconds is why it looks so believable. It might not actually be right, it might just be taking our whacked-up delta time and dividing it by 1000 so it has less of an effect...

I found that in updateTiming(), time_to_target was in ms but elapsed was in seconds, which means elapsed_at_target is not in any particular unit. This might be the cause of the problem.

I've fixed it on the watch and in ~/commute-timer, and I've updated the commute.json file. Great success.

Timegrapher

So it turns out I already have tg-timer installed, lol, not sure what project that is from. But it doesn't work, it doesn't hear anything from the microphone. It seems to be using JACK, so I'll quickly try and work out how to test/configure the microphone in JACK...

Meh, can't figure it.