Last modified: 2024-11-26 14:58:00
< 2024-11-25 2024-11-28 >This is now refactored into a bunch of separate files to make it easier to work with.
Also the moving averages now skip the first N points instead of averaging over a smaller window.
Temperature and pressure monitoring
How to do this?
Connecting anything up to the ESP32 is trouble, because the case doesn't have any room for it, and besides I don't want to have to do any more dead-bug-style soldering on it.
So I want a separate device to measure temperature and pressure, and I'll take humidity if easy as well.
Since I'm almost certainly going to be using a Raspberry Pi to run the data collection, I don't mind if the sensor only works with a Pi and not with a normal PC.
But most of the Pi temperature sensors only have 0.5 deg. C precision, I want much better than that.
I've ordered an "SHT85" sensor that supposedly has 0.1 deg. C precision, it looks like this:
I like that the board is necked down to provide a "heat break". In the past I have used a temperature sensor that slowly rose over time as the electronics heated up, so this should be an improvement. And probably I'll mount it on a wire to bring it some distance from the Raspberry Pi, so that that isn't heating it up either.
This device gives humidity and temperature over I2C. So I'll probably want a second device that gives barometric pressure.
And for pressure the best suggestion from ChatGPT was a "BMP390" which has precision down to 0.03 hPa. So I've ordered one of those.
I also found a BMP180 in the drawer which I could get hooked up today just to make a start.
I think the encoder backend will send temperature, pressure, etc. readings periodically, and the UI will use the most recent value wherever it needs it (e.g. adding new period/amplitude data points).
Then we add a plot of period vs temperature, period vs pressure, etc.
I tried to sort out the escape wheel depthing, and I think I got it pretty precise, but it is still doing the thing where it sometimes skips teeth.
You can see the big drop in amplitude every ~70 seconds. The reason it is more frequent than every 78 seconds is because of the skipped teeth.
I'm going to try to measure the distance between the balance shaft and the escape wheel teeth at each pallet.
I couldn't work out how to get any sort of measuring tool in there, but from looking at the gap between the tooth tip and the metal shaft as the tooth passes, it looks like the lower pallet is about 1mm further away!
I think I've straightened up the balance shaft a bit. I've also readjusted the balance spring so that it is taking the weight of the balance.
I tared the encoder UI at the centre position, and then loaded the drive string and manually rotated the balance wheel back and forth, noting the angle at which the top and bottom pallet escape, and then adjusted them to match.
I have them at +/- 40 degrees now, which I think is too low, should probably be at least 45 degrees to ensure the tooth lands on the resting face instead of the impulse face.
And this is with 3x M20 nuts. The period varies over 2 milliseconds over just this short run. Last night it was within only 0.6 milliseconds, so this is definitely worse.
I'm going to turn the pallets out so that they escape at about 46 degrees.
I didn't have the string wound far enough to run it for any longer.
That's within 0.7 milliseconds, so still not as good as yesterday, although it mostly seems to be a long-term trend down (maybe changing temperature or pressure?). I'm going to wind it up again and run it for longer with the same configuration.
Great, stayed within 0.2 milliseconds for 15 minutes.
So that is about the best result yet I think.
The best result last night was within 0.3 milliseconds, and that was with 6 nuts. So what if I use 6 nuts now?
The slotted disc is slightly scraping the encoder housing, and I heard it skip teeth a couple of times. I had this problem yesterday after I tried to re-adjust the balance spring.
Maybe the time it worked with 6 nuts was just luck, and it was very close to skipping? Because this is not working properly now.
Now that I can adjust the balance spring further (because it's not tied to the upper pallet), I can add 2 M12 bolts to the balance, make the spring take the weight, and see how it performs.
Back to 3 nuts now, so the comparison is the 15-minute run of "+/- 46 degrees" from above.
So, not as good as without the balance weight. Instead of being within 0.2 milliseconds, it's now a range of more like 1.0 milliseconds. So 5x worse in absolute terms, or 2.5x worse as a percentage of the period.
However, this has the advantage that it only uses energy half as fast! It ticks at half the speed, and has the same drive weight, so it takes twice as long to consume the drive weight. That's as good as getting another factor of 2 on the gear train without adding any extra teeth, gears, etc.; so it might be worth having even if the error is 2.5x worse.
And I think I have the upper pivot taking more weight than the lower one, so probably better performance is possible.
I noticed that the drop onto the lower pallet was much more severe than onto the upper one. I twisted the top part of the frame around to equalise the two, also closened the depthing of the escape wheel and pallets because it could accommodate it now, and ran it again.
Amplitude is up from about 220 deg. to 245 deg., still with 3 nuts, so that is a big improvement.
But the period range actually seems worse, which doesn't really make sense. Maybe this is just down to randomness from the tension in the winding etc.?
There isn't enough gearing to run it for long enough to take longer traces.
The gears are not meshing properly and I don't have a good way to adjust the depthing.
The frame is too flexible.
Sometimes the balance shaft is not perpendicular to the escape wheel shaft and I don't have a good way to adjust it.
It is difficult to precisely adjust the escape wheel depthing.
I don't have temperature/pressure data in the datalogging.
It skips teeth if run with too much drive weight, because the escape wheel has a very slight wobble, and the upper/lower edges are different distances away from the pallets, and the place that the tooth rests on the resting surface is too close to just bypassing the resting surface entirely.
I can't wind it up with even tension and no "snaking", because I am just manually looping the string over the drum, also the cotton string easily takes a twist.
I should be able to get higher precision amplitude data with some interpolation among the surrounding data points. If you know you spent a long time at the peak measured amplitude, then you can infer that it went "further" than if you only spent a very brief time at that amplitude.
The period always goes down as the amplitude increases ("faster in the larger arcs"). Could we change the shape of the resting surface to counteract this?