DIY Moon Phase Dial

[Gina]

Oh well I'll try again with a new post - there are still bugs in the new software...

8pm and clock spot on - to the nearest second   The stepper motor is pretty warm but not hot so I think it will be fine running on mains power.

[Gina]

9pm and correct within a couple of seconds

[Gina]

When it comes to correcting the residual error at 12 o'clock, the Hall sensors detect 12 o'clock a few seconds before the minute hand is exactly in the middle of the dial mark.  Therefore the RTC reading at this event will be in the region of something like 45-55 seconds.  I can estimate this accurately enough by running just the first part of the sketch, up to the point where the Hall sensors detect the magnets on the hands and stop the motor. 

The preset variable called "timeError" is used to advance the hands to put the minute hand exactly in the middle of the 12 o'clock mark when setting up.  Now if I run the sketch to include this correction and adjust the value of "timeError" to put the minute hand in the right place, this value will give the number of steps required, from which the number of seconds can be calculated.  This will be the number of seconds before the minute that should match the RTC seconds.  ie. the RTC seconds should be 60 - the seconds correction on setting up.

I shall not be implementing this until I have confirmed that the gearbox correction is correct.  I think I should know by the time I get up tomorrow morning.  If this battle has finally been won, the time on the hour mark will be within a second or two.  And I shall breathe a huge sigh of relief - I'm really getting tired of chasing shadows

[Gina]

10pm and the clock appears to be 14s fast - strange.  8pm spot on, 9pm within a couple of seconds and then 10pm 14s fast - ridicuolus   I'll probably still be up at 11pm so will report then...  It was looking good

[Gina]

Backlash in the gears will allow the minute hand to move by almost half a minute so I guess the minute hand position could change "on its own", though I find it hard to believe as I can't see any reason why the minute hand should move forward other than as driven by the motor.  What matters is what the apparent error is after 12 hours and tomorrow will have the answer to that.

[Gina]

11pm and that darn clock seems to be half a minute fast

[Gina]

Bedtime - tomorrow is another day

[Gina]

Hmmm...  9am and after an elapsed time of 12 hours the dreaded clock is 2m 12s fast

[Stu]

Hi Gina,

You may be getting to this stage anyway, but my thoughts are to run the clock for quite a while, noting as often as possible the deviations, say on the hour when possible. You seem to be making changes to the settings assuming the clock is performing consistently ie you reset it and then it's, say 30 seconds fast. If you do the same test again without changing anything, the clock may well give a different result so you are inevitably going to be chasing your tail.

Perhaps check the longer term consistency before deciding anything else?

[Gina]

Thanks Stu   All thoughts and ideas are most welcome   I agree, a log of the errors hour by hour would be very interesting.  I might even be able to automate the logging by reading the RTC every hour using the minute hand Hall sensor and saving the results to the EEPROM to be read later.  The current circuit doesn't have spare capacity for an SD card reader/writer.  Meanwhile, I can continue with manual logging.

I have one more experiment to do and that's run a stepper motor on the bench with just a pointer on the shaft and see how it runs with no load.  I can do that separately from the clock.

My thinking is continuing towards the conclusion that these little stepper motors are not reliable enough for this sort of exacting application.

[Stu]

19 minutes ago, Gina said:

Thanks Stu   All thoughts and ideas are most welcome   I agree, a log of the errors hour by hour would be very interesting.  I might even be able to automate the logging by reading the RTC every hour using the minute hand Hall sensor and saving the results to the EEPROM to be read later.  The current circuit doesn't have spare capacity for an SD card reader/writer.  Meanwhile, I can continue with manual logging.

I have one more experiment to do and that's run a stepper motor on the bench with just a pointer on the shaft and see how it runs with no load.  I can do that separately from the clock.

My thinking is continuing towards the conclusion that these little stepper motors are not reliable enough for this sort of exacting application.

How about a webcam capturing an image every hour?

[Gina]

A quick look at logging to EEPROM :-  https://www.arduino.cc/en/Tutorial/EEPROMWrite has the details of how to do it.  Simple enough   EEPROM stores just 512 bytes (it says).  We would want to store the minutes and seconds - DEC would be easiest, which is one byte per char and 4 bytes per reading so there's capacity for 128 readings.  That's over 5 days worth - plenty.

LOGGING :- 10am on clock and real time is 57:30 - 2m30s fast.

5 minutes ago, Stu said:

How about a webcam capturing an image every hour?

Too complicated I think - thanks for the suggestion

[Stub Mandrel]

I've sometimes debugged by sending data to a PC over serial - will the Nano let you do this?

One advantage of working directly in AVR code is you can use the simulator in Atmel's Studio, sure there will be a way of using this with an arduino but it would mean loading the compiled sketch then disassembling it and might just make life much harder...

[Gina]

Looking at the RTC read format, I think the minutes and seconds are bytes anyway which are then formatted to DEC in Serial.print.  ie. We only need to save the two bytes from each reading to the EEPROM, or maybe HMS (or even DHMS).  I quite like HMS

 

[Gina]

19 minutes ago, Stub Mandrel said:

I've sometimes debugged by sending data to a PC over serial - will the Nano let you do this?

One advantage of working directly in AVR code is you can use the simulator in Atmel's Studio, sure there will be a way of using this with an arduino but it would mean loading the compiled sketch then disassembling it and might just make life much harder...

Yes, serial is what I generally use but it won't work in an ISR.  In fact trying stops the interrupt.  Darn nuisance that

I agree that AVR code would probably be just too much.

[Gina]

I could do with a method of getting data out within an ISR.  4 data lines could send nybbles to another processor.  Actually, I already have that if I disconnect the seconds motor.  Driving the seconds is something else to be sorted out eventually.  It would be nice if the seconds kept time too.

Immediate access to logging/debugging data would be a big advantage and may be worth the extra complexity compared with EEPROM storage.  Some thought would be needed regarding the formatting and synchronisation of the data.  Probably the simplest would be B1111 sync then uH, lH, uM, lM, uS, lS, where "u" is upper nybble and "l" is lower nybble.  The sequence of 7 nybbles could be fed to another Nano, decoded and fed to the serial monitor.  The coding would be relatively simple and then there's the hardware to make up.

I think I shall be setting this project aside for a few hours though and doing something towards astro imaging.  I may be able to catch some logging times but no guarantees...

LOGGING :- Clock 11:06  Real 11:03:07

[Gina]

I have the 400mm FL triple imaging rig out on the bench (aka living room table) read to work on but ATM I'm having a mug of coffee so having a break.  Not stopping me from uploading the test sketch to the triple focuser Arduino Nano for bench testing a stepper motor though.

[Gina]

LOGGING :- Clock 12:07  Real time 12:04:07

[Stub Mandrel]

Does this mean it uses a software serial port?

The hardware ports should be transparent to interrupts, you just need to feed them with a byte when the sent flag says TX is complete.

Put the data in a buffer for the  serial when in the ISR and set a flag. Have another interrupt for Tx complete that sends a byte if the buffer flag is set.

[Gina]

I don't know - I'm jusing the standard USB serial port and Serial.begin(9600); plus Serial.print(whatever); etc.  The Arduino web pages state that serial comms cannot be used with an ISR.

LOGGING :- Clock 1:00pm  Real Time 12:57:07.

[Gina]

LOGGING :- Clock 2:00  Real time 1:57:58pm.  Clock fast by 2m 02s

LOGGING :- Clock 2:03  Real Time 1:59:47pm.  Clock fast by 3m 13s.

LOGGING :- Clock 2:05  Real Time 2:02:47pm.  Clock fast w by 2m 13s

LOGGING :- Clock 2:07  Real Time 2:03:39pm.  Clock fast by 3m 21s

LOGGING :- Clock 2:11   Real Time 2:07:55pm.  Clock fast by 3m 05s

Two observations (assuming I can read the time but I have had plenty of practice ) The variation from minute to minute seems extreme and the clock is gaining overall.  I'm beginning to doubt my own eyes

The stepper motor bench test is proceeding...  The result will be interesting!

[Gina]

I've been wondering if using interrupts for the 1Hz square wave is actually necessary.  Since I'm not getting any accuracy whatsoever with interrupts, I feel inclined to try polling instead.  At least I would be able to debug using serial comms.  The manual logging is not going well - I'm distrusting my own eyes and the timing can only be described as "wild"!

Done some work on the 400mm imaging rig but waiting for the new super-duper USB hub before doing any more. 

[Gina]

LOGGING :- Clock 3:03  Real Time 2:59:45pm.  Clock fast by 3m 15s.

[Gina]

I really don't think there's any point in continuing this clock timekeeping test run, the variation in timing is just too ridiculous!!  

[Gina]

Looking at polling for the timekeeping :- Since the RTC produces a square wave, we can use both the rising and the falling edge for timing if it seems useful.  In any case we check the logic level for change.  Every loop we check if the timing input has changed state and if it has we send steps to the stepper motor.  Next time round the loop there will be no change and we do nothing. 

The loop can also have code to do other things such as check the Hall sensors so it would be easy to report the RTC minutes and seconds to the Serial Monitor when the minute hand Hall sensor output goes low.  The same edge sensing method as the RTC square wave can be used.  I was going to correct the timekeeping at 12 o'clock just twice a day but there's no reason why it shouldn't be done every hour.  I still don't want the clock to be out by more than ten seconds or so though and certainly not as much as half a minute.