¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

DMR Trunking: Hytera PD755 Stuck in "Out of Range"


 

Hello Adrian,

my setup is still not working, but after a lot of testing, I have some insights - maybe that rings a bell?

- Sometimes, the Hytera radio is able to book into the dmrtc, but most of the time not. I have not recoginzed a pattern and it's not reproducable.

- I tried to access the 7 channels with a Tier II Anytone Radio. On channels 5-7 (below center), I can wake up the transmitter, and MMDVMhost shows a lot of received and transmitted packets. The dmrtx complains (Rejected local id ......., not registered with the site) , but on MMDVM level this is working. Also, channel 4 (the highest frequency),? _sometimes_ works. On Channel 1, no wakeup is needed, but also I see no received DMR frames in the log when I press PTT on my anytone. On Channel 2-3 and usually on 4 also, I only see that the downlink was activated, but I do not see any packes being received afterwards.

Reseach on the internet raises the suspicion that this could be related to DMRDelay. But why should a different delay be needed for the different channels?

I have DMRDelay=90 (and burst_delay_msec=100, if that's related).

As some channels work and others not, and the channel is aalways ctivated, I would non suspect rx-/txgain-Problems.

- I tried to set the control channel to 7 in dmrtc and in the mmdvmhost config file for channel 7. Magically, the registration works reliably in this setup and I could switch between talkgroups.

- When booked in with the hytera and subscribed to tg91, the radio bings and beeps all the time, but I cannot hear any voice transmissions from TG91 on the Hytera. I do see TX data on channel 1 timeslot 1 .My suspicion is that channel 1 TS1 is hardwired somewhere in dmrtc and/or qradiolink, as it's carrier is always on and I cannot disable RF channel 1/Timeslot 1 in DMRTC, even when the control channel in on RF channel 7.

- Weirdly, I can partially hear TG91 being transmitted on my Anytone on Channel 1 TS in monitor mode.

Any ideas how to make channels 1-4 receive reliably? It's unclear to me what could be the difference to channels 5-7, that do receive reliably.

Thanks

Christian DB9CR


 

Hi again Christian,

I suspect your issues with channel access might be related to the DMRDelay
setting. I'm not able to confirm right now, but I just checked the docs and it
seems they (wrongly) mention a value of 90. It should be zero I think instead,
so please try with this value on very MMDVM instance.

As far as using a different channel for the TSCC, this is not supported yet in
dmrtc, so the best thing is just to leave "Control channel physical id" to
zero and use the RF channel 1 for the control channel (if the DMRDelay set to
zero solves your problems).
If you use a LimeSDR-mini, you can try reducing burst_delay_msec to about
60-80, that will shave off some latency.

Finally, please update the MMDVM and MMDVMHost code, I've pushed a fix last
week to allow setting CallHang to zero and avoid latency build-up.

Adrian

On Saturday, 29 June 2024 13:03:48 EEST you wrote:
Hello Adrian,

my setup is still not working, but after a lot of testing, I have some
insights - maybe that rings a bell?

- Sometimes, the Hytera radio is able to book into the dmrtc, but most
of the time not. I have not recoginzed a pattern and it's not reproducable.

- I tried to access the 7 channels with a Tier II Anytone Radio. On
channels 5-7 (below center), I can wake up the transmitter, and
MMDVMhost shows a lot of received and transmitted packets. The dmrtx
complains (Rejected local id ......., not registered with the site) ,
but on MMDVM level this is working. Also, channel 4 (the highest
frequency), _sometimes_ works. On Channel 1, no wakeup is needed, but
also I see no received DMR frames in the log when I press PTT on my
anytone. On Channel 2-3 and usually on 4 also, I only see that the
downlink was activated, but I do not see any packes being received
afterwards.

Reseach on the internet raises the suspicion that this could be related
to DMRDelay. But why should a different delay be needed for the
different channels?

I have DMRDelay=90 (and burst_delay_msec=100, if that's related).

As some channels work and others not, and the channel is aalways
ctivated, I would non suspect rx-/txgain-Problems.

- I tried to set the control channel to 7 in dmrtc and in the mmdvmhost
config file for channel 7. Magically, the registration works reliably in
this setup and I could switch between talkgroups.

- When booked in with the hytera and subscribed to tg91, the radio bings
and beeps all the time, but I cannot hear any voice transmissions from
TG91 on the Hytera. I do see TX data on channel 1 timeslot 1 .My
suspicion is that channel 1 TS1 is hardwired somewhere in dmrtc and/or
qradiolink, as it's carrier is always on and I cannot disable RF channel
1/Timeslot 1 in DMRTC, even when the control channel in on RF channel 7.

- Weirdly, I can partially hear TG91 being transmitted on my Anytone on
Channel 1 TS in monitor mode.

Any ideas how to make channels 1-4 receive reliably? It's unclear to me
what could be the difference to channels 5-7, that do receive reliably.

Thanks

Christian DB9CR




 

Hello Adrian,

I changed:

DMRDelay to 0 <---- this needs fixing in the documentation!

burst_delay_msec? to 60

Control Channel back to channel zero.

Registration now works reliably. Also, triggering and transmitting voice with the Tier II Anytone works reliably on all frequencies. Welcome SMS, Ping Radio, Send message to all/to radio all work.

Also direct and group calls work now.

Thank you very much, big progress!

If you have some time, some insights in the documentation about the logic by which incoming and outgoing calls are distributed over the DMRGateways would be very much appreciated.

Christian DB9CR


 

On Saturday, 29 June 2024 19:28:55 EEST you wrote:
Hello Adrian,

I changed:

DMRDelay to 0 <---- this needs fixing in the documentation!
I'm glad it finally works ok for you. I will fix the documentation bugs and add
some new sections based on this email thread as soon as possible.

Regarding the routing to DMRGateway:
Incoming calls from the network side do not need any routing, they will
automatically be picked up by dmrtc and distributed correctly on the allocated
payload channel on a timeslot chosen by the controller.

For calls outgoing from RF towards the network, you need to use the settings
tab "Talkgroup gateway routing".
Add a new line for each talkgroup that needs to be routed to each DMRGateway.
You should define the talkgroups as static in the network Options or in
Brandmeister interface so you always get traffic from them since you have
capacity for 13 calls at the same time.

Let's say you have this setup:

DMRGateway #1:
connection 1: TG262 - slot 1, TG2621 slot 2
....
connection 5: TG2622 slot 1, TG2623 slot 2

DMRGateway #2:
connection 1: TG91 slot 1, TG 92 slot 2
....
connection 5: TG235 slot 1, TG 2351 slot 2

Then you need to set which DMRGateway to use for which outgoing talkgroups in
dmrtc.
Gateway number starts at 0 in dmrtc. If the TG always goes out to Gateway 0,
you may ignore it (not add it in dmrtc since 0 is default), or you may add it
also for clarity in the settings as you wish.

In this example:
262 -> Gateway 0
2621 -> Gateway 0
etc.

91 -> Gateway 1
92 -> Gateway 1
235 -> Gateway 1
2351 -> Gateway 1
etc.

In case you need to set the same TG number on two different networks, let's say
you have 91 on Brandmeister and also 91 on DMR+ or whatever.
Then you configure DMRGateway to rewrite 91 to 1000091, then in dmrtc you have:

91 -> Gateway 1
1000091 -> Gateway 2

depending of course on which connection and DMRGateway you use for each TG
(DMRGateway has something like 5 or 6 connection options, you may use all of
them on the same network or mix different networks).

Of course, the radio should have the TG 1000091 programmed for that rewritten
TG.
Any timeslot rewriting has to be done in the DMRGateway config. So if you want
to rewrite 91 to always go out on timeslot 1, add a rule in that
DMRGateway.conf.
Otherwise your calls will go out sometimes on TS1 other times on TS2 which you
probably don't want if you have static TGs.
Unfortunately I can' provide an example DMRGateway config now, but maybe next
week as I'm away from home.

Hope this makes sense.

Adrian


 

Hello Adrian,

that explains it. Thanks!

73 Christian DB9CR

Am 01.07.2024 um 10:04 schrieb Adrian M:

On Saturday, 29 June 2024 19:28:55 EEST you wrote:
Hello Adrian,

I changed:

DMRDelay to 0 <---- this needs fixing in the documentation!
I'm glad it finally works ok for you. I will fix the documentation bugs and add
some new sections based on this email thread as soon as possible.

Regarding the routing to DMRGateway:
Incoming calls from the network side do not need any routing, they will
automatically be picked up by dmrtc and distributed correctly on the allocated
payload channel on a timeslot chosen by the controller.

For calls outgoing from RF towards the network, you need to use the settings
tab "Talkgroup gateway routing".
Add a new line for each talkgroup that needs to be routed to each DMRGateway.
You should define the talkgroups as static in the network Options or in
Brandmeister interface so you always get traffic from them since you have
capacity for 13 calls at the same time.

Let's say you have this setup:

DMRGateway #1:
connection 1: TG262 - slot 1, TG2621 slot 2
....
connection 5: TG2622 slot 1, TG2623 slot 2

DMRGateway #2:
connection 1: TG91 slot 1, TG 92 slot 2
....
connection 5: TG235 slot 1, TG 2351 slot 2

Then you need to set which DMRGateway to use for which outgoing talkgroups in
dmrtc.
Gateway number starts at 0 in dmrtc. If the TG always goes out to Gateway 0,
you may ignore it (not add it in dmrtc since 0 is default), or you may add it
also for clarity in the settings as you wish.

In this example:
262 -> Gateway 0
2621 -> Gateway 0
etc.

91 -> Gateway 1
92 -> Gateway 1
235 -> Gateway 1
2351 -> Gateway 1
etc.

In case you need to set the same TG number on two different networks, let's say
you have 91 on Brandmeister and also 91 on DMR+ or whatever.
Then you configure DMRGateway to rewrite 91 to 1000091, then in dmrtc you have:

91 -> Gateway 1
1000091 -> Gateway 2

depending of course on which connection and DMRGateway you use for each TG
(DMRGateway has something like 5 or 6 connection options, you may use all of
them on the same network or mix different networks).

Of course, the radio should have the TG 1000091 programmed for that rewritten
TG.
Any timeslot rewriting has to be done in the DMRGateway config. So if you want
to rewrite 91 to always go out on timeslot 1, add a rule in that
DMRGateway.conf.
Otherwise your calls will go out sometimes on TS1 other times on TS2 which you
probably don't want if you have static TGs.
Unfortunately I can' provide an example DMRGateway config now, but maybe next
week as I'm away from home.

Hope this makes sense.

Adrian