clock with daytime chime / British summertime correction and new year chime

With the use of code from a john bloxhall tutorial and code snippets from other peoples sketches i have put together the code below , i have the clock working with the daily chime (between 9am and 9pm) after which it goes silent , the issues i have which i cannot get to work are the following

  1. i want the clock to chime at midnight of the new year, when i set the clock to just before midnight then wait as it rolls over midnight it does not chime,

  2. i am also trying to get the clock to auto correct itself for british summer time , i am convinced the error is with writing back to the RTC module but cant see what

i have had to attach a text file of code as it exceeds the number of characters allowed

clock chime code.txt (10.9 KB)

piccy:

  1. i want the clock to chime at midnight of the new year, when i set the clock to just before midnight then wait as it rolls over midnight it does not chime,

I think you are doing a wrong calculation for "strikes at midnight".
Possibly you want 12 strikes at midnight.
But you always take the hours as the number of strikes, and at midnight the hour is zero.
So you calculate to do zero strikes at midnight (00:00:00).

piccy:
2. i am also trying to get the clock to auto correct itself for british summer time , i am convinced the error is with writing back to the RTC module but cant see what

I don't think that it is a good idea to write changed times into the RTC at begin and end of summertime.

I'm always doing it like that:

  • RTC clock is always running in "zone time" (would be UTC/GMT time for you, I think), never changes!
  • if you need "local time" instead of "zone time", you check if the zone time falls into summertime, then add 1 hour if applicable.

So the logic for getting local time is always:

  • read zone time from RTC
  • check if this time is within summertime
  • if so, local time == zone time + 1 hour, otherwise local time == zone time

That way you never get into trouble if the Arduino is in power-off state while summertime begins or ends and RTC is running on backup battery at that time.

I think I'd change some of the programming logic in your code a bit. For example your clock seems to display seconds, but while chiming and "delay(4000)" the seconds are locked for 4 seconds. I'd like it better to let the seconds running smooth while chiming.

jurs thank you for your quick reply

I think you are doing a wrong calculation for "strikes at midnight".
Possibly you want 12 strikes at midnight.
But you always take the hours as the number of strikes, and at midnight the hour is zero.
So you calculate to do zero strikes at midnight (00:00:00).

you are right i do want 12 strikes and i can now see that i am asking the code to chime the hour value of 0 , thank you i can now work on that

So the logic for getting local time is always:

  • read zone time from RTC
  • check if this time is within summertime
  • if so, local time == zone time + 1 hour, otherwise local time == zone time

if i understand what you are saying , you say to test for the date being inside the start and end dates of BST and simply add or subtract 1 hour from the displayed value , is that correct ?

I think I'd change some of the programming logic in your code a bit. For example your clock seems to display seconds, but while chiming and "delay(4000)" the seconds are locked for 4 seconds. I'd like it better to let the seconds running smooth while chiming.

the seconds will not be displayed on the final version , i have them in there cureently as i was measuring the best length of thime for the chime to sound , while not exceeding 1 minute

being new to programming could you suggest what method i could use to have smooth seconds if i wanted , i used delay as i am using a serial controlled mp3 player to reproduce the chime sound which is four seconds long ( which is repeatedly played in step with the hour value, it a replacement for a mechanical bell and is an actual recording of the original bell.

I will start to work on the comments you have made in the morning , you can study the code for a long time and not see the obvious , thank you again

piccy:
if i understand what you are saying , you say to test for the date being inside the start and end dates of BST and simply add or subtract 1 hour from the displayed value , is that correct ?

Yes, something like that.

But as long as you just want to read the local time from RTC, you never have to subtract anything. Either you add nothing or you add one hour.

I've written a replacement for your function "getDateDs1307(...)":

Summertime change hour is the same in UK and all over Europe:

boolean summertime_EU(int year, byte month, byte day, byte hour, byte tzHours)
// European Daylight Savings Time calculation by "jurs" for German Arduino Forum
// input parameters: "normal time" for year, month, day, hour and tzHours (0=UTC, 1=MEZ)
// return value: returns true during Daylight Saving Time, false otherwise
// valid year range is from year 2000 ... 2099
{ 
 if (month<3 || month>10) return false; // keine Sommerzeit in Jan, Feb, Nov, Dez
 if (month>3 && month<10) return true; // Sommerzeit in Apr, Mai, Jun, Jul, Aug, Sep
 if (month==3 && (hour + 24 * day)>=(1 + tzHours + 24*(31 - (5 * year /4 + 4) % 7)) || month==10 && (hour + 24 * day)<(1 + tzHours + 24*(31 - (5 * year /4 + 1) % 7))) 
   return true; 
 else 
   return false;
}

void getDateDs1307(byte &second,byte &minute, byte &hour,byte &dayOfWeek,byte &dayOfMonth,byte &month,byte &year)
{
  // read date/time from RTC running in UTC time 
  // and adjust summertime if necessary
  Wire.beginTransmission(DS1307_I2C_ADDRESS);
  Wire.write(0);
  Wire.endTransmission();
 
  Wire.requestFrom(DS1307_I2C_ADDRESS, 7);
 
  second     = bcdToDec(Wire.read() & 0x7f);
  minute     = bcdToDec(Wire.read());
  hour       = bcdToDec(Wire.read() & 0x3f);
  dayOfWeek  = bcdToDec(Wire.read());
  dayOfMonth = bcdToDec(Wire.read());
  month      = bcdToDec(Wire.read());
  year       = bcdToDec(Wire.read());
  // do summertime test for timezone UTC+0 (i.e. UK)
  if (summertime_EU(year+2000, month, dayOfMonth, hour, 0)==false) return; // no summertime, leave function
  hour++; // adjust summertime by adding one hour
  if (hour<24) return; // same day, leave function
  hour=0; // day has changed because of summertime adjustment
  dayOfWeek= (dayOfWeek+1)%7;
  dayOfMonth++;
  byte daysInMonth[]={31,28,31,30,31,30,31,31,30,31,30,31};
  if (dayOfMonth<=daysInMonth[month-1]) return; // same month, leave function
  dayOfMonth=1; // month has changed because of summertime adjustment
  month++;
}

Please notice that I also changed the "call by reference" parameters syntax from C-pointer-style to C++-reference-style, so that you also have to change the function call. Within your loop function remove this:

  getDateDs1307(&second, &minute, &hour, &dayOfWeek, &dayOfMonth, &month, &year);
    
  // clock fwd check
  if (DST ==0 && month ==3 && dayOfWeek ==1 && dayOfMonth >24 && hour >0){
    bst_start();
  }
  
  // clock back check
  if (DST ==1 && month ==10 && dayOfWeek ==7 && dayOfMonth >23 && hour >1){
    bst_end();
  }

and replace with that:

getDateDs1307(second, minute, hour, dayOfWeek, dayOfMonth, month, year);

and remove bst_start()/bst_end() functions from your code.

The programming logic is then:
RTC must always be set to UTC-time (British winter time).
And when reading the time from RTC, it automatically gets adjusted to local summer time if needed.

Please test, that code is not really tested by me, I copied it together and adapted from functions that I use.

jurs:
The programming logic is then:
RTC must always be set to UTC-time (British winter time).
And when reading the time from RTC, it automatically gets adjusted to local summer time if needed.

As it should always be in any time code. Time zones as well.

Hi Jurs,

i have sorted the issue with the midnight chime thanks to your pointer of hour value being zero

i added the following line to the hourstrike() function

if (alarmValue == 0) { alarmValue = 12;}

when i tested it by setting the time to 23:58 and waited for it to roll over to 00:00 but the chime still did not happen

reading through the hourstrike() code the first line checks the hourtest variable to see if the chime has already happened for that hour , because i had set the time to 23:58 the value in this variable
was the initialisation value which was zero so it was telling the function that it had already chimed for that hour (0) so it was not allowed to chime .

int hourTest = 0; //flag to say if clock has chimed this past hour

( i had read a quote earlier at the bottom of a members profile , that said most programming errors can be cured by reading and making sure you understand exactly what the code is doing , i am still learning but how true that statement is !!!)

i will modify my code with the new DS1307 function code you have kindly provided and remove the dst functions and let you know the outcome

Thank you again for your help

piccy:
i added the following line to the hourstrike() function

if (alarmValue == 0) { alarmValue = 12;}

when i tested it by setting the time to 23:58 and waited for it to roll over to 00:00 but the chime still did not happen

I'd possibly do a rewrite of the complete silent/quiethours/hourStrike() logic.

Possibly to a count-down logic like that:

  • if the hour read from RTC has changed ==> set "strike" number to go
  • the "hourStrike()" function is called from the loop all the time (possibly hundreds of times per second)

And this "hourStrike()" function will then do all the rest:

  • check if "strike>0", so that at least one strike has to be done
  • check if the clock is set to "silent==true" or not
  • check if we are in "quiethours==true" or not
  • check if the last strike has been started more than 4000 milliseconds before
  • and if everythings says "strike now",
  • then the function will send the strike command
  • and remember the millis() timestamp of the strike
  • and substract one from the "strike" count variable

What do you think about?
Shall I give it a try?

Hi Jurs,

any help is appreciated and why not give it a try if you have the time, i would lilke to have the code as robust as possible , the finished project is a voluntary thing i am working on that will replace a broken bell in a clock tower on an island that was built in the 1800's , the clocks were replaced years ago but the cost of repairing the bell was too expensive so i suggested trying to do this way. (themp3 recording is of the actual bell)

i tested the operation of the 9 till 21.00 strike lockout and we have placed it through an amplifier and horn speakers to test it for a few days and it performed correctly , so then i decided to modifiy it for the midnight strike on new year and we are going to make it live (hopefully) at that time.

i will be adding the code you have done already and studying the code till i understand it thanks again

piccy:
any help is appreciated and why not give it a try if you have the time, i would lilke to have the code as robust as possible

OK, I've tried to simplify something and to make those things work that doesn't work.

Why didn't you use Serial for debugging?

I have added a DEBUG option for Serial. If you don't want that, change it to:

#define DEBUG 0  // set to 1 to see debug messages on Serial

The button logic for 'silent' setting has changed a bit:

  • when 'silent' button is toggled, the LED switches on/off immediately
  • but the LCD "bell" symbol updates with the next LCD update (up to one second delayed)

What about power loss?
Is the current 'silent' setting to be stored somewhere, so that at power-on after power-loss the last setting of 'silent' is restored automatically?

At the moment "int silent = 0;" (silent=false) is restored when the program starts to run.

piccy:
the finished project is a voluntary thing i am working on that will replace a broken bell in a clock tower on an island that was built in the 1800's , the clocks were replaced years ago but the cost of repairing the bell was too expensive so i suggested trying to do this way. (themp3 recording is of the actual bell)

Great enthusiasm! I think over here in Germany it is the same with old tower clocks: The owners often cannot afford repair, and if nobody cares, the watch hands and bells of such old devices stop forever.

The chime logic had been completely reworked:
First of all, the chiming is doing a countdown of strikes.
At every full hour, the number of strikes is set, then it is counted down to zero.
The clock does chiming every hour for a certain number of strikes, 4 seconds between two strikes, with just one little difference: The hourStrike() function has a parameter "loudStrike==true" or "loudStrike==false".

In case a strike has to be done "loud", the sendCommand() will be sent to the audio player module.
And in case a strike has to be done "silent", it just counts down the remaining number of strikes and no sound is played.

Perhaps you give it a try.
Please feel free to ask if something isn't working as expected or if you need some additions.

P.S.: I also did a minor bugfix to the BST time reading function posted in reply #3. In #3 the function fails to show the correct day of the week, when these three conditions meet all together:

  • we are in summertime
  • it is the last day of the week
  • it is the last hour of the day
    I was assuming that dayOfWeek is in the range 0...6, but actually it is in the range 1...7.
    Fixed in the code version that is in the file attachment.

Do NOT use the attached code any longer, it is faulty and outdated!
A newer and improved code version with striking bugs fixed and many imprevements is attached to reply #48 in this thread.

sketch_nov07a.ino (8.92 KB)

Wow Jurs ,
thank you so much i will start to test the new sketch, i had just added the code from earlier the bst working great re changing the hour so excited hadnt noticed any issue with the date

What about power loss?
Is the current 'silent' setting to be stored somewhere, so that at power-on after power-loss the last setting of 'silent' is restored automatically?

At the moment "int silent = 0;" (silent=false) is restored when the program starts to run.

silent was put in for human use for showing respect regarding a special occaision / or a passing away of an islander so dont think it will be a problem re remebering the last state so long as they can see the current state via the led

I am proposing to run the clock on battery power either charged via mains or poss solar , If there is a power failure the tower clocks will stop anyway , so manual intervention will then be required anyway to set the electric clocks.

poss future mods

  1. the lcd i intend to have the option to toggle the display on /off as it will be inside the tower and will not be seen from outside.

  2. check status of the unit by wifi (esp module ? )

all pie in sky for now , the deadline of New Years eve is fast approaching

The tower is nearly restored and has all been done by volunteers and fund raising ( i am in southern ireland by the way and so much heritage has dissapeared it is great when things get rescued ), the amp and horns are being donated , i am footing the bill for the chime unit , a local recording studio processed the bell recording for us, the original bell will be on display in the bottom of the tower, it is really a part of the places heritage, apparently the last time it is known to have rung its bell was 1922 . I will send you some images when allis sorted if you would like to see them , you will certainly get mentioned for the work you have done for me, time to start getting this all bulit now and into the waterproof case i have got for it - you have saved me so much time Thank You

Why didn't you use Serial for debugging?

I have added a DEBUG option for Serial. If you don't want that, change it to:

No idea about debugging etc the only other thing i have created was a simple pir based people counter for counting people numbers passing through a doorway, very crude but working ,

once this project is out of the way its time for some serious winter time study regarding arduinos and programming

piccy:
silent was put in for human use for showing respect regarding a special occaision / or a passing away of an islander so dont think it will be a problem re remebering the last state so long as they can see the current state via the led

The "bell" display could be optimized, so that not only the LED is switched on/off instantly as the button is pressed, but also the LCD bell symbol could be appearing/disappearing instantly when the button is pressed. Could be done with a small change in the loop() function logic.

It would also be possible to create a "summertime" icon and display on LCD when summertime is active.

piccy:
I am proposing to run the clock on battery power either charged via mains or poss solar , If there is a power failure the tower clocks will stop anyway , so manual intervention will then be required anyway to set the electric clocks.

If the electric clock mechanism is also running on mains power, the easiest solution would be a to use mains power and a 5V-USB power-adapter for your clock device as well, such as a charging adapter for MP3-players or smartphones. If it is a USB power adapter with a USB socket, you can easily connect any USB cable to connect every standard Arduino board.

piccy:

  1. the lcd i intend to have the option to toggle the display on /off as it will be inside the tower and will not be seen from outside.

Do you mean switching on/off the backlight? That should be easy, but requires another button, I think.

piccy:
2. check status of the unit by wifi (esp module ? )

Now it's going to become complicated.

piccy:
all pie in sky for now , the deadline of New Years eve is fast approaching

What about a possibly for date/time setting without the need to upload a sketch for setting the date/time and another sketch afterwards then to use the date/time setting?

I saw, that you provided a "commented out" line of code to set date/time.

What about setting date/time without programming the unit?
Perhaps with some extra buttons (select/up/down) for date/time settings?

Or perhaps "Serial date/time setting", so that the date/time setting doesn't need programming a new sketch, but just starting the "serial monitor" or any other "terminal program" on any PC connected to the Arduino?

Even a highly accurate DS3231 runs 60 seconds per year wrong, and perhaps needs a new setting once per year to stay accurate up to the minute.

piccy:
time to start getting this all bulit now and into the waterproof case i have got for it

Use caution in using a "waterproof case" for your application!
Typically this is the wrong decision in places with big temperature drops.

If you can place the device in a place where it is protected from rain (perhaps inside the clock tower), the decision for a "well ventilated case" might be more suitable. The reason is: condensed water!

In a "waterproof case" this will happen: On warmer temperatures, warm and moist air is diffusing into the case, and at the next temperature drop below dew point the water is condensing out in the case! So your case will become a sort of dripstone cave. Typically that condensated water never will evaporate from the case. So if the case is waterproof, you possibly have to place silica gel drying agent within the case, and possibly have to change it once per year.

I'd prefer a well ventilated case. Perhaps I'd spray some protective PCB coating laque on the PCB to provide some extra protection for the conducting paths and soldering.

Hi Jurs,
have just uploaded the sketch , i have a couple of issues which i am going to see if i can see why using the serial debug suggestion and guides you put in the code , but if you could also look that would be great

  1. The chime function doesnt drive the mp3 player (in loud), i am thinking it has to do with the timings ( the way it operates is as follows the chime command is sent to the player , the delay of 4s then starts before the next chime command is sent (the mp3 file is 3.4 seconds long and i allowed for the reset of the player when it has stopped playing the file) I have just started to look at the code to try and get an understanding of it now,

The "bell" display could be optimized, so that not only the LED is switched on/off instantly as the button is pressed, but also the LCD bell symbol could be appearing/disappearing instantly when the button is pressed. Could be done with a small change in the loop() function logic.

It would also be possible to create a "summertime" icon and display on LCD when summertime is active.

Re the bell outline , if it appeared instantly that would be great but not a real issue, i would also prefer that the bell outline is shown or another symbol when striking is disabled by the pushbutton

re summertime icon that would be a nice touch ,

What about a possibly for date/time setting without the need to upload a sketch for setting the date/time and another sketch afterwards then to use the date/time setting?

I saw, that you provided a "commented out" line of code to set date/time.

What about setting date/time without programming the unit?
Perhaps with some extra buttons (select/up/down) for date/time settings?

That was on my wishlist but way beyond my current knowledge level , i used the commented out method as it was the simplest but i did spend a few attempts guessing when to upload it , i have got within 2 seconds now, but i know it would mean messing around again should i have to reset it at any time.

Do you mean switching on/off the backlight? That should be easy, but requires another button, I think.

yes, i have found this line in the lcd library file lcd.noBacklight(); so i reckon i could try and build a function that shuts the backlight off after a predetermined time .

Use caution in using a "waterproof case" for your application!
Typically this is the wrong decision in places with big temperature drops.
Perhaps I'd spray some protective PCB coating laque on the PCB to provide some extra protection for the conducting paths and soldering.

I take on board your comments re the case , i have bought some pcb sealer and was going to apply that , there are plenty of cable entry knockouts in this case so i can easily remove then all and allow plenty of air into the case.

I am going to attempt to cure the strike and bell display myself as a learning excercise and will not read any corrections you do until i have done this , I am very concious of the time you are giving to this for me and it really is appreciated.

One other modification i would like to do is the way the manual override works i am concious that someone could set the manual bell off and forget to turn it back on, but i can see complications for when to turn it back on, ie if its for a funeral or special occaision the time for off could be different ( or do i just let it stay off untill the next day. There will only be two people with access to the unit so i am not sure its worth worrying about.

re the wifi monitoring that was only a dream - lol
I am using the nano board by the way - not sure if i mentioned that or if its relavent,

Jurs,
an update on the bell not sounding ,using the serial debug checksyou put in there i can see the loud command is sent and a short 1 second burst of sound is heard from the speakers , the command is sent for the appropriate number of strikes so i will look at the timing part

piccy:
have just uploaded the sketch , i have a couple of issues which i am going to see if i can see why using the serial debug suggestion and guides you put in the code , but if you could also look that would be great

The DEBUG option is just for debugging reasons, but as you are using the SoftwareSerial library in your code, this may interfere with Serial used at the same time. SoftwareSerial is one of the worst libraries provided with the Arduino IDE.

piccy:

  1. The chime function doesnt drive the mp3 player (in loud), i am thinking it has to do with the timings ( the way it operates is as follows the chime command is sent to the player , the delay of 4s then starts before the next chime command is sent (the mp3 file is 3.4 seconds long and i allowed for the reset of the player when it has stopped playing the file) I have just started to look at the code to try and get an understanding of it now,

To avoid interference with SoftwareSerial and Serial at the same time, disable DEBUG for testing the audo command:

#define DEBUG 0  // set to 1 to see debug messages on Serial

Is the audio file then playing?

Another try would be timing: In your code the timing for one strike was "time for play command plus 4 second delay". In my code the strikes are equally timed with 4 seconds from command to command. Perhaps increase the time by half a second to 4.5 seconds:

if (millis()-lastStrikeTime<4500) return; // no time for a strike

Does one of this help to play the file?

piccy:
Re the bell outline , if it appeared instantly that would be great but not a real issue, i would also prefer that the bell outline is shown or another symbol when striking is disabled by the pushbutton

Currently the display for bell setting is like that:

  • no bell symbol when bell is disabled by button
  • full bell symbol when bell is enabled during daytime (09:00:00-21:59:59)
  • outline bell symbol when bell is enabled by button, but disabled during nighttime (22:00:00-08:59:59)
    What changes do you want?

piccy:
re summertime icon that would be a nice touch ,

I can put a summertime symbol right beside the bell symbol?

piccy:
yes, i have found this line in the lcd library file

lcd.noBacklight();

so i reckon i could try and build a function that shuts the backlight off after a predetermined time .

Please describe the backlight logic you want:
Perhaps backlight off when x seconds have passed since the unit started?
Then backlight on after button has been pressed?
And off again after x seconds?

piccy:
One other modification i would like to do is the way the manual override works i am concious that someone could set the manual bell off and forget to turn it back on, but i can see complications for when to turn it back on, ie if its for a funeral or special occaision the time for off could be different ( or do i just let it stay off untill the next day.

It would be possible to have an automatic fallback to "silent=false" at a certain time. Let's say 17:00 or 00:00 or as you like. Or even "4 hours after button was pressed" enable bells again.
Just let me know about what you prefer for automatically switching bells loud mode again.

piccy:
I am using the nano board by the way - not sure if i mentioned that or if its relavent,

The Nano is Atmega328 based, so plenty of flash and RAM is left for extensions.

What about keeping the clockwork and your chiming unit in sync?
How precise is the clockwork running?

Perhaps you could use the chiming unit and the high precision DS3231 also to keep the clockwork in sync with the chimes work. For example: If the clockwork is adjusted that it runs a little bit fast, lets say it runs one hour forward within just 59 minutes, and you provide a sensor at the minute hand to detect the minute hand beeing at full hour. Then you could use the Nano to keep the clockwork running in sync with the chimes:

  • if minute hand reaches full hour: Sensor dects full hour and stops the clockwork motor
  • if DS3231 detects full hour, start the clockwork motor again
    In that case the clockwork motor will run to the next full hour within 59 minutes (needs to be adjusted to run a little bit fast), sensor stops clockwork. And one minute later the DS3231 gets the "real" full hour and starts the clockwork again and plays the hourly strikes.

I don't know if this idea is understandable. Currently I think there might be a problem with the clockwork and the chimes being in sync, because they are running independently from each other.

Currently the display for bell setting is like that:

  • no bell symbol when bell is disabled by button
  • full bell symbol when bell is enabled during daytime (09:00:00-21:59:59)
  • outline bell symbol when bell is enabled by button, but disabled during nighttime (22:00:00-08:59:59)
    What changes do you want?

leave as is , there is indication from led to say bell manually disabled so thinking about it that will be fine

Please describe the backlight logic you want:
Perhaps backlight off when x seconds have passed since the unit started?
Then backlight on after button has been pressed?
And off again after x seconds?

if the clock will have the ability for time to be set by buttons then could one of those buttons be used to activate backlight and turn off 180 seconds after any key presses or from start?

It would be possible to have an automatic fallback to "silent=false" at a certain time. Let's say 17:00 or 00:00 or as you like. Or even "4 hours after button was pressed" enable bells again.
Just let me know about what you prefer for automatically switching bells loud mode again.

00:00 would be best

What about keeping the clockwork and your chiming unit in sync?
How precise is the clockwork running?

I have been looking at sensors to address a possible problem with chime not at same point as mechanical clock, i was undecided whether we let the clocks run for a week or so to see what error in timings we got , and whether to use a hall effect or infra red sensor as you say to detect the minute hand or if sync to mains frequency was an option as they are synchronous motors, using hall effect made me wonder whether any attached magnet would affect the travel of the clock finger in the latter part of the hour , the other sensor i thought about was capacitve sensing (proximity)

i will try now the debug and time delay settings and let you know

If the clock motor is synchronous and running from the line, it would be feasible to monitor the line. You do need a filter as well as a threshold detector, to avoid false triggering from noise pulses on the line.

Jurs,

debug command was the issue with the audio playing, works fine now i have disabled debug as suggested

piccy:
leave as is , there is indication from led to say bell manually disabled so thinking about it that will be fine

if the clock will have the ability for time to be set by buttons then could one of those buttons be used to activate backlight and turn off 180 seconds after any key presses or from start?

00:00 would be best

I have been looking at sensors to address a possible problem with chime not at same point as mechanical clock, i was undecided whether we let the clocks run for a week or so to see what error in timings we got , and whether to use a hall effect or infra red sensor as you say to detect the minute hand or if sync to mains frequency was an option as they are synchronous motors, using hall effect made me wonder whether any attached magnet would affect the travel of the clock finger in the latter part of the hour , the other sensor i thought about was capacitve sensing (proximity)

i will try now the debug and time delay settings and let you know

Why not set the tower clock according to your RTC, rather than vice versa?

piccy:
debug command was the issue with the audio playing, works fine now i have disabled debug as suggested

OK, fine!

So it shows up once again: SoftwareSerial is a bad library and you cannot use Serial and SoftwareSerial sending at the same time without the SoftwareSerial data becoming corrupted during sending.

Not a big issue for your application, I think. So the debug option in the program is more a help for me in debugging "LOUD" and "silent" strikes, than it is for you.

You have the audio device and can do "audio debugging", I don't have it.
So just disable Serial debugging for the final program and the audio commands work.

I think that is the basic program then as you wanted it:

  • chiming at full hours, 4 seconds between single strikes
  • automatically summertime switching between UTC and BST time.
  • with exception: no chiming strikes during night hours
  • with exception: no chiming strikes when set to "silent" by button
  • with exception: 12 chiming strikes at midnight on new year
  • LCD display of time and bell icon

Some fine tuning left.

And one main function of any clock is left on the to-do-list: date and time setting

One relatively simple way to do so (without twice programming) would be "Serial date/time" setting. This would require that you use a better software serial library and replace SoftwareSerial with perhaps "AltSoftSerial", so that Serial and AltSoftSerial can work at the same time. But the disadvantage is: You will always need to connect a PC to the device for date/time setting and have to use the "serial monitor" or a "serial terminal software" to do the date/time setting (perhaps once per year when using a DS3231, which is very accurate).

But as I understand, you would prefer, that date/time setting could be done with the device itself, no other device attached, right?

When thinking about that I come to a "rotary encoder menu" demonstration sketch that I posted in this posting:
http://forum.arduino.cc/index.php?topic=315351.msg2454171#msg2454171

The hardware required for that type of date/time setting menu would be a "mechanical rotary encoder with switch. That would be something like offered by eBay from UK vendor in eBay article number 311300314576 (10 pieces).

What do you think? Would it be possible to replace the button in your application with such a rotary encoder with button and then try to adapt my menu for date/time setting from the other thread for your application?

But I really cannot tell you whether and how quickly I can adapt it. Needs some spare time.

Perhaps you can do it like that for now:

  • purchase a mechanical rotary encoder with switch
  • built your case with that rotary encoder instead of simple button and do the cabling
  • use the existing sketch as a firmware, only the button function of the encoder is used

And at any time when a new sketch is ready, you can do a 'firmware update' later, which adds the rotary menu function for date/time setting.

Create the full hardware now, prepared to be used for functions that are not available yet and need to be implemented later by programming a firmware update? But for now use the sketch that you have?

What do you think?

jurs:
And one main function of any clock is left on the to-do-list: date and time setting

Consider using MSF ( Time and frequency MSF radio signal - NPL ) to synchronize your DS3231. For my clock whenever the DS3231 is more than 2 seconds in error I update it with MSF time; this is fairly infrequent since the DS3231 is very accruate.

One of the advantages of using MSF is that it automatically corrects for DST/GMT changes and for leap seconds changes. There is an Arduino library for decoding the MSF signal and the hardware is cheap if purchased from China.

You should note that the MSF signal can be lost and/or corrupted so it is necessary to do all the MSF parity checks and some sanity checks before updating the DS3231.