开云体育

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

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 ?

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: https://copr.fedorainfracloud.org/coprs/lu3vea/qradiolink

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: 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. 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). 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

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

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 https://github.com/myriadrf/LimeRFE/blob/master/hardware/1v31/docs/LimeRFE_1v31_Measurements.pdf 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