Time, overboard


Brian Davis
 

Finally finished fixing my old boat, and am back finishing up my rig.  I'm doing 3d brackets right now for final version of equipment box, which holds all this stuff currently in my test deck:



I'm using an LRS 300w 24v power supply, FYSETC S6 V2 board, and a Raspberry Pi 4B 8G running StellarMate (INDI distribution put out by the main INDI developer Jasem).  

I spent a bit of time thinking about time, and the best way to use it.  After all, a GEM mount is nothing more than a big clock, and it seems sensible to spend a little time making it an accurate clock.  I wanted to fully leverage the new Ublox M8M GPS chip ($14), and so I turned the RPi into a Stratum 1 timeserver, by feeding the GPS data to GPSD and NTPd on the Pi.  NTP is key to this.  By itself, GPS data isn't very precise at all.  NMEA sentences arrive in 9600b bursts from the serial port about a half second late with a lot of jitter.  Using this directly just means your clocks won't be very accurate or precise.  A half second with 20 or 30 ms of jitter is a lot in computer land.  NTP uses the PPS output of the Ublox to discipline the system time on the Pi to a very high precision clock.  Further, I fed the Ublox PPS signal to the FYSETC, and configured Onstep to use it.  I'm also using a DS3231 RTC chip ($4.00) on the PI, to speed up the GPS lock, and to ensure Onstep doesn't get a bogus startup time when INDI sets it.  Today, it's all working as desired.  Here's the final result:



Here, you can see that the Pi is fully synched as a stratum 1 reference time source, and the clock is accurate to about 3 nanoseconds.  You can also see, that Onstep is using the PPS signal as well, as reported by the INDI driver.  The NeoM8M chip has a serious advantage of being very very fast to sync up to the three GPS constellations, which means by the time INDI sets the time

So, now I'll measure again.  I'll be thrilled to see a small boost in tracking rate and pointing accuracy from this, but even if I don't, I still get a kick out of having such an accurate clock running my CGEM system!  


Chad Gray
 

I have always had problems with raspberry pi and GPS when I connect some USB devices to it.

My GPS hooked up via the GPIO pins works great until i start adding devices to the raspberry pi.

Have you run into any problems like this if/when you add your astronomy devices to the Pi?

Chad

On Tue, Sep 14, 2021 at 6:56 PM Brian Davis <tapperbld@...> wrote:
Finally finished fixing my old boat, and am back finishing up my rig.  I'm doing 3d brackets right now for final version of equipment box, which holds all this stuff currently in my test deck:



I'm using an LRS 300w 24v power supply, FYSETC S6 V2 board, and a Raspberry Pi 4B 8G running StellarMate (INDI distribution put out by the main INDI developer Jasem).  

I spent a bit of time thinking about time, and the best way to use it.  After all, a GEM mount is nothing more than a big clock, and it seems sensible to spend a little time making it an accurate clock.  I wanted to fully leverage the new Ublox M8M GPS chip ($14), and so I turned the RPi into a Stratum 1 timeserver, by feeding the GPS data to GPSD and NTPd on the Pi.  NTP is key to this.  By itself, GPS data isn't very precise at all.  NMEA sentences arrive in 9600b bursts from the serial port about a half second late with a lot of jitter.  Using this directly just means your clocks won't be very accurate or precise.  A half second with 20 or 30 ms of jitter is a lot in computer land.  NTP uses the PPS output of the Ublox to discipline the system time on the Pi to a very high precision clock.  Further, I fed the Ublox PPS signal to the FYSETC, and configured Onstep to use it.  I'm also using a DS3231 RTC chip ($4.00) on the PI, to speed up the GPS lock, and to ensure Onstep doesn't get a bogus startup time when INDI sets it.  Today, it's all working as desired.  Here's the final result:



Here, you can see that the Pi is fully synched as a stratum 1 reference time source, and the clock is accurate to about 3 nanoseconds.  You can also see, that Onstep is using the PPS signal as well, as reported by the INDI driver.  The NeoM8M chip has a serious advantage of being very very fast to sync up to the three GPS constellations, which means by the time INDI sets the time

So, now I'll measure again.  I'll be thrilled to see a small boost in tracking rate and pointing accuracy from this, but even if I don't, I still get a kick out of having such an accurate clock running my CGEM system!  


Brian Davis
 

No, but I'm very careful to plug in the minimum number of USB devices directly into the Pi.  The achilles heel of all Raspberry Pi's is the USB subsystem which is chronically underpowered, and shares data lanes with the ethernet port.  I always connect a powered hub, and plug all USB devices into the hub, not the Pi.   That seems to help in many ways.

I'm not a fan of pluggable GPS dongles.  They're fine for location, but terrible for time.  For less money, you can pick up a gps breakout like this one:


and do it the right way, and sync time with both Onstep and the control station.  Failing that, a DS3231 chip with its SQW pin tied to Onstep's PPS pin is a better option, in my personal opinion, for whatever that's worth :)

Brian


On Tue, Sep 14, 2021 at 6:11 PM Chad Gray <rchadgray@...> wrote:
I have always had problems with raspberry pi and GPS when I connect some USB devices to it.

My GPS hooked up via the GPIO pins works great until i start adding devices to the raspberry pi.

Have you run into any problems like this if/when you add your astronomy devices to the Pi?

Chad

On Tue, Sep 14, 2021 at 6:56 PM Brian Davis <tapperbld@...> wrote:
Finally finished fixing my old boat, and am back finishing up my rig.  I'm doing 3d brackets right now for final version of equipment box, which holds all this stuff currently in my test deck:



I'm using an LRS 300w 24v power supply, FYSETC S6 V2 board, and a Raspberry Pi 4B 8G running StellarMate (INDI distribution put out by the main INDI developer Jasem).  

I spent a bit of time thinking about time, and the best way to use it.  After all, a GEM mount is nothing more than a big clock, and it seems sensible to spend a little time making it an accurate clock.  I wanted to fully leverage the new Ublox M8M GPS chip ($14), and so I turned the RPi into a Stratum 1 timeserver, by feeding the GPS data to GPSD and NTPd on the Pi.  NTP is key to this.  By itself, GPS data isn't very precise at all.  NMEA sentences arrive in 9600b bursts from the serial port about a half second late with a lot of jitter.  Using this directly just means your clocks won't be very accurate or precise.  A half second with 20 or 30 ms of jitter is a lot in computer land.  NTP uses the PPS output of the Ublox to discipline the system time on the Pi to a very high precision clock.  Further, I fed the Ublox PPS signal to the FYSETC, and configured Onstep to use it.  I'm also using a DS3231 RTC chip ($4.00) on the PI, to speed up the GPS lock, and to ensure Onstep doesn't get a bogus startup time when INDI sets it.  Today, it's all working as desired.  Here's the final result:



Here, you can see that the Pi is fully synched as a stratum 1 reference time source, and the clock is accurate to about 3 nanoseconds.  You can also see, that Onstep is using the PPS signal as well, as reported by the INDI driver.  The NeoM8M chip has a serious advantage of being very very fast to sync up to the three GPS constellations, which means by the time INDI sets the time

So, now I'll measure again.  I'll be thrilled to see a small boost in tracking rate and pointing accuracy from this, but even if I don't, I still get a kick out of having such an accurate clock running my CGEM system!  


Chad Gray
 

Good idea on the powered usb hub.  I should try that instead of plugin everything into the Pi.

I was using the neo type gps unit and following this guide to get the GPS as the NTP time source.

Chad

On Tue, Sep 14, 2021 at 7:30 PM Brian Davis <tapperbld@...> wrote:
No, but I'm very careful to plug in the minimum number of USB devices directly into the Pi.  The achilles heel of all Raspberry Pi's is the USB subsystem which is chronically underpowered, and shares data lanes with the ethernet port.  I always connect a powered hub, and plug all USB devices into the hub, not the Pi.   That seems to help in many ways.

I'm not a fan of pluggable GPS dongles.  They're fine for location, but terrible for time.  For less money, you can pick up a gps breakout like this one:


and do it the right way, and sync time with both Onstep and the control station.  Failing that, a DS3231 chip with its SQW pin tied to Onstep's PPS pin is a better option, in my personal opinion, for whatever that's worth :)

Brian

On Tue, Sep 14, 2021 at 6:11 PM Chad Gray <rchadgray@...> wrote:
I have always had problems with raspberry pi and GPS when I connect some USB devices to it.

My GPS hooked up via the GPIO pins works great until i start adding devices to the raspberry pi.

Have you run into any problems like this if/when you add your astronomy devices to the Pi?

Chad

On Tue, Sep 14, 2021 at 6:56 PM Brian Davis <tapperbld@...> wrote:
Finally finished fixing my old boat, and am back finishing up my rig.  I'm doing 3d brackets right now for final version of equipment box, which holds all this stuff currently in my test deck:



I'm using an LRS 300w 24v power supply, FYSETC S6 V2 board, and a Raspberry Pi 4B 8G running StellarMate (INDI distribution put out by the main INDI developer Jasem).  

I spent a bit of time thinking about time, and the best way to use it.  After all, a GEM mount is nothing more than a big clock, and it seems sensible to spend a little time making it an accurate clock.  I wanted to fully leverage the new Ublox M8M GPS chip ($14), and so I turned the RPi into a Stratum 1 timeserver, by feeding the GPS data to GPSD and NTPd on the Pi.  NTP is key to this.  By itself, GPS data isn't very precise at all.  NMEA sentences arrive in 9600b bursts from the serial port about a half second late with a lot of jitter.  Using this directly just means your clocks won't be very accurate or precise.  A half second with 20 or 30 ms of jitter is a lot in computer land.  NTP uses the PPS output of the Ublox to discipline the system time on the Pi to a very high precision clock.  Further, I fed the Ublox PPS signal to the FYSETC, and configured Onstep to use it.  I'm also using a DS3231 RTC chip ($4.00) on the PI, to speed up the GPS lock, and to ensure Onstep doesn't get a bogus startup time when INDI sets it.  Today, it's all working as desired.  Here's the final result:



Here, you can see that the Pi is fully synched as a stratum 1 reference time source, and the clock is accurate to about 3 nanoseconds.  You can also see, that Onstep is using the PPS signal as well, as reported by the INDI driver.  The NeoM8M chip has a serious advantage of being very very fast to sync up to the three GPS constellations, which means by the time INDI sets the time

So, now I'll measure again.  I'll be thrilled to see a small boost in tracking rate and pointing accuracy from this, but even if I don't, I still get a kick out of having such an accurate clock running my CGEM system!