MMDVM Bridging #99
Comments
|
It is possible to achieve, at least to transmit samples from MMDVM to the SDR. I tried a very basic proof of concept and managed to get some DMR decodes this way, but at least DMR is quite tricky because of the strict timing demands which is why it uses a microcontroller. I'll keep this updated with any progress. |
|
For transmit DMR, mmdvm-sdr had ported the mmdvm firmware to x86/arm, and thereby using FM modulation of generated samples to get decodes on DMR Radio through PlutoSDR / RpiTX / OsmoFL2K... |
|
Yeah exactly, so using it, I now have a transmit only duplex hotspot with my plutosdr. Transmission of both timeslots by the pluto is fine, but receiving my bursts is not. At one point I had it decoding only CACH bursts from the MS, but now I lost it somehow. My bet is there are timing issues in mmmdvm-sdr which prevent decoding of what the pluto receives. My own code in qradiolink is on branch mmdvm-integration, and I will push more code but currently busy.
…On July 7, 2021 5:20:54 PM UTC, g1nsj0h4n ***@***.***> wrote:
For transmit DMR, [mmdvm-sdr](https://github.com/r4d10n/mmdvm-sdr) had
ported the mmdvm firmware to x86/arm, and thereby using FM modulation
of generated samples to get decodes on DMR Radio through PlutoSDR /
RpiTX / OsmoFL2K...
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#99 (comment)
|
|
Right, so the situation is as follows. The plutosdr works in TX mode as a simplex and duplex DMR hotspot with MMDVM just fine, both timeslots are transmitted correctly to the radio through qradiolink. The architecture is pretty basic, ZeroMQ is used to push samples towards qradiolink and back, which means there's an added dependency on mmdvm-sdr towards libzmq. I also need to push the needed code for mmdvm-sdr, but needs a lot of cleanup, ongoing investigation why the timeslots are not picked up correctly when I transmit, and I should probably contact the original authot for a merge request. |
|
Duplex hotspot tested, transmits both timeslots since the BS sets the time reference, can receive only timeslot 2 (in DMO mode which is a hack). Radio can transmit on any timeslot but will be picked up as TS 2. Strict MS access time constraints and the gazillions of buffers between MMDVM and the SDR mean there's no way to determine precisely on which timeslot the inbout transmission came form the MS. Ideas, solutions welcome. Outbound FM deviation is not really ETSI standards compliant since the MMDVM sample levels were optimised for different ADCs. All testing done on PlutoSDR, Debian Bullseye, GNU radio 3.8.2. |
|
Great... Missed this here... I will try to get the setup back running and follow the instructions to get it working as a duplex TX / DMO RX hotspot... Cheers |
|
So I have a basic setup running on my Arch... I am yet to recieve the transmitted packets from Pluto.. Some issues I noticed:
while the mmdvm-sdr programs gets into the Idle mode and does not change to DMR after initial packets:
Cheers |
|
If you see slot overruns it means no samples are flowing to qradiolink. Check first TX is started in qradiolink, then netstat -tnlp and check both programs are listening on 5990 and 5991.
…On July 10, 2021 2:56:49 PM UTC, g1nsj0h4n ***@***.***> wrote:
So I have a basic setup running on my Arch... I am yet to recieve the
transmitted packets from Pluto.. Some issues I noticed:
1) MMDVMHost reports a lot of this:
E: 2021-07-10 14:47:18.382 DMR Slot 2, overflow in the DMR slot RF
queue
E: 2021-07-10 14:47:18.382 DMR Slot 2, overflow in the DMR slot RF
queue
E: 2021-07-10 14:47:18.382 DMR Slot 2, overflow in the DMR slot RF
queue
while the mmdvm-sdr programs gets into the Idle mode and does not
change to DMR after initial packets:
D: 2021-07-10 10:47:34.907 IO Int start()
D: 2021-07-10 10:47:35.017 setMode() invoked!
D: 2021-07-10 10:47:47.715 setMode() invoked!
D: 2021-07-10 10:47:47.715 Mode set to DMR
D: 2021-07-10 10:46:49.004 setMode() invoked!
D: 2021-07-10 10:46:49.004 Mode set to Idle
2) In QRadioLink, I can see just a single line in the spectrum on the
split transmission, which is a bit off from the expected TX frequency
programmed for RX on my DMR radio. How can I change the shift (ppm
correction?) ? Also should I not expect a wider waveform if the
modulation is happening ?
3) Is there a way to see I'm recieving packets through ZMQ in
QRadioLink ? I tried using an external program called zmqcat, which
shows some data being sent from mmdvm-sdr..
Cheers
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#99 (comment)
|
|
I can see CWID messages being transmitted thru QRadioLink... I added a Debug print when ZMQ was sending data from mmdvm-sdr.. E: 2021-07-10 16:40:46.133 DMR Slot 2, overflow in the DMR slot RF queue At the same time in mmdvm-sdr: D: 2021-07-10 16:40:53.119 Message created with length: 87 And I can see the transmission in QRadioLink... I'm quite not able to see the DMR data being transmitted thou. |
|
This is strange, because the DMR transmission works perfectly for me. It's the reception which has some quirks. Which version of MMDVMHost are you using? The TX zmq messages should always have 640 short signed samples, so 1280 bytes (buffered before sending).
…On July 10, 2021 4:47:26 PM UTC, g1nsj0h4n ***@***.***> wrote:
I can see CWID messages being transmitted thru QRadioLink... I added a
Debug print when ZMQ was sending data from mmdvm-sdr..
So when MMDVMHost times a CWID message:
E: 2021-07-10 16:40:46.133 DMR Slot 2, overflow in the DMR slot RF
queue
E: 2021-07-10 16:40:46.133 DMR Slot 2, overflow in the DMR slot RF
queue
M: 2021-07-10 16:40:46.133 DMR Slot 2, received network end of voice
transmission to TG 91, 0.8 seconds, 0% packet loss, BER: 0.0%
D: 2021-07-10 16:40:53.119 sending CW ID
E: 2021-07-10 16:40:53.192 DMR Slot 2, overflow in the DMR slot RF
queue
E: 2021-07-10 16:40:53.192 DMR Slot 2, overflow in the DMR slot RF
queue
At the same time in mmdvm-sdr:
D: 2021-07-10 16:40:53.119 Message created with length: 87
D: 2021-07-10 16:40:53.119 Message sent by ZMQ....
D: 2021-07-10 16:40:53.149 Message sent by ZMQ....
And I can see the transmission in QRadioLink...
I'm quite not able to see the DMR data being transmitted thou.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#99 (comment)
|
|
Ok.. I think I found the problem... I'd configured the MMDVMHost as Simplex with Slot0 disabled and Slot1 enabled. In my BM Selfcare, I'd routed the TG to TS1, whereas I should have sent it to TS2. Now I tried with Duplex setting and it is transmitting data. Yet to get a DMR decode on my handset. It is blinking and showing signal bars, but no decodes - probably need to tune it around. Do you use some ppm setting or offsets ? Will update ! I am using MMDVMHost from github and mmdvm-sdr fork from your repo. Many thanks for the support.. |
|
Yes, qradiolink has ppm adjustment in the settings pages. Use a known repeater to figure out the offset.
If you get it working, let me know if your transmissions get through in the first try. For me sometimes my radio says repeater not found and I think it's because of the buffer latencies, and the fact mmdvmhost is not perfectly standards compliant and does not generate idle bursts when CSBK is received. Usually I can get in after a while though.
…On July 10, 2021 5:10:37 PM UTC, g1nsj0h4n ***@***.***> wrote:
Ok.. I think I found the problem... I'd configured the MMDVMHost as
Simplex with Slot0 disabled and Slot1 enabled. In my BM Selfcare, I'd
routed the TG to TS1, whereas I should have sent it to TS2. Now I tried
with Duplex setting and it is transmitting data. Yet to get a DMR
decode on my handset. It is blinking and showing signal bars, but no
decodes - probably need to tune it around. Do you use some ppm setting
or offsets ?
Will update ! I am using MMDVMHost from github and mmdvm-sdr fork from
your repo.
Many thanks for the support..
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#99 (comment)
|
|
I figured out the reason why my inbound transmissions are sometimes not picked up or are missing a few seconds at the start. It seems the MMDVM SYNC correlator is quite sensitive to being off frequency by as little as 1 kHz, so I need to be less than 300 Hz off-channel in qradiolink. Otherwise works. |
|
Some progress, but not much... When I configure my MMDVMHost with Duplex=0, on TX from my handset - I get this in my mmdvm-sdr log: D: 2021-07-14 09:59:08.906 DMRDMORX: voice sync found pos/centre/threshold They are not getting transmitted to the network side through MMDVMHost. When I enable Trace=1 in Modem section, I can see RX DMR packets being printed, without any callsign decoding, etc. When I transmit on a Duplex mode frequency (TX handset freq == RX hotspot freq), the hotspot goes into continous transmit mode for a while with constant tone with mmdvm-sdr outputting data like this: D: 2021-07-14 10:14:04.783 DMRDMORX: voice sync found pos/centre/threshold In Duplex=0 mode, TX does not otherwise happen from Pluto (for avoid looping?) for data from network, except for CWID message. Hence I could not check DMR RX in Duplex = 0 mode. In Duplex=1, I am unable to TX from handset due to handshaking not working. When I transmit on Simplex freq from handset, I get this in mmdvm-sdr: I am still unable to decode the TX from the hotspot. Tried tweaking around the frequencies. Does making changes in MMDVM.ini settings (Invert, Levels, etc) make sense ? I did try a bit, but not sure its making any effect. |
|
I think I forgot to mention the most important thing: yes, you need to enable both RX invert and TX invert. Here's my Modem section: |
|
Also, use Duplex=1 in MMDVMHost and Repeater mode on the radio. Simplex should work as well but it's more tricky, because I didn't add any code in qradiolink to handle PTT switching for simplex and it will decode itself with perhaps strange results. |
|
That's just about it !! Its working very well now.. I'm able to RX and TX to the network thru PlutoSDR as hotspot....Will keep experimenting... Many thanks for the support and excellent implementation in such a short while !! Cheers... |
|
Roger that. Make sure to monitor on the FFT once in while where the center of the radio TX signal is, because these SDRs tend to drift in frequency as they warm or cool. Also make sure the RX gain in qradiolink is set so it doesn't start clipping if you transmit very close to the SDR. I've been bitten by these issues before. I'll merge this code into the |
|
I'd left the SDR/QRadioLink in hotspot mode and after a long while the radio does not seem to decode the transmissions. So as you said probably there is some freq drift happening. Although, restarting the chain (mmdvm-sdr / MMDVMHost / QRadioLink) brought the decode back online... Otherwise its working really well ! |
|
I have a PlutoSDR now and running 20.04, so I’ll give this a stab. Unfortunately I don’t own a DMR radio, so I’ll have to borrow. I’d love to include all three pieces in DragonOS once pushed to the next branch. |
|
@g1nsj0h4n the problem which occurs after a long time running can also be something related to timing. In mmdvm-sdr there is a kind of problematic sleep() call in the TX loop. That call should not normally be required, but there is some interaction on the TX fifo which I don't yet understand and which can cause slots to be overwritten, especially in simplex only mode. I'll keep looking at that. |
|
I've switched ZeroMQ endpoints from TCP to IPC in the latest commits, because two TCP ports were tied up for no good reason. |
|
@alphafox02 this feature is now merged in the |
|
Awesome I’ll be testing as much of it as I can this weekend. Don’t suppose once I get it all worked in, maybe I could send a link to a test ISO that either of you could boot live and test against real DMR traffic? |
|
@alphafox02 I don't think it will be any trouble to bake it in... and I'd love to test the Live CD... |
|
Thank you, feedback would be much appreciated. The entire ISO is still a work in progress, but I did confirm just now that it boots after burning using etcher. Qradiolink link and the other two pieces of the puzzle are sitting in /usr/src. You may need to use sudo for running the mmdvm pieces since it’s sitting in /usr/src. I confirmed qradiolink starts (built just awhile ago from next). Mmdvm-SDR is built and I attempted to edit the MMDVMHOST settings to what I thought they would be. SoapySDR and PlutoSDR support is in place. There’s lot of other things preinstalled, but I mainly wanted to see if I got everything spot on in regards to this new development. Test iso is located here https://drive.google.com/file/d/1Ph185PWrhmr0vw2fyS7HD7o8KBezLePv/view?usp=drivesdk |
|
@alphafox02 great work integrating all these SDR applications into your distribution! Unfortunately I don't have the time to run it but I'm sure somebody else will help you test it. |
|
@alphafox02 I am unable to get the iso to boot... Lubuntu screen comes up and tries to fsck the squashfs file... Then it aborts to dmesg screen, with lots of errors - one of which I remember is stdin Invalid argument. Could you check your iso to boot ? |
|
@g1nsj0h4n i didn’t have an issue :/ but I also made a new one for testing. There’s an md5 file to check and make sure there’s no corruption. It’ll boot on legacy or uefi but not secure boot yet. I’ll remove the link after awhile. https://drive.google.com/drive/folders/1--rwGIqSs38huxZAOGjKKeU3MTZJjGJc Edit: also it’s for 64bit only |
|
This feature is now released in version 0.8.6, so closing. |
|
I've now got a proper TDMA implementation which means that RX works on both timeslots, compliant with ETSI standards, using the LimeSDR (which supports FPGA timestamps). I just need to cleanup the code for a merge. |
Hi!
Great talk @ SDRA...
It would be nice to support DMR/DStar/YSF modes in QRadioLink. So how do we go about bridging MMDVM ?
As you have ruled out mbelib, I guess another option is based on md380 firmware emulation - which I believe MMDVM Bridge also uses.
Cheers
The text was updated successfully, but these errors were encountered: