Hi All,
I just need to check if some of this pi-star behaviour I'm seeing is as expected or if I might have a configuration that needs adjusting.
I connect using DMR2YSF as my DMR master setting. I connect to a YSF reflector attached to a local repeater using a DMR radio, this works - I can hear the repeater and it can hear me.
If a station calls into the reflector using RF via the repeater with a Fusion transceiver, I can hear them fine and their details appear correct in the GateWay Activity log on Pi-Star dashboard.
If a station calls into the reflector using a hotpsot or linked from another repeater, I can hear them fine, but their details appear in the Pi-Star dashboard activity log as if they are me, it shows my callsign against the entry.
Is this correct behaviour or is there a setting I can change to show the correct callsign?
Thanks,
Pi-Star dashboard gateway activity
Re: Pi-Star dashboard gateway activity
Found the solution under DMR specific. Never had this problem with DMR, only YSF, which is why I asked about it in this forum.
But here it is anyway, for reference:
It was nothing to do with coming in via a different repeater, that was just coincidence.
viewtopic.php?t=1899
But here it is anyway, for reference:
It was nothing to do with coming in via a different repeater, that was just coincidence.
viewtopic.php?t=1899
Re: Pi-Star dashboard gateway activity
To better describe whats happening here... pistar is replacing the online call with ur ID because it can't find an ID for the guy transmitting at that time.
This happens a lot with YSF particularly because of cross linking on fusion networks or 'bridges' with Yaesu's wires x network. Yaesu's own network doesn't require their users to register with an ID. It was designed with hams in mind, so uses their callsigns to ID digitally. On a YSF bridge transmissions from the yaesu side, not having an ID means there's nothing to cross over to YSF, and nothing to display on a DMR radio.
With this and also. to follow legislation in some regions pistar has to identify the transmission digitally, so it TXs your ID/ callsign along with the other guys audio out of ur hotspot when there is no ID/ callsign info 'visable' over the network.
Its a very simple solution to the problem of having to identify a transmission digitally.
Sent via smoke signals from my SM-G935F M1DNS (Admin)
This happens a lot with YSF particularly because of cross linking on fusion networks or 'bridges' with Yaesu's wires x network. Yaesu's own network doesn't require their users to register with an ID. It was designed with hams in mind, so uses their callsigns to ID digitally. On a YSF bridge transmissions from the yaesu side, not having an ID means there's nothing to cross over to YSF, and nothing to display on a DMR radio.
With this and also. to follow legislation in some regions pistar has to identify the transmission digitally, so it TXs your ID/ callsign along with the other guys audio out of ur hotspot when there is no ID/ callsign info 'visable' over the network.
Its a very simple solution to the problem of having to identify a transmission digitally.
Sent via smoke signals from my SM-G935F M1DNS (Admin)
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.
Re: Pi-Star dashboard gateway activity
Thanks Andrew,
That makes very good sense. Understanding this saves me from fiddling around looking for something I've done wrong with the config. In fact the setup to make Pi-Star work to use Fusion reflectors with a DMR radio is wonderfully simple and works very well.
That makes very good sense. Understanding this saves me from fiddling around looking for something I've done wrong with the config. In fact the setup to make Pi-Star work to use Fusion reflectors with a DMR radio is wonderfully simple and works very well.