...I posted a question for WBP...
Can I ask if your firmware (which has been running beautifully since I loaded it!) includes checksum verification of the GPRMC sentence?
Why do I ask?
Well, I have been experimenting with 433MHz wireless re-transmission of the GPS data, so my clocks don't need to be placed close to a window.The BR355 is plugged into small circuit that just re-transmits the RS232 data for 15 seconds every few minutes (if transmitted continuously it blocks my garage door remote!) and it's then received by one of those small 433MHz receivers and turned back into RS232.
I've managed to get this working quite reliably with my nixie clocks (the clocks from Jurgen Grau and Pete Virica both include checksum verification of the GPRMC sentence and any incorrect strings are rejected) but the Ice Tube frequently has this peculiar problem - the hours get set to zero (usually) and the location data is corrupt but the minutes and seconds are ok. I've noticed it can go from correct time to corrupted time and back several times within the 15 second data transmission burst!
If the Ice Tube is wired directly to the BR355 there is no problem, of course. It only occurs with the wireless re-transmission system which is, not surprisingly, much less reliable.
If anyone else is interested in experimenting with this idea, Jurgen Grau now has some wireless GPS modules available that should work, more or less reliably, with any clocks that can take RS232 satellite data.
<http://www.nixiekits.eu/> (see the bottom of his "Sven" clock page)
There was quite a bit of discussion between William and myself in that thread about this issue, and indeed William did implement the checksum, discussed in a separate thread...
That didn't solve my problem. It took a while to figure it out, and William can expand on this if he wants, but the problem was a bug in the buffer-length handling for the GPS data. This bug did not affect hardwired GPS receivers, since the buffer never filled, but with all the gibberish coming in from the 433MHz receiver between data bursts (see explanation above) the buffer filled, a null character was added, and that null character overwrote the first bit of data in the subsequently defined variable in the hex file (which just happened to be the time). This caused the hours to keep reverting to zero (the time on my clock kept coming up "00.mm.ss"). William cleverly spotted the problem after I wondered allowed (well, by email) about what I thought was a problem with the buffer-length definition. I wasn't quite correct, but it made William look in the right place. Nothing like a bit of teamwork :) . William deserves the credit, however, and I am most grateful for his patience with me.
William's latest IceTube firmware version, which I think he will make available shortly for both 168 and 328 processors, includes new GPS handling routines, checksum verification of the data, and a buffer-length fix to solve the rather unique problem I was having.
The fact that my GPS retransmission system (single BR-355 GPS receiver connected to a prototype of Jurgen Grau's 433MHz data transmitter) is now working flawlessly with the IceTube (using a very cheap 433MHz superhet data receiver), as well as all my other nixie clocks, meant that I could incorporate the receiver onto the IceTube circuit board itself, rather than having external connectors. Happy to post further details if anyone is interested, but here are some pics. The first one shows the tiny (12x10mm) 433MHz receiver module and how I mounted it the the left side of the board, through 5 small holes I drilled, with the ground pins soldered to the board's ground plane underneath. The insulated Vcc, data and antenna wires can be just made out in the blurry photo (sorry). You can also see the unemployed ATmega168V processor I've replaced with a 328p.