Member postings for S K

Interesting stuff. One point: "And solid carbon rods temp coef is a lot poorer than a tube..."

I'm wondering why this should be? Thanks.

Considering a simple pendulum (weightless rod, point-mass bob): Sure, if you are not adding mass but merely lowering an adjustment weight, the CG shifts down. But the CG isn't the main point, the radius of oscillation is. That's the position that the point-mass bob would be if you converted a compound pendulum (bob plus adjustment weight) to an ideal pendulum with the same period.

Slide the adjustment weight all the way to the top, and that weight becomes irrelevant to the period since it's not even swinging. Slide it all the way down to the bob, and it's also irrelevant! Why? Because now you just have a heavier bob, and the period isn't dependent on the mass of the bob! (T=2*Pi*sqrt(L/g) - the mass m of the bob is not in the equation.) The CG is obviously quite different in those two cases, but the result is the same - no change in period!

Slide it to somewhere near the middle, though, and now you have distinctly changed both the CG and the radius of oscillation. In that case, the compound pendulum is like an ideal pendulum with the bob higher up than before, hence a reduction in the period (the pendulum swings faster). This effect is at a maximum when the adjustment weight is at the middle of the rod. You have to put the adjustment weight below the bob to increase the period.

It becomes a bit more complicated when the rod is heavy and the bob is light in comparison. Then, the radius of oscillation is already above the bob, so lowering an adjustment weight below that point (but still above the bob) can increase the period. That result came up in my very light "gravity pendulum," but wouldn't often be the case for a more typical pendulum (carbon fiber rod, very massive bob that's extended in space) that folks are making here.

Edited By S K on 01/10/2023 19:29:01

First, I think you mean that the period increases when you lower the bob, not the rate.

If you add mass right at the pivot, there will be no impact on the period at all. If you lower the adjustment nut, the period will decrease. Think of that mass as detracting from the mass of the bob. If you add mass below the bob, the period will finally increase.

That's assuming that the rod is very light and the bob is very heavy, meaning that the center of mass and the radius of oscillation are both inside the bob.

In the other extreme, imagine a pendulum consisting only of a heavy rod (no bob). For this, the radius of oscillation is 2/3 down from the pivot. Add weight above that, and the period will decrease. Add below that, and it will increase.

Edited By S K on 30/09/2023 22:58:30

Well, the computer can't see contexts such as an actual fire or bullying or other non-verbal context, it just works on what it's given, and hence it has certain limitations. But if you added verbal context such as saying "there's a fire!", "there's a bully kicking someone," etc., it would likely do reasonably well.

Researchers are also tying various AI systems together, such as connecting text generation with picture generation and math facilities. Research in vision is a pretty tough problem, as Tesla is finding, but that's getting there too.

As amazing as they can be already (and also still lame at times), these new generative systems are still in their infancy. Companies, Universities and sovereign states are racing to build ever larger models, and because their "intelligence" scales with the size of the models, they will continue to improve.

It's both hopeful and scary.

There are many situations in which a scream is all that is needed to confer meaning. You could call that a proto-word. And of course external context (drowning or fire) is always helpful in refining meaning ("help" or "danger!" ). But in many if not most cases of written matter, the context is provided primarily by other words. And that context isn't just the words that are immediately being used, the point is that it includes the whole corpus of language.

The crazy thing that ChatGPT is proving is just how much actual information and knowledge is embedded in the connections between words. This isn't the old-school "if then else" kind of hand-wired knowledge, nor is it brute-force computation as in Deep Blue. With only weights (strengths of connections) between basically every word and every other word, it can do things like solve the above crossword puzzle. That is an amazing revelation!

Edited By S K on 23/09/2023 18:04:32

ChatGPT and its ilk does not have a memory of verbatim text from the internet, though the ability to look things up is being added to it so it can fact-check its own output. It also does not explicitly "repeat" anything verbatim, since it doesn't remember any of that anyway.

What it does have is an incredibly vast network of the strengths of connections between words - many billions of them. So the word "Merry" has a strong connection to the word "Christmas," for example, but a weak connection to "hubcap." Then, provide it with a prompt, and it will assemble a response based on those connections in a probabilistic fashion - prompt "merry" and it will probably choose "Christmas" rather than "hubcap".

Words only have meaning by those connections with other words, and actual knowledge is also embedded in those connections, to the extent that, by dint of those connections, ChatGPT can pass college admissions exams, etc.

I'd even argue that we ourselves work somewhat similarly to ChatGPT when we write.

Also: Should we worry? Yes. First, you and I - at least unless you are a billionaire - will never have as much power as the giant companies that are trying their best to monopolize their control over AI. We will only suffer under their power. Second, the next stage in AI's evolution would be super-human intelligence, and by definition no one knows what will happen after that. Maybe it will mark a new age of wonder and unimaginable benefits for mankind (cure cancer...), or maybe you will wake up one morning and every single bank account in the world will have been emptied, and all humanity enslaved forever or dismissively extinguished.

Edited By S K on 23/09/2023 15:01:22

Actually, I'm using an external oscillator, not the Arduino's oscillator. A fast oscillator is preferred in this configuration, and I've tested up to 6 MHz.

I could use the DS3231's 32 kHz TCXO, which though slower would work just fine for most purposes. But I'm also looking at 10 MHz oscillators, divided by two, yielding 200 ns resolution. Some TCXOs have quite good ppb's, and they have low power requirements. Faster ones are all surface mount, though, which is an inconvenience that nearly requires making a board. OCXO's typically consume a few W, but some are available with pins. I'm not looking at GPS or atomic clocks, etc., for this project.

It almost certainly does, but I don't believe that's an issue.

My concern is about whether the Arduino accurately counts at 5 MHz, or whether it misses clocks, etc., and also if the interrupt for the period registers the time promptly and correctly, i.e., within one 200ns clock, or whether it's noisy in the time domain. A stable output would appear to verify both of these, wouldn't it?

But I should ask: What process would best show that the timing of a period is being recorded accurately?

One fear I still have is that there may be beats or some other bizarre interactions between the 16 MHz Arduino clock and the 5 MHz clock. I think so long as the Nyquist criteria is satisfied there should be none, but how to prove that?

Edited By S K on 20/09/2023 23:25:09

OK, I used two channels on my function generator, one at 5MHz for the high-speed clock, and one at 0.1 Hz for the period, and the output is quite stable to 1 LSB (200 ns), which is the minimum error I'd expect to be possible.

Awesome! 🙂

Success! 🙂

I managed to use an external clock (5 MHz from a function generator) to measure periods, using the single 16 bit counter.

Now I have to validate the precision somehow, as I'm not yet 100% confident that the technique really does give me as high precision as I hope for at that high resolution. I'm also not certain of the function generator's noise or stability, so I'll probably switch to the 32kHz RTC clock output for now. But if that works out, I can get a good oscillator and move onward with the pendulum.

Edited By S K on 20/09/2023 21:02:32

I have a "Metro Mini" (not a "Metro" ) that uses the ATmega328P. This has 2x 8-bit and only 1x 16 bit counters (and yes, the same resonator). I hadn't realized there were so many minor variations of what are purportedly all "Arduinos." Perhaps I should purchase a different board.

Edit: I found that I do have a (non-mini) "Metro 328" lying about, but that presumably uses the same ATmega328. Hmm, am I missing something? Must investigate this further.

Thank you for the code. I'll take a look. I'm still interested in doing away with the need to calibrate the high speed clock, though.

Edited By S K on 20/09/2023 20:12:46

Actually, that was my understanding of your proposal, and it's fine in principle. But it's the means of doing that that I'm unsure about. The problem is the lack of sufficient counters with sufficient flexibility in an Arduino. There is only one 16 bit hardware counter and one possibly-suitable 8 bit counter. It's easy enough to time one external signal (e.g. a 1 pps clock) using the Arduino's 16 MHz crystal as the time base via using the 16 bit counter plus interrupts to handle the overflow. But using a puny 8 bit counter for the second timing job feels like trouble, generating interrupts every 16us. But maybe it would work fine?

Dave, any chance you might post your code?

My Arduino (Adafruit Metro Mini V1) appears to have a crystal, though I'm not 100% sure since the part number isn't noted. Properly changing from a crystal to an external oscillator is possible, but unfortunately it requires blowing fuses (I've wondered if simply jamming in a clock would work, though - let us know if you try it!).

Going back to the use of an external high-accuracy counter clock as I suggested earlier, I note that the hardware counters can be clocked externally at half the system clock's speed (i.e., the Nyquist limit), but the documentation suggests lowering that to 1/2.5 of the system clock as a safety margin. Therefore, up to a 6.4 MHz external clock is viable, e.g. dividing a 10 MHz counter by 2 for 5 MHz (200 ns least count).

If using an external counter clock, there is no need to time two external signals (the period and an external reference), and only the period needs to be measured, which can be done pretty easily with the 16 bit counter and a modest overflow interrupt rate. There remains the problem of the +/-32ns uncertainty due to pin synchronization, but counting over a ~2s period thoroughly solves this.

Edited By S K on 20/09/2023 15:45:26

Yes, I think that's what Dave does or proposes to do. But there might be a technical problem: It requires managing two clocks with high precision instead of one.

In the scheme I proposed above, the 32kHz clock (high accuracy, low resolution) is sampled using the processor's 16 MHz clock (low accuracy, high resolution) and counted in hardware. But there is no need for the 16 MHz clock itself to be timed or counted, as it has virtually no bearing on the result as long as it's generically "fast."

In the scheme you described, you need accurate timing of both the 32kHz clock and the 16 MHz clock. Otherwise you might not know the fast clock's result well enough to calibrate it adequately.

In one possibility, the "micros" command might be good enough to time the fast clock - I think that gives either 4 or 8 us of resolution (can't remember), but you do have to call it manually, e.g. once per period. This may not be of deterministic latency in that it could be delayed by other code or interrupts (the precision counter's overflow is handled by interrupts, for example). Some experimentation would be needed to verify that it's good enough, and odds are that it wouldn't be perfect. And, in addition, that isn't even all that fast: One really wants it to be faster than the 3-5us that the opto seems to deliver in practice.

Between the two approaches, using a faster high precision clock might be the better solution for an Arduino. So take a 10 MHz oscillator, and divide it down say by a factor of 4, until the counter's input is happy (e.g. about 2.5 MHz). Then you get the long-term precision at 400 ns resolution. (Or "just get a picpet" - sigh.)

Edited By S K on 20/09/2023 02:49:42

So while the long-term accuracy of the DS3231 is likely better than my pendulum, now I'm feeling unhappy about the resolution. The issue is that the pendulum + Sharp opto is good for 3-5 us, but a 32kHz clock only delivers 31 us. I liked it a lot better when my eyes misread a spurious extra zero and came up with 3us!

Curses! What to do now? I guess I really do have to consider John's Picpet+OCXO.

Edited By S K on 19/09/2023 22:51:51

Thanks. Fixed above. Any other mistakes?

Thinking out loud about timing resolution and accuracy:

The DS3231's 32kHz TCXO (and TCXO's in general) is good to +/-2ppm, or about +/-0.17s per day. I think this is adequate for my purposes, at least for the moment, since I'm not expecting my relatively-light pendulum operating in open air to be much better than that. For comparison, Bateman claimed +/-0.5s per day for his heavier and enclosed pendulum. If I did bump up against the TCXO's limit, an OCXO could be used instead.

Now, if the Arduino samples that asynchronously at 16MHz, an uncertainty of +/-32ns per sample is added that can be nullified to below the TCXO's native stability by counting say 1000 32kHz ticks. This is easily done well within the ~1.8s period my pendulum has (about 57k ticks). So for basic timing measurements (e.g. for the purposes of operation as a clock) I think the combination should be fine.

Note that this delivers the relatively-high long-term accuracy of the TCXO (over that of the native Arduino), but not extreme resolution. For the DS3231, that is limited by the 32kHz frequency of its output. This would yield about a 31us least count or under 0.002% for a 1.8s period, which doesn't sound especially bad for my purposes either.

To obtain more resolution requires a faster clock. At that point, an OCXO could be used. For convenience, a CMOS or TTL output is preferred, and these are available down to about 5ppb. However, prescaling would be needed for use with an Arduino, since the 10 MHz+ frequencies of these OCXO's (from what I've found) are too fast. Prescaling down to maybe 1MHz should be OK to drive an Arduino's hardware counter. But to realize the higher accuracy, the amount of averaging would need to be about 16,000 times higher too, and realistically some other solution (e.g. picpet) would be better over-all.

Since I have it wired up already, I think I'll try the DS3231's 32kHz clock feeding the Arduino's hardware counter, and average the asynchronous sampling over the pendulum's period. The advantage of this is that there would be no need to explicitly calibrate the Arduino's internal clock against an outside one (e.g. a 1 pulse per second clock).

The Arduino has so little memory that it can't do much more than tell time. Logging may also be problematic, as Dave pointed out, but I'll probably try it. Maybe I could implement a single-pass running S.D. calculation on the period, too. What else would be useful or interesting that could be displayed in real time?

(Eh, I probably won't be able to resist getting an OCXO anyway. 😉 )

Edited By S K on 19/09/2023 22:07:57

Yes, that would work. It's been a long, long time since I broke out the 74xx parts, though, and I tend not to look at them first for stuff now. (I did build my first computer that way, all hand-wired, with a staggering 1024 bytes of RAM.) Maybe for my final setup, though I'm toying with ideas involving multiple sensors.

I was once asked by a smart-ass: "If you built your first computer like that so long ago, how come you're not rich like Bill Gates?"

My response: "What makes you think I'm not!?"

...silence... 😄

Yes, that's quite likely due to that very serious and tragic earthquake.

If someone else here has similarly-good reference timing, you might even triangulate it.

Well, if the S.D. was found to be 0.15um, then there should be plenty of room for improvements in timing resolution.

I still think that using a brighter light source (e.g. a laser) in conjunction with a fine slit should improve the timing as well as reducing the effect of stray light. I also bought a few of the optos that Joseph is using, but - warning - it seems I broke the first one I tried (they may be particularly sensitive to ESD, which the data sheet even prominently highlights in red letters). One day I'll get back to these investigations.

Also, I've mostly been placing the opto at the end of the swing rather than at BDC. This way, I conveniently get a measure of the period directly, as opposed to half of the period (and annoyingly-different measures for the left vs. right swings). I've believed that this is not optimal, though, since the pendulum is moving slowest at its apex vs. fastest at BDC. It's probably indeed not optimal, but by John's measurement, it may not be that bad after all.

If the position error of a sensor is 1um, and a pendulum is moving at say 1cm/s at the sensor, then there's an uncertainty of 1us in the sensor's timing - a reasonable number (but put in proper speed values).

So, if the wavelength of light dictates the position uncertainty, then it also dictates the time uncertainty? If so, we must break out the ultraviolet laser or better yet an electron beam immediately! Hey, you are putting your pendulum in a vacuum already, after all! 😄