开云体育

Motorola SL4000e and DP4801e - is it the e at the end that makes it a Tier III Radio?

Am 11.08.2024 um 11:02 schrieb Adrian M:

I've created a documentation page to keep track of supported radios and what
exactly is supported for each radio:


Thanks Christian and sky4mazon for your feedback.

Thanks for your effort to bring this to life!

73 Christian DB9CR

I've created a documentation page to keep track of supported radios and what
exactly is supported for each radio:


Thanks Christian and sky4mazon for your feedback.

Adrian

Hello,

can anyone shed some light on how to identify Tier III compatible Motorola radios?

What Motorola radios would be recommended for dmrtc?

On Hypera it's the SW00029 license, can be checked in the CPS in Common/Feature Control, item "DMR Trunking".

73 Christian DB9CR

On Sunday, 11 August 2024 03:19:05 EEST you wrote:

Is that helps - moto sends talker alias as Iso-8 (as indicated by dmrtc),
hytera as UTF-16. Readable both ways, but dmrtc adds a couple of rectangles
to hyt's one (not moto's).

Okay, I'll look into that. For what is worth, the Hytera HP785 UTF-16 talker
alias is displayed correctly.

Is that helps - moto sends talker alias as Iso-8 (as indicated by dmrtc), hytera as UTF-16. Readable both ways, but dmrtc adds a couple of rectangles to hyt's one (not moto's).

Checked msg encoding settings - nope, none.

they would also be stuck in "Sending..." mode). Motorola may expect a
different source id than TSI (text service id), to be investigated.

Errata: TSI is actually trunking station id, SDMI should be used for the
message service (short data message id).

On Friday, 9 August 2024 20:20:22 EEST you wrote:

Max length of sms on moto is 21 chars when sending. Guessing this is
non-moto capmax mode limitation on moto's side.

DMR tier 3 standard specifies maximum 46 characters in ISO 8 bit format.
If using 7 bit, that number increases since more 7 bit chars fit within 46
bytes.
A limit of 21 chars suggests the Moto radio uses UTF-16 format (2 byte chars).
Is there any option in the CPS to switch it to ISO-8? Hytera has such an
option for messages.

Adrian

On Friday, 9 August 2024 20:01:21 EEST you wrote:

1. Sending from moto. Sms reaches prv or group ok, but moto still shows
'Failed', although in about 20 attempts - one shown 'Sent'. Also, when
sending pvt to moto it alarms, shows message, but continues to alarm
(sender shows 'msg sending'). I'm guessing this is same problem (some sort
of confirmation on cc required?)

Yup, the standard specifies for private message confirmation of receipt is
required from target radio, that also happens on the control channel. Hytera
here implements the standard exactly as specified.
For group messages, confirmation is instead expected from the trunking
controller, which also happens (Hyteras receive this confirmation, otherwise
they would also be stuck in "Sending..." mode). Motorola may expect a different
source id than TSI (text service id), to be investigated.

. 2. Sending texts between radios produces
readable contents. Sending sms from dmrtc - it reaches the moto, but
regardless of contents it shows as just one unicode character (rectangle).

This may be a latent bug in dmrtc, the implementation is a bit loose with
regards to some UDT headers, or maybe Motorola expects a different character
set or some zero terminated string.
Is it possible to choose short message format in the CPS? DMRTC originated
messages always use ISO 8 bit. If the Motos are configured for something like
ISO 7 bit or UTF-16, this may explain it.

Send msg to all from dmrtc - hyts get the sms, moto silent, no indication, no text.

Will grab some logs later.

Max length of sms on moto is 21 chars when sending. Guessing this is non-moto capmax mode limitation on moto's side.

Just confirmed - the continuous alarm on moto sms rx happens only for prv sms sent from other radios. If I send (even tho it's garbled) from dmrtc - correct behavior (alarm, confirm, alarm stops). Same with group sms sent from other radios, alarm, confirm, alarm stops.

Okay, upgraded moto fw and lo and behold - sms now works somewhat. Both in open radio and open system. Allowed me to chose IOP.
Only 2 problems I see right now:
1. Sending from moto. Sms reaches prv or group ok, but moto still shows 'Failed', although in about 20 attempts - one shown 'Sent'. Also, when sending pvt to moto it alarms, shows message, but continues to alarm (sender shows 'msg sending'). I'm guessing this is same problem (some sort of confirmation on cc required?).
2. Sending texts between radios produces readable contents. Sending sms from dmrtc - it reaches the moto, but regardless of contents it shows as just one unicode character (rectangle).

Sadly no such option. CapMax settings set in RM is really scarce, compared to Hyt. All in all about 10 settings overall.

On Friday, 9 August 2024 05:43:19 EEST you wrote:

Sending text 'A' from 1002077 to group 1002222:

MMDVMHost output:
---
M: 2024-08-09 02:39:36.743 DMR Slot 1, received RF Call Alert CSBK from
1002077 to 1467028 D: 2024-08-09 02:39:37.227 Call Alert CSBK
D: 2024-08-09 02:39:37.227 0000: 9F 00 00 03 16 62 94 0F 4A 5D 27 F1
*.....b..J]'.* M: 2024-08-09 02:39:37.227 DMR Slot 1, received RF
Call Alert CSBK from 1002077 to 1467028 D: 2024-08-09 02:39:37.822 Call
Alert CSBK
D: 2024-08-09 02:39:37.822 0000: 9F 00 00 03 16 62 94 0F 4A 5D 27 F1
*.....b..J]'.* M: 2024-08-09 02:39:37.822 DMR Slot 1, received RF
Call Alert CSBK from 1002077 to 1467028 M: 2024-08-09 02:39:59.022
Unhandled CSBK type
M: 2024-08-09 02:39:59.022 0000: A8 00 1A 20 12 00 27 B4 FD C0 66 5F
*... ..'...f_* W: 2024-08-09 02:39:59.022 DMR Slot 1, unhandled
network CSBK type - 0x28 --- (I've shortened extra repeating call alert
messges)

dmrtc output:
---
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:11.852] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.395] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.920] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.414] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.890] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:14.426] [Debug] Unhandled CSBK type slot 1, channel 0
--- (UI shows 'Unknown service request)

Yup ok this seems fixable. CSBK 1F is just a random access request, but the
third field (Service Kind) seems to be group packet data call which is not
implemented.
Strange that it doesn't use GroupUDTDataCall (5) as that is what the tier 3
standards specifies for SMS on the control channel.
My guess is that there might be an option in the CPS to use the control
channel for SMS and thus the standard UDT procedure. From the options listed
previously, DMR IOP might stand for Inter-Operability and may be the right
choice... but requires trial and error.
I don't know how to deal with such packet data calls at the moment. I have no
Moto radios, and Hytera's packet data is completely proprietary format and
this makes it hard to implement something that works for every radio.

The best case scenario here is to try to get the Motorolas to use UDT data
calls instead of packet if possible.

Adrian

On Friday, 9 August 2024 05:47:56 EEST you wrote:

[8/Aug/2024 22:43:53.066] [Info] TSCC: DMR Slot 1, received private packet
data call request from 1002077 to destination 1002001 [8/Aug/2024
22:43:53.066] [Debug] Allocated physical channel 0, logical channel 89,
slot 2 to destination 1002001 and source 1002077 [8/Aug/2024 22:43:53.066]
[Info] Received private packet data call request from 1002077, slot 1 to
destination 1002001 (not registered ID) [8/Aug/2024 22:43:53.641] [Debug]
DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001 [8/Aug/2024
22:43:53.705] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077
to 1002001 [8/Aug/2024 22:43:53.756] [Debug] DMR Slot 2, received UDT data
MS to MS from 1002077 to 1002001 [8/Aug/2024 22:43:53.821] [Debug] DMR Slot
2, received UDT data MS to MS from 1002077 to 1002001 [8/Aug/2024
22:43:54.825] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077
to 1002001 [8/Aug/2024 22:43:54.898] [Debug] DMR Slot 2, received UDT data
MS to MS from 1002077 to 1002001 [8/Aug/2024 22:43:54.945] [Debug] DMR Slot
2, received UDT data MS to MS from 1002077 to 1002001 [8/Aug/2024
22:43:55.011] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077
to 1002001 [8/Aug/2024 22:43:56.042] [Debug] DMR Slot 2, received UDT data
MS to MS from 1002077 to 1002001 [8/Aug/2024 22:43:56.089] [Debug] DMR Slot
2, received UDT data MS to MS from 1002077 to 1002001 [8/Aug/2024
22:43:56.156] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077
to 1002001 [8/Aug/2024 22:43:56.208] [Debug] DMR Slot 2, received UDT data
MS to MS from 1002077 to 1002001 [8/Aug/2024 22:43:57.009] [Debug] Physical
channel 0, slot 2 to destination 1002001 and source 1002077 is marked as
idle and deallocated --- (UI shows Individual packet data call. 1002001
shows 'Data rx' but then 1002077 shows fail and both reset.)

Alright, many thanks. The above shows that instead of using normal UDT
procedure (private short data message) for SMS, the private packet call
procedure is used instead.
Question: does this happen when the SMS is very short, like 2-3 words?
Private packet call is something I'm currently trying to reverse-engineer on
Hyteras, they use a proprietary format with confirmed data (the code for that
is not even in master yet because it's ugly and needs rewriting).
Instead in Motorola's case it seems to be using UDT format which is why dmrtc
(the code you have from master) can decode it. Weird.

Anyway this gives me a lot to chew on.

Thank you!

Great fix, thank you.

Please add PD685G to supported, both hunt modes etc.

Motorola SL4000e - only fixed hunt mode, Open Radio or Open System mode in RadioManager CapMax system settings, otherwise no reg, voice to group and voice to private work, everything else does not at this moment, regardless of settings. Also, one timing parameter needs to be adjusted in RM, otherwise in about 30min radio deregisters from dmrtc.

Motorola DP4801e - about same.

Sending sms from 1002077 to 1002001:

---
D: 2024-08-09 02:43:53.065 Call Alert CSBK
D: 2024-08-09 02:43:53.065 0000: 9F 00 00 02 0F 4A 11 0F 4A 5D A6 12 *.....J..J]..*
M: 2024-08-09 02:43:53.065 DMR Slot 1, received RF Call Alert CSBK from 1002077 to 1002001
M: 2024-08-09 02:43:53.071 Unhandled CSBK type
M: 2024-08-09 02:43:53.071 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.071 DMR Slot 1, unhandled network CSBK type - 0x33
M: 2024-08-09 02:43:53.076 Unhandled CSBK type
M: 2024-08-09 02:43:53.077 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.077 DMR Slot 2, unhandled network CSBK type - 0x33
M: 2024-08-09 02:43:53.129 Unhandled CSBK type
M: 2024-08-09 02:43:53.130 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.130 DMR Slot 2, unhandled network CSBK type - 0x33
M: 2024-08-09 02:43:53.193 Unhandled CSBK type
M: 2024-08-09 02:43:53.193 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.193 DMR Slot 2, unhandled network CSBK type - 0x33
M: 2024-08-09 02:43:53.249 Unhandled CSBK type
M: 2024-08-09 02:43:53.249 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.249 DMR Slot 2, unhandled network CSBK type - 0x33
M: 2024-08-09 02:43:53.304 Unhandled CSBK type
M: 2024-08-09 02:43:53.304 0000: B3 00 05 98 0F 4A 11 0F 4A 5D 5F 13 *.....J..J]_.*
W: 2024-08-09 02:43:53.304 DMR Slot 2, unhandled network CSBK type - 0x33
D: 2024-08-09 02:43:53.637 DMR, Confirmed Data Header
D: 2024-08-09 02:43:53.637 0000: 43 4A 0F 4A 11 0F 4A 5D 83 08 58 71 *CJ.J..J]..Xq*
M: 2024-08-09 02:43:53.638 DMR Slot 2, received RF data header from 1002077 to 1002001, 3 blocks
M: 2024-08-09 02:43:53.819 DMR Slot 2, ended RF data transmission
D: 2024-08-09 02:43:54.824 DMR, Confirmed Data Header
D: 2024-08-09 02:43:54.824 0000: 43 4A 0F 4A 11 0F 4A 5D 83 08 58 71 *CJ.J..J]..Xq*
M: 2024-08-09 02:43:54.825 DMR Slot 2, received RF data header from 1002077 to 1002001, 3 blocks
M: 2024-08-09 02:43:55.010 DMR Slot 2, ended RF data transmission
D: 2024-08-09 02:43:56.040 DMR, Confirmed Data Header
D: 2024-08-09 02:43:56.040 0000: 43 4A 0F 4A 11 0F 4A 5D 83 08 58 71 *CJ.J..J]..Xq*
M: 2024-08-09 02:43:56.040 DMR Slot 2, received RF data header from 1002077 to 1002001, 3 blocks
M: 2024-08-09 02:43:56.207 DMR Slot 2, ended RF data transmission
M: 2024-08-09 02:43:57.015 Unhandled CSBK type
M: 2024-08-09 02:43:57.015 0000: AE 00 00 00 FF FE D4 FF FE CA FF 8F *............*
W: 2024-08-09 02:43:57.015 DMR Slot 2, unhandled network CSBK type - 0x2E
M: 2024-08-09 02:43:57.070 Unhandled CSBK type
M: 2024-08-09 02:43:57.070 0000: AE 00 00 00 FF FE D4 FF FE CA FF 8F *............*
W: 2024-08-09 02:43:57.070 DMR Slot 2, unhandled network CSBK type - 0x2E
M: 2024-08-09 02:43:57.131 Unhandled CSBK type
M: 2024-08-09 02:43:57.131 0000: AE 00 00 00 FF FE D4 FF FE CA FF 8F *............*
W: 2024-08-09 02:43:57.131 DMR Slot 2, unhandled network CSBK type - 0x2E
M: 2024-08-09 02:43:57.192 Unhandled CSBK type
M: 2024-08-09 02:43:57.192 0000: AE 00 00 00 FF FE D4 FF FE CA FF 8F *............*
W: 2024-08-09 02:43:57.192 DMR Slot 2, unhandled network CSBK type - 0x2E
M: 2024-08-09 02:43:57.249 Unhandled CSBK type
M: 2024-08-09 02:43:57.249 0000: AE 00 00 00 FF FE D4 FF FE CA FF 8F *............*
W: 2024-08-09 02:43:57.249 DMR Slot 2, unhandled network CSBK type - 0x2E
M: 2024-08-09 02:43:59.015 Unhandled CSBK type
M: 2024-08-09 02:43:59.015 0000: A8 00 1A 20 12 00 27 B5 7D C0 4A F7 *... ..'.}.J.*
W: 2024-08-09 02:43:59.015 DMR Slot 1, unhandled network CSBK type - 0x28
---

---
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:11.852] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.395] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.920] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.414] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.890] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:14.426] [Debug] Unhandled CSBK type slot 1, channel 0
[8/Aug/2024 22:42:29.012] [Info] Announcing adjacent sites: 0
[8/Aug/2024 22:42:29.012] [Info] Announcing local time: Thu Aug 8 22:42:29 2024
[8/Aug/2024 22:42:59.011] [Info] Announcing adjacent sites: 0
[8/Aug/2024 22:42:59.011] [Info] Announcing local time: Thu Aug 8 22:42:59 2024
[8/Aug/2024 22:43:29.011] [Info] Announcing site frequencies, used channels: 2
[8/Aug/2024 22:43:29.012] [Info] Announcing adjacent sites: 0
[8/Aug/2024 22:43:29.012] [Info] Announcing local time: Thu Aug 8 22:43:29 2024
FID: 0 data1: 0 data2: 2
[8/Aug/2024 22:43:53.066] [Info] TSCC: DMR Slot 1, received private packet data call request from 1002077 to destination 1002001
[8/Aug/2024 22:43:53.066] [Debug] Allocated physical channel 0, logical channel 89, slot 2 to destination 1002001 and source 1002077
[8/Aug/2024 22:43:53.066] [Info] Received private packet data call request from 1002077, slot 1 to destination 1002001 (not registered ID)
[8/Aug/2024 22:43:53.641] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:53.705] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:53.756] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:53.821] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:54.825] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:54.898] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:54.945] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:55.011] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:56.042] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:56.089] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:56.156] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:56.208] [Debug] DMR Slot 2, received UDT data MS to MS from 1002077 to 1002001
[8/Aug/2024 22:43:57.009] [Debug] Physical channel 0, slot 2 to destination 1002001 and source 1002077 is marked as idle and deallocated
--- (UI shows Individual packet data call. 1002001 shows 'Data rx' but then 1002077 shows fail and both reset.)


Thank you!

Sending text 'A' from 1002077 to group 1002222:

MMDVMHost output:
---
M: 2024-08-09 02:39:36.743 DMR Slot 1, received RF Call Alert CSBK from 1002077 to 1467028
D: 2024-08-09 02:39:37.227 Call Alert CSBK
D: 2024-08-09 02:39:37.227 0000: 9F 00 00 03 16 62 94 0F 4A 5D 27 F1 *.....b..J]'.*
M: 2024-08-09 02:39:37.227 DMR Slot 1, received RF Call Alert CSBK from 1002077 to 1467028
D: 2024-08-09 02:39:37.822 Call Alert CSBK
D: 2024-08-09 02:39:37.822 0000: 9F 00 00 03 16 62 94 0F 4A 5D 27 F1 *.....b..J]'.*
M: 2024-08-09 02:39:37.822 DMR Slot 1, received RF Call Alert CSBK from 1002077 to 1467028
M: 2024-08-09 02:39:59.022 Unhandled CSBK type
M: 2024-08-09 02:39:59.022 0000: A8 00 1A 20 12 00 27 B4 FD C0 66 5F *... ..'...f_*
W: 2024-08-09 02:39:59.022 DMR Slot 1, unhandled network CSBK type - 0x28
--- (I've shortened extra repeating call alert messges)

dmrtc output:
---
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:11.852] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.395] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:12.920] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.414] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:13.890] [Debug] Unhandled CSBK type slot 1, channel 0
CSBKO: "1f" FID 0 data1: 0 data2: 3 dst: 1467028 src: 1002077
[8/Aug/2024 22:42:14.426] [Debug] Unhandled CSBK type slot 1, channel 0
--- (UI shows 'Unknown service request)

The crashes in dmrtc related to disabling DMRGateway should now be fixed in the
master branch. I've also introduced some sanity checks on some config values.
It is no longer possible to set less than one gateway or one channel.
If not using gateways, instead of setting number of gateways to zero, use the
toggle which enables or disables DMRGateway.

Adrian