Ice Tube firmware - Drift correction with Auto DST, Dimmer

[wbp]

I'll take a look at the link and see if I can incorporate the checksum.

FWIW, with the $40 GPS module from Adafruit, I cannot find a location in my house where it doesn't work. I'm guessing it's a lot more sensitive than the GPS receiver you are using. I do have it mounted vertically, maybe that helps?

William

[grumpygasbag]

Awesome.

My house is quite new. We built it in 2006. The entire place (brick veneer) is lined between the brick and the timber frame with foil sarking. It's turned the place into quite an effective Faraday cage. Mobile (cell) phone reception inside the house is even dodgy!

The other advantage of using a re-transmitter is that a single GPS receiver can be used for all the clocks in the place, assuming they are GPS capable, just by connecting a cheap data receiver module to them.

[wbp]

Hey, Grumpy! I finally got the GPS Checksum code working today. Took a while to sort it all out but it's running on my clock now. I'll post an updated version with this and the fix for the alarm going off at midnight as soon as it's run for a while without any glitches.

William

[grumpygasbag]

Hey William,

I am *happy*gasbag today!

That is very good news. Thank you so much! Can't wait to see how you did it (I've been trying to figure out the code).

I got myself a usbasp programmer and can now 'talk' reliably to both my Atmel-based clocks with my Mac (IceTube and IV-17 Modular Clock from Akafugu). Done away with the DAPA.

I also got hold of some fantastic little 433MHz receiver boards (about 12mm square) and one of these now lives under my IceTube. When I get the new firmware installed I will probably put the receiver inside the clock itself. The serial data from a single BR-355 GPS receiver is now being received using 433MHz wireless retransmission by 5 nixie and VFD clocks in my house. The only one that doesn't have GPS enabled is the Akafugu one - only a matter of time

And, FWIW, I have never had any alarms going off at midnight. Mind you, the alarm has never been switched on so maybe that's why.

Thanks again,

J

[wbp]

The alarm goes off at midnight if you flip the switch to enable it, regardless of when the alarm is set for. That was a bug in some code that attempted to detect if the alarm time had occurred while the clock was without a GPS fix. I took it out for now.

Here's the code that calculates the checksum from the data, then extracts the checksum at the end of the message and compares the two:

Code: Select all

   //Calculate checksum from the received data
   gpsPtr = &gpsBuffer[0];  // start at the "G"
   gpsCheck1 = 0;  // init collector
    /* Loop through entire string, XORing each character to the next */
   while (*gpsPtr != '*')  // count all the bytes up to the asterisk
   {
      gpsCheck1 ^= *gpsPtr;
      gpsPtr++;
   }
   // now get the checksum from the string itself, which is in hex
   uint8_t chk1, chk2;
   chk1 = *(gpsPtr+1);
   chk2 = *(gpsPtr+2);
   if (chk1 > '9')
      chk1 = chk1 - 55;  // convert 'A-F' to 10-15
   else
      chk1 = chk1 - 48;  // convert '0-9' to 0-9
   if (chk2 > '9')
      chk2 = chk2 - 55;  // convert 'A-F' to 10-15
   else
      chk2 = chk2 - 48;  // convert '0-9' to 0-9
   gpsCheck2 = (chk1 * 16)  + chk2;
      
   if (gpsCheck1 == gpsCheck2) {  // if checksums match, process the data

      //Find the first comma:
      gpsPtr = strchr( gpsBuffer, ',');
      //Copy the section of memory in the buffer that contains the time.
      memcpy( gpsTime, gpsPtr + 1, 6 );
      gpsTime[6] = 0;  //add a null character to the end of the time string.

      gpsPtr = strchr( gpsPtr + 1, ',');  // find the next comma
      memcpy( gpsFixStat, gpsPtr + 1, 1 );  // copy fix status
      if (gpsFixStat[0] == 'A')
         gpsTimeout = 0;  // reset gps timeout counter
(more code)
      }


[nhibanez]

This firmware sounds exactly like what I've been looking for. I've got an Icetube clock that I built a couple of years ago. I loaded one of the firmwares that had the autodim feature, but I've been clamoring for the drift correction as my clock loses several seconds per day.

Have you uploaded the latest version of your firmware?

[wbp]

My current Ice Tube firmware may not fit on an 168 any more unless it is compiled with some features disabled. Do you have a 328P available? If not and you aren't using a GPS, I can probably compile a version for you that will give you what you want...

William

[nhibanez]

Unfortunately I don't have a 328P. But I'm not using GPS either so that could be disabled.
Thanks!

I've been wanting to mess with the code for some of the mods to piece something together, but not being a programmer has made me hit the wall and not being able to do it.

[wbp]

OK, here's a copy of my 12 October version with the GPS support removed. I have not tested this but give it a try and see if it does what you want.

William

[nhibanez]

I was able to load the firmware fine but the clock didn't do anything. No beep when I plugged it in or anything.
Fortunately I was able to flash back to the old firmware I was using and the clock is working fine. Looks like I might need to try to find a local source of a 328P that isn't too expensive or i'll just live with what I have.

[wbp]

What did command you use to flash the firmware? I don't see how loading new firmware without changing anything else can cause what you're seeing, but changing the fuses might.

[nhibanez]

Aah, I must have been editing my post when you posted as I was able to flash back to a previous firmware. usbtiny wasn't being recognized by my system for some reason after I flashed to your firmware.

avrdude -c usbtiny -p m168 -U flash:w:iv.hex

[wbp]

It occurs to me that the .hex file was compiled with the makefile set for 328p not 168. Oops...
I changed it and recompiled. Let's see if this works any better...

William

[nhibanez]

That did it. Flashed fine and clock is working. i'll have to figure out all of the options/modes to the new mod and see how it goes.
Thanks a ton!