beta-tester/RPi-GPS-PPS-StratumOne

Would This Receiver Work?

AlexLandherr opened this issue · 6 comments

I found this GNSS timing module and am wondering if it could be used with your repo?

My suspicion is that it can; though I value your opinion.

I already asked the seller and they said that it could indeed be wired up to the GPIO without issue for data, PPS and power.

Seller quote from email exchange:

Dear customer,
 
Yes, ELT0030 module can be used with RPI. You can either connect it with USB cable to RPI USB port or connect with some wires to RPI serial port (ELT0030 have 3V serial port signals).

hi, according the silkscreen from the bottom product photo of the gnss there is written

...
3 TIMEPULSE
...
9 RX / MOSI SPI
10 TX / MISO SPI
...

3 is the PPS signal, 9 is RX and 10 TX. i think the labeling is from the point of view of the GNSS module.
so GNSS 3 TIMEPULSE goes to PI GPIO 4 / Pin 7, GNSS 9 RX goes to PI GPIO 14 TXD / Pin 8 and GNSS 10 TX goes to PI GPIO 15 RXD / Pin 10.

make sure the GNSS module is not set to SPI mode for communication.

when wired up this way, you can use my script without changing the PPS setting for the GPIO pin.

PS.: this is a very pricy device you are interested in. when you simply need it for the Stratum clock for private use and when you do not need the other stuff from the silkscreen (4, 7, 8 for frequenry reference) then i would say the device is way too expensive for the usecase.

note: i guess that you can not communicate with the GNSS directly anymore when gspd service takes over the control of the GNSS, in case you need some fancy information from the GNSS device that the normal NMEA isnt giving you.

the NMEA information you can get from gpsd in raw format and in processed format as JSON output. e.g.: gpspipe -w or gpspipe -R

EDIT: and GND an +5V you can take from the PI header as well.

I know it's pricey, I am just checking it out.
If I do get it it's a lot cheaper than what's based on the OCP-TAP Time Card.

If I ever do go full timing nerd this module would be worth it.

Thanks for the help; very much appreciated!

for precision of the stratum clock:

  1. use all hardware in a controlled temperature environment. temperature jumps will be clearly visible in jumps of time precisions. (running warm/hot is not an issue but it must be constant in temperature)
  2. keep the workload of the RPi as low as possible - best use the RPi without graphical interface.

Is a "regular" RPi with an Ethernet port better than say an RPi Zero 2 W using a Micro-USB-to-Ethernet adapter?

i don't know. i tend to say that a built in ethernet card would be better - less latency because it is more direct (CPU->PCIE->ETH RPi4) than going to a (CPU->USB->USB->ETH RPi Zero2)

as far as i know the built-in and the USB ethernet do not support the higher precision time protocol (PTP) - in my script i install the packages for that, but when the hardware does not have that capability it will not help to sync other clients to get a more precise sync.

anyway, with this stratum clock, do not expect better precision than µs range. the best chrony with my 20€ cheap GPS device was showing me was 0.1µs. but this means nothing - this was what chrony was thinking its precision was. i have no test-equipment to verify this numbers. the guy from gpsd project just laughed about the numbers the system tells. the real precision is not THAT good. because of all the delays/jitters/errors.

Ok, thanks!