forum.pistar.uk

I am a new Pi-Star user.
I have my hotspot up and running. But I did not understand how people provide dynamic location data (APRS ?)
My radio device is a Radioddity GD77 and it does not have GPS.
So what are my options to provide dynamic GPS data ?

I have a bluetooth GPS dongle which I successfully connected to the Pi-Star Linux OS.
It is on bluetooth port /dev/rfcomm0

How do I get location to Pi-Star and then send it to ... (where ?)

I also wonder if it is possible to provide GPS location to my hotspot from my mobile phone (Android) using a specific app.
any option to use mobile phone for location data ?

I'd appreciate a response...

For those reaching here via a search of the forum, please skip this post.
It was based upon out-of-date memories of "how things used to be".
I leave it here merely for continuity

Have you tried searching the past messages on the forum?

I haven't kept up if there have been changes (and if there were, they are likely in up-stream providers -- the people who write ircddb/mmdvmhost -- first, before pi-star wrappers can consider changing).

As I recall, pi-star only looks for location information ONCE -- during start-up when it reads the config files. I don't believe anyone has managed to create start-up scripts that would: 1) delay pi-star start-up until after a GPS unit has obtained a position fix; 2) write that position information into the pi-star config file; 3) THEN allow pi-star to start all its services running. Of course, this scheme is still just a one-shot operation and only provides a location /when/ the unit is restarted.

For the most part, GPS information requires that one uses a GPS-capable radio with proper firmware to send positions as part of the digital stream (I believe D-STAR radios with GPS can be configured to transmit the position as a final packet when PTT is released; I've never managed to understand the DMR scheme -- it seems to rely on sending GPS information to specific talk groups, not as part of regular voice packets/talk groups).

cf:
viewtopic.php?t=2983
viewtopic.php?t=3408
viewtopic.php?t=1139
{No doubt there are more -- search "pi-star gps location"}

thanks for your response.
I had thought that there is a dynamic GPS update mechanism when I saw the mobile gps configuration.
so it is useless ?

TB2IAK wrote: ↑Sun Feb 20, 2022 10:32 pm thanks for your response.
I had thought that there is a dynamic GPS update mechanism when I saw the mobile gps configuration.
so it is useless ?

I'll have to confess that appears to be a rather new section on the config page. {Okay, based on viewtopic.php?t=2746 about 18 months ago; my system is fixed, and the last time I had to do any config changes was when going from 3.x to 4.x}.

Have you confirmed you can read NEMA sentences from the GPS device? (Using some sort of "terminal" with the serial port associated with it).

You mention a "bluetooth" "dongle", which is somewhat perplexing -- to me this wouldn't be a "dongle"; it would be a separate device that runs independent of the R-Pi, and would be linked to it via a BlueTooth RF signal. If you can't get NEMA sentences from some serial port terminal it could be that the device needs a custom application to communicate.

Most of the linked message thread is focused upon direct USB dongles that present as a serial port.

it is a separate bluetooth device but it works with other apps on RPI.
so it is not a matter of reading info from the device.

actually there is also a github project here, using it:
https://github.com/decibyte/raspberry-pi-gps-tracker

the information I am looking in this thread is "how can I configure gps settings on pi-star ?"
there is not much information on the configuration UI or the wiki about this.

and I really don't know the purpose of using GPS with pi-star.
is it a one-time location update ? or is it a location update to aprs each time I access the network using my radio ?
I just want to learn the basics, purpose and how to configure.
if bluetooth devices are not supported, I am also interested in any other method that I can use.

TB2IAK wrote: ↑Mon Feb 21, 2022 8:56 am it is a separate bluetooth device but it works with other apps on RPI.
so it is not a matter of reading info from the device.

Since I don't know what those "other apps" might be, I have no knowledge of how they may be obtaining GPS data.

Until it is proven that you are getting NMEA messages to a console from a plain serial device, nothing can be stated.

actually there is also a github project here, using it:
https://github.com/decibyte/raspberry-pi-gps-tracker

Said project appears to rely upon having GPS daemon running by the system, and a Python client library that connects to the daemon using /TCP sockets/. The daemon is reading some serial port and parsing the NMEA messages into some JSON format. I suspect one would have to disable/stop this daemon in order for MMDVMHOST to be able to open the serial port to fetch NMEA messages directly.

the information I am looking in this thread is "how can I configure gps settings on pi-star ?"
there is not much information on the configuration UI or the wiki about this.

There are only two things to set (ignoring the enable/disable button). The serial port that is the source of the NMEA messages, and the bit rate of that port (I'm surprised there isn't any option for parity/word-length, eg: 8n1, 7e2 -- though I suspect 8n1 has become the norm).

That's why I stated, above, that until you can show NMEA messages coming from a serial port in a console, nothing else can be considered.

and I really don't know the purpose of using GPS with pi-star.
is it a one-time location update ? or is it a location update to aprs each time I access the network using my radio ?
I just want to learn the basics, purpose and how to configure.

It is not a Pi-Star function, per se... It is a feature of MMDVMHOST -- you'd have to study the code or ask the maintainers of that application; Pi-Star is just a package that incorporates various digital mode packages under one user interface.

if bluetooth devices are not supported, I am also interested in any other method that I can use.

If it presents as a serial port selectable in the config page, and produces a stream of NMEA messages, it shouldn't matter.

What a pain... I have two hand-held GPS units. Garmin eTrex Touch 35 and older Garmin GPSMAP 76CSx. Both have USB ports. I tried the eTrex since it was nearest. Nothing... The interface options appear to be "Garmin", MTP, and SD Card. Couldn't see anything in minicom on a plain R-Pi. Tried the 76CSx. It did have a selection for NMEA In/Out, along with "Garmin" and "Text Out" and None. Still no joy. Turns out serial output is only via the NMEA 4-pin connector, USB is just "Garmin" proprietary format.

FINALLY tracked down a 40 year old NMEA to 9-pin serial cable, connected that to a 9-pin<>USB FTDI cable. Started minicom
sudo minicom /dev/ttyUSB0 -b 4800
(NMEA is slow) and immediately got a stream of sentences...

ok. I got my device bound on /dev/rfcomm0 and can get GPS data from that port as seen below:

root@pi-star(ro):~# cat /dev/rfcomm0
$GPRMC,201029,A,4057.98242,N,02905.71316,E,000.0,,220222,005.9,E,A*3C

$GPGGA,201029,4057.98242,N,02905.71316,E,1,03,,82.708,M,,M,,*43

$GNGSA,A,1,8,16,18,,,,,,,,,,,,*36

$GNGSA,A,1,421,434,406,,,,,,,,,,,,*36

$GNGSA,A,3,314,314,301,301,,,,,,,,,,,*02

$GPGSV,2,1,7,23,44,049,19,08,41,311,28,16,32,220,37,32,23,155,12*4D

$GPGSV,2,2,7,21,20,285,14,18,19,081,27,26,09,195,12,,,,*7B

$GLGSV,1,1,1,69,64,079,19,,,,,,,,,,,,*6F

however, there is no option to choose this device on pi-star UI.
I only see /dev/ttyAMA0 as option.
how can I select /dev/rfcomm0 ?

Interesting -- my 3B Pi-Star system (nothing in USB ports, no onboard display, using a DV-Mega) shows both /ttyACM0 and /ttyAMA0 as options. Recall I did not attempt anything with my Garmin<>NMEA serial to FTDI serial<>USB test (that was done with a random 3B+; for one thing, my Pi-Star is on top of a china cabinet in the middle of my house -- under a stone-coated steel roof and aluminum siding, and the cables aren't long enough to put the Garmin on a window sill to get satellite lock), so I don't know if /ttyUSB0 would have shown up. I seem to recall that more than one device did show up...

Give me a moment...

SSH into "virgin" Pi-Star, Drag FTDI serial<>USB cable to physical Pi-Star and connect it, return to SSH session DIFF the two files results in For this, the big changes are that "icom_ta" (which is a sym-link to /ttyUSB0, and appears to be dedicated to use with certain ICOM radios "terminal mode"), the appearance of "serial", and the main item appearing being "ttyUSB0".

I then restarted the Pi-Star dashboard (well, for me admin page is the saved link), went to configuration, and the drop-down list now shows /dev/ttyACM0, /dev/ttyAMA0, and /dev/ttyUSB0.

Removed the FTDI cable; config page was still showing ttyUSB0 as an option, but a simple browser refresh results in that disappearing.

I don't know enough about Linux to say this is even possible but... maybe creating a sym-link for, say /ttyUSB<somenumber> (0 might be okay, until you connect a real USB serial device ) pointing /to/ your /rfcomm0 (as root [sudo] and setting the group to dialout), and refreshing the config page, might let you select the device (first make sure the sym-link name produces a data stream).

Of course, you'd have to do this sym-link/group assignment every time the unit reboots -- so you might need an "atboot" crontab entry; which has to be timed late enough to activate after /rfcomm0 is detected, but before the pi-star services begin. Or maybe a udev rule can be defined to trigger on /rfcomm0 and create the sym-link at that time. Otherwise the service will start and attempt to open a device that doesn't yet exist.

Last comment: maybe do and see if /any/ tty device is already sym-linked to /rfcomm0... Though that opens the question of why Pi-Star didn't see it as a candidate.

The 3B has on-board bluetooth, and I just tried running bluetoothctl to enable it. Nothing showed up /dev -- possibly because I didn't have anything to attempt pairing. If you are using a USB<>Bluetooth "dongle" you may be at the mercy of the provider to create a /tty* if a "serial" stream device is paired.

Just a side-comment.

If there is NO physical UART involved, the baud rate selection probably doesn't matter. Virtual comm ports created by USB clients transfer data packets at the USB data rate (accounting for protocol overhead, USB 2 gets around 22Mbps, and the same holds true for Bluetooth radio packets). If there is a real UART involved (as with my FTDI 9-pin serial<>USB cable), the baud rate setting is passed to the FTDI chip, so IT can properly time the bits being transferred over the 9-pin connector.

This is just an advisory. If you can't get a tty device to appear you may need to dump the bluetooth GPS and go to a direct USB unit.