Closed amontefusco closed 4 years ago
There seems to already be option for that:
app.add_flag("--keep-nmea,-k", doKeepNMEA, "Don't disable NMEA");
You've tried that?
Also as default enabled "UBX-NAV-POSECEF" and "UBX-NAV-PVT" messages contain position information? They are pretty straightforward to decode. Message format is in:
BTW, for NTP-timing if you want accuracy you should consider using PPS-signal from receiver. Serial port read NMEA-derived time is not that very accurate.
Hmm... it just occured to me you would most likely need the NMEA/UBX -messagestream in unmodified form, "tapped" direct from serial input and sent onwards in some form. I've been thinking the same, but for raw messages to be fed to RTKLIB, so the same receiver could be used as RTK-basestation at the same time.
This should be doable, as ublox receiver supports quite a large number of concurrent messages mainly limited on serial port bandwidth, bit with large baudrate this should be quite a lot.
There seems to already be option for that:
app.add_flag("--keep-nmea,-k", doKeepNMEA, "Don't disable NMEA");
You've tried that?
yes, I did but I was unable to find WHERE that stuff is kept.
BTW, for NTP-timing if you want accuracy you should consider using PPS-signal from receiver. Serial port read NMEA-derived time is not that very accurate.
I'm very aware about that stuff (ntpd config and PPS detection using pps-gpio kernel module). Indeed my question here is meant to understand if I can use the same (valuable) GNSS receiver both for GALMON network and ntpd synch.
And, as you mentioned, the ntpd would like to read regular ASCII NMEA sentences, so probably there is no way, apart from buy another ZED breakout board.
Sure it is doable, I'll look into this.
Start looks promising, with interceptty I managed easily to "tap" serial port traffic to/from receiver:
sudo interceptty -s 'ispeed 230400 ospeed 230400' -l /dev/ttyACM0 /dev/ttyDUMMY
It can be found at:
https://github.com/geoffmeyers/interceptty/blob/master/interceptty
and install is easy as:
./configure
make
make install
ubxtool is then connected to this:
./ubxtool --wait --port /dev/ttyDUMMY
Then next step is to strip extra padding and feed that into program parsing it.
And for the NTPD, would a PPS-signal suffice by itself? After setting the initial time, that is?
And for the NTPD, would a PPS-signal suffice by itself? After setting the initial time, that is?
As per current implementation, ntpd needs a continuous stream of NMEA messages.
Sure it is doable, I'll look into this.
It seems that -k is acting in such a way that the receiver is configured to provide info both as per NMEA ASCII protocol and a binary (proprietary?) protocol.
At this point, the NMEA is readable just reading the very same/dev.
ntpq -n -cpeers pine64: Mon Jan 6 15:10:05 2020
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
*127.127.20.0 .GPS. 0 l 9 16 377 0.000 -3.046 37.750
+80.211.128.146 193.204.114.232 2 u 1 64 7 33.616 48.888 48.703
+147.135.207.213 85.199.214.102 2 u - 64 7 34.994 60.604 55.843
+212.45.144.206 193.204.114.232 2 u 67 64 3 22.869 32.269 31.512
+80.211.178.99 216.239.35.0 2 u 68 64 3 13.434 38.059 29.433
+147.135.207.214 85.199.214.102 2 u 64 64 3 38.806 32.899 32.644
Alas, when operated together, the jitter as seen by ntpd is remarkable higher (below the values achievable with ubxtool stopped).
ntpq -n -cpeers pine64: Mon Jan 6 16:10:24 2020
remote refid st t when poll reach delay offset jitter
==============================================================================
o127.127.20.0 .GPS. 0 l 2 16 377 0.000 -0.007 0.007
Which reveiver are you using? I do not seem to be able to enable NMEA-messages with F9P, even with -k option there seem to be no NMEA messages in the tapped stream - haven't parsed it though but looking the stream with hexdump it seems so. UBX raw messages yes, so the tapping with interceptty seems to work fine. I have to search one of my old F8s and try with that if it works differently.
I believe USB/serial device sharing is not that well defined in Linux, so behaviour might be not so predictable. The jitter might be because of this maybe?
Though should the use of PPS signal fix this jitter as well, if it is just on the serial message, and PPS should retain the same accuracy?
From your previous post I am guessing F8, correct?
I have one somewhere, just have to find it. But definitely my F9 is not outputting any NMEA right now with -k flag or not.
I have an ublox ZED-F9P (#58) and NEO-M8N-0 (#33).
I have to check the ZED.
for the F9P, if you're using the USB output for normal signals, you should be able to add a ttl-usb adapter onto UART2 of the F9P board and feed that separately into ntpd.
With at least C099-F9P evaluation board you can also route (different) messages via i2c to bluetooth/wifi.
Which receiver are you using? I do not seem to be able to enable NMEA-messages with F9P, even with -k option there seems to be no NMEA messages in the tapped stream - haven't parsed it though but looking the stream with hexdump it seems so.
You are right, even with -k option, the F9P doesn't emit NMEA messages interspersed with the binary stream.
for the F9P, if you're using the USB output for normal signals, you should be able to add a ttl-usb adapter onto UART2 of the F9P board and feed that separately into ntpd.
From a quick test, it seems that even there (RX2/RX1) there are the same binary messages, not NMEA ones.
for the F9P, if you're using the USB output for normal signals, you should be able to add a ttl-usb adapter onto UART2 of the F9P board and feed that separately into ntpd.
From a quick test, it seems that even there (RX2/RX1) there are the same binary messages, not NMEA ones.
ah, yes - you may need to use ucenter to enable the messaging; though that should have read UART1.
UART1 can be used for host messaging (as can USB) but UART2 cannot be for host messaging. It seems like you can enable NMEA on UART2 - but UART1 is probably the better choice.
ah, yes - you may need to use ucenter to enable the messaging; though that should have read UART1.
You are right, I wiggled with parameters in Windows ucenter 19 and now I get on UART1 (dubbed TX1 on ArduSimple) the NMEA messages @38400 bps.
On Ardusimple, do not forget to connect IOREF !
Thanks akhepcat and all for the support.
ntpq -n -cpeers pine64.local andrewp: Fri Jan 10 16:37:06 2020
remote refid st t when poll reach delay offset jitter
==============================================================================
o127.127.20.0 .GPS. 0 l 13 16 377 0.000 -0.007 0.009
The purpose would be to use the same systems as NTP and position server, whilst ubxtool is running.