[INFO] [SOLVED] Can be the position and timestamp NMEA messages printed in cleartext in the stdout ? about galmon HOT 18 CLOSED

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.

from galmon.

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

from galmon.

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:

https://www.u-blox.com/sites/default/files/u-blox_ZED-F9P_InterfaceDescription_%28UBX-18010854%29.pdf

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.

from galmon.

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.

from galmon.

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.

from galmon.

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.

from galmon.

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

• for some reason in my system access to /dev/ttyACM0 always needs sudo or root or chmod 666 /dev/ttyACM0, strange, but anyway.

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.

from galmon.

And for the NTPD, would a PPS-signal suffice by itself? After setting the initial time, that is?

from galmon.

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.

from galmon.

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

from galmon.

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 galmon.

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.

from galmon.

I have an ublox ZED-F9P (#58) and NEO-M8N-0 (#33).
I have to check the ZED.

from galmon.

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.

• this is based on a convo had with Remc0 on the #galileo channel - i haven't yet tried it, but will be doing so later this week.

from galmon.

With at least C099-F9P evaluation board you can also route (different) messages via i2c to bluetooth/wifi.

from galmon.

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.

from galmon.

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.

from galmon.

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.

from galmon.