DMR2YSF anomaly or not?

General support for the Pi-Star System
Post Reply
G1VQV
Posts: 10
Joined: Wed Apr 11, 2018 2:17 pm

DMR2YSF anomaly or not?

Post by G1VQV » Mon May 20, 2019 5:55 pm

Hi guys. I have noticed unusual behaviour of my two hotspots regarding the use of DMR2YSF under DMRGateway. I have two RPi 3b's running with JumboSpot HS Hats and this happens with both. Running Pi-Star 4.0.0. RC4.. all up-to-date... Modes active are DSTAR, DMR & DMR2YSF.

On the config page in the YSF section I am pointing to "YSF624000 GB W.Mids-IO82UI" as my default YSF reflector and the dashboard shows this also. I have programmed up 3 channels on the radio to operate the DMR2YSF, each with their contacts set to TG7062400, TG7100420 & TG7100290 respectively, covering a couple of other reflectors.

After boot-up of the Pi, or after a Start/Stop of services as happens during the night (one is running 24/7), if I do nothing else except monitor TG7062400 (my default YSF reflector) I will see traffic (when there is any) on the dashboard but it comes in on TG7000009 from the default YSF reflector. This traffic does NOT open the squelch because I am monitoring TG7062400 so I hear nothing. If I make a transmission on TG7062400 then subsequent traffic from the same reflector appears on the dashboard coming in on TG7062400 and I can then hear it on that channel. It stays that way until a future reboor or Start/Stop of the services

It appears as though, until a transmission is made, the DMR2YSF service is behaving as if partially 'user activated', even though the desired reflector is set as default and the dashboard is reporting that it is 'linked'.

Is this 'normal' behaviour or have I found an anomaly?

Steve.

ea7gwc
Posts: 14
Joined: Wed Apr 11, 2018 3:53 pm

Re: DMR2YSF anomaly or not?

Post by ea7gwc » Mon May 20, 2019 6:14 pm

The same thing happens to me, until I do not pulse PTT
all the traffic is for the 7000009
73.

MW0MWZ
Site Admin
Posts: 777
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: DMR2YSF anomaly or not?

Post by MW0MWZ » Mon May 20, 2019 6:40 pm

Well the news so far, is that its not a problem in DMRGateway;

Code: Select all

D: 2019-05-20 18:37:11.456 Rule Trace, network 3 transmission: Slot=2 Src=3023856 Dst=TG9
D: 2019-05-20 18:37:11.456 Rule Trace,	RewriteTG from DMR2YSF_Cross-over Slot=2 Dst=TG1-TG999998: matched
D: 2019-05-20 18:37:11.456 Rule Trace,	RewriteTG to DMR2YSF_Cross-over Slot=2 Dst=TG7000001-TG7999998
As you can see in the first line, the YSF2DMR system is writing the destination TG as TG9, and DMRGateway is re-writing that to 7000009 (as it should do)....

Still investigating...
Andy

73 de MW0MWZ
http://pistar.uk

MW0MWZ
Site Admin
Posts: 777
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: DMR2YSF anomaly or not?

Post by MW0MWZ » Mon May 20, 2019 6:59 pm

MW0MWZ wrote:
Mon May 20, 2019 6:40 pm
Well the news so far, is that its not a problem in DMRGateway;

Code: Select all

D: 2019-05-20 18:37:11.456 Rule Trace, network 3 transmission: Slot=2 Src=3023856 Dst=TG9
D: 2019-05-20 18:37:11.456 Rule Trace,	RewriteTG from DMR2YSF_Cross-over Slot=2 Dst=TG1-TG999998: matched
D: 2019-05-20 18:37:11.456 Rule Trace,	RewriteTG to DMR2YSF_Cross-over Slot=2 Dst=TG7000001-TG7999998
As you can see in the first line, the YSF2DMR system is writing the destination TG as TG9, and DMRGateway is re-writing that to 7000009 (as it should do)....

Still investigating...
OK and now fixed up, DMR2YSF has a default re-write to TG9, the dashboard now sets the default rewrite to the default TG number, so this now works much more like you would expect.

EDIT: Update, head to the config page, apply the changes (even if there are none) and re-test it.
Andy

73 de MW0MWZ
http://pistar.uk

G1VQV
Posts: 10
Joined: Wed Apr 11, 2018 2:17 pm

Re: DMR2YSF anomaly or not?

Post by G1VQV » Tue May 21, 2019 8:46 am

Thanks Andy. I have just done an update (didn't see any changes) and 'applied' changes on the config page as you suggested. It may take a while as there is not a lot of traffic on YSF GB W.Mids but I have it set as my default reflector so just need to wait for incoming traffic (before I make any tx). I'll report back ASAP.

Steve.

G1VQV
Posts: 10
Joined: Wed Apr 11, 2018 2:17 pm

Re: DMR2YSF anomaly or not?

Post by G1VQV » Tue May 21, 2019 4:16 pm

Yes, fixed. Incoming calls (before I make any transmission) now show on correct TG.

Thanks Andy.

Steve.

Post Reply