Jupiter-T GPS module binary protocol - Page 1
Forum section: electronics / projects

author: davorin
author_rank: Unknown
timestamp: October 13, 2014, 04:30:19 pm
content: I've setup a prototype GPSDO based in the Jupiter-T module....But as I would like to also display accurate date/time information with a microcontroller, the only seems to rely on the UTC time mark message 1108...From the Jupiter-T datasheet it states that it should be possible to switch over to binary protocol with @@Wb command...but after that I still can send @@ commands and it responds...What is the proper way to be able to receive the Zodica binary messages?

author: davorin
author_rank: Unknown
timestamp: October 13, 2014, 04:47:51 pm
content: Found it...the command should be @@Wb\x01 and not just @@Wb...Solution found here with help from James R. Miller:http://www.jrmiller.demon.co.uk/projects/ministd/faq.html"How do I RESET a Jupiter GPS?"...contains a ZIP file with various messages to switch between protocols you can just pipe to serial port...

author: Melt-O-Tronic
author_rank: Frequent Contributor
timestamp: October 13, 2014, 07:27:51 pm
content: Thanks for that! I thought I had been all over J R Miller's site, but I missed that file somehow. Working out the protocol is the next step in my GPSDO project.

author: davorin
author_rank: Unknown
timestamp: October 13, 2014, 08:05:56 pm
content: Well...GPSDO works....btu if I can have accurate timing for free...why not extend it...Did some serial capture after switching to binary mode...it sends back @@Wb and immediately after that starts sending several messages after the 1PPS pulse...Code:<- @@Wb\x01\x34\x0D\x0ASwitch to binary mode-> @@Wb\x01\x34\x0D\x0AAcknowledged->FF815404Message 1108UTC time mark...FF81E803Message 1000geodetic position status output...FF81EA03Message1002channel summary...FF816F04Message1135EEPROM update...FF811F04Message1055timing receiver configuration output...FF812004Message1056timing receiver status output...FF815404Message1108UTC TIme Mark...FF81E803Message 1000geodetic position status output...FF81EA03Message1002channel summary...FF816F04Message1135EEPROM update...FF812004Message1056timing receiver status output...FF815404Message1108UTC TIme Mark...I just don't know yet to which 1PPS pulse the UTC time in message 1000 belongs to...

author: davorin
author_rank: Unknown
timestamp: October 17, 2014, 09:25:13 am
content: This is odd...After every time mark pulse the modules starts sending messages with ID 1000 first, which contains the GPS and UTC time...THe last message is always ID 1108, the time mark message...But when comparing the UTC seconds (seconds from ID 1000, and UTC seconds in week), the UTC seconds in message 1108 is always 3 seconds ahead....Need to build a quick DCF77 receiver to be able to compare it against something (o;

author: ruffy91
author_rank: Regular Contributor
timestamp: October 17, 2014, 03:03:40 pm
content: GPS time doesnt count switch seconds. They are separately counted. I think this is your problem.

author: davorin
author_rank: Unknown
timestamp: October 17, 2014, 03:27:20 pm
content: EhmmmI didn't mention GPS time (o;Message ID 1000 outputs UTC time applied with the current 16 seconds correction...Right after mark pulse the UTC time is for example 17:23:46, whereas the UTC time mark week seconds calculate to 17:23:48 instead...Hmm...I missed UTC nanoseconds from Epoch...whatever that is (o;Code:FF81Start FlagE803Message ID = 10003100Data word count = 490000E879Header checksumB70ESet Time 10msec ticks, 32 bit00002400Sequence Number2400Satellite Measurement Sequence Number0000Navigation Solution Validity1000Navigation Solution Type0600Number of Measurements Used in Solution0000Polar Navigation1607GPS Week Number = 1814A93EGPS SecondsFrom Epoch, next run = AA3E0200GPS SecondsFrom Epoch0000GPS Nanoseconds From Epoch0000GPS Nanoseconds From Epoch0D00UTC Day = 130A00UTC Month = 10DE07UTC Year = 20141000UTC Hours = 163300UTC Minutes = 512400UTC Seconds = 36FFC9UTC Nanoseconds From Epoch9A3BUTC Nanoseconds From EpochCalculates to 999999999nsec...really close to 1sec (o;