thr3ads.net - freebsd stable - [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though... [Apr 2013]

If this information is useful, please help other people find it:
Share via:

Igor Mozolevsky

2013-Apr-28 17:48 UTC

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

Hi,
I'm having issues connecting Garmin GPS 18 to COM1 on 9.1, I get
nothing but silence. Identical setup works absolutely fine with Linux.
I've got PPS wire connected to DCD, but that seems to make no
difference on Linux, so I presume it shouldn't affect fbsd either.

On Linux, I get:


$ uname -a
Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux

$ sudo stty -F /dev/ttyS0 raw 4800
$ sudo stty -F /dev/ttyS0 -a
speed 4800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

$ sudo cat /dev/ttyS0
$GPGLL,0000.00000,N,00000.00000,W,170638.0,V*3D
$GPGLL,0000.00000,N,00000.00000,W,170638.0,V*3D
$GPGLL,0000.00000,N,00000.00000,W,170638.0,V*3D
$GPGLL,0000.00000,N,00000.00000,W,170639.0,V*3C
$GPGLL,0000.00000,N,00000.00000,W,170639.0,V*3C
$GPGLL,0000.00000,N,00000.00000,W,170639.0,V*3C
$GPGLL,0000.00000,N,00000.00000,W,170639.0,V*3C
$GPGLL,0000.00000,N,00000.00000,W,170639.0,V*3C
$GPGLL,0000.00000,N,00000.00000,W,170640.0,V*32



With FreeBSD, the story is different:

# uname -a
FreeBSD fbsd 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4
09:23:10 UTC 2012
root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

# stty -f /dev/cuau0.init raw 4800

# stty -f /dev/cuau0.init -a
speed 4800 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff ixany -imaxbel ignbrk
	-brkint -inpck -ignpar -parmrk
oflags: -opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

# cu -l /dev/cuau0 -s 4800
Connected

and after the 'Connected' there is just silence (should be getting
$GPGLL every 200ms from the GPS unit)...



Obviously I'm missing something, just can't figure out what it is...


Cheers,

-- 
Igor M.

Daniel O'Connor

2013-Apr-28 22:26 UTC

head link

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

On 29/04/2013, at 3:18, Igor Mozolevsky <igor at hybrid-lab.co.uk>
wrote:> I'm having issues connecting Garmin GPS 18 to COM1 on 9.1, I get
> nothing but silence. Identical setup works absolutely fine with Linux.
> I've got PPS wire connected to DCD, but that seems to make no
> difference on Linux, so I presume it shouldn't affect fbsd either.
<snip>> # cu -l /dev/cuau0 -s 4800
> Connected
> 
> and after the 'Connected' there is just silence (should be getting
> $GPGLL every 200ms from the GPS unit)...

Do you have any other serial ports?
They may be probed in a different order between the 2 OSs.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4358 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130429/d9b734f2/attachment.bin>

Igor Mozolevsky

2013-Apr-28 22:32 UTC

head link

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

On 28 April 2013 18:26, Daniel O'Connor <doconnor at gsoft.com.au>
wrote:
> Do you have any other serial ports?
> They may be probed in a different order between the 2 OSs.

Nope, that's the only serial port on the system:


# dmesg | grep uart
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0


-- 
Igor M.

Igor Mozolevsky

2013-Apr-28 22:41 UTC

head link

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

On 28 April 2013 13:48, Igor Mozolevsky <igor at hybrid-lab.co.uk> wrote:

<snip>
> # cu -l /dev/cuau0 -s 4800
> Connected
>
> and after the 'Connected' there is just silence (should be getting
> $GPGLL every 200ms from the GPS unit)...
> Obviously I'm missing something, just can't figure out what it
is...
I should add that when I connect through uplcom on cuaU0, the messages
come through (and ntpd can use them) but I need the UART connection
for the PPS sync...


-- 
Igor M.

Michael Butler

2013-Apr-28 23:52 UTC

head link

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

On 04/28/13 13:48, Igor Mozolevsky wrote:
> On Linux, I get:
 [ .. ]

Just a thought - Linux is not using flow-control ..
> $ sudo stty -F /dev/ttyS0 -a
> speed 4800 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp =
^Z; rprnt = ^R;
> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts                                          ^^^^^^

BSD does ..
> With FreeBSD, the story is different:
> # stty -f /dev/cuau0.init -a
> speed 4800 baud; 0 rows; 0 columns;
> lflags: -icanon -isig -iexten -echo -echoe -echok echoke -echonl echoctl
> 	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
> 	-extproc
> iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff ixany -imaxbel ignbrk
> 	-brkint -inpck -ignpar -parmrk
> oflags: -opost onlcr -ocrnl tab0 -onocr -onlret
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow                                          ^^^^^^^

	imb

Colin House

2013-Apr-28 23:56 UTC

head link

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

On 29/04/2013 3:48 AM, Igor Mozolevsky wrote:> Hi,
> I'm having issues connecting Garmin GPS 18 to COM1 on 9.1, I get
> nothing but silence. Identical setup works absolutely fine with Linux.
> I've got PPS wire connected to DCD, but that seems to make no
> difference on Linux, so I presume it shouldn't affect fbsd either.
...>
> With FreeBSD, the story is different:
>
> # uname -a
> FreeBSD fbsd 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4
> 09:23:10 UTC 2012
> root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>
> # stty -f /dev/cuau0.init raw 4800
>
> # stty -f /dev/cuau0.init -a
> speed 4800 baud; 0 rows; 0 columns;
> lflags: -icanon -isig -iexten -echo -echoe -echok echoke -echonl echoctl
> 	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
> 	-extproc
> iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff ixany -imaxbel ignbrk
> 	-brkint -inpck -ignpar -parmrk
> oflags: -opost onlcr -ocrnl tab0 -onocr -onlret
> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
> 	-dtrflow -mdmbuf
> cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
> 	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
> 	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
> 	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
>
> # cu -l /dev/cuau0 -s 4800
> Connected
>
> and after the 'Connected' there is just silence (should be getting
> $GPGLL every 200ms from the GPS unit)...
>
>
>
> Obviously I'm missing something, just can't figure out what it
is...
>
>
> Cheers,
>

If it helps any, I've got the 18x LVC (not the 5hz model) working on 9.0.

clock# uname -r
9.0-RELEASE

clock# head /dev/cuau0
$GPRMC,234655,A,3353.4847,S,15112.0482,E,000.0,130.4,280413,012.5,E*65
$GPGGA,234655,3353.4847,S,15112.0482,E,1,05,1.2,51.9,M,20.2,M,,*66
$GPGSA,A,3,02,05,17,24,25,,,,,,,,2.2,1.2,1.8*38
$GPGLL,3353.4847,S,15112.0482,E,234655,A*35
$GPRMC,234656,A,3353.4847,S,15112.0481,E,000.0,130.4,280413,012.5,E*65
$GPGGA,234656,3353.4847,S,15112.0481,E,1,05,1.2,51.9,M,20.2,M,,*66
$GPGSA,A,3,02,05,17,24,25,,,,,,,,2.2,1.2,1.8*38
$GPGLL,3353.4847,S,15112.0481,E,234656,A*35
$GPRMC,234657,A,3353.4848,S,15112.0480,E,000.0,130.4,280413,012.5,E*6A
$GPGGA,234657,3353.4848,S,15112.0480,E,1,04,1.8,52.0,M,20.2,M,,*68
clock#


It's been a good while since I set it up so I can't remember exactly 
which hoops I may have had to jump through.

Not sure if any of this is particularly helpful/relevant or not..

clock# grep cuau0 /etc/*
/etc/devfs.conf:link    cuau0   gps1
/etc/devfs.conf:link    cuau0   pps1
/etc/remote:    :dv=/dev/cuau0:cu=/dev/cuau0:at=hayes:du:pa=none:
/etc/remote:cuau0c|cua0c:dv=/dev/cuau0:br#9600:pa=none:
/etc/remote:uart0|com1:dv=/dev/cuau0:br#9600:pa=none:

clock# stty -a -f /dev/cuau0
speed 4800 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
         -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
         -nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon ixoff -ixany -imaxbel ignbrk
         -brkint -inpck ignpar -parmrk
oflags: -opost -onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd -hupcl clocal -cstopb -crtscts -dsrflow
         -dtrflow -mdmbuf
cchars: discard = ^@; dsusp = ^@; eof = ^@; eol = ^@; eol2 = ^@;
         erase = ^@; erase2 = ^@; intr = ^@; kill = ^@; lnext = ^@;
         min = 1; quit = ^@; reprint = ^@; start = ^@; status = ^@;
         stop = ^@; susp = ^@; time = 0; werase = ^@;

clock# stty -a -f /dev/cuau0.init
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
         -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
         -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
         brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
         -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
         eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
         lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
         status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

clock# ntpq -pn | grep 127
  127.127.1.0     .LOCL.          10 l   13   64  377    0.000 0.000   0.002
  127.127.20.1    .NMEA.           0 l 1107   16    0    0.000 0.029   0.002
o127.127.22.1    .PPS.            0 l   10   16  377    0.000 0.033   0.002

clock# grep 127.127 /etc/ntp.conf
restrict 127.127.1.0
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server  127.127.20.1    mode 0  minpoll 4       prefer  #  maxpoll 4    
prefer
fudge   127.127.20.1    flag1   1       flag2 0 time2 0.600 refid NMEA
server  127.127.22.1    mode 0  minpoll 2       prefer  iburst
fudge   127.127.22.1    refid PPS


hope this helps..
col

Lev Serebryakov

2013-Apr-29 07:47 UTC

head link

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

Hello, Igor.
You wrote 29 ?????? 2013 ?., 6:06:35:

IM> Once I narrowed down the problem (acpi uart), I stumbled across
IM> http://forums.freebsd.org/archive/index.php/t-15740.html
IM> Preventing the ACPI driver from seizing control of UART seems to work
IM> and cuau0 is now functional.
 Hm.  I  need to try this on my D2500CC, where I have 4 UARTs and none
 of them works.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>

Adrian Chadd

2013-Apr-29 07:51 UTC

head link

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

please file a PR!



Adrian


On 28 April 2013 19:06, Igor Mozolevsky <igor at hybrid-lab.co.uk>
wrote:> Once I narrowed down the problem (acpi uart), I stumbled across
>
> http://forums.freebsd.org/archive/index.php/t-15740.html
>
> Preventing the ACPI driver from seizing control of UART seems to work
> and cuau0 is now functional.
>
>
> Thanks to all,
>
> --
> Igor M. :-)
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"

Fabian Wenk

2013-Apr-29 15:53 UTC

head link

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

Hello Igor

On 29.04.2013 04:06, Igor Mozolevsky wrote:> Once I narrowed down the problem (acpi uart), I stumbled across
>
> http://forums.freebsd.org/archive/index.php/t-15740.html
>
> Preventing the ACPI driver from seizing control of UART seems to work
> and cuau0 is now functional.
I have a similar problem, but with a DCF77 Gude mouseCLOCK 
(connected to on-board COM2), which was working just fine on this 
system when running FreeBSD 7.4 (sio). But since I have upgraded 
to FreeBSD 9.1 (uart), ntpd does only get partial data from the 
mouseCLOCK. So today I tried with the above hint, but this did 
not help.

Without any modification (and also with disabled acpi for the 
uart) I do see messages like this (sorry for the line wrapping):

Apr 29 16:31:39 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 0 bits
Apr 29 16:31:39 superman ntpd[1737]: PARSE receiver #0: interval 
for following error message class is at least 00:01:00
Apr 29 16:31:39 superman ntpd[1737]: PARSE receiver #0: FAILED 
TIMECODE: 
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00..."
(check receiver configuration / wiring)
Apr 29 16:31:41 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 1 bits
Apr 29 16:31:43 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 2 bits
Apr 29 16:31:52 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 11 bits
[...]
Apr 29 16:33:01 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 4 bits
Apr 29 16:33:08 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 8 bits
Apr 29 16:33:16 superman ntpd[1737]: PARSE receiver #0: no data 
from device within poll interval (check receiver / wiring)


When I also add the following line to /boot/device.hints it does 
improve a little bit and ntpd sees more bits, but still not 
enough to be working (log entries below):
hint.uart.1.flags="0x100"

Apr 29 16:46:06 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 0 bits
Apr 29 16:46:06 superman ntpd[1737]: PARSE receiver #0: interval 
for following error message class is at least 00:01:00
Apr 29 16:46:06 superman ntpd[1737]: PARSE receiver #0: FAILED 
TIMECODE: 
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00..."
(check receiver configuration / wiring)
Apr 29 16:46:21 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 1 bits
Apr 29 16:46:53 superman ntpd[1737]: PARSE receiver #0: interval 
for following error message class is at least 00:01:00
Apr 29 16:46:53 superman ntpd[1737]: PARSE receiver #0: no data 
from device within poll interval (check receiver / wiring)
Apr 29 16:47:00 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 45 bits
Apr 29 16:47:41 superman ntpd[1737]: parse: convert_rawdcf: 
parity check FAILED for 
"--##--####-####RADMLS-24--24p-24---P1--81--2412-81-2481--8P_?"
Apr 29 16:47:41 superman ntpd[1737]: PARSE receiver #0: 2 
messages where suppressed, error condition class persists for 
00:01:35
Apr 29 16:47:41 superman ntpd[1737]: PARSE receiver #0: FAILED 
TIMECODE: 
"--##--####-####RADMLS-24--24p-24---P1--81--2412-81-2481--8P_" 
(check receiver configuration / wiring)
Apr 29 16:47:58 superman ntpd[1737]: PARSE receiver #0: no data 
from device within poll interval (check receiver / wiring)
Apr 29 16:48:00 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 23 bits
Apr 29 16:48:45 superman ntpd[1737]: parse: convert_rawdcf: 
parity check FAILED for 
"--##-------##-#-AD--S1--8124p-24--2P12-8121-4-2481--48-248P__"
Apr 29 16:48:45 superman ntpd[1737]: PARSE receiver #0: 1 message 
was suppressed, error condition class persists for 00:02:39
Apr 29 16:48:45 superman ntpd[1737]: PARSE receiver #0: FAILED 
TIMECODE: 
"--##-------##-#-AD--S1--8124p-24--2P12-8121-4-2481--48-248P_" 
(check receiver configuration / wiring)
Apr 29 16:49:00 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 18 bits
Apr 29 16:49:44 superman ntpd[1737]: parse: convert_rawdcf: 
parity check FAILED for 
"------#########---MLs-24--24p---81-P1--8121-41-4811--81-48P?_"
Apr 29 16:50:00 superman ntpd[1737]: parse: convert_rawdcf: 
INCOMPLETE DATA - time code only has 18 bits
Apr 29 16:50:00 superman ntpd[1737]: PARSE receiver #0: 2 
messages where suppressed, error condition class persists for 
00:03:54
Apr 29 16:50:00 superman ntpd[1737]: PARSE receiver #0: FAILED 
TIMECODE: "---##--####--#---" (check receiver configuration / wiring)
Apr 29 16:50:08 superman ntpd[1737]: PARSE receiver #0: no data 
from device within poll interval (check receiver / wiring)


Is there anything else I could try?


bye
Fabian

Apparently Analagous Threads

Search for more possibly parallel threads

freebsd stable - Apr 2013 - [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

[Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...

Apparently Analagous Threads