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.