M1DNS wrote: ↑Sun May 05, 2019 6:48 am
You might be misreading what my last message was indicating...
The newer vers of MMDVM has written in support for mobile GPS.
Yes you need a usb GPS puck but it will work natively with the differing gateways and forward to APRS servers. So no dependencies reguired of external code and no android rooting or dependency etc.
I'm not 'knocking' what ur doing, ur use case is fitting in the way you are using it
, and it showing TG status is a good addition.
It still to me had the tone of "we're going to do this so you can stop what you're doing and adopt our method regardless if it works for you". At the same time, I realize you guys don't develop mmdvm directly.
When I dug through the code for what I could understand...I almost just don't see the point. I mean mobileGPS basically looks like it's scanning the GPGGA and GMRMC sentences and updating based on distance. It seems like re-inventing the wheel. That's not to mention the modules only seem to beacon every 20 minutes and don't show reflector/TG status. I looked heavily in to using what was already in Pi-Star...I didn't want to reinvent the wheel either; but the wheel already there wasn't up to the task.
That being said, it'd be possible to fake out mobilegps by having something like gpscat feed data to a virtual serial port.
My mention of Android was just the fact it is possible to use it's GPS data since it's GPSD output. It's possible to have that data routed using an app "outside the phone". If we already have that capability and it wind up not being too difficult, then why not use something that would let users leverage it?
The current native implantation wouldn't work for my purposes; I built something largely for me that meets my needs and requirements. I'm sharing it on the off-chance someone else has similar requirements. It's entirely possible I don't need to use gpspipe, there's likely a way I can have something else pull GPSD data from my source. It's entirely possible I could compile a gpspipe executable and include it in the package. These are things I haven't gotten around to yet.
Plus adding outside stuff is just another case of why Pi-Star powered hotspots are "a little bit better" than the others; we have a whole underlying standard operating system we can get at and do stuff like this. Could you do this on an OpenSpot(2)? Probably not.
But when you get down to it...my script only requires a $GPRMC (as of last night) sentence to operate. It literally doesn't care how it gets it.
SP2ONG wrote: ↑Sun May 05, 2019 7:33 am
Another interesting solution may be to use GPS data from a mobile phone that sends via UDP to Pi-Star. On Pi-star we can download data using netcat (nc) and then via scripts send data to APRS.
https://play.google.com/store/apps/deta ... eGPS&hl=en
I tried to use this but it looks like you need to add a rule to the firewall so you can receive data from GPS on the UDP port
I tested this on my ntp server, which is good because the GPS dongle lost GPS sync overnight and it might be a while before it gets it back, so the alternative GPS source will let me keep tweaking my script: (192.168.1.183 is the ip of my android device)
Code: Select all
[email protected]:~/scripttest $ ncat 192.168.1.183 50000
$GPGSV,3,2,10,23,64,264,22,26,41,049,18,27,49,149,26,31,15,098,13*7A
$GPGSV,3,3,10,03,08,219,,21,04,066,*7E
$GLGSV,3,1,10,78,16,066,19,79,53,016,23,69,38,226,16,88,25,045,20*69
$GLGSV,3,2,10,81,34,101,20,70,34,303,,82,12,150,,80,35,295,*64
$GLGSV,3,3,10,71,01,341,,68,06,187,*63
$GAGSV,1,1,0,*74
$PQGSV,1,1,0,*73
$PQGSV,1,1,0,*73
$GNGSA,A,3,09,16,23,26,27,,,,,,,,1.3,0.9,0.9,1*3D
$GNGSA,A,2,69,81,88,,,,,,,,,,1.3,0.9,0.9,2*37
$GNVTG,,T,,M,0.0,N,0.0,K,A*3D
$GNRMC,144011.00,A,3843.655284,N,07725.965287,W,0.0,,050519,7.9,W,A*06
Right now I just have to figure out how to get ncat to stop after so many lines. It was also 12 lines before I got the sentence I wanted. The sentences are also renamed GNGGA and GNRMC. But this does pose a problem. For starters, ncat isn't installed on the hotspots; which is an outside source "we shouldn't need". You also can't make ncat gracefully exit after so many lines; the GNRMC happens every twelve lines.
Sadly that app's gpsd doesn't seem to work. The phone indicates a connection; but I don't ever get any data out of it.
Code: Select all
[email protected]:~/scripttest $ gpspipe -r 192.168.1.183:2947
{"class":"VERSION","protocolMajor":3.0,"protocolMinor":11.0,"release":"3","rev":"3.16"}
I didn't have to do any special firewall stuff to get the ncat output from the thing. I don't think you need to root for this one...that was something I did years ago on an old phone to get raw access to the underlying gpsd to forward it to a phone with broken gps. (This was back when sharing gps over bluetooth amounted to brute-forcing data in to 'fake location')
The problem I have with running a script to just write location information is that it won't be as current as when the packet was sent, it could be as far off as how ever that information is updated. When you're flying down the highway at 70/75 miles/hour...a minute or two old location data can amount to more than a mile. But I would like to get something working using the phone as a source in the long run since most people have smartphones.
Now on to new stuff:
Script was redone last night to add speed and heading information. A change to $GPRMC sentences as source was involved.
Code: Select all
#!/bin/bash
# script activation/webui control
[ ! -s "/tmp/aprs" ] && exit
# Script Configuration
# APRS-IS user id
user=USER
# APRS-IS passcode
password=URPASS
# APRS Object ID/SSID
senduser=CALL-SSID
# APRS Icon Selection (refer to pdf)
# Standard table
#table="/"
# Alternate Table
table="\\"
# Symbol
symbol=">"
# Poll GPSD
gpsd=$(gpspipe -n 9 -r | sed -n '/$GPRMC/{p;q}')
# GPS Lock Check
gpss=$(printf "$gpsd" | cut -d ',' -f3)
test "$gpss" = "V" && exit
# GPS Coordinate Set
lat=$(printf "$gpsd" | awk -F, '$1 == "$GPRMC" {printf "%07.2f%c", $4, $5;}')
lon=$(printf "$gpsd" | awk -F, '$1 == "$GPRMC" {printf "%08.2f%c", $6, $7;}')
# Set heading & speed
spd=$(printf "$gpsd" | awk -F, '$1 == "$GPRMC" {printf "%03.0f%c%03.0f", $9, "/", $8}')
#gps="$lat$table$lon$symbol$spd"
# DMR - Scrape for TGs and set comment.
#tg=$(curl -s http://pi-star/pistaprs/bmscrape.php| sed 's/<[^>]\+>//g' | sed 's/None//g' | sed ':a;N;$!ba;s/\n/ /g' | sed 's/TG/#/g')
#comment="BrandMeister TGs: $tg"
# DSTAR - Scrape for reflector and set comment (should work for YSF too)
dstar=$(curl -s http://pi-dstar/mmdvmhost/repeaterinfo.php | egrep "Linked|linked" | sed 's/<[^>]\+>//g' | sed 's/L/l/')
comment="DStar $dstar"
# I have not tested if it actually works for YSF.
#comment="YSF $dstar"
# parse packet
data="$senduser>APRS,TCPIP*:!$lat$table$lon$symbol$spd $comment"
# Send data to the terminal for testing
printf "%s\n" "user $user pass $password" "$data"
#DO NOT ENABLE UNTILL YOU'RE SURE IT WORKS!!!!!!!
#printf "%s\n" "user $user pass $password" "$data" | ncat rotate.aprs2.net 14580
The main change is that all your configuration can be done without modifying the script itself; so changing your icon table and symbol doesn't require hacking the script. I also updated the script to indicate we don't have APRS messaging...working more like a generic tracker. Coordinates are now rounded (somewhat) and properly padded. Speed and heading information is also rounded and padded with 0s to match the protocol. I also believe the YSF Reflector information can be scraped the same way the DStar information is; though if you're using YSF2DMR bridge on BM it may be better to just use the DMR code instead.
At some point it'll stop raining and my NTP server will regain it's GPS or I'll figure out how to get ncat to poll my phone and exit after so many lines.
should changes made in pistar effect ur particular project.