Experimental Pendulum Clock

[Michael GilliganParticipant @michaelgilligan61133]

Dave and John

If you’ve found a problem with the interrupts … may I suggest that you contact the Authors ?

They specifically stated the device is open-source and they encourage experimentalists …

MichaelG.

[duncan webster 1Participant @duncanwebster1]

Posted by Michael Gilligan on 16/12/2022 14:06:01:

Posted by duncan webster on 16/12/2022 11:20:22:

[…]

The other clock I referred to had an accurate clock connected all the time, so you might as well have just used the electronic clock. This is from memory, I'm not going googling to find a reference. This is not the same as the microset.

.

Bit pointless carping on about it then

MichaelG.

.

Edit: __ Please give us a clue though …

You attributed it to Mumford … how confident are you ?

Edited By Michael Gilligan on 16/12/2022 14:11:30

As requested I've stopped carping on about it

[duncan webster 1Participant @duncanwebster1]

Posted by Michael Gilligan on 16/12/2022 14:02:36:

Posted by duncan webster on 16/12/2022 10:38:40:

What's difficult about Pascal's? […]

.

Simply that they are too small to be conveniently useful for most things that interest me … any unit that requires expressing in Mega or Giga terms before it becomes practical seems daft.

MichaelG.

.

P.S. __ Now that you have done your big calculations: Do you have an answer to the question of whether a ‘tank’ made from [say] plastic underground-drainage pipe would suffice ?

Well that's Farads ruled out then, for most practical purposes they are micro, pico, nano.

Depends what you consider sufficient.

[Michael GilliganParticipant @michaelgilligan61133]

Posted by duncan webster on 16/12/2022 14:41:55:

.

Depends what you consider sufficient.

.

Well … on 13-Dec I had a stab at that, when I wrote:

” As the practical scope for pressure variations inside, outside, or twixt the two, is probably much less than 1bar … I’m happy to stick with my gut-feeling that its significance is “trivial in the grand scheme of things, because it would only be causing a very small variation in an already small variable.”

Lacking your computational expertise … I was rather hoping that you might assist my comprehension by offering numbers to either support or discredit my gut-feeling.

I must confess that the numbers you have provided so far do neither.

So, John’s question remains unanswered.

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 16/12/2022 12:29:11:

Thanks for doing those experiments Dave, very illuminating! Small point, a seconds pendulum would be interrupting at 0.5Hz…

isn't the potential problem though that if the pulse rates are nearly harmonically related, when they do clash they will continue to for some time while they slide past each other? For a clock that is very nearly correct that could persist for many seconds perhaps during which one loses readings.

I have 3 nanos, I could set up 2 as pulse generators and run the "HJ" code on another…

Good idea. I have have difficulty imagining what would happen as two harmonically related signals slid past each other. It would be easy enough to try it. I guess the closer they are together the more serious the consequences; as my example showed one of the interrupts is effectively disabled by the other when both happen at the same time.

Re Michael's suggestion about contacting the authors, I would if I had a cure!

Their code is clearly written, they do amplitude in the same way as me but go a step further by quantifying it, an idea I might steal. I work with unquantified relative values.

The way they handle output timing solves a problem I've got, which is output driven by pendulum time isn't accurately spaced, or might not be. That makes it difficult to do FFT which depends on a regular timebase.

On the other hand, the HJ code reports offset from GPS, which is vulnerable to interrupt clash errors that might be serious if the GPS and the pendulum are closely synchronised. (I might try the HJ code to see what it does when GPS and the pendulum inputs are identical.)

Other features that might be improved are the use of micros() with only 4us precision and the absence of temperature compensation of the Arduino's crystal, which is only stable within about 100 parts per million. Compensation is a problem with my clock too, but I have a plan. As the HJ code collects temperature and pressure, it's likely they compensate at the analysis stage, which is what I'm doing at the moment too.

Replacing micros() with 'my' Timer/Counter approach* would be worthwhile, especially if an external high precision clock is used to drive the timer. Not tried it yet, though I have a 2ppb OCXO on order.

Dave

* Not my original idea: the timer/counter method is copied from Tom van Baak's picPET. Smart guy – anyone interested in this stuff will find his website well worth a visit.

[Michael GilliganParticipant @michaelgilligan61133]

Duncan

I think I may have found your Mumford reference !

In Horological Journal he has an article broadly similar to his web-page

**LINK**

Performance Analysis

 

But it includes this specific statement:

“My results show that the impulse mechanism of a common quartz pendulum is capable of precision timekeeping when applied to a proper pendulum. I feel a little like an horological anthropologist, discovering the unexpected descendants of Fedchencko and early electric slave clocks hiding inside the modern quartz clock. Some may view me as a mad Frankenstein, removing the quartz oscillator from an accurate electronic clock, and implanting a 'primitive' mechanical pendulum in its place. The remarkable result is about as accurate as the quartz clock it replaces.”

[my emboldening, for emphasis]

If I am correct, this may be the detail that allays your concern.

MichaelG.

.

Ref. __ HJ vol.141 No.01-02 Jan-Feb 1999 (Page 22)

Edited By Michael Gilligan on 16/12/2022 21:27:39

[John HaineParticipant @johnhaine32865]

Posted by Michael Gilligan on 16/12/2022 14:18:28:

Dave and John

If you’ve found a problem with the interrupts … may I suggest that you contact the Authors ?

They specifically stated the device is open-source and they encourage experimentalists …

MichaelG.

Indeed and I have, no response yet.

On your Mumford point Michael, he adjusts amplitude with a pot to do fine rating. Coarse adjustment is through the microprocessor counting and driving the dial. But once adjusted it runs open loop. I believe some people have adjusted amplitude to vary rate to lock the clock to a reference.

Indeed the last post on my previous thread:

https://www.model-engineer.co.uk/forums/postings.asp?th=169174&p=3

Described one such.

Edited By John Haine on 17/12/2022 09:21:48

[John Doe 2Participant @johndoe2]

Just coming back to this thread, but haven't read every reply, so my apologies if this has been covered:

Measuring the pendulum by when the bob interrupts the IR beam is using a curved, reflective surface to break the beam. Might this cause some weird effects, owing to changing reflections and refractions around the surface of the bob as the curved surface moves into and out of the width of the IR beam? Might these effects not be symmetrical, and give rise to on/off measurement differences, giving errors and noise? Maybe try a flat IR absorbent plate to interrupt the beam instead? A small piece of cardboard maybe?

Why have what is effectively a spring as the pendulum "pivot"? This is always going to result in two oscillations, one from the pendulum swing, the other from the spring in the "pivot". Why not have an actual pivot, e.g. a knife edge bearing in the form of a T shape across the top of the pendulum resting in twin V blocks, one either side. That would remove a second source of oscillation and any work hardening effects of the "pivot" spring etc.

Forgive me if I have missed it, but your pendulum seems to have no temperature compensation. I think some clocks have a negative temperature coefficient element which compensates for length variations of the pendulum owing to temperature changes, and your pendulum variations shows a close correlation to temperature variations.

[Michael GilliganParticipant @michaelgilligan61133]

Thanks, John Haine

On the Mumford/Fedchenko thing … I was just hoping to clear-up what I think was a misinterpretation by Duncan, and to hopefully thereby set his mind at rest.

Ref. __ Duncan wrote: “The other clock I referred to had an accurate clock connected all the time, so you might as well have just used the electronic clock. This is from memory …”

But clearly [if indeed I have found the right item] it did not have an accurate clock connected … simply Fedchenko’s electronic impulsing and adjusting arrangement serving a pendulum.

MichaelG.

.

Note: ___ my use of ‘serving’ rather than ‘controlling’ is intentional, as I think it better describes the proper relationship.

Edited By Michael Gilligan on 17/12/2022 10:09:46

[John HaineParticipant @johnhaine32865]

Posted by John Doe 2 on 17/12/2022 09:55:15:

Just coming back to this thread, but haven't read every reply, so my apologies if this has been covered:

Measuring the pendulum by when the bob interrupts the IR beam is using a curved, reflective surface to break the beam. Might this cause some weird effects, owing to changing reflections and refractions around the surface of the bob as the curved surface moves into and out of the width of the IR beam? Might these effects not be symmetrical, and give rise to on/off measurement differences, giving errors and noise? Maybe try a flat IR absorbent plate to interrupt the beam instead? A small piece of cardboard maybe?

Why have what is effectively a spring as the pendulum "pivot"? This is always going to result in two oscillations, one from the pendulum swing, the other from the spring in the "pivot". Why not have an actual pivot, e.g. a knife edge bearing in the form of a T shape across the top of the pendulum resting in twin V blocks, one either side. That would remove a second source of oscillation and any work hardening effects of the "pivot" spring etc.

Forgive me if I have missed it, but your pendulum seems to have no temperature compensation. I think some clocks have a negative temperature coefficient element which compensates for length variations of the pendulum owing to temperature changes, and your pendulum variations shows a close correlation to temperature variations.

I have done some measurements of the precision of beam breaking using an opto-interrupter, I think I gave the results here somewhere. I used a 5mm (from memory) steel pin (may have been 6mm) and also compared with a thin blade. I was worried about diffraction around the pin but there was no appreciable difference between pin and blade, and the results indicated that sub-micron repeatability was achievable. It may be different with a larger cylinder but it wouldn't fit in my gap! Since the light is incoherent and we are talking about precision significantly larger than a wavelength I'm not sure I see why a bigger cylinder would be worse.

Suspension springs are almost universally used in precision clocks. Both the Shortt and Fedchenko clocks used springs, probably the most accurate pendulum clocks ever made. Generally speaking there isn't another mode due to the spring other than a torsional one that affects timekeeping. (However the analysis of a bending spring is horrendous!) Knife edge bearings are hard to make and subject to wear and damage, but they are used in some clocks, for example there was a solar/siderial clock in HJ with one pendulum on gimbals swinging in orthogonal planes; and there's an experimental free pendulum clock in the December (?) HJ that uses Stanley knife blades.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Doe 2 on 17/12/2022 09:55:15:

Just coming back to this thread, but haven't read every reply, so my apologies if this has been covered:

Measuring the pendulum by when the bob interrupts the IR beam is using a curved, reflective surface to break the beam. Might this cause some weird effects, owing to changing reflections and refractions around the surface of the bob as the curved surface moves into and out of the width of the IR beam? Might these effects not be symmetrical, and give rise to on/off measurement differences, giving errors and noise? Maybe try a flat IR absorbent plate to interrupt the beam instead? A small piece of cardboard maybe?

…

Forgive me if I have missed it, but your pendulum seems to have no temperature compensation. I think some clocks have a negative temperature coefficient element which compensates for length variations of the pendulum owing to temperature changes, and your pendulum variations shows a close correlation to temperature variations.

Yes, reflections and ambient light both caused trouble in earlier versions of the clock. Not only the bob is reflective, but so is the Aluminium frame, the plastic LED holder, and the interior of the plastic pipe! Now mostly eliminated by blackening surfaces, reducing beam power, and protecting the IR detector with black plasticine. I should try shining the beam through slits. Breaking the beam with a curved surface is a worry, and it might explain some of the noise. Part of the experiment is keeping the mechanics as simple as possible, hence the bob does the breaking rather than a properly shaped flag. But you're right to be suspicious – it could be a problem!

My approach to compensation is different too. The strategy is to protect the clock moderately with a low temperature coefficient carbon-fibre pendulum rod, and by running it inside a vacuum, but mainly by fitting it with temperature, air-pressure and humidity sensors and using the data to correct the reported period of the pendulum to what it should be.

In a conventional clock, temperature compensation is applied mechanically to the pendulum, and the motion counts ticks at a fixed rate. In this experiment, the pendulum is uncompensated, but the software motion, not gears, is completely variable. The pendulum doesn't have to be perfect because compensation is done mathematically by the motion rather than physically in the construction. It still needs to be a good pendulum though!

First, the clock is run for a long time in learn mode. It runs uncompensated, logging it's notion of period, plus temperature, humidity and barometric pressure values on every tick. Log data is collected by a bigger computer that adds accurate NTP or GPS timestamps. Exactly how period is effected over a long time by environmental factors is measured, and converted into a simple y=mx+c formula to be applied in real time by the clock. The accuracy of the formula improves with sample size.

In stand-alone mode, the clock's motion, converting period to HHMMSS, is able to take the pendulum's reported time, know that it's wrong perhaps because temperature'changed, and correct the measured number to what it should be. The statistically found y=mx+c formula is used. So the motion counts HHMMSS based on compensated rather than actual period, and should be more accurate.

Dave

[John HaineParticipant @johnhaine32865]

Dave, I'm thinking of using a similar approach, but one thing bothers me. The response to temperature changes has a distinct lag due to thermal time constants; and also changes in rate caused by amplitude changes induced by density changes are slow because of the pendulum Q. So compensating based on instantaneous pressure and temp may not work so well, do we really need a sort of "PID" model, and if so how would it be characterised? Or is there a sort of regression algorithm that could do it?

[duncan webster 1Participant @duncanwebster1]

If the pendulum is in a hermetically sealed tube it will be largely isolated from pressure and humidity changes. Can I suggest that a dummy pendulum rod (non swinging) is hung inside the containment and that you monitor its temperature rather than air temp.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 17/12/2022 14:31:57:

Dave, I'm thinking of using a similar approach, but one thing bothers me. The response to temperature changes has a distinct lag due to thermal time constants; and also changes in rate caused by amplitude changes induced by density changes are slow because of the pendulum Q. So compensating based on instantaneous pressure and temp may not work so well, do we really need a sort of "PID" model, and if so how would it be characterised? Or is there a sort of regression algorithm that could do it?

Bothers me now too! Hadn't thought of lag as being a problem. I had to look up PID, 'Proportional-Integral-Derivative', and found this website as a starter for ten. I sort of understand it.

Is it necessary though? The clock compensates on every beat, and, as temperature and pressure vary slowly, any anticipation due to lag would be quite small, I hope but don't know. Another way of dealing with it might be to delay the correction 'n' beats before applying it, or to apply some sort of exponential smoothing to a running average so that it doesn't change too quickly, i.e lags. I've no idea how long temperature or density change lags would be – seconds, minutes or hours?

This whole enterprise reminds me of pulling a thread. The more I tug, the more it unravels. Simple ideas turn out to be too simple!

I'm currently struggling with the OSC5A2B02 modules you highlighted, thanks. They arrived so I fired one up to test it. Small problem, the pins don't fit standard veroboard, Bigger problem, the device has to be tuned with a pot to be spot on 10MHz: out of the box it could be 20Hz out, so worth doing.

How to tune it though? It's 5 times more accurate than any other 10MHz frequency standard I have, so I can't do it with a simple comparison. I think the best I can do is count how many ticks it emits in 1 GPS second with an Arduino, which would get me ±1Hz. The other problem is more annoying, and I've had to order a divider to fix it. When I fed 10MHz into an Arduino's external clock, the answer was wrong. Reading the datasheet revealed the max external clock frequency is crystal/2.5 ie 6.4MHz, so I need to halve the module's output to 5MHz. More work!

In yet another distraction I've been looking at matching frequencies with Lissajous figures on an oscilloscope. I thought of matching the OCXO against WWV. In deep water already: lissajous is different with square waves. And 10MHz WWV is rarely a good signal here.

Dave

[duncan webster 1Participant @duncanwebster1]

It's just occurred to me (whilst walking the dog in the rain) that there is a second temperature effect, the containment tube will expand and contract, affecting the density of the fixed mass of air enclosed. Steel has an expansion coeff of 13e-6 /C, so a 10 degree rise in temp will change the volume by 390 ppm. This is still small compared with normal changes in barometric pressure, but you could measure the tube temperature and allow for it. Perhaps this is why vacuum is used in astro clocks.

PVC expansion is 4 times as great

Edited By duncan webster on 17/12/2022 16:20:12

[John HaineParticipant @johnhaine32865]

"I'm currently struggling with the OSC5A2B02 modules you highlighted, thanks. They arrived so I fired one up to test it. Small problem, the pins don't fit standard veroboard,"

Yes, I noticed that! Isn't it a pain? They seem to be on an 0.05 raster.

"It's 5 times more accurate than any other 10MHz frequency standard I have, so I can't do it with a simple comparison."

Well you could always build a GPSDO! I'm wondering about using a picDIV to generate 1pps then something like this:

**LINK**

using a nano to tweak the oscillator. One could feed the two pps signals into interrupt pins and adjust the OCXO to drive the time difference to a constant offset…

You did want another project didn't you?

[SillyOldDufferModerator @sillyoldduffer]

Posted by duncan webster on 17/12/2022 16:17:17:

It's just occurred to me (whilst walking the dog in the rain) that there is a second temperature effect, the containment tube will expand and contract, affecting the density of the fixed mass of air enclosed…

Aargh!!! Second thoughts though, if I'm compensating for barometric pressure, it won't matter. However, that led me to look up the BME280 sensor I'm using, and it only goes down to 0.3bar. The deeper vacuum I'm planning needs a different sensor. Will it never end???

[Peter Cook 6Participant @petercook6]

Posted by SillyOldDuffer on 16/12/2022 12:16:58:

Had a go at what happens when an Arduino Nano gets two interrupts at the same time.

….

Up to 5kHz, the Interrupt on Pin 3 is reliably detected, and that on Pin 2 is ignored.

Dave I think there is a problem with both your code and your understanding of the interrupts. If I read the Arduino documentation correctly, if two interrupts arrive simultaneously, then they are processed in priority order. Pin 2 has a higher priority than pin 3, so in your test Interrupt 2 should get processed first which sets Value equal to 1, when that ISR is finished the interrupt on pin 3 is executed, which sets Value equal to 2 — overwriting the bit set by interrupt 2 and making it seem as if the pin 2 interrupt is being ignored.

I also think that the problems you are seeing at over 5khz are the result of the serial print process being interrupted. 115,200 baud is about 10,000 chars/second max. You are sending 15 – 20 chars per print. Once the serial print buffer fills Serial Print waits until there is room in the buffer – so once the buffer fills each serial print will be taking 100 microseconds per character printed. At 10khz interrupt rate you are almost guaranteed to get the print process interrupted and the data corrupted.

A more valid test would be to have each ISR increment a separate counter each time it is executed, then in the main loop simply compare the two counters.

If both interrupts are being serviced properly the two counters should remain in step. When they differ, you have found the limits.

PS if an interrupt on 2 arrives while the interrupt on 3 is being serviced, then it simply gets queued until the one on 3 has completed.

Edited By Peter Cook 6 on 17/12/2022 17:47:30

[SillyOldDufferModerator @sillyoldduffer]

Posted by Peter Cook 6 on 17/12/2022 17:46:12:

Posted by SillyOldDuffer on 16/12/2022 12:16:58:

Had a go at what happens when an Arduino Nano gets two interrupts at the same time.

….

Up to 5kHz, the Interrupt on Pin 3 is reliably detected, and that on Pin 2 is ignored.

Dave I think there is a problem with both your code and your understanding of the interrupts. If I read the Arduino documentation correctly, if two interrupts arrive simultaneously, then they are processed in priority order. Pin 2 has a higher priority than pin 3, so in your test Interrupt 2 should get processed first which sets Value equal to 1, when that ISR is finished the interrupt on pin 3 is executed, which sets Value equal to 2 — overwriting the bit set by interrupt 2 and making it seem as if the pin 2 interrupt is being ignored.

I also think that the problems you are seeing at over 5khz are the result of the serial print process being interrupted. 115,200 baud is about 10,000 chars/second max. You are sending 15 – 20 chars per print. Once the serial print buffer fills Serial Print waits until there is room in the buffer – so once the buffer fills each serial print will be taking 100 microseconds per character printed. At 10khz interrupt rate you are almost guaranteed to get the print process interrupted and the data corrupted.

A more valid test would be to have each ISR increment a separate counter each time it is executed, then in the main loop simply compare the two counters.

If both interrupts are being serviced properly the two counters should remain in step. When they differ, you have found the limits.

PS if an interrupt on 2 arrives while the interrupt on 3 is being serviced, then it simply gets queued until the one on 3 has completed.

Edited By Peter Cook 6 on 17/12/2022 17:47:30

We're on the same page, I think. Priority is why pin 3 is detected more often in my code than pin 2. When there's time, pin 3 is counted and pin 2 has no apparent effect. Which works until the cpu isn't fast enough to process the interrupt 1 function and the interrupt 2 function, and the Serial connection in loop(). I'm not very good at explaining it

When there's time value contains either one or two, but my code shows there are times when it's neither: something horrible happened.

I'll try your way and see where it breaks!

Developing interrupt code is challenging because what happens is time sensitive. All is good up to a certain interrupt rate, and then chaos.

Dave

[Peter Cook 6Participant @petercook6]

Sorry Dave, I think Pin 2 AND pin 3 are both detected EVERY time (at least up to a certain speed). It's just that your ISR3 code (which happens second) overwrites the Least significant bit in VALUE which has been set every time by ISR2 which runs first.

Your code executes as Loop – ISR2 – ISR3 – Loop.

When it gets warmer in the workshop I will see if I have a suitable frequency source and have a go.

[John HaineParticipant @johnhaine32865]

I think that this is much too fast to exercise the system! In reality you get one interrupt/second from the GPS and 1 every 2 seconds from the pendulum (or one every second if you observe both beats). Though it may capture both, as the lower priority one is not serviced when it arrives surely its registered time will be delayed by at least the time it takes to service the first (since it's in the ISR that micros() is captured)? In the HJ code loop() does nothing, everything happens in the ISRs.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Peter Cook 6 on 17/12/2022 19:25:38:

Sorry Dave, I think Pin 2 AND pin 3 are both detected EVERY time (at least up to a certain speed). It's just that your ISR3 code (which happens second) overwrites the Least significant bit in VALUE which has been set every time by ISR2 which runs first.

Your code executes as Loop – ISR2 – ISR3 – Loop.

When it gets warmer in the workshop I will see if I have a suitable frequency source and have a go.

We're having a violent agreement! Last night I thought you were misinterpreting me, but rereading what I typed after sleeping on it, I plead guilty. Your explanation is clearer – 'Loop – ISR2 – ISR3 – Loop'.

My code shows what happens when interrupts arrive too fast for 'Loop – ISR2 – ISR3 – Loop' to be maintained. You're right to question it, as I see John has too, because this isn't what John asked originally about Hazel Mitchell & Mike Godfrey's Nano Pendulum Clock Timer, available here on github.

Bit of a diversion from my task list, but it's an interesting question. So I've downloaded ChronovaEngineering's code to see what it does when I feed it John's scenario with a signal generator. (The necessary pulses could also be produced by programming another Nano.)

Meanwhile, the statistics produced from my latest clock run have produced an anomaly; Pearson says there's no correlation between temperature and period, when the graphs emphatically show otherwise. The other correlation tests are suspicious too, so that needs investigating. Another mystery – as far I can see the clock is working normally and I don't think I changed the software.

Dave

[Michael GilliganParticipant @michaelgilligan61133]

Posted by Michael Gilligan on 16/12/2022 21:24:15:

Duncan

I think I may have found your Mumford reference !

[…]

.

Oh dear … it looks like I have made it onto Duncan’s ‘Ignore Member’ list

MichaelG.

[duncan webster 1Participant @duncanwebster1]

Posted by Michael Gilligan on 18/12/2022 11:26:37:

Posted by Michael Gilligan on 16/12/2022 21:24:15:

Duncan

I think I may have found your Mumford reference !

[…]

.

Oh dear … it looks like I have made it onto Duncan’s ‘Ignore Member’ list

MichaelG.

As requested, not carping

[SillyOldDufferModerator @sillyoldduffer]

A report on the ChronovaEngineering program, which I won't judge because the output isn't what I expected, suggesting I don't understand it. An example looks like:

418788v412468
417004v410684
415224v408908
413452v407136
411668v405352
409892v403576
408112v401796
406336v400020
404552v398236
402772v396456
400992v394676
399216v392900
397440v391128
395656v389344
393880v387568
392108v385796
390324v384012
388548v382236
386768v380456
384988v378676

The test set up is a Ultimate GPS Breakout Board sending super-accurate second pulses to a Nano:

The Nano is also fed not so good second pulses from a Siglent Function Generator substituting for a real pendulum. Note the generator allows me to alter the phase of the output, delaying or advancing when the pulse starts:

The GPS and pendulum signals are compared with an oscilloscope. On a slower scale the two signals appear to be aligned, but zooming in shows they're actually about 5mS apart:

Then I altered the sig gen phase to sweep the pendulum pulse over the GPS pulse and logged what happens to the Nano's output numbers. They jump:

402836v388744
401088v395336
399336v399140
397592v1008
395836v1012
394088v393892
392344v392148
390592v390396
388844v388648
387096v386904
385344v385148
383596v1012
381852v1012
380104v379908
378352v372600
376604v368076
374860v374664
373112v1012
371356v1012
369608v1012
367864v1012
366108v1012

No idea if that's good or bad!

Dave

[Author]

Posts