We are developing a distributed sensor setup in which we’ll use the Reach for high-precision georeferencing of measurements on a mobile platform. However, as time synchronization between the sensors is of high importance, we want to use the Reach rover module as a Stratum-1 time server by using the time mark pulse.
Preferably, the Reach would be running the ntpd and gpsd deamons itself, thus functioning as the time server for the entire network, but alternatively we need to use an external module for running the software.
Can you provide some details about the schematics of the Reach? Have you interfaced the uBlox module to the Edison directly? Is the time mark puls available on one of the Edison’s pins for accurate timestamping of the GPS time information?
Also, what are the real-time capabilities of the Edison in the software version you are shipping? Would it be possible to attach/build a kernel module for monitoring of the time mark pulse?
Basically what I want to do is to draw on all the great information found on e.g. this page: GPSD redirection page and set up a similar system with the Reach.
I think it would be a great addition to the software stack of the module if you could provide a high-accuracy time server in addition to the high accuracy GPS information.
Hi, is there still something going on with this project?
We need to sync a timecode device with the GPS-time of our M2 / RS2, so an NTP that broadcasts the EMLIDs time would be the most direct & reliable way to solving this problem. I know you can buy dedicated GPS-masterclocks for this – but why, if we basically have something like that already in our hands.
So far we’re planning to parse the RS2s NMEA-string and sync the system time of our PC, then sync our timecode-device with the PCs system time. But that sounds like begging for unrecognized errors if you ask me…
So any hints about reliably syncing the PC / MACs system time with the EMLIDs GPS-time are greatly appreciated! THANKS
thanks for answering. As far as I understand, the PPS is for correcting a time signal within a one second timespan. Is that correct?
What we need is the full time string as a timed stream, which we are now trying to read from the TCP-position output of the EMLID (in this case: RS+). Turns out we’re not that fit in this space, so could you give us a hint on what command line magic to use to get the output of that (LLH) position stream to our terminal?
Or can we steam the NMEA protocol and use listen to it with something like the gpsd, chrony or something like that to sync my MACs / PCs computer clock directly, basically using the EMLID as a NTP-server??
Sorry, it’s a lot of new stuff for us, trying to figure out the details, so much info…
Hi Svetlana, yes, we did that (NMEA-TCP-streaming). But then we would still have to verify that the parsed signal from that action is timed below the threshold that is critical to us. Plus we would have to write the Software. So as I said, while I’m sure it can be done, it’s more cost effective for us to just buy the GPS-NTP-server and get the precision guaranteed by third parties without further questions
To sync the system time of our camera, we either need an NTP-server, or a timecode signal, both of wich have to be synced to the EMLID (GPS) time, with a max deviation of about 0.01 seconds.
Hi Vincent, not sure what are you connecting Reach RS2 to, but if you want to have a good time sync you can connect to the PPS pin, which is synchronized to a full second with very high accuracy. Not available on a Mac or Windows machine, but if you are using something like a Raspberry Pi it could totally work.
A typical setup is to listen both to the PPS pin and to the NMEA stream. You read the absolute time from NMEA and get the precise synchronization using the PPS output. GPSD actually has support for both NMEA and PPS. A much cheaper setup than buying a dedicated NTP server.
Hi Igor, yes the dedicated ntp is much easier, no fiddling with the NMEA stream and the PPS. I thought I got a deal with my 350$ piece, but SBM put me to shame Seems like exactly the same board inside too, since the LEDs, ports & thing are identical…
Anyways, after breaking my ears & eyebrows finding a good solution to sync the Cam with the GPS time this setup turned out really great and it’s not even a big deal anymore that the time signal isn’t coming straight from the EMLID.