开云体育

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!!!

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

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.

On Tuesday, 6 August 2024 18:17:18 EEST you wrote:

As sort of addition to wishlist - Auth not just being cosmetic feature, but
refuse registration for non-auth'ed radios.

Yes, that is already planned and will be implemented at some point as an
optional feature.

As sort of addition to wishlist - Auth not just being cosmetic feature, but refuse registration for non-auth'ed radios.

Pioneer wagon n.2 here.
Ordered PAs of different designs as well as filters.
On my Limesdr Mini 1.2 max tx limit is 101, I use 80 to 100 (100 equals '+74db max' in lime driver). External cooling, obviously.

On Tuesday, 6 August 2024 15:17:16 EEST you wrote:

Hallo Adrian,

DMR Tier III is mainly running smoothly in the software side here. Now I
want to make the next step.

Hello Christian,
Answers below:

I was able to aquire two narrow bandpass filters for input and output. A
little too much loss for production use, but TX/RX isolation is
definitely good enough for testing.

For my prototype SDR repeater based on the LimeNet Micro v1, I have a tunable
6 cavity UHF Procom duplexer. These guys can be factory / home tuned for
multi-carrier operation if all carriers fit within 200 - 300 kHz. The downside
is a little increase in insertion loss both sides, but they provide a pretty
flat response over 200 kHz and excellent isolation. Used duplex split here is 8
MHz so beware there are several variants at the Danish producer.

You'll also want a good bandpass filter on RX in addition to the duplexer. The
SDR front-end is too wide-band and will pick up a lot of out of band signals
otherwise de-sensing the receiver. I can't tell you whether to use an external
LNA in addition to the internal one, because it all depends on some
measurements you'll need to take yourself as specs can vary a lot. I do
recommend a signal limiter before the internal LNA as nearby signals will
overwhelm the RX and create IMD in the LNA.

Also, a friend gave me a suitable 70cm preamp that is waiting for testing.

Do you have an opinion about the best PA?

I'd recommend two amplification stages, and I can tell you what I use as a first
stage: DK6JL's design, to bring the -3 dBm output of the SDR towards 25 - 26
dBm total output (depending on the number of carriers I end up with 17 - 21
dBm per carrier.
For the second power stage, I'm not really there yet due to lack of time, but
I'd recommend to keep it a little in the linear-ish regime (if using a class
C, at least 6 dB back-off), or even a small linear amplifier. I recommend
testing the output on a spectrum analyser for any IMD, as the multi-carrier
waveform is very finnicky. You can safely use a Kuhne linear amp, they can take
as input power around 0 dBm or up to 10-20 dBm AFAIK. To reduce the price, a
second stage using a class C design is desirable though.

My first stage PA source website;
kleinleistungsverstaerker-fuer-adalm-pluto-hackrf-lime-langstone-usw/

Currently, with 100% TX gain in qradiolink, I roughly get -19dBm per
Carrier directly on the TX connector of the Lime

Strong recommendation to not exceed 94 on output gain in qradiolink, the
LimeSDR PA tends to introduce distortion above about 96 gain at least on my
model. Do check the waveform and spurious on a spectrum analyser at that
point, highly recommended.

With a small chinese amplifier (WYDZ-PA-1M-750MHz-3W) I can amplify
this to about +15dBm per Carrier.

Like I said, just make sure to check the output for spurious and IMD, because
of the specifics of the waveform. Cheap Chinese PAs tend to have widely wrong
P1dB figures quoted in marketing, so be careful, I got burned on a couple of
such Ebay purchases which distorted very early, but others were fine if I
backed them off 3-4 dB below their quoted P1dB.

I did not check the signal quality yet in depth with multiple carriers
transmissing at the same time.

From your experience:

- What would be a reasonable TX gain setting for the Lime Mini 2 to get
7 clear carriers out of the SDR?

Maximum 94 tx_gain on my Lime v1. Can't say for sure on the v2 as I don't have
that model.

- What amplifier chain would you recommend to get the output signal to a
resonable level?

See above, two stage amplification, or even one stage using a Kuhne linear
amplifier. You can experiment with a class C as a second stage (FM amp) and let
us know if results are acceptable when backing off the max output by at least 6
dB. I was going to do this this spring but was too busy. My expectations are
that a normal Mitsubishi PA module with adequate cooling should work...

In the beginning, 10-100mW per Carrier would be fine. At the end I am
aiming for at least 50W for all 7 carriers together, so at least 7W per
carrier, maybe more to account for filter and cable losses.

Yeah that sounds reasonable, that's what I'm aiming at too. You're one of the
pioneers here, not many people even attempted this yet, so would be great if
you document your findings during the process and publish them.

On the testing method: What's the easiest way to get qradiolink to
produce an not necessary modulated FM signal all the 7 channels

FM carrier not possible AFAIK unless you go change the GNU Radio code inside
it. But you can set in MMDVM beacons to run for 29 seconds every 30 seconds
and you'll achieve the same result. See my video here:

Thanks in advance

Christian DB9CR

Cheers and 73s
Adrian

It works, thank you. Had to do little patching but it does now...
Really stable, great audio quality (unlike HS+dvmhost t3).
So far only one small glitch is seen - if during a group call one party presses 'hangup' button, the call ends for it, but other MS go into sort of a limbo (hang) for about 20 seconds, beeping, before closing the call.
Oh, and thanks for passing S+.

Hallo Adrian,

DMR Tier III is mainly running smoothly in the software side here. Now I want to make the next step.

I was able to aquire two narrow bandpass filters for input and output. A little too much loss for production use, but TX/RX isolation is definitely good enough for testing.

Also, a friend gave me a suitable 70cm preamp that is waiting for testing.

Do you have an opinion about the best PA?

Currently, with 100% TX gain in qradiolink, I roughly get -19dBm per Carrier directly on the TX connector of the Lime

With a small? chinese amplifier (WYDZ-PA-1M-750MHz-3W) I can amplify this to about +15dBm per Carrier.

I did not check the signal quality yet in depth with multiple carriers transmissing at the same time.

From your experience:

- What would be a reasonable TX gain setting for the Lime Mini 2 to get 7 clear carriers out of the SDR?

- What amplifier chain would you recommend to get the output signal to a resonable level?

In the beginning, 10-100mW per Carrier would be fine. At the end I am aiming for at least 50W for all 7 carriers together, so at least 7W per carrier, maybe more to account for filter and cable losses.

On the testing method: What's the easiest way to get qradiolink to produce an not necessary modulated FM signal all the 7 channels

Thanks in advance

Christian DB9CR

On Monday, 5 August 2024 17:47:25 EEST you wrote:

Of course I tried it. Many times. No go. I'll take a dirty patch right now.

The workaround described in my previous email is valid, you just need to
apply it while dmrtc is stopped to avoid the config file being overwritten.
A fix will also be implemented, but meanwhile you can use the
workaround.

Of course I tried it. Many times. No go. I'll take a dirty patch right now.

Please change
gateway_number = 1;
gateway_enabled = 1;

and then try again (even if you don't have any DMRGateway started).
Seems like there's a bug in that area.

[5/Aug/2024 03:04:35.817] [Info] Received group short data message request to TG from 1002001, slot 1 to destination 1467029
A: false GI: true Format: 0 UDTFormat: 7 Opcode: 26 RSVD: 0 PF: false SF: false SAP: 0 Blocks: 1
[5/Aug/2024 03:04:36.120] [Debug] DMR Slot 1, received UDT data MS to TG from 1002001 to 1002223

Thread 9 "controller" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd23ff6c0 (LWP 4796)]
UDPClient::writeDataToNetwork (this=this@entry=0x0,
data=data@entry=0x7fffd23feb20 "DMRD\003\017J\021\017J\357\207\326\022",
size=size@entry=55) at ../src/udpclient.cpp:149
149 if(!_started)
(gdb) bt
#0 UDPClient::writeDataToNetwork(unsigned char*, int)
(this=this@entry=0x0, data=data@entry=0x7fffd23feb20 <error: Cannot access memory at address 0x7fffd23feb20>, size=size@entry=55)
at ../src/udpclient.cpp:149
#1 0x000055555557d382 in UDPClient::writeDMRData(CDMRData&)
(this=0x0, data=...) at ../src/udpclient.cpp:234
#2 0x0000555555590c88 in Controller::run() (this=0x5555556a1e70)
at ../src/controller.cpp:271
(gdb)


If I send msg to group too. Sending sms from dmrtc to radio works.

Nope, no bind errors.
---
control_port = 4939;
mmdvm_listen_port = 44550;
mmdvm_send_port = 44560;
gateway_listen_port = 44660;
gateway_send_port = 44670;
window_width = 1400;
window_height = 700;
headless_mode = 0;
channel_number = 1;
gateway_number = 0;
udp_local_address = "127.0.0.1";
mmdvm_remote_address = "127.0.0.1";
gateway_remote_address = "127.0.0.1";
control_channel_physical_id = 0;
control_channel_slot = 1;
gateway_enabled = 0;
announce_priority = 1;
system_announcement_message = "DMR tier III trunked radio site";
payload_channel_idle_timeout = 4;
system_identity_code = 9;
freq_base = 420000000;
freq_separation = 25000;
freq_duplexsplit = 33000000;
use_absolute_channel_grants = 1;
use_fixed_channel_plan = 1;
announce_system_message = 1;
prevent_mmdvm_overflows = 1;
receive_tg_attach = 1;
registration_required = 1;
transmit_subscribed_tg_only = 0;
announce_system_freqs_interval = 120;
announce_adjacent_bs_interval = 30;
announce_late_entry_interval = 1;
channel_disable_bitmask = 0;
talkgroup_routing = ( );
slot_rewrite = ( );
logical_physical_channels = (
{
channel_id = 1L;
logical_channel = 1L;
tx_freq = 422200000L;
rx_freq = 455200000L;
colour_code = 8L;
} );
adjacent_sites = ( );
service_ids = (
{
service_name = "dgna";
id = 1000002;
},
{
service_name = "help";
id = 1000001;
},
{
service_name = "location";
id = 1048677;
},
{
service_name = "signal_report";
id = 1000003;
} );
call_priorities = (
{
id = 9;
priority = 1;
},
{
id = 112;
priority = 3;
},
{
id = 226;
priority = 2;
} );
call_diverts = ( );
auth_keys = ( );
-----

On Monday, 5 August 2024 09:16:55 EEST you wrote:

#0 0x000055555557ce95 in UDPClient::writeDataToNetwork(unsigned char*, int)
(this=this@entry=0x0, data=data@entry=0x7fffd23feb20 <error: Cannot access
memory at address 0x7fffd23feb20>, size=size@entry=55) at
../src/udpclient.cpp:153
#1 0x000055555557d2e2 in UDPClient::writeDMRData(CDMRData&)
(this=0x0, data=...) at ../src/udpclient.cpp:226
#2 0x0000555555590be8 in Controller::run() (this=0x5555556a1b80)
at ../src/controller.cpp:271

(that's after I commented out if (!_started) statement to zero in on
offending command.

Right, that makes sense. Without making any changes to the code, fo you not
have a message like "Server could not bind to port..." during startup? That
points to a different issue. You either have two instances of dmrtc running at
the same time and the second one fails to bind to the network interface, or
some kind of network misconfiguration.
There cannot be two programs trying to bind to the same IP address and ports.
I suggest you also paste your config file here.

Adrian

[5/Aug/2024 02:31:17.547] [Debug] Allocated physical channel 0, logical channel 89, slot 2 to destination 1002223 and source 1002001

Thread 9 "controller" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd23ff6c0 (LWP 4540)]
UDPClient::writeDataToNetwork (this=this@entry=0x0,
data=data@entry=0x7fffd23feb20 "DMRD", size=size@entry=55)
at ../src/udpclient.cpp:149
149 if(!_started)
(gdb) bt
#0 UDPClient::writeDataToNetwork(unsigned char*, int)
(this=this@entry=0x0, data=data@entry=0x7fffd23feb20 <error: Cannot access memory at address 0x7fffd23feb20>, size=size@entry=55)
at ../src/udpclient.cpp:149
#1 0x000055555557d382 in UDPClient::writeDMRData(CDMRData&)
(this=0x0, data=...) at ../src/udpclient.cpp:234
#2 0x0000555555590c88 in Controller::run() (this=0x5555556964b0)
at ../src/controller.cpp:271
(gdb)

On Monday, 5 August 2024 09:14:55 EEST you wrote:

gbd reported error in udpclient.cpp at line 149 at crash. That's where my
c++ knowledge ends. Something with memcpy and out of bounds?

Can you please paste the output of the backtrace here?
Or open an issue on Github, either way I need the output to figure out what's
happening. If you can, the complete output from gdb please.

Adrian

#0 0x000055555557ce95 in UDPClient::writeDataToNetwork(unsigned char*, int)
(this=this@entry=0x0, data=data@entry=0x7fffd23feb20 <error: Cannot access memory at address 0x7fffd23feb20>, size=size@entry=55)
at ../src/udpclient.cpp:153
#1 0x000055555557d2e2 in UDPClient::writeDMRData(CDMRData&)
(this=0x0, data=...) at ../src/udpclient.cpp:226
#2 0x0000555555590be8 in Controller::run() (this=0x5555556a1b80)
at ../src/controller.cpp:271

(that's after I commented out if (!_started) statement to zero in on offending command.

gbd reported error in udpclient.cpp at line 149 at crash. That's where my c++ knowledge ends. Something with memcpy and out of bounds?

On Monday, 5 August 2024 07:50:32 EEST you wrote:

After many attempts I finally got a red tx led and MMDVMHost showing voice
frames!! .. and.... dmrtc crashed the moment voice started. Segmentation
fault. Debian 11, 4gb ram, 4 cores intel x64....

Thanks for sharing your experience here! These are interesting findings, it
seems there are some bugs somewhere, as I've never managed to crash dmrtc with
my radios.
It would be a great help if you could provide a backtrace when the program
crashes.
For that, start the program using gdb, run it and after the crash type bt:
gdb ./drmtc
r
...
bt

I'll try to take a look at the issues as soon as possible, when I get some
free time.

Adrian