开云体育

Hi Adrian,

Thanks for info.
I wonder why 100% CPU busy is svxlink. I had such a case when I was using Alsa loop in svxlink
but yes in normal work I have not had such cases especially since I use myself in one configuration also support USRP link to Analog Reflector DVSwitch

Yes connecting svxlink via USRP to USRP2M17 program works and gives you a pass to M17 network e.g. connecting to M17 Reflector


73 Waldek

Hi Waldek,

I came up with an initial draft architecture for SVXlink to GNUradio via
qradiolink. By this I mean the net to RF transmit. RF to net will be somewhat
similar but it's not ready yet.
You can check it out here:


The main points are:
1. enable support for svxlink to analog FM as well as svxlink to digital (e.g.
M17 protocol) and vice versa
2. enable automatic control of relays (power amps, filters, LimeRFE etc.)
3. enable automatic RF gain control if using simplex mode
4. potential bridging svxlink <-> mumble <-> RF (if feasible)

I've had some help with svxlink setup from Catalin YO7GQZ, but svxlink when
started locally goes to 100% CPU with just simplex logic and reflector logic. I
have to find out the cause, but it's not usable yet.

To be continued

Adrian

Hi Adrian,

It's a pity that there is no description of the communication protocol between svxreflector and svxlink because it would a
allow the creation of different solutions for this platform which is popular in Europe but is also used by others outside of Europe.
Reading the implementation of the communication protocol from sources is very difficult and labor-intensive.
The current solution is very interesting and efficient and recently SM0SVX Tobias wrote that he plans to introduce the possibility of linking svxreflectors



73 Waldek

On Thursday, 20 July 2023 07:50:25 EEST you wrote:

Hi Adrian,
I understand you, after all this is just a hobby of ours and we can devote
time to it when we can, I have the same.

Hi Waldek,

I'm sufficiently interested in this topic to start investigating it sooner
rather than later. The main problem for me will be testing, but since you
expressed interest in it too, I have a reason to prioritize it over other
improvements I was planning.

If you have some versions for testing I would be happy to check in my FM
POLAND network.

I am familiar with MUMBLE and it is really a great communication platform.
My intention was to maybe move the possibility of communication closer to
the amateur radio community, which is, among other things, SVXReflector,
which is also based on OPUS codec and is a server just like MUMBLE, but it
is used by already connected transceivers, amateur radio hotspots as is the
case with ROLink or other similar national networks based on SVXReflector /
svxlink.

I agree, Mumble is the simplest way to get the job done, since the protocol is
pretty well documented but it's not very suitable for amateur radio. Svxlink
was a source of inspiration for me at that time, but Mumble was a bit easier
to implement, and the in-band text messaging made it easier to implement
control of the SDR as well as audio via a mobile phone which was desirable for
me.
I'll see what I can do about svxlink or USRP. First I need to sketch some high
level architecture since I want to integrate well with existing features. I'll
let you know when I have something functional and testable.

Best regard,
Adrian

Hi Adrian,
I understand you, after all this is just a hobby of ours and we can devote time to it when we can, I have the same.

If you have some versions for testing I would be happy to check in my FM POLAND network.

I am familiar with MUMBLE and it is really a great communication platform.
My intention was to maybe move the possibility of communication closer to the amateur radio community,
which is, among other things, SVXReflector, which is also based on OPUS codec and is a server just like MUMBLE,
but it is used by already connected transceivers, amateur radio hotspots as is the case with ROLink or
other similar national networks based on SVXReflector / svxlink.


Currently, it is the holiday season, but I think I can also find some free time, although more will be in September

73 Waldek SP2ONG

On Wednesday, 19 July 2023 12:06:21 EEST you wrote:

I forgot e svxlink can have an audio exchange
via UDP so maybe it would be enough to add to QRadioLink the ability to
connect to svxlink via UDP and svxlink would have linked from svxreflector
so QRadioLink would have FM network connections svxreflecotr

Yes, this would clearly be easier than replicating the whole svxlink client in
qradiolink. UDP voice is straightforward, if not very efficient bandwidth-wise.
But since this would not connected across the WAN, it's not a problem.

The website you linked is interesting and I didn't know about it. I'll check
it out.

Adrian

On Wednesday, 19 July 2023 10:01:40 EEST you wrote:

Hi Adrian,

Thank you for your very interesting QRadioLink project.
Very interesting solution. I read your articles on QRadioLink website about
various applications.

Hi Waldek,
Glad you find it useful.

You might find it interesting to add a connection to SVXReflector via OPUS
Codec in addition to the connection to the MUMBLE server. But that would
require implementing the Reflector Client but I don't know if there is a
readable description in the svxlink sources

I started considering a connection to svxlink sometimes last year, when I
started to work on the multicarrier repeater. The way I wanted to use this was
to transmit and receive two DMR carriers, two YSF carriers, one M17 and two FM
carriers (linked to svxlink, RoLink like you said).
The USRP protocol seems a bit easier to implement as a client, especially
considering MMDVM-SDR can connect to USRP directly.
Svxlink is a bit more complicated I think. I'd like to avoid duplicating the
svxlink client in qradiolink if possible.

Would you be interested in collaborating on such features? My time is sort of
limited to a few hours a week at the moment, but this is a topic I'm definitely
interested in.

Adrian

I forgot e svxlink can have an audio exchange
via UDP so maybe it would be enough to add to QRadioLink the ability to connect to svxlink via UDP
and svxlink would have linked from svxreflector so QRadioLink would have FM network connections svxreflecotr

A description about making a connection from svxlink via UDP is shown here



SVXLink.conf RX1 can be setup as AUDIO_DEV=udp:127.0.0.1:1234

SVXLink.conf TX1 can be setup as AUDIO_DEV=udp:127.0.0.1:1235

SVXlink audio interface op 16Khz

Hi Adrian,

Thank you for your very interesting QRadioLink project.
Very interesting solution. I read your articles on QRadioLink website about various applications.

You mentioned in the descriptions that you were making attempts to connect to the FM network (I assume it was RoLink)
which uses svxreflector /svxlink. SVXRflector also uses the OPUS codec to connect svxlink nodes.
Now it is popular solution to integrate Fm repeater use svxlink similar like ROLink





You might find it interesting to add a connection to SVXReflector via OPUS Codec in addition to the connection to the MUMBLE server.
But that would require implementing the Reflector Client but I don't know if there is a readable description in the svxlink sources



Another alternative would be to be able to do the connection via USRP protocol which is available in svxlink-usrp version DL1HRC


Description of the protocol

This would enable via UDP link connection to svxlink which has connections to svxreflector


73 Waldek SP2ONG

Today I've released 0.8.9-1 after several successful tests of MMDVM
multicarrier.
I have some updated information on this topic, see below:

On Saturday, 11 March 2023 10:14:58 EET you wrote:

A new configuration setting is now available in qradiolink.cfg:
- burst_delay_msec - the delay in milliseconds used for DMR timestamps
Samples will be transmitted this far in the future, so this also influences
the minimum TX chain delay.

This setting is only available in the config file and cannot be set via the
user interface. Originally this value was hardcoded at 100 msec, which
seemed to work fine on an x86_64 CPU. However on ARM platforms this value
was too small and led to wrong DMR timing and/or dropped sample packets.
A value of 200 msec seems to work on a Rockchip 6 core big.LITTLE ARM
platform.

In release 0.8.9-1 this setting defaults at 60 msec and can probably be
tweaked between 10 msec and 100 msec. However a value of 60 works best for me
on an AMD quad-core CPU. Hasn't been tested on low power ARM platforms yet.

In MMDVM-SDR there were several issues with interruptions on local repeated
DMR transmissions, as well as lost DMR timing on some platforms due to
suboptimal and bug prone ZeroMQ packet sending. The hardcoded values
depended on CPU speed so only worked for some machines and didn't work on
others.

Mostly fixed in release 0.8.9-1, except for some short interruptions on
repeater downlink with cause yet unknown. This new version requires version
1.0 of MMDVM-SDR (tagged as such in the git repo).

For this reason, the code was rewritten and now the DMRDelay setting in
MMDVM.ini is used to time the sending of TX samples to qradiolink.
DMRDelay will no longer affect RX delay since the timing is mainly driven by
the LimeSDR FPGA timestamps.

DMRDelay is no longer used because it did not fix the root cause. In fact it
should be set to zero now.

BR,
Adrian

Hello,

Recently I've made some significant changes to both qradiolink and MMDVM-SDR
which should resolve some serious issues that were present in MMDVM modes.

A new configuration setting is now available in qradiolink.cfg:
- burst_delay_msec - the delay in milliseconds used for DMR timestamps
Samples will be transmitted this far in the future, so this also influences the
minimum TX chain delay.

This setting is only available in the config file and cannot be set via the user
interface. Originally this value was hardcoded at 100 msec, which seemed to
work fine on an x86_64 CPU. However on ARM platforms this value was too small
and led to wrong DMR timing and/or dropped sample packets.
A value of 200 msec seems to work on a Rockchip 6 core big.LITTLE ARM
platform.

Another important change in qradiolink is usage of a lower sample rate in
MMDVM modes. The original implementation used 1.2 Msps which was much higher
than needed, wasting CPU resources. The sample rate used now is 240 ksps.
LimeSDR device calibration is now fixed as well.

In MMDVM-SDR there were several issues with interruptions on local repeated
DMR transmissions, as well as lost DMR timing on some platforms due to
suboptimal and bug prone ZeroMQ packet sending. The hardcoded values depended
on CPU speed so only worked for some machines and didn't work on others.

For this reason, the code was rewritten and now the DMRDelay setting in
MMDVM.ini is used to time the sending of TX samples to qradiolink.
DMRDelay will no longer affect RX delay since the timing is mainly driven by
the LimeSDR FPGA timestamps.
A default value of 0 is the same as a setting of 70 and works on my test
machine. The value can be adjusted between 0 and 100, although I expect only
values between 30 and 80 to be actually useful.

At this point my own capacity for testing is very limited, so I would be
grateful if someone is willing to step up and test the new code, especially on
ARM platforms with limited CPU power. I'm especially interested in the
performance of the multicarrier mode on ARM CPUs.
In the qradiolink repo the new code is on the `next` branch and in MMDVM-SDR
on the `mmdvm_sdr` branch. I've also updated instructions in docs/
README_MMDVM_operation.md however there may still be missing some old/missing
info.

BR,
Adrian

On Saturday, 3 September 2022 13:03:16 EEST you wrote:

Using LimeSDR equipment (LimeNET-Micro / LimeSDR-mini) and MMDVM + GNU radio
as core components, the implementation of a full duplex SDR base station
was created in order to support the DMR, System Fusion, D-Star and M17
amateur digital voice standards in a multi-carrier configuration, with up
to 7 transmitted carriers within 200 kHz bandwidth, in any combination of
operating modes and with a configurable channel separation. The channel /
mode matrix is entirely user configurable by using multiple MMDVM
instances, each of them dedicated to one operating channel.

This is now released in 0.8.7-1. Unfortunately no binary packages could be
built because of a failure in the automated Docker build job..
D-Star, M17 and other digital modes except DMR and System Fusion could not be
tested because I lack the necessary hardware. Hoping someone else will pick
this up and let us know if these modes also work with the LimeSDR.

Adrian

I've recently implemented some early support for the M17 digital amateur protocol.
The qradiolink code uses the OpenRTX reference implementation which is quite plug
and play, with FM modulation / demodulation handled by GNU Radio. The plan next
is to separate this code into a GNU Radio OOT module for wider usage.

So far, only voice streaming is implemented, the other features of M17 don't work
yet. I'm hopeful this will tie right into the MMDVM multi-carrier gateway mode, but
the road up to that point is still long.

Release 0.8.7-1 (a source only release due to a problem with the Debian Docker build
script) contains the M17 mode.

Regards,
Adrian

Using LimeSDR equipment (LimeNET-Micro / LimeSDR-mini) and MMDVM + GNU radio
as core components, the implementation of a full duplex SDR base station was
created in order to support the DMR, System Fusion, D-Star and M17 amateur
digital voice standards in a multi-carrier configuration, with up to 7
transmitted carriers within 200 kHz bandwidth, in any combination of operating
modes and with a configurable channel separation. The channel / mode matrix is
entirely user configurable by using multiple MMDVM instances, each of them
dedicated to one operating channel.

The long term goal is to continue software development and combine LimeSDR
equipment with the LimeRFE front-end and capable computing hardware to supply
a self-contained, easily deployable base station in NITB style. The end-user
should only need to supply their own antennas, power amplification and
duplexing hardware for a complete SDR base station solution.

The current testing status has confirmed operation of the DMR and System Fusion
standards, while D-Star and M17 modes are still theoretical and need to be
tested. There is interest in further extended support for the new M17 open
digital voice standard and investigating how a multi-carrier approach can
provide amateur radio operators new avenues of experimentation with topics
like trunking, multiple access, IP network facilities and other such topics.
Work is in progress to improve code, refine user documentation and create
deployable packages.

A video demonstrating the operation of a four-channel mixed DMR and System
Fusion duplex repeater system can be seen here:


All credit for the work supporting this project goes to Jonathan Naylor, Peter
Rakesh and all the people who created or contributed to MMDVM and GNU Radio
along the years.

Regards,
Adrian YO8RZZ

This note concerns support of the LimeRFE frontend in qradiolink.
This note applies both to receive and transmit RF paths, including duplex mode (connectors J3/J4 used simultaneously).

Up to and including version 0.8.6-2, LimeRFE automatic band tuning was limited to IARU region 1 amateur radio bands.
The 220 MHz and 900 MHz bands were not supported at all.
The 144 MHz and 440 MHz bands were only partly supported for IARU region 2, as these bands cover more spectrum there.
The automatic tuning as implemented in version 0.8.6-2 would choose the WIDEBAND-1000 and WIDEBAND-4000 RF paths for frequencies outside IARU region 1 bands, and these RF paths do not have any filtering on input and output.

The next version of qradiolink will correct this issue and enable support for all amateur radio bands that the LimeRFE provides, while extending the frequency range where amateur radio receive and transmit paths are enabled. This will allow amateur radio operators in IARU region 2 to use the full extent of their bands.
The range of frequencies where these ham bands are enabled was set using the gain measurements for RX paths in the LimeRFE reference documentation available at and may be slightly altered in the future if necessary.

Do note that the "TX Limits" option will still restrict (if enabled) tuning the transmitter outside IARU region 1 bands. To use the transmitter in IARU region 2 or other IARU zones you will still need to disable this option in the settings. For ease of operation, this setting was moved to the first settings page.

As there is no release yet with the new features, you will need to compile the software from source to take advantage of the new code.

//Adrian