开云体育

2nd update: Answer Mode ------------------------------------------------------------------------ This parameter allows you to set the mode of answering the private call. Option

Update: Two radios with different DMR IDs connectd to same dmrtc can do private calls. Private call from radio on dmrtc to brandmeister tier ii doesn't work. Trunking-Radio looks like call

Hello Adrian, Thanks for updating the docs. I can confirm that -h works - stupid error on my side. My trunk mode repeater is running for evereral days now and only once needed a restart for unknown

Hello Christian, I've fixed all documentation bugs now hopefully, and also added a troubleshooting guide based on our conversation. Can you confirm that your below issue with headless mode does not

Hello Christian, I don't see anywhere the "-h" option when you start it headless. You can omit the DISPLAY variable when using "-h". Adrian

Hello Adrian, that explains it. Thanks! 73 Christian DB9CR Am 01.07.2024 um 10:04 schrieb Adrian M:

Hello Adrian, while dmrtc has a headless mode, it seems that still, a connection to an X11 server is needed to start: db9cr@tmo:~/software$ ( cd dmrtc/build ; DISPLAY= ./dmrtc ) qt.qpa.xcb: could

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

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,

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)

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

Oh I see, if there are no dropped packets everything is ok on this side. Most likely not an interruption, but the receiver used for dsd-fme is momentarily overloaded by the nearby high-power

Hello Adrian, did some more debugging. CPU resources are not a problem. $ cat /proc/cpuinfo processor?????? : 0 vendor_id?????? : GenuineIntel cpu family????? :

Error 14 is due to the serial communication protocol between MMDVMHost and MMDVM being slightly changed for trunking support. So the mmdvm_sdr branch is not compatible with the trunking branch.

The "trunking" branch should be used in both MMDVM-SDR and MMDVMHost-SDR. I am not sure about the cause of the interruptions. One thing to check for is that qradiolink is at the latest (0.8.13-2 or

Hello Adrian, as said -? in the MMDVM section in your documentation, "git checkout mmdvm_sdr" gives me the error 14. "git checkout trunking" resolves error 14, but produces the interruptions in the

Unfortunately, the solution was not permanent. The signal on the control channel ist again interrupted 1-2 times per second. In dsd-fme, messages are coming in blocks like this, with a short break

Hello Christian, You are completely correct, that is how it works. Regarding your errors, I see that you have solved them, congratulations! The full documentation is now at this

rm -rf MMDVM-SDR/ git clone https://codeberg.org/qradiolink/MMDVM-SDR cd MMDVM-SDR git checkout mmdvm_sdr mkdir build && cd build cmake .. make -j 2 [...] Runnign with this MMDVM binary, MMDVMHost

Hello Adrian, things start to make sense. Lookong at the output of MMDVMHost, I see an error something like "message 14". 14 is the ID of Aloha. I made a clean recompile of MMDVM-SDR and now I get