Closed mreinart closed 5 years ago
You have to manually 'pipe' Dragino's GPS standard output onto SoftRF program's standard input as written in Example 1.
Resolution: invalid
Dear Linar,
thanks for the quick reply - but have done this too - this is what I meant with
... or commands as document in PI Examples
and how I also controlled protocol
(FANET/OGNT
P) and band
settings.
e.g. { echo "{class:SOFTRF,protocol:FANET}" ; cat /dev/ttyS0 ; } | sudo ./SoftRF
or { echo "{class:SOFTRF,protocol:OGNTP}" ; cat /dev/ttyS0 ; } | sudo ./SoftRF
which is currently running.
recent output:
pi@pi0:~/srf/SoftRF/software/firmware/source/SoftRF $ { echo "{class:SOFTRF,protocol:OGNTP}" ; cat /dev/ttyS0 ; } | sudo ./SoftRF
SX1276 RFIC is detected.
$GPGGA,155142.000,4913.1702,N,00822.4818,E,1,10,0.79,105.8,M,47.9,M,,*65
$GPGLL,4913.1702,N,00822.4818,E,155142.000,A,A*59
$GPGSA,A,3,03,23,02,01,22,06,17,31,07,09,,,1.06,0.79,0.71*00
$GPGSV,3,1,12,23,75,072,24,09,64,229,37,06,55,290,26,03,44,097,37*7E
$GPGSV,3,2,12,22,25,105,11,19,23,247,,02,16,318,27,17,16,234,25*79
$GPGSV,3,3,12,07,13,176,16,01,06,154,22,31,05,029,21,26,05,065,16*75
$GPRMC,155142.000,A,4913.1702,N,00822.4818,E,0.14,18.24,090919,,,A*5C
$GPVTG,18.24,T,,M,0.14,N,0.25,K,A*00
$GPGLL,4913.1702,N,00822.4818,E,155142.000,A,A*59
$GPGSA,A,3,03,23,02,01,22,06,17,31,07,09,,,1.06,0.79,0.71*00
$GPGGA,155142.000,4913.1702,N,00822.4818,E,1,10,0.79,105.8,M,47.9,M,,*65
$GPGSV,3,1,12,23,75,072,24,09,64,229,37,06,55,290,26,03,44,097,37*7E
$GPGSV,3,2,12,22,25,105,11,19,23,247,,02,16,318,27,17,16,234,25*79
$GPGSV,3,3,12,07,13,176,16,01,06,154,22,31,05,029,21,26,05,065,16*75
$GPRMC,155142.000,A,4913.1702,N,00822.4818,E,0.14,18.24,090919,,,A*5C
after the initial message SX1276 RFIC is detected.
only lines from GPS are seen.
Best regards Manfred
There were no reports from numerous builders of Raspberry Edition that they had any issues with bringing it up, provided that the Dragino board and Raspberry itself are fully functional. See #60 as an example.
Inspect your hardware and work with your seller if it is defective.
Dear Linar,
again thanks for the quick reply. Effectively I have 2x the same Dragino HAT and also was testing on a PI-0 - in parallel and also Hats interchanged - same behaviour. Thus I am ruling out a basic defect of the RasPi(s) or the Draginos. Nevertheless I will try to find in Dragino forums what might cause Lora reception issues.
Would be thankful for any hint on where in the SoftRF source I might place additional debugging to track potential issues down.
Thanks&Regards Manfred
I have exactly the same problem.
I am using a pi3 b+. To get the dragino to work required substitution of the ttyAMA0 to ttyS0, as specified in the dragino 'how to get the board working on a pi3' on their website. With this change it provides the GPS sentences and works with XCSoar as a device on the ttyS0 port, but trying to use the command '( echo "(class:SOFTRF,protocol:LEGACY,band:EU)" ; cat /dev/ttyS0 ; ) / sudo./SoftRF' doesn't appear to work. There are certainly no sentences added with the SoftRF data. (This is written on my mobile phone so some of the characters in that command scentence aren't correct) Hope this helps. Daren
On Mon, 9 Sep 2019, 17:16 Linar Yusupov, notifications@github.com wrote:
There were no reports from numerous builders of Raspberry Edition that they had any issues with bringing it up, provided that the Dragino board and Raspberry itself are fully functional. See #60 https://github.com/lyusupov/SoftRF/issues/60 as an example.
Inspect your hardware and work with your seller if it is defective.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lyusupov/SoftRF/issues/67?email_source=notifications&email_token=ALCEUUMDIG3KNYKLVPICGELQIZZFJA5CNFSM4IU4DBG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6IF4JA#issuecomment-529554980, or mute the thread https://github.com/notifications/unsubscribe-auth/ALCEUUNCSLCCGMFUOWI3SETQIZZFJANCNFSM4IU4DBGQ .
Manfred, several prerequisites must be met for the SoftRF program to start emitting $PFLAx messages.
If I would have a situation like you do, I would:
1) enable SoftRF 'private' messages:
pi@raspberrypi:/run/tmp/SoftRF/SoftRF $ { echo "{class:SOFTRF,nmea:{private:true}}" ; cat /dev/ttyAMA0 ; } | sudo ./SoftRF
SX1276 RFIC is detected.
$GPRMC,093352.073,A,XXXX.XXXX,N,0XXXX.v,E,000.0,237.3,250100,,,A*6D
$GPVTG,237.3,T,,M,000.0,N,000.0,K,A*08
$GPGGA,093353.073,XXXX.XXXX,N,0XXXX.XXXX,E,1,06,2.4,166.3,M,13.1,M,,0000*5C
$PSRFO,948792832,01017F0BF6E71BFB5886D9513345116DE7CC1FBC
$GPGSA,A,3,27,16,08,10,32,18,,,,,,,3.1,2.4,1.9*3D
$GPGSV,3,1,12,10,75,178,43,27,65,235,48,20,64,083,,04,55,205,42*72
$GPGSV,3,2,12,08,42,299,41,21,37,106,12,15,23,046,,32,14,165,32*71
$PSRFI,948792832,04D8C503B18300F12804FC2B071054EEF0D44433,0
$GPGSV,3,3,12,18,13,282,35,16,11,220,34,24,02,083,,11,01,298,*72
$GPRMC,093353.073,A,XXXX.XXXX,N,0XXXX.XXXX,E,000.0,237.3,250100,,,A*6C
$PFLAA,3,-19,-23,17,3,C5D804!OGN_C5D804,341,,0,00000.0,1*58
$PFLAU,1,1,2,1,3,-129,2,17,30*72
where each:
2) then I would use an SDR receiver with SDRSharp or similar software to monitor frequency, spectrum and quality of transmitted frames from aside
3) I would also use 'top' utility to make sure that SoftRF program has enough CPU usage and solely occupies one hardware CPU thread:
top - 09:48:00 up 120 days, 19:06, 4 users, load average: 0.39, 0.30, 0.35
Tasks: 155 total, 2 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu0 : 28.8 us, 0.0 sy, 0.0 ni, 70.8 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 15.0 us, 5.7 sy, 0.0 ni, 79.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 0.7 us, 0.7 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 945516 total, 151900 free, 114392 used, 679224 buff/cache
KiB Swap: 102396 total, 92988 free, 9408 used. 585024 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24276 root 20 0 29164 3224 3028 R 40.8 0.3 0:05.23 SoftRF
... skipped ...
My personal experience with SX1276 might help: I also had issues with the SX1276 not receiving anything because it's crystal was several kHz off. After tuning, it receives quite well now.
To test this, you need to get your SX1276 to transmit, then see on your transmission at the RTLSDR/OGN receiver's log output; as a nice feature, the OGN receiver software log shows you how much the transmitted signal is off the correct center frequency.
Dear Linar,
thanks for the hints. checked 1 and 3 so far
Best regards, Manfred
ad 3: on PI0 with nothing else running but top
CPU consumption of SoftRF executable varies around 90%
ad 1:
{ echo "{class:SOFTRF,nmea:{private:true}}" ; cat /dev/ttyS0 ; } | sudo ./SoftRF
and also added further options like protocol OGNTP
and band EU
.$GPVTG,223.22,T,,M,0.33,N,0.62,K,A*3A
$GPGLL,4913.1697,N,00822.4831,E,113146.000,A,A*59
$GPGSV,3,2,12,22,46,231,,32,41,082,29,14,39,115,26,28,24,304,*79
$GPGSV,3,3,12,03,24,230,,27,22,156,18,RAy�BX����u���F�<R�k?$GPGSA,A,3,18,27,08,11,01,32,14,,,,,,1.73,1.44,0.96*08
$GPGLL,4913.1694,N,00822.4825,E,113156.000,A,A*5E
$GPGSA,A,3,18,08,11,01,32,14,,,,,,,2.05,1.80,0.98*09
$GPGSV,3,1,12,18,82,329,23,11,67,289,20,08,57,181,38,01,57,293,34*77
$GPGSV,3,2,12,22,46,231,,32,41,082,28,14,39,115,25,28,24,304,*7B
$GPGSV,3,3,12,03,24,230,,27,22,156,,10,20,055,20,24,01,019,*77
$GPRMC,113156.000,A,4913.1694,N,00822.4825,E,0.25,199.34,100919,,,A*68
$GPVTG,199.34,T,,M,0.25,N,0.47,K,A*3F
and
$GPGGA,114320.000,4913.1805,N,00822.4833,E,1,10,1.02,106.0,M,47.9,M,,*61
$GPGLL,4913.1808,N,00822.4833,E,114326.000,A,A*50
$GPGSA,A,3,18,27,08,22,01,32,11,14,28,03,,,1.32,1.02,0.84*05
$GPGSV,4,1,13,18,85,015,27,11,72,284,23,01,62,297,28,22,51,233,29*7F
$GPGSV,4,2,13,08,51,180,26,14,42,109,29,32,41,075,33,03,29,232,18*78
$GPGSV,4,3,13,28,24,299,17,27,17,157,25,10,16,056,20,17,03,321,*71
$GPGSV,4,4,13,24,01,014,*49
$GPRMC,114326.000,A,4913.1808,N,00822.4833,E�t<�tI�t�3�͍l?$GPGGA,114332.000,4913.1808,N,00822.4833,E,1,10,1.02,106.0,M,47.9,M,,*6F
$GPGLL,4913.1808,N,00822.4833,E,114332.000,A,A*55
$GPGSA,A,3,18,27,08,22,01,32,11,14,28,03,,,1.32,1.02,0.84*05
$GPGSV,4,1,13,18,85,015,26,11,72,283,23,01,62,297,29,22,51,233,29*78
$GPGSV,4,2,13,08,51,180,27,14,42,109,29,32,41,075,32,03,29,232,18*78
$GPGSV,4,3,13,28,24,299,17,27,17,157,26,10,16,056,19,17,03,321,*78
$GPGSV,4,4,13,24,01,014,*49
$GPRMC,114332.000,A,4913.1808,N,00822.4833,E,0.26,178.04,100919,,,A*6C
$GPVTG,178.04,T,,M,0.26,N,0.47,K,A*30
SoftRF in 'normal' (default) mode generates :
- but this is valid only when SoftRF's internal NMEA/JSON parser has got a GNSS fix.
Your GGA and RMC sentences are looking Ok for my eyes, but I suspect that SoftRF's parser doesn't think so.
You say that 'have recognized some gabled characters in the output stream...' I suspect you have a conflicting process in your Raspberry system that competes for your GNSS input (/dev/ttyS0) with SoftRF. Typically it is the built-in 'GPSD service'. But it can be some other application as well.
You have to provide clean NMEA, '\<CR>\<LF>'-terminated stream to your SoftRF program input. It will not operate properly otherwise.
Resolution: unable to reproduce
Hello Linar, not sure why you are so fast in declaring a reported issue close ;-). Reproduced on
Will analyze tty output and NMEA parser behaviour more deeply.
Raw NMEA output from GPS:
$GPGLL,4913.1693,N,00822.4774,E,190042.000,A,A*5D
$GPGSA,A,3,05,30,07,09,13,02,,,,,,,2.74,1.92,1.95*0C
$GPGSV,2,1,08,30,74,177,43,07,62,068,30,05,56,292,34,09,30,090,24*77
$GPGSV,2,2,08,13,26,273,24,02,22,240,24,28,11,157,,06,03,198,*79
$GPRMC,190042.000,A,4913.1693,N,00822.4774,E,0.23,101.89,100919,,,A*6A
$GPVTG,101.89,T,,M,0.23,N,0.42,K,A*3B
$GPGGA,190043.000,4913.1693,N,00822.4775,E,1,6,1.92,124.0,M,47.9,M,,*59
$GPGLL,4913.1693,N,00822.4775,E,190043.000,A,A*5D
$GPGSA,A,3,05,30,07,09,13,02,,,,,,,2.74,1.92,1.95*0C
Could well be line endings are just <LF>
s (0x0a
) as we are on a IX platform.
Best regards Manfred
Hello Linar and other participants,
digged a bit deeper and just want to communicate the solution to the question on my Raspis
In the fresh installed setup the tty GPS output contains bare Unix \n
line endings with empty lines inbetween - meaning double \n
(\n\n).
By placing corresponding sed
command to generate the <CR><LF>
(\r\n
) sequences expected prior to piping the stream to SoftRF the desired result is achieved.
Many thanks again for swift replies. Manfred
{ echo "{class:SOFTRF,protocol:FANET,band:EU,nmea:{private:true}}" ; sudo cat /dev/ttyS0 ; } | sed "s/\$/$CR/" | sudo ./SoftRF
SX1276 RFIC is detected.
$GPGGA,192231.000,4913.1734,N,00822.4854,E,1,7,1.46,111.8,M,47.9,M,,*5A
...
$PSRFO,946668151,4107010126004691F4056FC001000300
$PFLAU,0,1,2,1,0,0,2,0,2147483647*68
$GPVTG,4.95,T,,M,0.20,N,0.36,K,A*32
$GPGGA,192232.000,4913.1734,N,00822.4854,E,1,7,1.46,111.8,M,47.9,M,,*59
...
$GPGSV,3,2,09,09,22,096,21,28,20,153,28,02,15,233,17,27,03,037,*71
$PSRFI,946668151,41071CB52E004688F40561B00300E000,-32
$PFLAA,3,8,-13,-14,3,07B51C!FAN_07B51C,315,,0,00000.0,11*57
$PFLAU,1,1,2,1,3,-58,2,-14,16*6F
$PFLAA,3,8,-13,-14,3,07B51C!FAN_07B51C,315,,0,00000.0,11*57
$PFLAU,1,1,2,1,3,-58,2,-14,16*6F
$PSRFO,946668153,4107010127004691F4056FC001000300
$PFLAA,3,8,-13,-14,3,07B51C!FAN_07B51C,315,,0,00000.0,11*57
$PFLAU,1,1,2,1,3,-58,2,-14,16*6F
'sed' ??? 'the solution' ???
Manfred, your TTY device settings are not appropriate.
These are known good default settings:
pi@raspberrypi:/run/tmp/SoftRF/SoftRF $ stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; discard = <undef>; min = 1; time = 5;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
Dear Linar,
of course you are right.
Using sed
inbetween is/was just a quick way of massaging the NMEA stream which just differs in line separators to the expectations of the NMEA parser.
In a RasPi-Installation the problem should be fixed at the source, of course.
Thanks again
Manfred
Manfred,
I've spent my own time to process your request. And that was not a bug of SoftRF or it's documentation. I believe that it is fair enough that I would expect to take your time as a compensation.
This is the list of CONTRIBUTIONS wanted. It would be nice if you could spend your time on 2.3 and 1.2
Regards, Linar.
Dear Linar, fair enough - will invest time in these areas. Thanks again Manfred
Dear Linar,
slightly adapted template for Raspberry issue
Hardware
Firmware version
< screenshot of WebUI status page > (required)
Firmware settings
< screenshot of WebUI settings page > (required) - N/A as Raspberry PI version
Describe the bug (or ask a question)
GPS data are received from Dragino hat - "
cat /dev/ttyAMA0
" orcat /dev/ttys0
produces expected output:$GPxxx
sentencesReceiver gets detected upon start of "
sudo ./SoftRF
" (SX1276 RFIC detected
)No signals received from TTGO based SoftRF device with FANET or OGNTP setting. Same device is 'seen' by RTL-SDR based OGN receiver
To Reproduce
start "
sudo ./SoftRF
" or commands as document in PI Examples.Expected behavior
$PFLAA
and$PFLAU
sentences for received signalsDo I miss some wiring or configuration setting?