Gallery

[DU2XXR]

One lesser-documented feature in Pi-Star is the DgIdGatway, which lets users route their transmissions to their desired YSF reflectors (or YSF2DMR talkgrups, FCS reflectors, or other gateways like parrot, local, etc).

Some steps in enabling it:

1. Access your Pi-Star terminal via shell.
2. Make sure your filesystem is writeable:

Code Select Expand

rpi-rw
3. Edit /etc/dgidgateway using your favorite text editor. Need to be superuser.

Code Select Expand

sudo nano /etc/dgidgateway
4. Add lines as necessary. You may refer to examples found on the DgIdGateway github on how to set up your targets: https://github.com/g4klx/YSFClients/blob/master/DGIdGateway/DGIdGateway.ini

There are also some discussions here: https://groups.io/g/OpenDV/topic/dg_id_gateway/76993305

You will need to establish whether your targets are static (Static=1) or dynamic (Static=0). If static, that means you will be primarily connected to that reflector or link after the transmission. Hangtimes can be defined.

5. Enable the dgidgateway service.

Code Select Expand

sudo systemctl enable dgidgateway
You can then start or restart the service.

Code Select Expand

sudo systemctl start dgidgateway
You might need to restart your hotspot, either through the web interface or just by rebooting.

Code Select Expand

sudo reboot
6. You can then change the transmit DG-ID on your radio to direct the traffic to its intended link. For example, a DG-ID of 08 might direct you to the DX1ARM 78427 YSF room, while a DG-ID of 09 can direct you elsewhere. DG-ID 01 might be defined as a parrot reflector for checking your audio. If you use YSF2DMR, you can also direct your traffic to your defined TG.

Changing DG-IDs is much simpler than doing DTMF or connecting to the "WIRES-X" interface for changing rooms.

[DU2XXR]

As an example, these are the stanzas we're using for the DX1ARM YSF:

Code Select Expand

[DGId=1]
Type=YSF
Static=0
Name=Parrot
Local=42023
RFHangTime=10
NetHangTime=10
Debug=0

[DGId=8]
Type=YSF
Static=0
Name=DX1ARM
Local=42022
RFHangTime=1
NetHangTime=1
Debug=0

DG-ID 1 directs to the parrot/echo so we can test our audio quality or at least determine if coverage is good when there's no one else to talk to.

My purpose here is so that the YSF reflector can run alongside our WIRES-X room as a backup, without the two looping. The WIRES-X node uses a different DG-ID from the YSF node. The reason for the short hangtimes is so that traffic to WIRES-X no longer get re-routed back to RF via the YSF.

Essentially, this renders our YSF node a receive-only node from RF, until the time I manually activate the link full-time.

That can also be achieved by using a static DGIDgateway link, which can perhaps be done by something like this:

Code Select Expand

[DGId=1]
Type=YSF
Static=0
Name=Parrot
Local=42023
RFHangTime=10
NetHangTime=10
Debug=0

[DGId=9]
Type=YSF
Static=1
Name=DX1ARM
Local=42022
RFHangTime=15
NetHangTime=15
Debug=0

The Local ports are arbitrary and are mostly meant to prevent collisions and perhaps can be used if there is linking to/from other services needed. In the above stanzas, the DX1ARM YSF connection is "Static" meaning it will continue receiving traffic from the network even after the hangtime, until the time that a different YSF is selected via DG-ID or an empty DG-ID is selected.

The routing is done via the "Name" item. DGIDgateway uses the equivalent reflector from the Hosts.txt file and routes the traffic accordingly. Similarly, for any traffic received from the network, DGIDgateway tries to match the name with the stanza identifying the DG-ID and sets the DG-ID being transmitted by MMDVM locally to that ID. This is useful for routing and linking purposes, if so desired.

The discussions also point to other options, such as YSF2DMR, YSF2NXDN, IMRS, but I have not had the time to explore those.

[ka1cm]

Hi DU2XXR,

I've successfully follow your tutorial and make it work. However, every time pi-star update or reboot or lost power, I have to SSH in and type up the systemctl enable / start and then reboot to make it work again. Is there a way to name dg-idgateway permanent?

P.S. Pi-Star:4.1.8 / Dashboard: 20240307

[DU2XXR]

Hi. You can try editing the service to make it auto start upon boot up. might have to define that it should start up after MMDVMhost.

Or you can edit your crontab to make the service start or restart upon reboot.

[ka1cm]

Hi. You can try editing the service to make it auto start upon boot up. might have to define that it should start up after MMDVMhost.

Or you can edit your crontab to make the service start or restart upon reboot.

I have edit crontab for daily task (pistar-daily.cron) and it has been good sofar. do you have the name and location of the crontab that execute every reboot?

[DU2XXR]

Hi. You can try editing the service to make it auto start upon boot up. might have to define that it should start up after MMDVMhost.

Or you can edit your crontab to make the service start or restart upon reboot.

I have edit crontab for daily task (pistar-daily.cron) and it has been good sofar. do you have the name and location of the crontab that execute every reboot?

You can utilize the @reboot syntax for executing a command or shell script at boot.

https://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/

I would usually add a delay to make sure other services that are potentially dependencies. Maybe a restart is needed

Code Select Expand

@reboot sleep 60 && sudo systemctl restart dgidgateway
You might also want to look into whether dgidgateway is conflicting with ysfgateway. If that is the case, then dgidgateway may not be auto starting because ysfgateway is still running. You can perhaps disable ysfgateway service.

Code Select Expand

sudo systemctl disable ysfgateway
Also, make sure dgidgateway is enabled

Code Select Expand

sudo systemctl enable dgidgateway
Sorry, not exactly sure about the service names and capitalizations, as I am not currently actively using an MMDVM hotspot. But try tabbing to autocomplete the names, just to check if you're inputting them correctly on corn.

Another thing, you might want to check the status first and then check the logs to see whether the service is running and why dgidgateway is not automatically starting.

Code Select Expand

sudo systemctl status dgidgateway
(Depending on your distro, you might or might not have to include the .service filename extension with systemctl)