|
Decided to start a new thread. Spent about 15 hours testing.
Hyteras are great, everything works, sms, location etc.
After much ado was able to attach SL4000e. It took ages to get it to register. But it did.
So, on moto, only fixed channel plan works. The moment I enable absolute chan assn - it stops working (establishing a call). Even with flex channels setup in moto cps. Same. Only fixed plan works every time (and I do NOT click 'use fixed plan' in dmrtc, just uncheck absolute ch assn).
No problem, switched hyteras to fixed plan, all good.
Private calls work.
Sms does not work, dgna does not work. Ping does. Sms to private and group fails, although hyteras show 'receiving data' then fail out.
There are only one option relating to text transmission, and it only has 3 options (Advantage mode, DMR Standard and DMR T3 IOP. none work).
Also, channel numbers in moto cps are wildly different from what hytera uses (shows in cps) and dmrtc (same as hyt). For example dmrtc/hyt group 1002222 (flat dial plan) needs to be entered as 1467028 in moto cps. Weird, and I don't thing the difference is static.
As usual, willing to contribute. Amazing new life for a lot of hardware.
|
Interesting findings, thanks! I'll try to address them one by one below. On Wednesday, 7 August 2024 07:03:30 EEST you wrote: Decided to start a new thread. Spent about 15 hours testing.
Hyteras are great, everything works, sms, location etc.
After much ado was able to attach SL4000e. It took ages to get it to
register. But it did. It might be a good idea to capture some logs during the registration attempts, both in MMDVMHost and in dmrtc, so we can see why Motorolas have a hard time registering. Maybe they are slightly off frequency and not all packets can be decoded by MMDVMHost, or maybe their registration procedure is different, hard to tell without having a radio. So, on moto, only fixed channel plan works. The
moment I enable absolute chan assn - it stops working (establishing a
call). Even with flex channels setup in moto cps. Same. Only fixed plan
works every time (and I do NOT click 'use fixed plan' in dmrtc, just
uncheck absolute ch assn). No problem, switched hyteras to fixed plan, all
good. Just to clarify, absolute channel grants are not related to channel plan in the CPS. An absolute channel grant contains two PDUs, and gives the radio the exact frequency, not just a channel number (set in the CPS beforehand). So maybe double check RX frequencies and TX frequencies, colour codes and channel numbers in the Logical / Physical Channel Map settings. The values should be valid for the radio freqs, not the SDR freqs which are reversed. The checkbox for "fixed channel plan" toggles between a channel plan with base frequency, channel spacing and duplex split, and a channel plan which is stored in the radio (both channel number and frequencies) if unchecked. So if unchecked and the radio knows channel 2 is 434.925000 because the freq is saved, it will work. Otherwise see the Hytera CPS for the other option (checked with base freq only defined in CPS). Private calls work.
Sms does not work, dgna does not work. Ping does. Sms to private and group
fails, although hyteras show 'receiving data' then fail out. There are only
one option relating to text transmission, and it only has 3 options
(Advantage mode, DMR Standard and DMR T3 IOP. none work). SMS is one of the most difficult things, even Hytera's long messages don;t work because they are not standard. Again, some output logs from dmrtc and MMDVMHost would be good. Also, if you have some programming knowledge, you can introduce some debug code that prints the binary payload (as hex values). I may do that later but can't right now, being busy with work. Also, channel
numbers in moto cps are wildly different from what hytera uses (shows in
cps) and dmrtc (same as hyt). For example dmrtc/hyt group 1002222 (flat
dial plan) needs to be entered as 1467028 in moto cps. Weird, and I don't
thing the difference is static. Hytera's "flat" dialing plan uses base 11 talkgroup numbers. Maybe Motorola uses base 10 or some other weird numbering scheme. What might help is to try various numbers in the CPS, like 1, 10, 100, 200, 500, 1000 and see what they look like in dmrtc (which converts from base 11 to base 10). That can tell use what the scheme might use.
As usual, willing to contribute. Amazing new life for a lot of hardware.
Thanks for the offer. Indeed there's a lot of work waiting and I'm currently stuck between work and holidays season which means slow moving in this area. Any contribution is welcome. Adrian
|
1. It has trouble registering because of look n2. With fixed plan it registers easily.
2. I understand! That does not work with motorola. Exactly same setings (both tc and radio side) work on hyteras. Yes, I'm not dumb, I've been working with radios since 80s...
3. I will get logs. Dmrtc shows sms from moto as 'unknown packet data' or 'private packet data'.
4. Understood.
5. Thank you for efforts!!!
|
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)
|
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!
|
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!
|
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
|
Sadly no such option. CapMax settings set in RM is really scarce, compared to Hyt. All in all about 10 settings overall.
|
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).
|
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.
|
Max length of sms on moto is 21 chars when sending. Guessing this is non-moto capmax mode limitation on moto's side.
|
Send msg to all from dmrtc - hyts get the sms, moto silent, no indication, no text.
Will grab some logs later.
|
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.
|
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
|
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).
|
Checked msg encoding settings - nope, none.
|
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).
|
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.
|
