开云体育

Hello Christian,

That is indeed wrong and explains why the radio doesn't attempt registration.
On an idle control channel, most of the PDUs should be C_ALOHA (95% of the
time).
DSD-FME decodes them as follows:
C_ALOHA_SYS_PARMS - Tiny - Net ID: 2 Site ID: 1.2 Cat: AB
Reg Req: 1 V: 2 Mask: 00 MS: 16776916

To me it almost looks like the ControlChannel parameter is not set in the
MMDVMHost config file for the control channel instance.
Can you confirm that the control channel instance has in the [DMR] section the
following parameters?
Trunking=1
SystemCode=9
RegistrationRequired=1
ControlChannel=1
ControlChannelAlternateSlot=0

Especially the ControlChannel=1 parameter is important here. Only the MMDVM
instance 1 (on the control channel frequency) needs it set to one, rest should
be zero.
I can only reproduce your issue by setting ControlChannel to 0 or ignoring the
setting completely.
If you have this setting configured as above, then please send a complete
capture for at least 30 seconds without grep exclusion so I can try to figure
it out further.

Related to your question about the system code setting in dmrtc: both dmrtc
system code and MMDVMHost config file system code need to match. dmrtc cannot
configure MMDVMHost due to an architectural limitation, and the setting is used
in both programs differently.

Regarding the date mismatch: it is most likely a locale difference. In some
locales like the en_US, the week starts on Sunday so day 0 of the week will be
Sunday and day 6 will be Saturday. European week starts Monday. I can't
remember which locale is used by default or if system dependent, but might be
some display thing in dsd-fme. I can check.

Best regards,
Adrian

Hello Adrian,

got my RTL stick back.

SDRTrunk on Windows was not able to recognize my Stick. On Linux, it didn't start at all.

I finally got dsd-fme running.

# cat dmr_t3_chan.csv
ChannelNumber(dec),frequency(Hz) (do not delete this line or won't import properly)
999,439700000,1

# dsd-fme -i rtl -T -fs -C dmr_t3_chan.csv -o udp:127.0.0.1:23470 |& grep -v Sync:? | grep -v "SLCO NULL"

[...]

?Announcements (C_BCAST) Mass Registration (MassReg)
?Reg Window: 8; Aloha Mask: 00; Target: 0;
?Announcements (C_BCAST) Broadcast Local Time (Local_Time)
?Date: 6.16; Saturday; UTC Time: 22:45:37; Local: 22:45:37; Offset: 0;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0007; RX Base: 439000000; RX Step: 700000; RX Freq: 439700000;
???????????? TX Base: 434000000; TX Step: 900000; TX Freq: 434900000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0009; RX Base: 439000000; RX Step: 725000; RX Freq: 439725000;
???????????? TX Base: 434000000; TX Step: 925000; TX Freq: 434925000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0011; RX Base: 439000000; RX Step: 750000; RX Freq: 439750000;
???????????? TX Base: 434000000; TX Step: 950000; TX Freq: 434950000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0013; RX Base: 439000000; RX Step: 775000; RX Freq: 439775000;
???????????? TX Base: 434000000; TX Step: 975000; TX Freq: 434975000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0005; RX Base: 439000000; RX Step: 675000; RX Freq: 439675000;
???????????? TX Base: 434000000; TX Step: 875000; TX Freq: 434875000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0003; RX Base: 439000000; RX Step: 650000; RX Freq: 439650000;
???????????? TX Base: 434000000; TX Step: 850000; TX Freq: 434850000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0001; RX Base: 439000000; RX Step: 625000; RX Freq: 439625000;
???????????? TX Base: 434000000; TX Step: 825000; TX Freq: 434825000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0007; RX Base: 439000000; RX Step: 700000; RX Freq: 439700000;
???????????? TX Base: 434000000; TX Step: 900000; TX Freq: 434900000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0009; RX Base: 439000000; RX Step: 725000; RX Freq: 439725000;
???????????? TX Base: 434000000; TX Step: 925000; TX Freq: 434925000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0011; RX Base: 439000000; RX Step: 750000; RX Freq: 439750000;
???????????? TX Base: 434000000; TX Step: 950000; TX Freq: 434950000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0013; RX Base: 439000000; RX Step: 775000; RX Freq: 439775000;
???????????? TX Base: 434000000; TX Step: 975000; TX Freq: 434975000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0005; RX Base: 439000000; RX Step: 675000; RX Freq: 439675000;
???????????? TX Base: 434000000; TX Step: 875000; TX Freq: 434875000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0003; RX Base: 439000000; RX Step: 650000; RX Freq: 439650000;
???????????? TX Base: 434000000; TX Step: 850000; TX Freq: 434850000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Announce Logical Channel/Frequency Relationship (Chan_Freq)
?LPCN: 0001; RX Base: 439000000; RX Step: 625000; RX Freq: 439625000;
???????????? TX Base: 434000000; TX Step: 825000; TX Freq: 434825000;
?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;


[...]

Changing the System Identity Code in the dmrtc gui does not seem to change anything. Tried 9 and 100. Also Require Registration does not seem to have an effect.

The radio is still not registering.

This look to me as if the radio finds the correct frequency, in general likes the channel, but waits for something to happen to finally start registering. Maybe a Aloha-PDU?

?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Mass Registration (MassReg)
?Reg Window: 8; Aloha Mask: 00; Target: 0;

That's a Mass Registration Request, to me it looks like Aloha is never sent out in current version of software. Or am i missing something?

6.4.4.1.0 Registration by Random Access - Introduction
When an MS determines that it is required to register, it shall attempt to do so by random access using the procedures
defined in clause 6.2. If the random access timeout C_RandTC expires and the MS has not sent a random access
registration request, the MS shall enter the TSCC acquisition procedures

Could that mean that the PD755 MS never starts registering if no aloha PDU is received? And then resorts to searching for a different TSCC? And that the newer devices handle this case in a more clever way and try nevertheless to register? Or is there a switch in the CPS to change this behavior?

6.4.1.1 Introduction
The registration strategy describes two types of registration. The first of these is explicit registration, where registration
is achieved by means of an MS random access procedure. The second is implicit registration, where registration is
achieved as the result of any PDUs exchanged between a TSCC and an MS

Is the 755 not able to implicit registration? Or does this need to be enableded somewhere?

What would you suggest as a next step?

One minor bug:

?SLC_C_SYS_PARMS: Tiny; Net ID: 2; Site ID: 1.2; Reg Req: 1; CSC: 1; SYS: 0009;
?Announcements (C_BCAST) Broadcast Local Time (Local_Time)
?Date: 6.16; Saturday; UTC Time: 22:51:07; Local: 22:51:07; Offset: 0;

Today is Sunday, not Saturday, even if I wish it was true ;-)

73 Christian DB9CR

Greetings,

A new feature is being developed at the moment to complement the frequency
domain and constellation displays: time domain display.
You may want to contribute some suggestions regarding the way this feature
should work, so this is the time to do so.

Demo video:

Cheers,
Adrian

Hello Adrian,

Am 11.06.2024 um 10:00 schrieb Adrian M:

The most interesting finding comes from the service menu. I am sure now
that it's hunting on the correct frequency. Also I can see that during
hunting, it stays a little bit longer on the channel that is actually
transmitting. RSSI on the correct channel is about -70dBm. Thats very
good progress.

Just to be sure, if I were you I'd use a tool like dsd-fme or SDRTrunk with an
RTL dongle or similar just to check that the control channel parameters are as
expected.

Yes, need to do that. Unfortunately, my RTLStick is currently not here - was used for a Repeater test bya fellow OM. Need to wait until it is back. But that's in deed the next logical step.

I have never heard transmissions on the radio's TX frequency.

That might point to some mismatch in CPS parameters. Hytera generally sticks
pretty close to the Tier 3 standard except for some stuff like packet data
calls, message with position or query neighbours. I'll double check tonight my
CPS settings for any tricky setting in the System or Developer sections that I
need to document.

Thanks, lets see.

If you are interested in the details regarding TSCC acquisition, system codes
structure etc., it is very well described in the standard:

ts_10236104v011001p.pdf
at pages 62 through 67.

Yes, seen that, you mention that somewhere on the website.

Hunt/Fixed TSCC, last column 9

Trunking Controller, Setting/General Setting, System Identity Code: 9

MMDVMhost, Section DMR, SystemCode=9

Somewhere else?

No, this is all that's needed for the System Identity code.

Good.

The base frequency is channel 1 (the base frequency for the channel plan),
then each channel number gets incremented by the channel spacing. So for you
that would be channel 1 for the radio TX and base station RX. In my screenshot
in the first email, the control channel is channel 37 which is relative to this
base frequency.

If all else fails, you can try to set Flexible Channel Plan in the CPS and
define all channel frequencies there, then disable "Fixed channel plan" in
dmrtc. This was also my initial configuration of the radio until I got the hang
of the fixed channel plan. I think one additional problem might be that my
Hytera CPS is a different version to yours and might have some settings in
different places.
Duplex split in dmrtc is relative to the RX frequency (which is the inverse of
the radio), same as "tx_shift" in qradiolink.cfg. If you have a negative split
in the radio (TX lower than RX), the split will be positive in qradiolink and
dmrtc since the base station listens on the reverse of the radio TX.
Now that you mention that, I can see that it is confusing. The channel plan
lists the RX and TX freq of the radio instead of the base station. That is
because channel grants are given from the perspective of the user radio. I
need to clarify that in the docs. However, those frequencies are only relevant
after registration for channel grants and such.

Thanks for clarification.

Sure, you're welcome! I will be free tonight so we can set a sched on
Brandmeister if you want. I look forward to adding another radio to the
compatibility matrix.

I am pretty sure that we will find out what's going on, just needs some time. First I need my RTLStick back. I will keep you posted.

73 Christian DB9CR

Greetings again Christian.
Replies inline below:

The most interesting finding comes from the service menu. I am sure now
that it's hunting on the correct frequency. Also I can see that during
hunting, it stays a little bit longer on the channel that is actually
transmitting. RSSI on the correct channel is about -70dBm. Thats very
good progress.

Just to be sure, if I were you I'd use a tool like dsd-fme or SDRTrunk with an
RTL dongle or similar just to check that the control channel parameters are as
expected.

I have never heard transmissions on the radio's TX frequency.

That might point to some mismatch in CPS parameters. Hytera generally sticks
pretty close to the Tier 3 standard except for some stuff like packet data
calls, message with position or query neighbours. I'll double check tonight my
CPS settings for any tricky setting in the System or Developer sections that I
need to document.

So the system code needs to go

Network/Network 00.000000001.001

Yes, that binary number adds up to 9. Generally the network number needs to be
the same between radio and control channel, while the site id (last 3 binary
digits) can be different since the radio can seamlessly roam between sites on
the same network. There's another setting in the CPS which can enable roaming
between networks, but let's not get into that yet.

If you are interested in the details regarding TSCC acquisition, system codes
structure etc., it is very well described in the standard:

ts_10236104v011001p.pdf
at pages 62 through 67.

Hunt/Fixed TSCC, last column 9

Trunking Controller, Setting/General Setting, System Identity Code: 9

MMDVMhost, Section DMR, SystemCode=9

Somewhere else?

No, this is all that's needed for the System Identity code.

One point I am wondering about:

What needs to go into Setting/General Settinge/Base frequency in the
trunking controller. The Transmit Frequency of the radio or of the base
station?

The base frequency is channel 1 (the base frequency for the channel plan),
then each channel number gets incremented by the channel spacing. So for you
that would be channel 1 for the radio TX and base station RX. In my screenshot
in the first email, the control channel is channel 37 which is relative to this
base frequency.

If all else fails, you can try to set Flexible Channel Plan in the CPS and
define all channel frequencies there, then disable "Fixed channel plan" in
dmrtc. This was also my initial configuration of the radio until I got the hang
of the fixed channel plan. I think one additional problem might be that my
Hytera CPS is a different version to yours and might have some settings in
different places.

Setting/General Settinge/Duplex split in the controller is TX - RX or
RX-TX? Of Radio or of Base Station?

Duplex split in dmrtc is relative to the RX frequency (which is the inverse of
the radio), same as "tx_shift" in qradiolink.cfg. If you have a negative split
in the radio (TX lower than RX), the split will be positive in qradiolink and
dmrtc since the base station listens on the reverse of the radio TX.

Also, in the Logical Physical Channel Map: is it RX/TX frequency of
radio or of base station?

Now that you mention that, I can see that it is confusing. The channel plan
lists the RX and TX freq of the radio instead of the base station. That is
because channel grants are given from the perspective of the user radio. I
need to clarify that in the docs. However, those frequencies are only relevant
after registration for channel grants and such.

Next steps tomorrow. Multumesc again!

Sure, you're welcome! I will be free tonight so we can set a sched on
Brandmeister if you want. I look forward to adding another radio to the
compatibility matrix.

BR,
Adrian

Buna seara Adrian,

multumesc for the quick answer.

No success so far, but some very good hints.

The most interesting finding comes from the service menu. I am sure now that it's hunting on the correct frequency. Also I can see that during hunting, it stays a little bit longer on the channel that is actually transmitting. RSSI on the correct channel is about -70dBm. Thats very good progress.

I have never heard transmissions on the radio's TX frequency.

As I said, I am pretty much sure that the SDR is transmitting sensible DMR, as I could communicate over one of the channels directly to brandmeister in Tier II Mode with the same Hytera radio. Also, when I subscribe a static channel and it appears on TS2 of the control channel, I can hear it in monitor mode on my Anytone.

For some reason, the Hytera is receiving, but not accepting the base station. Some System Code foo that I still need to find out.

So the system code needs to go

Network/Network 00.000000001.001

Hunt/Fixed TSCC, last column 9

Trunking Controller, Setting/General Setting, System Identity Code: 9

MMDVMhost, Section DMR, SystemCode=9

Somewhere else?

One point I am wondering about:

What needs to go into Setting/General Settinge/Base frequency in the trunking controller. The Transmit Frequency of the radio or of the base station?

Setting/General Settinge/Duplex split in the controller is TX - RX or RX-TX? Of Radio or of Base Station?

Also, in the Logical Physical Channel Map: is it RX/TX frequency of radio or of base station?

Next steps tomorrow. Multumesc again!

73 Christian DB9CR

Am 10.06.2024 um 21:37 schrieb Adrian M:

Some further troubleshooting information (and I guess I should put this in the
documentation as well):

1. To check if the Control Channel is being transmitted at all - use a program
like SDRTrunk or dsd-fme. Example:
./dsd-fme -fs -i rtl:0:434.900M:25:0:40:0 -T 2>&1

2. If the TSCC transmission is ok, check that once radio is turned on and
hunting, a periodic transmission is happening from the radio side.

3. If the radio transmits (attempting to register), check that qradiolink
receives the transmission at a good level and the SDR is not overloaded. If
the SDR is overloaded reduce RX gain close to minimum. Check Duplex mode
enabled. Also check that RX offset is set to +/-12500 Hz to avoid DC leakage
from the SDR.

4. If above is ok, check that MMDVMHost for the control channel is logging
received registration CSBKs that look like this:
M: 2024-06-10 19:54:34.638 DMR Slot 1, received RF Call Alert CSBK from YO8RZZ
to 167769│M: 2024-06-10 14:56:26.504 Unhandled CSBK type
19
│M: 2024-06-10 14:56:26.505 0000: AE 00 00 01 FF FE D4 FF FE CA 47 EE
M: 2024-06-10 19:54:34.663 Unhandled CSBK type
│ *..........G.*
M: 2024-06-10 19:54:34.663 0000: 9C 00 03 0E 22 9B 72 FF FE D7 A8 6C
*..│W: 2024-06-10 14:56:26.505 DMR Slot 1, unhandled network CSBK type - 0x2E
..".r....l*
│M: 2024-06-10 14:56:26.560 Unhandled CSBK type
W: 2024-06-10 19:54:34.663 DMR Slot 1, unhandled network CSBK type - 0x1C
│M: 2024-06-10 14:56:26.560 0000: AE 00 00 01 FF FE D4 FF FE CA 47 EE
D: 2024-06-10 19:54:34.993 DMR Slot 1, raw RSSI: 1, reported RSSI: -1 dBm
│ *..........G.*
D: 2024-06-10 19:54:34.993 DMR, Unified Data Transport Header
│W: 2024-06-10 14:56:26.560 DMR Slot 1, unhandled network CSBK type - 0x2E
D: 2024-06-10 19:54:34.993 0000: 40 01 FF FE D7 22 9B 72 01 9B 6C 9C
*@.│M: 2024-06-10 14:56:26.621 Unhandled CSBK type
...".r..l.*
│M: 2024-06-10 14:56:26.621 0000: AE 00 00 01 FF FE D4 FF FE CA 47 EE
M: 2024-06-10 19:54:34.993 DMR Slot 1, received RF data header from YO8RZZ to
16776919, │ *..........G.*
2 blocks
│W: 2024-06-10 14:56:26.621 DMR Slot 1, unhandled network CSBK type - 0x2E
D: 2024-06-10 19:54:35.044 DMR Slot 1, raw RSSI: 3, reported RSSI: -3 dBm
│M: 2024-06-10 14:56:26.677 Unhandled CSBK type
D: 2024-06-10 19:54:35.115 DMR Slot 1, raw RSSI: 84, reported RSSI: -84 dBm
│M: 2024-06-10 14:56:26.677 0000: AE 00 00 01 FF FE D4 FF FE CA 47 EE
M: 2024-06-10 19:54:35.115 DMR Slot 1, ended RF data transmission
│ *..........G.*
D: 2024-06-10 19:54:35.136 Call Alert Ack CSBK
│W: 2024-06-10 14:56:26.677 DMR Slot 1, unhandled network CSBK type - 0x2E
D: 2024-06-10 19:54:35.136 0000: A0 00 FE C4 22 9B 72 FF FE C6 7E 2B

5. If registration CSBKs are received, check that dmrtc receives the
registration attempt (visible in log). If console output show "Unknown CSBK"
contact the developer, since the radio is doing something unusual that might
need investigation.

6. If the registration attempt does not show up in the dmrtc log, check that
UDP ports and IP addresses of MMDVMHost instances and dmrtc are configured
correctly since UDP packets are probably not reaching dmrtc.


Adrian

And the second part, some screenshots of the radio menus, although they may
not be much use if you haven't got it to register yet.
You might also want to send me your qradiolink.cfg file, just to check if
offsets and duplex mode are configured correctly.

Please note the menus are valid for the HP785, but might be similar for your
radio.
In the Scan menu, there is a View TSCC option which will tell you also the
signal level if a control channel is detected but might have the wrong
identity code.
Also, you can access the Service Menu of the radio where you will be able to
see some additional parameters of the control channel configured.

Do let me know if I can provide additional assistance.

Hope this helps,
Adrian

Hi Christian,

I don't normally allow attachments here, but now I'll have to send a few
screenshots in case it helps you.

It appears you got most of the settings correct, except I have a few doubts
about Shot Hunt. According to my HP785 manual, Short Hunt only hunts in the
most recent 10 control channels. I use Comprehensive Hunt on my radios.
Another thing to check is that the System Identity Code in dmrtc matches the
on in MMDVMHost.ini, and also the one configured in the CPS. The binary id
displayed in the CPS should add up to this base 10 number, regardless of the
other numbers.

Once the hunting procedure has started, you should see attempts to register on
the MMDVMHost log of the control channel and also in the dmrtc log.

One other important thing to double check is if the SDR device is not off-
frequency. The Lime-mini has a less accurate clock than the LimeNET Micro so
it might be a cause.

See attached screenshots for my own configuration.
In the next message I'll attach some pictures of radio menus.

BR,
Adrian YO8RZZ

Hello,

I have set up a PC with LimeSDR mini, MMDVM-SDR, MMDVMHost-SDR, DMRGateway, dmrtc and qradiolink according to documentation on
I get a steady DMR noise on the control channel (checked with FM radio).
I also verified that DMR in general is working: I reconfigured my channel 7 to Trunking disabled, bypassing the dmrtc and connecting directly to the DMRGateway. The Repeater appeared in Brandmeister. With a conventional channel (Tier II) I could talk to 9990 and got a reply.

Conclusion: modulation layer seems to work well.

BUT: I programmed a Hytera PD755 A9.02.04.001 (the same I used for Tier II test above) to Trunking. DMR trunking license is active according to Feature Control in CPS.

The Hytera in Trunking mode is stuck. It just shows "Out of Range" and I have not found a way to change that.

How is Trunking working?
Is the Radio just listening for a control channel to appear and then starts transmitting to register? (I guess so!)
Or should there be any transmit activity from the radio without hearing the control channel (I guess no?)

Some Hints on the Hytrea configuration - please ask if something else is of relevance here:
Dial Rules: DMR Flat
Network Model: Tiny, NetworkID 2 (also tried 1), LA 1, LocatioN Area ID 1, Location Side ID1, System Code 00.000000001.000
TSCC Plan: Fixed Control Channel
Hunt Mode: Short Hunt
RX Base Frequence: 439.6
TX Base Frequency: 434.8
Fixed TSCC List: Channel No 5, 439.7/434.9 (that's exactly where I hear the control channel from the base station on my FM radio)

What could cause the radio not to identify the control channel and start registering?
Any ideas how to tackle this problem?

Thanks in advance for your help.
73 Christian DB9CR

Changelog for version 0.8.12-1:

* Consolidate DMR Tier III base station functions
* Direct support for Ettus USRP via gnuradio-uhd and libuhd
* Reduced roundtrip latency to half (350 ms) for the DMR TDMA RF channel
* Added RSSI calculation for MMDVM channel
* Compatibility with tag 1.1 of MMDVM-SDR
* Added documentation for DMR trunking mode with MMDVM

The newly introduced DMR tier III base station functionality is described in
this page:


Regards,
Adrian

Hello,

As part of the next release, qradiolink will get native support for Ettus USRP
and other UHD devices via gr-uhd.
This means you will be able to use USRPs directly without going through gr-
osmosdr or SoapySDR. Also, you will be able to create MMDVM or MMDVM multi-
carrier base stations with Ettus USRP or other UHD devices (AntSDR maybe?) in
addition to the LimeSDR family.
This also means TDMA transmission modes like DMR will be fully supported on
these devices. which have FPGA based timestamps.

Other major changes have been made to the TDMA timing management, reducing DMR
roundtrip latency to half (from about 640 msec in DMR tier-III to ~320 msec).
This applies to both USRP and LimeSDR devices.

Your USRP device should be detected automatically at startup and will appear
in the settings as a Soapy device. If it is not, you can use a device string
of the form:
driver=uhd,serial=YOUR_DEVICE_SERIAL_NUMBER
Even if it appears as a Soapy device in the GUI or config file, native sinks and
sources will be used by GNU Radio automatically.
If you have previously used an USRP device string of the form "uhd=0" you will
now need to switch the new device string form to be able to take advantage of
the new code.

Part of this new work, new build dependencies have been added. You will need
to also install libuhd and libuhd-dev prior to building the project.

These new changes live for now in the "uhd_support" branch of the qradiolink
repo. After a period of testing, they will be merged into mainline and be part
of the next release (hopefully rather soon). You are encouraged to test using
this branch and report back any issues you might find.

Best regards,
Adrian

On Sunday, 17 September 2023 12:32:58 EEST you wrote:

Hi Adrian,

Yes Orange Pi Zero has not enough memory to run QRadioLink , maybe when we
use Orange Pi Zero 3 with 2 or 4Gb RAM and OZPI Zero v3 has faster CPU it
is possible run QradioLink but I use Orange Pi Zero v1.x which has 512 Mb
RAM is not good for QRadioLink for this reason I am looking to connect
audio svxlink via UDP across network :-)

Hi Waldek,

I've pushed this new feature to branch next. I've moved the config settings
around a bit, and there's now a separate tab for UDP streaming settings.
You can now set the local IP address as well as the remote IP address, so
svxlink on a remote computer should work. Docs updated as well.

Please test the feature and let me know if it works for you.
Reminder: for a CLI only machine, start qradiolink with the parameters
** --headless --udp ** after configuring all the relevant options.

Best,
Adrian

On Tuesday, 19 September 2023 22:15:20 EEST you wrote:

this was ment to go direct sorry. just a invite as I am working to make it
so that there is a resource for all things sdr. and giving adrian a
linkif he wish to join.

Thanks again for your work adrian

Thanks, really appreciate it, unfortunately I don't have a Discord account so
that link doesn't show anything but the Discord homepage.

BR,
Adrian

this was ment to go direct sorry. just a invite as I am working to make it so that there is a resource for all things sdr. and giving adrian a linkif he wish to join.

Thanks again for your work adrian

On Sep 19, 2023, at 3:01 PM, Adrian M <kantooon@...> wrote:

Ok I also have an update of libs for bookworm . I managed to get it to build on a arm64 desktop. I would also like to see it intake ported to build and work Mac


I will post the lib changes shortly

On Tuesday, 19 September 2023 21:38:17 EEST you wrote:

I am building on Debian BookWorm . I use the build_debian.sh but but it has
no install in it. and if you cd to build and do make install it says there
is no install option. is there a update to the build script to build a .deb
that can be installed ?

Hi Richard,

You can just copy the qradiolink binary from the build/ directory to /usr/bin
or whatever other path you need, or even just run it in place.

There is no install target since the deb packages are built with the Docker
scripts inside the ci/ directory.

I've been meaning to update the build scripts to also build a deb for Bookworm
but didn't manage to do it yet.

Hope this helps,
Adrian

I am building on Debian BookWorm . I use the build_debian.sh but but it has no install in it. and if you cd to build and do make install it says there is no install option.
is there a update to the build script to build a .deb that can be installed ?

On Wednesday, 13 September 2023 01:16:41 EEST you wrote:

Hello everyone!

I have not been able to find an installation package for Fedora so I have
decided to create and maintain the installer in Copr

For those interested:

Hi Emiliano,

Many thanks for this information and apologies for the delay in replying.
I only saw this message now in the approval queue, so I'm bumping the topic in
case there are any Fedora users here.

Best regards,
Adrian