Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Apr 21, 2012 4:09 am

Default 4800, as far as I know. That's what the other clocks use.
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by wbp on Sat Apr 21, 2012 4:16 am

can you connect the GPS to a serial port on your PC? or connect it to an Arduino per the tutorial on Adafruit.
That's the best way I know of to see what it's doing. You should be able to see the NMEA strings as clear text.
4800 bps is what the clock is using.
Code: Select all
  uart_init(BRRL_4800);
User avatar
wbp
 
Posts: 213
Joined: Mon Mar 07, 2011 12:18 pm

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Apr 21, 2012 5:53 am

Can't easily connect it to a PC. I use Macs and of course none of them have PS/2 ports (that the BR-355 uses). The one I used to program your firmware onto the clock is an old PC my daughter has (it rarely gets used) and I don't have anything readily to hand to connect it to the serial port. The DAPA programmer is one I built myself (I posted to another thread about this when it didn't work at first).

I don't have any Arduino gear at all, I'm afraid.

Both the BR-355s I have are currently connected to nixie clocks and I have checked that they both use the default NMEA protocol (4800,n,8,1).

In any case, I can't do much at the moment because since my first post today the clock has got stuck in December 2055. I think connecting it to the GPS has caused some sort of corruption :( Is that possible?

I can set the time and the day of the month but then the month and year are stuck (nothing happens when I press any of the buttons when in date setting mode, after changing the day). I've disconnected power and removed the battery so I'll see what it's doing tomorrow. If it's still the same I'll try reflashing it with the DAPA programmer.
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by wbp on Sat Apr 21, 2012 10:23 am

That sure sounds like the data from the GPS is getting corrupted somehow. The code that parses the NMEA strings is looking for something that looks like this:
Code: Select all
$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68


It wouldn't have done anything at all unless it saw "$GPRMC,", so if the date got set as you describe, it saw that at least once. The fact that it isn't always updating the time would indicate that the data stream isn't being received correctly most of the time.

I wonder if that GPS mouse is outputting TTL (3.3 V) instead of RS-232 (5v). That won't work with the Ice Tube clock, you'll need a level converter. The GPS modules that Adafruit sells have both outputs. The GPS module inside the mouse housing may have both.
User avatar
wbp
 
Posts: 213
Joined: Mon Mar 07, 2011 12:18 pm

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Apr 21, 2012 5:03 pm

William, you are a genius!

The Globalsat BR-355 manual says it outputs TTL or RS232 levels, which doesn't make a lot of sense to me. I thought the former was supposed to be 5/0V and the latter +/-12V, or at least that's what it was when I was a kid, but anyway.

Your suggestion prompted me to look at the circuit diagrams of my other clocks (which I should have done before - DUH!). Both of these include a transistor between the data line of the BR-355 and the RXD pin of the chip (ie corresponding to pin 2 on the AVR in the Ice Tube). That transistor inverts the signal from the BR-355, by the looks of it. The collector is connected to Vcc by a 10K resistor. The emitter directly to ground. The base takes the signal from the BR-355 also via a 10K resistor. The RXD pin of the chip is connected to the collector, pulling it up to Vcc.

I cobbled together a version of this and interposed it between the clock and the BR-355.

INSTANT SUCCESS!

Time and date correct. Latitude = -3351.31. Longitude = 15109.58

So there you go folks - a solution for people using GPS "mouse" receivers (the ones usually having a PS/2 connector).

If I get time later I'll upload some photos.

John
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by wbp on Sat Apr 21, 2012 5:36 pm

John,

Congratulations on getting it working! I'm glad I was able to provide a seed for your inspiration. And now, as Lady Ada says, your clock really knows where it's at! (and so do we :-) )

William
User avatar
wbp
 
Posts: 213
Joined: Mon Mar 07, 2011 12:18 pm

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Apr 21, 2012 8:00 pm

Hi William,

Thanks again. I have nothing to hide, location-wise :wink: and it's not as exact as you might think - entering the values (after deg/min/sec to deg dec conversion) into a relevant web page puts me on the wrong side of the Iron Cove Bridge!

A couple of things worth mentioning...

I had connected the power line for the GPS to Vcc (ie *after* D2). That was simply because it was a convenient place to connect the wire. It occurred to me this morning, however, that with power disconnected that would cause the battery power to drain into the GPS. Not good, I suspect. I pulled it to bits again and reconnected the GPS power to pin 3 of the regulator (as per the mod page and as I should have done in the first place, DUH again).

I also found that the problem I had setting the date persisted after setting GPS to off again in the menu. I could change the day of the month, but not the month or the year (ie same problem as what I described last night before I got the GPS working). I re-flashed it with your firmware and using the DAPA (again getting verification errors) but that didn't change anything.

Everything else working fine. GPS sets time perfectly when connected and GPS turned on in the menu. Autodim perfect. Last digit looking pretty much the same brightness as the rest (was way dimmer before I used your firmware). So the flash of the firmware seems to have worked despite the verification failure.

So, what happened exactly is this (if trying to set the date). Pressed menu button to bring up date (I have it set to "Euro" mode - DD/MM/YY). Pressed set - showed date with the day of month highlighted as it should. Pressing + button then advanced the day of the month but at the same time the highlight decimals moved to the *month* (while still changing the *day of month* by pressing +). Pressing set or menu again caused it to freeze at this point, with nothing highlighted. Had to wait then until clock went back to the time by itself (ie out of the menu by timeout) - couldn't do anything else. Could this be a bug in the firmware? Or have I done something bad?

It then occurred to me :idea: to see what happened if I changed it to USA mode (MM/DD/YY) in the menu. Well, well. It worked fine! Setting date not a problem. Ok, so I set it back to Euro mode and it's now ok too!

Weird.

Anyway. It's seems now that all is good and well in the world. Sigh. :D

William, I owe you a beer.

Cheers!

John
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by wbp on Sat Apr 21, 2012 11:44 pm

John,

Try using deg/min.fraction instead of deg/min/sec. Odd but that's the data stream. Corner of Renwick and Thomley?
http://aprs.gids.nl/nmea/#rmc

It's possible there is a bug in the date setting code when set to "Euro" mode, but it sounds more like it was just corrupted data. I'll do some testing and code peering just to be sure though.

My beverage of choice is single malt, and rather old, so best not to worry about that. I'm glad to have been able to help! That's what open source is all about. I got it from someone else, who did a tremendous amount of work, I made some improvements, and it gets passed on...

William
User avatar
wbp
 
Posts: 213
Joined: Mon Mar 07, 2011 12:18 pm

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sun Apr 22, 2012 12:47 am

William,

Location exactly correct (Thornley, it is) using your method. Deg/min/sec had me in a house boat on the other side of Iron Cove :-)

I think you're right about the frozen date stuff. Once I changed to US then back to Euro it was fine.

And the chap who designed my first nixie clock (Jürgen Grau) tells me that the BR-355 outputs its data inverted and at +/-2.5V which would explain what happened in my experimentation quite nicely. I've now popped the socket for the BR-355 and the necessary transistor inverter/level correction circuit onto a little bit of strip board that I'll shrink wrap eventually.

If we ever meet up, the Glenfiddich is on me.

Yours aye!

John.
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sun Apr 22, 2012 2:03 am

Ok, I've figured this out now. Can't believe I was so stupid to not work it out before (that'll be the third DUH for me :oops: ). I was thinking about why the Adafruit module connects directly to RXD on the AVR but the Globalsat one doesn't. Then I had this vague recollection about something to do with negative going edges and RS232 (dredged this memory up from 20+ years ago).

The Adafruit GPS module is sending out the serial data as TTL (it has RS232 lines but these aren't used): 0-Vcc(5V) signal with logic high being Vcc.

The Globalsat BR-355 is using RS232: -ve to +ve signal with logic high being *negative* (ie inverted with respect to TTL).

Interested parties sharing my sketchy knowledge of serial data transmission might want to peruse this...

<http://www.sparkfun.com/tutorials/215>
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sun Apr 22, 2012 4:46 am

photo1.jpg
photo1.jpg (271.99 KiB) Viewed 2357 times


Photos as promised. Not great quality but best I could do.

Showing Ice Tube with most of my collection (Frank 3 missing - in my daughter's room). In the photo above, Ice Tube is sitting on top of Manuela (Jürgen Grau kit) with Sven on the left (Jürgen Grau also) and Frank 2 on the right (Pete Virica).

Other photos showing the front of the clock with light-dependent resistor installed for auto-dimming...

photo2.JPG
photo2.JPG (283.11 KiB) Viewed 2357 times


...the back with the cable coming through the bottom to the pin header...

photo3.jpg
photo3.jpg (248.73 KiB) Viewed 2357 times
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sun Apr 22, 2012 4:50 am

...the underside showing the pin header from the floppy drive and the CD audio cable attached...

photo4.jpg
photo4.jpg (307.56 KiB) Viewed 2357 times


...and the auxiliary board with socket for the GPS receiver (3.5mm stereo socket/plug adapted as per the connections required for Sven)...

photo5.JPG
photo5.JPG (263.47 KiB) Viewed 2357 times
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Jun 16, 2012 10:58 pm

Hi again William,

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)

Cheers,

John
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by wbp on Sat Jun 16, 2012 11:30 pm

I don't believe it does check the check sum, but I can probably add it. I have another bug I need to fix as well, so I'll look at doing both at the same time. Don't hold your breath though, I don't have a lot of spare time to work on this right now.

One question though - does your 433Mhz wireless work with TTL signals or only RS232? As you will recall we figured out that the Ice Tube needs TTL...

William
User avatar
wbp
 
Posts: 213
Joined: Mon Mar 07, 2011 12:18 pm

Re: Ice Tube firmware - Drift correction with Auto DST, Dimmer

by grumpygasbag on Sat Jun 16, 2012 11:50 pm

Hi William,

Happy to wait for when you have time! I already owe you.

There's some potentially suitable code in C, which could be easily modified for our purposes I expect, here...

http://www.eex96.com/?p=4#more-4

I have little doubt the wireless data transmit/receive pairs can be made to work with *either* TTL or RS232, assuming the relevant logic levels are taken into consideration.

The BR355 outputs RS232 which is the inverse of TTL, as we have previously discussed. Its data are inverted by a transistor before being transmitted over the wireless data link. If using TTL, the data signal could just be applied directly to the data transmitter module's data input pin.

At the receiver end, the data are converted back to RS232 by another transistor connected to the receiver's data pin. That is done because the nixie clocks I have are expecting RS232 (out of a BR355). Inside the clocks, this is converted yet again to TTL by another transistor inverter.

As far as I can tell, the TTL output of a suitable GPS receiver module like the one from Adafruit could be connected directly to the data pin of the 433MHz (or 315MHz or whatever) transmitter and, at the other end, the data pin of the receiver could be connected directly to the relevant pin of the Arduino, since the wireless receiver outputs TTL.

Cheers,

John
grumpygasbag
 
Posts: 33
Joined: Fri Mar 30, 2012 4:28 pm
Location: Sydney, Australia