Are you over 18 and want to see adult content?
More Annotations
A complete backup of catchoftheweekedmonton.com
Are you over 18 and want to see adult content?
A complete backup of retinapodcast.com
Are you over 18 and want to see adult content?
A complete backup of computadoras-portatiles.com
Are you over 18 and want to see adult content?
A complete backup of niunadietamas.com
Are you over 18 and want to see adult content?
A complete backup of financieonline.sk
Are you over 18 and want to see adult content?
A complete backup of cofcultur22.blogspot.com
Are you over 18 and want to see adult content?
A complete backup of disneytermsofuse.com
Are you over 18 and want to see adult content?
Favourite Annotations
A complete backup of https://bsonspec.org
Are you over 18 and want to see adult content?
A complete backup of https://radio4.nl
Are you over 18 and want to see adult content?
A complete backup of https://ngrcw.com
Are you over 18 and want to see adult content?
A complete backup of https://rozanski.li
Are you over 18 and want to see adult content?
A complete backup of https://thedianeconklinshow.com
Are you over 18 and want to see adult content?
A complete backup of https://piloter.org
Are you over 18 and want to see adult content?
A complete backup of https://tarifaluzhora.es
Are you over 18 and want to see adult content?
A complete backup of https://caslpa.ca
Are you over 18 and want to see adult content?
A complete backup of https://apticirl.com
Are you over 18 and want to see adult content?
A complete backup of https://infoledis.ru
Are you over 18 and want to see adult content?
A complete backup of https://brainking.com
Are you over 18 and want to see adult content?
Text
in
RTLSDR STRONG SIGNALS AND NOISE FIGURE Airspy and RTLSDR. The Airspy uses the same tuner chip so I tested it and found about the same strong signal results, i.e. it overloads at the same signal levels as the RTLSDR at max gain. Guess this is no surprise if it’s the same tuner. I once again measured the Airspy noise figure at about 7dB, slightly higher than the 6dB of theRTLSDR.
VDSL VERSUS HF RADIO This is simply a 5uH inductor in series with a 100pF capacitor, connected across the VDSL phone line. This has a few hundred ohms of Xc above resonance, which results in just a few dB attenuation at 8-12 MHz. This obtained 38 Mbps downstream. Upstream was the same (24 Mbps) as with no filter. Good enough. FREEDV 700E AND COMPRESSION FreeDV 700E and Compression. FreeDV 700D is built around an OFDM modem and powerful LDPC codes, and was released in mid 2018. Since then our real world experience has shown that it struggles with fast fading channels. Much to my surprise, the earlier FreeDV 700C mode actually works better on fast fading channels. CODEC2 AND FREEDV UPDATE Quite a lot of Codec2/FreeDV development going on this year, so much that I have been neglecting the blog! Here is an update.. Github,Travis, and STM32
OPEN SOURCE LOW RATE SPEECH CODEC PART 1 Open Source Low Rate Speech Codec Part 1. I have decided to start working on a free (as in speech) low bit rate speech codec. The initial target is 2400 bit/s communications quality speech. Communications quality means something between synthetic, robotic sounding speech and a mobile phone. The application is voice over lowbandwidth digital
URBAN HF NOISE
The Octave script impulse_noise.m was used to generate the plots in this post. Here is a plot of some PWM impulse samples (top), and the HF spectrum. I’ve injected a “wanted” signal at 1MHz for comparison. Given a switcher frequency of 255kHz, with 0.1V impulse amplitude, the noise floor is -90dBV down, or about 10uV.RPITX AND 2FSK
So here are the command lines that generate 600 seconds (10 minutes) of 100 bit/s 2FSK test frames, and transmit them out of rpitx, using a 7.177 MHz carrier frequency: On the receive side I used my FT-817 connected to FreeDV to sample the signal as a wave file, then fed the signal into C and Octave versions of the demodulator. MODEMS FOR HF DIGITAL VOICE PART 2 In the previous post I argued that pushing bits through a HF channel involves much wailing and gnashing of teeth. Now we shall apply numbers and graphs to the problem, which is – in a nutshell – Engineering. QPSK Modem Simulation. I have worked up a GNU Octave modem simulation called hf_modem_curves.m.This operates at 1 sample/symbol, i.e. the sample rate is the symbol rate. FREEDV 2020 FIRST ON AIR TESTS FreeDV 2020 First On Air Tests. Brad (AC0ZJ), Richard (KF5OIM) and I have been putting the pieces required for the new FreeDV 2020 mode, which uses LPCNet Neural Net speech synthesis technology developed by Jean-Marc Valin. The goal of this mode is 8kHz audio bandwidth in just 1600 Hz of RF bandwidth. FreeDV 2020 is designed for HF channels OSLEC ECHO CANCELLER Oslec is an open source high performance line echo canceller. When used with Asterisk it works well on lines where the built-in Zaptel echo canceller fails. No tweaks like rxgain/txgain or fxotrain are required. Oslec is supplied as GPL licensed C source code and is free as in speech. Oslec partially complies with the G168 standard and runsin
RTLSDR STRONG SIGNALS AND NOISE FIGURE Airspy and RTLSDR. The Airspy uses the same tuner chip so I tested it and found about the same strong signal results, i.e. it overloads at the same signal levels as the RTLSDR at max gain. Guess this is no surprise if it’s the same tuner. I once again measured the Airspy noise figure at about 7dB, slightly higher than the 6dB of theRTLSDR.
VDSL VERSUS HF RADIO This is simply a 5uH inductor in series with a 100pF capacitor, connected across the VDSL phone line. This has a few hundred ohms of Xc above resonance, which results in just a few dB attenuation at 8-12 MHz. This obtained 38 Mbps downstream. Upstream was the same (24 Mbps) as with no filter. Good enough. FREEDV 700E AND COMPRESSION FreeDV 700E and Compression. FreeDV 700D is built around an OFDM modem and powerful LDPC codes, and was released in mid 2018. Since then our real world experience has shown that it struggles with fast fading channels. Much to my surprise, the earlier FreeDV 700C mode actually works better on fast fading channels. CODEC2 AND FREEDV UPDATE Quite a lot of Codec2/FreeDV development going on this year, so much that I have been neglecting the blog! Here is an update.. Github,Travis, and STM32
OPEN SOURCE LOW RATE SPEECH CODEC PART 1 Open Source Low Rate Speech Codec Part 1. I have decided to start working on a free (as in speech) low bit rate speech codec. The initial target is 2400 bit/s communications quality speech. Communications quality means something between synthetic, robotic sounding speech and a mobile phone. The application is voice over lowbandwidth digital
URBAN HF NOISE
The Octave script impulse_noise.m was used to generate the plots in this post. Here is a plot of some PWM impulse samples (top), and the HF spectrum. I’ve injected a “wanted” signal at 1MHz for comparison. Given a switcher frequency of 255kHz, with 0.1V impulse amplitude, the noise floor is -90dBV down, or about 10uV. MODEMS FOR HF DIGITAL VOICE PART 2 In the previous post I argued that pushing bits through a HF channel involves much wailing and gnashing of teeth. Now we shall apply numbers and graphs to the problem, which is – in a nutshell – Engineering. QPSK Modem Simulation. I have worked up a GNU Octave modem simulation called hf_modem_curves.m.This operates at 1 sample/symbol, i.e. the sample rate is the symbol rate.RPITX AND 2FSK
This post describes tests to evaluate the use of rpitx as a 2FSK transmitter. About 10 years ago I worked on the Village Telco – a system for community telephone networks based on WiFi. At the time we used WiFi SoCs which were open source at the OS level, but the deeper layers were completely opaque which led (at least for me) to significant frustration. FREEDV 700E AND COMPRESSION FreeDV 700E and Compression. FreeDV 700D is built around an OFDM modem and powerful LDPC codes, and was released in mid 2018. Since then our real world experience has shown that it struggles with fast fading channels. Much to my surprise, the earlier FreeDV 700C mode actually works better on fast fading channels.SM1000 V2 FIRMWARE
SM1000 V2 Firmware. After a year of development we have released version 2 of the SM1000 firmware. Major new features include: FreeDV 700D (thanks Don W7DMR) A Morse menu system (thanks Stuart VK4MSL) The SM1000 Manual which tells you how to upgrade to the new firmware. I’d also like to thanks Steve (K5OKC) for his fine work on the OFDMmodem
OPEN SOURCE LOW RATE SPEECH CODEC PART 1 Open Source Low Rate Speech Codec Part 1. I have decided to start working on a free (as in speech) low bit rate speech codec. The initial target is 2400 bit/s communications quality speech. Communications quality means something between synthetic, robotic sounding speech and a mobile phone. The application is voice over lowbandwidth digital
SNR AND EB/NO WORKED EXAMPLE SNR (dB) = Eb/No (dB) + 10log10 (Rb/B) So for FreeDV 700B, the bit rate Rb = 700, B = 3000 Hz (for SNR in a 3000Hz bandwidth) so we get: SNR = Eb/No – 6.3. Now, say we need a BER of 2% or 0.02 for speech, the lower Blue curve says we need an Eb/No = 4dB, so we get: SNR = 4 – 6.3 = -2.3dB. So if the modem is working down to “just” 0dB we MEASURING WIFI TRANSMIT POWER Here is a photo of a 54 Mbit 802.11g signal on a V1.1 MP01: P, the Wifi transmit power is given by: P = Pm + Pref – 10log (RB) + 10log (BW) where Pm is the measured power on the spec-an graticule (-31 in the photo above), Pref is the reference level (30dBm in top left hand corner, RB is the resolution bandwidth (1MHz, lower right hand corner OPEN IP OVER VHF/UHF 3 Open IP over VHF/UHF 3. The goal of this project is to develop a “100 kbit/s IP link” for VHF/UHF using just a Pi and RTLSDR hardware, and open source signal processing software . Since the last post, I’ve integrated a bunch of components and now have a half duplex radio data system running over the bench. The Tx and Rx signal BINARY TELEMETRY PROTOCOL The lower lines starting with “1” from the new binary protocol. The binary protocol was delivering packets at Eb/No as low as 6dB (SNR in 3000Hz of -9dB) at 100 bit/s. Here are some packets from the very end of the flight, from a sample provided by VK5EI in Adelaide: HORUS,2513,07:19:41,-35.12791,140.72295,7992,50,9,-14,1393 CRC OK. CODEC 2 700C EQUALISER The two right hand columns show the results (variance after 2nd stage) without and with the equaliser, using the Codec 2 700C VQ (which I have labelled train_120 in the source code). On some samples it has quite an effect (cq_ref, cq_freedv_8k), less so on others. After the equaliser, most of the samples are in the 8dB^2 range.RPITX AND 2FSK
This post describes tests to evaluate the use of rpitx as a 2FSK transmitter. About 10 years ago I worked on the Village Telco – a system for community telephone networks based on WiFi. At the time we used WiFi SoCs which were open source at the OS level, but the deeper layers were completely opaque which led (at least for me) to significant frustration. OQPSK MODEM SIMULATION A friend of mine is developing a commercial OQPSK modem and was a bit stuck. I’m not surprised as I’ve had problems with OQPSK in thepast as well.
ROWETEL – OPEN TELEPHONY SOFTWARE, HARDWARE, CRITICAL THINKINGCODEC 2SM1000FSK LDPC DATA MODEFREEDV 700D RELEASEDOSLEC ECHO CANCELLER FSK_LDPC can scale to any bit rate you like. The ratio of the sample rate to symbol rate Fs/Rs = 8000/1000 (8kHz, 1000 bits/s) is the same as Fs/Rs = 800000/100000 (800kHz, 100k bits/s), so it’s the same thing to the modem. I’ve tried FSK_LDPC between 5 and 40k bit/s sofar.
FREEDV 2020 FIRST ON AIR TESTS FreeDV 2020 First On Air Tests. Brad (AC0ZJ), Richard (KF5OIM) and I have been putting the pieces required for the new FreeDV 2020 mode, which uses LPCNet Neural Net speech synthesis technology developed by Jean-Marc Valin. The goal of this mode is 8kHz audio bandwidth in just 1600 Hz of RF bandwidth. FreeDV 2020 is designed for HF channels VDSL VERSUS HF RADIO This is simply a 5uH inductor in series with a 100pF capacitor, connected across the VDSL phone line. This has a few hundred ohms of Xc above resonance, which results in just a few dB attenuation at 8-12 MHz. This obtained 38 Mbps downstream. Upstream was the same (24 Mbps) as with no filter. Good enough. CODEC 2 – ROWETELSEE MORE ON ROWETEL.COM RTLSDR STRONG SIGNALS AND NOISE FIGURE Airspy and RTLSDR. The Airspy uses the same tuner chip so I tested it and found about the same strong signal results, i.e. it overloads at the same signal levels as the RTLSDR at max gain. Guess this is no surprise if it’s the same tuner. I once again measured the Airspy noise figure at about 7dB, slightly higher than the 6dB of theRTLSDR.
CODEC 2 700C EQUALISER The two right hand columns show the results (variance after 2nd stage) without and with the equaliser, using the Codec 2 700C VQ (which I have labelled train_120 in the source code). On some samples it has quite an effect (cq_ref, cq_freedv_8k), less so on others. After the equaliser, most of the samples are in the 8dB^2 range. TRELLIS DECODING FOR CODEC 2 Hear are some samples that compare trellis based decoding to simple hard decision decoding, when applied to Codec2 at 700 bit/s on a AWGN channel using PSK. Only the 6 LSP parameters are tested (short term spectrum), no errors or correction are applied to the excitation parameters (voicing, pitch, energy). Eb/No (dB) BAND PASS FILTER AND POWER AMPLIFIER FOR SIMPLE HF DATA Band Pass Filter. The RTL-SDR samples at 28.8 MHz, capturing a broad chunk of spectrum. In direct mode we just sample the Q-channel, so any energy above 14.4 MHz will be aliased into our passband; e.g. both 21 and 7 MHz will appear as a 7 MHz sampled signal. In the previous post we determined the ADC overloads at -30dBm, so we want to removeURBAN HF NOISE
The Octave script impulse_noise.m was used to generate the plots in this post. Here is a plot of some PWM impulse samples (top), and the HF spectrum. I’ve injected a “wanted” signal at 1MHz for comparison. Given a switcher frequency of 255kHz, with 0.1V impulse amplitude, the noise floor is -90dBV down, or about 10uV. OQPSK MODEM SIMULATION A friend of mine is developing a commercial OQPSK modem and was a bit stuck. I’m not surprised as I’ve had problems with OQPSK in thepast as well.
ROWETEL – OPEN TELEPHONY SOFTWARE, HARDWARE, CRITICAL THINKINGCODEC 2SM1000FSK LDPC DATA MODEFREEDV 700D RELEASEDOSLEC ECHO CANCELLER FSK_LDPC can scale to any bit rate you like. The ratio of the sample rate to symbol rate Fs/Rs = 8000/1000 (8kHz, 1000 bits/s) is the same as Fs/Rs = 800000/100000 (800kHz, 100k bits/s), so it’s the same thing to the modem. I’ve tried FSK_LDPC between 5 and 40k bit/s sofar.
FREEDV 2020 FIRST ON AIR TESTS FreeDV 2020 First On Air Tests. Brad (AC0ZJ), Richard (KF5OIM) and I have been putting the pieces required for the new FreeDV 2020 mode, which uses LPCNet Neural Net speech synthesis technology developed by Jean-Marc Valin. The goal of this mode is 8kHz audio bandwidth in just 1600 Hz of RF bandwidth. FreeDV 2020 is designed for HF channels VDSL VERSUS HF RADIO This is simply a 5uH inductor in series with a 100pF capacitor, connected across the VDSL phone line. This has a few hundred ohms of Xc above resonance, which results in just a few dB attenuation at 8-12 MHz. This obtained 38 Mbps downstream. Upstream was the same (24 Mbps) as with no filter. Good enough. CODEC 2 – ROWETELSEE MORE ON ROWETEL.COM RTLSDR STRONG SIGNALS AND NOISE FIGURE Airspy and RTLSDR. The Airspy uses the same tuner chip so I tested it and found about the same strong signal results, i.e. it overloads at the same signal levels as the RTLSDR at max gain. Guess this is no surprise if it’s the same tuner. I once again measured the Airspy noise figure at about 7dB, slightly higher than the 6dB of theRTLSDR.
CODEC 2 700C EQUALISER The two right hand columns show the results (variance after 2nd stage) without and with the equaliser, using the Codec 2 700C VQ (which I have labelled train_120 in the source code). On some samples it has quite an effect (cq_ref, cq_freedv_8k), less so on others. After the equaliser, most of the samples are in the 8dB^2 range. TRELLIS DECODING FOR CODEC 2 Hear are some samples that compare trellis based decoding to simple hard decision decoding, when applied to Codec2 at 700 bit/s on a AWGN channel using PSK. Only the 6 LSP parameters are tested (short term spectrum), no errors or correction are applied to the excitation parameters (voicing, pitch, energy). Eb/No (dB) BAND PASS FILTER AND POWER AMPLIFIER FOR SIMPLE HF DATA Band Pass Filter. The RTL-SDR samples at 28.8 MHz, capturing a broad chunk of spectrum. In direct mode we just sample the Q-channel, so any energy above 14.4 MHz will be aliased into our passband; e.g. both 21 and 7 MHz will appear as a 7 MHz sampled signal. In the previous post we determined the ADC overloads at -30dBm, so we want to removeURBAN HF NOISE
The Octave script impulse_noise.m was used to generate the plots in this post. Here is a plot of some PWM impulse samples (top), and the HF spectrum. I’ve injected a “wanted” signal at 1MHz for comparison. Given a switcher frequency of 255kHz, with 0.1V impulse amplitude, the noise floor is -90dBV down, or about 10uV. OQPSK MODEM SIMULATION A friend of mine is developing a commercial OQPSK modem and was a bit stuck. I’m not surprised as I’ve had problems with OQPSK in thepast as well.
ROWETEL – OPEN TELEPHONY SOFTWARE, HARDWARE, CRITICAL THINKING FSK_LDPC can scale to any bit rate you like. The ratio of the sample rate to symbol rate Fs/Rs = 8000/1000 (8kHz, 1000 bits/s) is the same as Fs/Rs = 800000/100000 (800kHz, 100k bits/s), so it’s the same thing to the modem. I’ve tried FSK_LDPC between 5 and 40k bit/s sofar.
FREEDV 2020 OVER THE QO-100 SATELLITE FreeDV 2020 over the QO-100 Satellite. Gerhard (OE3GBB), Steve (K5OKC) and I have been working on FreeDV 2020 over the Es’hail 2/QO-100 satellite. This satellite is in geosynchronous orbit and has a linear transponder. It’s designed for SSB so has a narrow bandwidth which rules out most digital voice modes – OPEN SOURCE ECHO CANCELLER PART 1 Introduction. For the Free Telephony Project I have an embedded version of Asterisk running on hardware that supports several FXO and FXS ports. I need a line echo canceller that can handle echo on typical FXO and FXS ports. As a starting point I am using the echo canceller software included in the Zaptel device driver package.. However on my FXS and especially FXO ports, this echo canceller OPEN SOURCE LOW RATE SPEECH CODEC PART 1 Open Source Low Rate Speech Codec Part 1. I have decided to start working on a free (as in speech) low bit rate speech codec. The initial target is 2400 bit/s communications quality speech. Communications quality means something between synthetic, robotic sounding speech and a mobile phone. The application is voice over lowbandwidth digital
NATURAL AND GRAY CODING After writing up the Variable Power Quantiser work I added another function to my fuzzy_gray.m Octave simulation to compare natural and Gray coded binary.. Here are some results for 3,4, and 5 bit quantisers over a range of errors: Curiously, the natural binary results are a little better (about 1dB less Eb/No for the same SNR). FREEDV 700E AND COMPRESSION FreeDV 700E and Compression. FreeDV 700D is built around an OFDM modem and powerful LDPC codes, and was released in mid 2018. Since then our real world experience has shown that it struggles with fast fading channels. Much to my surprise, the earlier FreeDV 700C mode actually works better on fast fading channels. SNR AND EB/NO WORKED EXAMPLE SNR (dB) = Eb/No (dB) + 10log10 (Rb/B) So for FreeDV 700B, the bit rate Rb = 700, B = 3000 Hz (for SNR in a 3000Hz bandwidth) so we get: SNR = Eb/No – 6.3. Now, say we need a BER of 2% or 0.02 for speech, the lower Blue curve says we need an Eb/No = 4dB, so we get: SNR = 4 – 6.3 = -2.3dB. So if the modem is working down to “just” 0dB we HIGH SPEED BALLOON DATA LINK The data rate of the link is Rs=115.2 kbit/s, which is sampled by the demodulator at Fs = 115200*8 = 921.6 kHz. However to the modem it just looks like an 8 times oversampled signal. So here is 10 seconds of the modem signal replayed at Fs=9600 Hz. You can hear the packets startingby the sound of
ELECTRIC CAR BMS CONTROLLER The BMS LOOP2 Controller at the bottom is the easiest to understand. Q6 and Q7 form a Set-Reset flip-flop. You pull the base of Q6 low to set the flip flop, and the base of Q7 is taken low to reset the flip flop. When power is applied, C6 sets the flip flop, putting it in theCHARGE state.
AN OPEN-SOURCE SPEECH CODEC AT 450 BIT/S WITH PSEUDO An Open-Source Speech Codec at 450 bit/s with Pseudo-Wideband Mode. Stefan Erhardt #1, Thomas Kurin #2, Fabian Lurz #3, Robert Weigel #4,Alexander Koelpin*
Skip to content
ROWETEL
open telephony software, hardware, critical thinkingMenu and widgets
QUICK LINKS
* Archive
* Codec 2
* FreeDV
* SM1000
* Contact
POPULAR POSTS
* Codec 2
* SM1000
* AMBE+2 and MELPe 600 Compared to Codec 2* Archive
* Measuring SDR Noise Figure in Real Time * LPCNet Quantiser – wideband speech at 1700 bits/s * FreeDV 700D Released * Testing HAB Telemetry Protocols * LPCNet meets Codec 2* Codec 2 700C
* Codec 2 and TWELP
* Open Source Low Rate Speech Codec Part 1* Electric Vehicles
* WaveNet and Codec 2 * Codec 2 HF Data Modes Part 3RECENT POSTS
* Simple FreeDV API Examples * Codec 2 HF Data Modes Part 3 * Codec 2 HF Data Modes Part 2 * FreeDV 700E and Compression * Open IP over VHF/UHF 4RECENT COMMENTS
* david on Codec 2 HF Data Modes Part 3 * Bill Bullet on Codec 2 HF DataModes Part 3
* david on Codec 2 HF Data Modes Part 3 * john on Codec 2 HF Data Modes Part 3 * glen english on Codec 2 HF Data Modes Part 3BLOG CATEGORIES
* Blackfin
* Critical Thinking
* Electric Vehicles
* Hardware
* News
* Radio
* Renewables
* Telephony
* The Next Wave
* Uncategorized
SITE MAP
* Archive
* Codec 2
* Contact
* Projects
* Electric Vehicles
* Oslec Echo Canceller* SM1000
* Store
META
* Log in
* Entries RSS
* Comments RSS
* WordPress.org
SIMPLE FREEDV API EXAMPLESHere are some
simple examples showing how to use the Codec 2 and FreeDV API in C and Python applications. Some of the other examples have grown a little too full featured and complex so I thought it might be useful to show the simplest possible programs. Instructions at the top of each file. The Quisk SDR is a fine example of a GUI application that uses the FreeDV API. I’m intrigued by the idea of using the FreeDV API with other languages such as Python. I first became aware of this idea through this FreeDV KISS TNC projectfrom xssfox.
Using similar techniques Mark, VK5QI, has implemented a High Altitude Balloon (HAB) telemetry libraryusing a fork of C
modem/protocol code from Codec 2 combined with Python. The project includes a nice Python GUI application for receiving HAB telemetry. Posted on April 30, 2021 Author david Categories Radio Leave a comment on Simple FreeDVAPI Examples
CODEC 2 HF DATA MODES PART 3 It works! I’ve spent the last few weeks building automated tests for the new HF data modes. All three modes are working well over real world 40m/20m channels at distances between 100km and 3000km. My goalswere:
* Transfer a total 1 Mbyte of data – that’s quite a bit for HF. * Find some fast fading and long delay spread channels. Hence the100km (NVIS) tests.
* Run the tests over a week to experience a range of HF conditions. * Look for any corner cases that break the modems. * Collect a bunch of real world samples to support furtherdevelopment.
I ended up with 649 off air samples, that I can inspect by browsingthe spectograms:
Here is a histogram of the SNRs tested: The data modes work fine in simulation down to -4dB, so I’m pleased to see the same is true on real world channels. Curiously I didn’t get any really high SNRs, perhaps my station is too modest (IC7200 into a dipole). At some stage I will need to find a high SNR path totest QAM modes.
I did find a fast fading example (with bonus co-channel SSB): The spectrogram of this sample shows the “barber pole” lines moving quickly as the notch sweeps through the modem spectrum: Each test logs some data: in this case 5 good frames from 5 transmitted, despite the fast fading and SSB. sdr.ironstonerange.comdatac3
waiting for KiwiSDR .Tx data signal
Stopping KiwiSDR
Process receiver sample modembufs: 183 bytes: 630 Frms.: 5 SNRAv: 3.66 BER......: 0.0354 Tbits: 10240 Terrs: 363 Coded BER: 0.0000 Tbits: 5120 Terrs: 0 Coded FER: 0.0000 Tfrms: 5 Tfers: 0 FrmGd FrmDt Bytes SNRAv RawBER Pre Post UWfails 5 5 630 3.66 0.0354 5 0 0 Unfortunately I didn’t collect any large delay spread examples – these would show up as closely spaced notches in the spectrogram. In this example the notches about 700Hz apart: … which means 1/700=1.4ms of delay spread. The worst case sample had notches spaced by 500 Hz (2ms delay spread). The modes I tested are designed to handle up to 6ms so they didn’t get much of a work out. I might need some help from friends in high latitudes….RUNNING A TEST
Each test is controlled by the ota_test.sh script, for example: ./ota_test.sh kiwisdr.areg.org.au This records the received signal from the KiwiSDR while transmitting data frames using my HF radio. After the transmission is complete, the received wave file is run through the demodulator. The received frames are checked and we log some statistics. There are set-up instructions at the top of the script, and even some help:./ota_test.sh
Automated Over The Air (OTA) data test for FreeDV OFDM HF data modems usage ./ota_test.sh kiwi_url -d debug mode; trace script execution -o model select radio model number ('rigctl -l' to list) -m mode datac0|datac1|datac3 -t Tx only, useful for manually observing SDRs which block multiple sessions from one IP I also wrote scripts to automate the tests via cron, and to summariseresults.
Looking at the data over time, I learnt a bit about HF propogation, e.g. I could see 100km NVIS falling over at sunset, but could still send packets 800km away for a few more hours (although with reduced performance). In the morning it was the reverse, I could see SNRs from a 800km path reducing, and NVIS SNRs building up. I can think of a few improvements to my test system: * Rx from multiple KiwiSDRs at the same time, to collect data faster from multiple paths. * Add an option to pre-pend a wavefile with SSB for peridoic stationID.
* The system could be used to test voice modes: send a SSB signal, then a FreeDV voice mode signal, to compare them over the same channel. The samples could be normalised to the same peak power. The tests also reminded me I haven’t tuned the compression (PAPR) of the data modes to get maximum performance out of them for a given peak power. Will work on that next.LINKS
README_data
– Codec 2 data mode documentation (HF OFDM raw data section) HF OFDM Data testing – GitHub PR where I’m developing the automated tests. Codec 2 HF Data Modes Part 1 Codec 2 HF Data Modes Part 2 Posted on April 25, 2021May 1, 2021Author david
Categories Radio
5 Comments on Codec 2 HF DataModes Part 3
CODEC 2 HF DATA MODES PART 2 Over the past few months I’ve been working on HF data modes, in particular building up a new burst acquisition system for our OFDM modem. As usual, what seemed like a small project turned out to be a lot of work! I’ve now integrated all the changes into the FreeDV API and started testing over the air, sending frames of data from a Tx at my home to remote SDRs all over Australia.Features:
* Importantly – this work is open source – filling a gap in the HF data world. HF is used for Ham radio, emergency communications and in the developing world where no other infrastructure exists. It needsto be open.
* High performance waveforms designed for fast fading channels with modern FEC (thanks Bill, VK5DSP). * Implemented as a C library that can be cross compiled on many machines, and called from other programs (C and Python examples). You don’t need to be tied to one operating system or expensive, proprietary hardware. * Further development is supported by a suite of automated tests. I’m not aiming to build a full blown TNC myself, just the layer that can move data frames over HF Radio channels. This seems to be where the real need lies, and the best use of my skills. I have however been working with TNC developers like Simon, DJ2LS. Together we have written a set of use cases that we have been developing against. This has been very useful, and a fun learning experience for both of us. I’ve documented the Codec 2 HF data modes in README_data,
which includes simple examples of how to use the API, and simulated/real world results.Further work:
* Automated testing over real world channels * Tuning performance * Port a higher bit rate QAM16 mode to C * Working with TNC developers * Prototype very simple low cost HF Data links using RTLSDRs andRpiTx transmitters
READING FURTHER
HF Acquisition Pull Request – journal of the recentdevelopment
README_data
– Codec 2 data mode documentation (HF OFDM raw data section) Codec2 HF Data Modes Part 1 Posted on April 13, 2021May 1, 2021Author david
Categories Radio
1 Comment on Codec 2 HF Data ModesPart 2
FREEDV 700E AND COMPRESSION FreeDV 700D is built around an OFDM modem and powerful LDPC codes, and was released in mid 2018. Since then our real world experience has shown that it struggles with fast fading channels. Much to my surprise, the earlier FreeDV 700C mode actually works better on fast fading channels. This is surprising as 700C doesn’t have any FEC, but instead uses a simple transmit diversity scheme – the signal is sent twice at two different frequencies. So I decided to develop a new FreeDV 700E waveform with thefollowing features:
* The ability to handle fast fading through an increased pilot symbol rate, but also with FEC which is useful for static crashes, interference, and mopping up random bit errors. * Uses a shorter frame (80ms), rather than the 160ms frame of 700D. This will reduce latency and makes sync faster. * The faster pilot symbol rate will mean 700E can handle frequency offsets better, as well as fast fading. * Increasing the cyclic prefix from 2 to 6ms, allowing the modem to handle up to 6ms of multipath delay spread. * A wider RF bandwidth than 700D, which can help mitigate frequency selective fading. If one part of the spectrum is notched out, we can use FEC to recover data from other parts of the spectrum. On the flip side, narrower signals are more robust to some interference, and useless spectrum.
* Compression of the OFDM waveform, to increase the average power (and hence received SNR) for a given peak power. * Trade off low SNR performance for fast fading channel performance. A higher pilot symbol rate and longer cyclic prefix mean less energy is available for data symbols, so low SNR performance won’t be asgood as 700D.
* It uses the same Codec 2 700C voice codec, so speech quality will be the same as 700C and D when SNR is high. Over the course of 2020, we’ve refactored the OFDM modem and FreeDV API to make implementing new modem waveforms much easier. This really helped – I designed, simulated, and released the FreeDV 700E mode in just one week of part time work. It’s already being used all over the world in the development version of FreeDV 1.5.0. My bench tests indicate 700C/D/E are equivalent on moderate fading channels (1Hz Doppler/2ms spread). As the fading speeds up to 2Hz 700D falls over, but 700C/E perform well. On very fast fading (4Hz/4ms) 700E does better as 700C stops working. 700D works better at lower SNRs on slow fading channels (1Hz Doppler/2ms and slower). The second innovation is compression of the 700C/D/E waveforms, to increase average power significantly (around 6dB from FreeDV 1.4.3). Please be careful adjusting the Tx drive and especially enabling the Tools – Options – Clipping. It can drive your PA quite hard. I have managed 40W RMS out of my 75W PEP transmitter. Make sure your transmitter can handle long periods of high average power. I’ve also been testing against compressed SSB, which is pretty hard to beat as it’s so robust to fading. However 700E is hanging on quite well with fast fading, and unlike SSB becomes noise free as the SNR increases. At the same equivalent peak power – 700D is doing well when compressed SSB is -5dB SNR and rather hard on the ears.SSB COMPRESSION
To make an “apples to apples” comparison between FreeDV to SSB at low SNRs I need SSB compressor software than I can run on the (virtual) bench. So I’ve developed a speech compressor using some online wisdom . Turns out the “Hilbert Clipper” in is very similar to how I am compressing my OFDM signals to improve their PAPR. This appeals to me – using the same compression algorithm onSSB and FreeDV.
The Hilbert transformer takes the “real” speech signal and converts it to a “complex” signal. It’s the same signal, but now it’s represented by in phase and quadrature signals, or alternatively a vector spinning around the origin. Turns out you can do a much better job at compression by limiting the magnitude of that vector, than by clipping the input speech signal. Any clipping tends to spread the signal in frequency, so we have a SSB filter at the output to limit the bandwidth. Good compressors can get down to about 6dB PAPR for SSB, mine is not too shabby at 7-8dB. It certainly makes a difference to noisy speech, as you can see in this plot (in low SNR channel), and the samples below:COMPRESSION
SNR
SAMPLE
Off
High
Listen
On
High
Listen
Off
Low
Listen
On
Low
Listen
FREEDV PERFORMANCE
Here are some simulated samples. They are all normalised to the same peak power, and all waveforms (SSB and FreeDV) are compressed. The noise power N is in dB but there is some arbitrary scaling (for historical reasons). A more negative N means less noise. For a given noise power N, the SNRs vary as different waveforms have different peak to average power ratio. I’m adopting the convention of comparing signals at the same (Peak Power)/(Noise Power) ratio. This matches real world transmitters – we need to do the best we can with a given PEP (peak power). So the idea below is to compare samples at the same noise power N, and channel type, as peak power is known to be constant. An AWGN channel is just plain noise, MPP is 1Hz Doppler, 2ms delay spread; and MPD is 2Hz Doppler, 4ms delay spread.TEST
MODE
CHANNEL
N
SNR
SAMPLE
1
SSB
AWGN
-12.5
-5
Listen
700D
AWGN
-12.5
-1.8
Listen
2
SSB
MPP
-17.0
0
Listen
700E
MPP
-17.0
3
Listen
3
SSB
MPD
-23.0
8
Listen
700E
MPD
-23.0
9
Listen
Here’s a sample of the simulated off air700E modem
signal 700E at 8dB SNR in a MPP channel. It actually works up to 4 Hz Doppler and 6ms delay spread. Which sounds likes a UFO landing.Comments:
* With digital when your in a fade, you’re a fade! You lose that chunk of speech. A short FEC code (less than twice fade duration) isn’t going to help you much. We can’t extend the code length because latency (this is PTT speech). Sigh. * This explain why 700C (with no FEC) does so well – we lose speech during deep fades (where FEC breaks anyway) but it “hangs on” as the Doppler whirls around and sounds fine in the “anti-fades”. The voice codec is robust to a few % BER all byitself which helps.
* Analog SSB is nearly impervious to fading, no matter how fast. It’s taken a lot of work to develop modems that “hang on” in fast fading channels. * Analog SSB degrades slowly with decreasing SNR, but also improves slowly with increasing SNR. It’s still noisy at high SNRs. DSP noisereduction can help.
Lets take a look at the effect of compression. Here is a screen shot from my spectrum analyser in zero-span mode. It’s displaying power against time from my FT-817 being driven by two waveforms. Yellow is the previous, uncompressed 700D waveform, purple is the latest 700D with compression. You can really get a feel for how much higher the average power is. On my radio I jumped from 5-10W RMS to 40WRMS.JOSE’S DEMO
Jose, LU5DKI sent me a wave file sample of him “walking through the modes” over a 12,500km path between Argentina and New Zealand. The SSB is at the 2:30 mark: This example shows how well 700E can handle fast fading over a path that includes Antartica:A few caveats:
* Jose’s TK-80 radio is 40 years old and doesn’t have any compression available for SSB. * FreeDV attenuates the “pass through” off air radio noise by about 6dB, so the level of the SSB will be lower than the FreeDV audio. However that might be a good idea with all that noise. * Some noise reduction DSP might help, although it tends to fall over at low SNRs. I don’t have a convenient command line tool for that. If you do – here is Jose’s sample. Please share the
output with us.
I’m interested in objective comparisons of FreeDV and SSB using off air samples. I’m rather less interested in subjective opinions. Show me the samples ……. CONCLUSIONS AND FURTHER WORK I’m pleased with our recent modem waveform development and especially the compression. It’s also good fun to develop new waveforms and getting easier as the FreeDV API software matures. We’re getting pretty good performance over a range of channels now. Learning how to make modems for digital voice play nicely over HF channels. I feel our SSB versus FreeDV comparisons are maturing too. The main limitation is the Codec 2 700C vocoder – while usable in practice it’s not exactly HiFi. Unfortunately speech coding is hard – much harder than modems. More R&D than engineering, which means a lot more effort – with no guarantee of a useful result. Anyhoo, lets see if I can make some progress on speech quality at low SNRs in 2021!LINKS
Compression – good introduction from AB4OJ. DSP Speech Processor Experimentation 2012-2020–
Sophisticated speech processor. Playing with PAPR – my initial simulations fromearlier in 2020.
Jim Ahlstrom N2ADR has done some fine work on FreeDV filter C code – very useful once again for this project. Thanks Jim! Modems for HF Digital Voice Part 1 and Part 2 – gentle introduction in to modems for HF. Steve Ports an OFDM modem from Octave to C – the OFDM modem Steve and I built – it keeps getting better! FreeDV 700E uses one of Bill’sfine LDPC codes.
Modem waveform design spreadsheet.
FreeDV 700D ReleasedCOMMAND LINES
Writing these down so I can cut and paste them to repeat these testsin the future….
Typical FreeDV 700E simulation, wave file output: ./src/freedv_tx 700E ../raw/ve9qrp_10s.raw - --clip 1 | ./src/cohpsk_ch - - -23 --mpp --raw_dir ../raw --Fs 8000 | sox -t .s16 -r 8000 -c 1 - ~/drowe/blog/ve9qrp_10s_700e_23_mpd_rx.wav Looking at the PDF (histogram) of signal magnitude is interesting. Lets generate some compressed FreeDV 700E: ./src/freedv_tx 700D ../raw/ve9qrp.raw - --clip 1 | ./src/cohpsk_ch - - -100 --Fs 8000 --complexout > ve9qrp_700d_clip1.iq16 Now take the complex valued output signal and plot the PDF and CDF the magnitude (and time domain and spectrum): octave:1> s=load_raw("../build_linux/ve9qrp_700d_clip1.iq16"); s=s(1:2:end)+j*s(2:2:end); figure(1); plot(abs(s)); S=abs(fft(s)); figure(2): clf; plot(20*log10(S)); figure(3); clf; = hist(abs(s),25,1); cdf = empirical_cdf(1:max(abs(s)),abs(s)); plotyy(nn,hh,1:max(abs(s)),cdf); This is after clipping, so 100% of the samples have a magnitude less than 16384. Also see . When testing with real radios it’s useful to play a sine wave at the same PEP level as the modem signals under test. I could get 75WRMS (and PEP) out of my IC-7200 using this test (13.8VDC power supply): ./misc/mksine - 1000 160 16384 | aplay -f S16_LE We can measure the PAPR of the sine wave with the cohpsk_ch tool: ./misc/mksine - 1000 10 | ./src/cohpsk_ch - /dev/null -100 --Fs 8000 ohpsk_ch: Fs: 8000 NodB: -100.00 foff: 0.00 Hz fading: 0 nhfdelay: 0 clip: 32767.00 ssbfilt: 1 complexout: 0 cohpsk_ch: SNR3k(dB): 85.23 C/No....: 120.00 cohpsk_ch: peak.....: 10597.72 RMS.....: 9993.49 CPAPR.....: 0.51 cohpsk_ch: Nsamples.: 80000 clipped.: 0.00% OutClipped: 0.00% CPAPR = 0.5dB, should be 0dB, but I think there’s a transient as the Hilbert Transformer FIR filter memory fills up. Close enough. By chaining cohpsk_ch together is various ways we can build a SSB compressor, and simulate the channel by injecting noise and fading: ./src/cohpsk_ch ../raw/ve9qrp_10s.raw - -100 --Fs 8000 | ./src/cohpsk_ch - - -100 --Fs 8000 --clip 16384 --gain 10 | ./src/cohpsk_ch - - -100 --Fs 8000 --clip 16384 | ./src/cohpsk_ch - - -17 --raw_dir ../raw --mpd --Fs 8000 --gain 0.8 | aplay -f S16_LE cohpsk_ch: peak.....: 16371.51 RMS.....: 7128.40 CPAPR.....: 7.22 A PAPR of 7.2 dB is pretty good for a few hours work – the cools kids get around 6dB . Posted on December 28, 2020December 30, 2020Author david
Categories Radio
, Telephony
Leave a comment on FreeDV 700E andCompression
OPEN IP OVER VHF/UHF 4 For the last few weeks I’ve been building up some automated test software for my fledgling IP over radio system. Long term automated tests can help you thrash out a lot of issues. Part of my cautious approach in taking small steps to build a complex system. I’ve built up a frame repeater system where one terminal “pings” another terminal – and repeats this thousands of times. I enjoyed writing service scripts to wrap up the complex command lines, and bring the system “up” and “down” cleanly. The services also provide some useful debug options like local loopback testing of the radio hardware on each terminal. I started testing the system “over the bench” with two terminals pinging and ponging frames back and forth via cables. After a few hours I hit a bug where the RpiTx RF would stop. A few repeats showed this sometimes happened in a few minutes, and other times after a fewhours.
This lead to an interesting bug hunt. I quite enjoy this sort of thing, peeling off the layers of a complex system, getting closer and closer to the actual problem. It was fun to learn about the RpiTx internals. A very clever system of a circular DMA buffer feeding PLL fractional divider values to the PLLC registers on the Pi. The software application chases that DMA read pointer around, trying to keep the buffer full. By dumping the clock tree I eventually worked out some other process was messing with the PLLC register. Evariste on the RpiTx forum then suggested I try “force_turbo=1” . That fixed it! My theory is the CPU freq driver (wherever that lives) was scaling all the PLLs when the CPU shifted clock speed. To avoid being caught again I added some logic to check PLLC and bomb out if it appears to have beenchanged.
A few other interesting things I noticed: * I’m running 10 kbit/s for these tests, with a 10kHz shift between the two FSK tones and a carrier frequency of 144.5MHz. I use a FT-817 SSB Rx to monitor the transmission, which has bandwidth of around 3 kHz. A lot of the time a FSK burst sounds like broadband noise, as the FT-817 is just hearing a part of the FSK spectrum. However if you tune to the high or low tone frequency (just under 144.500 or 144.510) you can hear the FSK tones. Nice audio illustration of FSK in action. * On start up RPiTx uses ntp to calibrate the frequency, which leads to slight shifts in the frequency each time it starts. Enough to be heard by the human ear, although I haven’t measured them. I’ve just finished a 24 hour test where the system sent 8600 bursts (about 6 Mbyte in each direction) over the link, and everything is running nicely (100% of packets were received). This gives me a lot of confidence in the system. I’d rather know if there are any stability issues now than when the device under test is deployed remotely. I feel quite happy with that result – there’s quite a lot of signal processing software and hardware that must be playing nicely together to make that happen. Very satisfying.NEXT STEPS
Now it’s time to put the Pi in a box, connect a real antenna and try some over the air tests. My plan is: * Set up the two terminals several km apart, and see if we can get a viable link at 10 kbit/s, although even 1 kbit/s would be fine for initial tests. Enough margin for 100 kbit/s would be even better, but happy to work on that milestone later. * I’m anticipating some fine tuning of the FSK_LDPC waveforms willbe required.
* I’m also anticipating problems with urban EMI, which will raise the noise floor and set the SNR of the link. I’ve instrumented the system to measure the noise power at both ends of the link, so I can measure this over time. I can also measure received signal power, and estimate path loss. Knowing the gain of the RTLSDR, we can measure signal power in dBm, and estimate noise power in dBm/Hz. * There might be some EMI from the Pi, lets see what happens when the antenna is close. * I’ll run the frame repeater system over several weeks, debug any stability issues, and collect data on S, N, SNR, and Packet ErrorRate.
READING FURTHER
Open IP over VHF/UHF Part 1 Part 2 Part 3 RpiTx – Radio transmitter software for Raspberry Pis GitHub repo for this project with build scripts, a project plan and a bunch of command lines I use to run various tests. The latest work in progress will be an open pullrequest.
RpiTx Group discussion of the PLLC bug discussed above Posted on December 3, 2020December 3, 2020Author david
Categories Radio
OPEN IP OVER VHF/UHF 3 The goal of this project is to develop a “100 kbit/s IP link” for VHF/UHF using just a Pi and RTLSDR hardware, and open source signal processing software . Since the last post, I’ve integrated a bunch of components and now have a half duplex radio data system running over the bench.Recent progress:
* The Tx and Rx signal processing is now operating happily together on a Pi, CPU load is fine. * The FSK_LDPC modem and FEC has been integrated, so we can now send and receive coded frames. The Tx and Rx command line programs have been modified to send and receive bursts of frames. * I’ve added a PIN diode Transmit/Receive switch, which I developed for the SM2000 project . This is controlled by a GPIO from the Pi. There is also logic to start and stop the Pi Tx carrier at the beginning and end of bursts – so it doesn’t interfere withthe Rx side.
* I’ve written a “frame repeater” application that takes packets received from the Rx and re-transmits them using the Tx. This will let me run “ping” tests over the air. A neat feature is it injects the received Signal and Noise power into the frame it re-transmits. This will let me measure the received power, the noise floor, and SNR at the remote station. * The receiver in each terminal is very sensitive, and inconveniently picks up frames transmitted by that terminal. After trying a few approaches I settled on a “source filtering” design. When a packet is transmitted, the Tx places a “source byte” in the frame that is unique to that terminal. A one byte MAC address I guess. The local receiver then ignores (filters) any packets with that source address, and only outputs frames from other terminals. Here is a block diagram of the Pi based terminal, showing hardware and software components: When I build my next terminal, I will try separate Tx and Rx antennas, as a “minimalist” alternative to the TR switch. The next figure shows the transmit control signals in action. Either side of a burst we need to switch the TR switch and turn the Tx carrier on and off: Here’s the current half duplex setup on the bench: Terminal2 is on the left, is comprised of the Pi, RTLSDR, and TR switch. Terminal1 (right) is the HackRF/RTLSDR connected to my laptop. Instead of a TR switch I’m using a hybrid combiner (a 3dB loss, but not an issue for these tests). This also shows how different SDR Tx/Rx hardware can be used with this system. I’m using 10,000 bit/s for the current work, although that’s software configurable. When I start testing over the air I’ll include options for a range of bit rates, eventually shooting for 100kbits/s.
Here’s a demo video of the system:NEXT STEPS
The command lines to run everything are getting unwieldy so I’ll encapsulate them is some “service” scripts to start and stop the system neatly. Then box everything up, try a local RF link, and check for stability over a few days. Once I’m happy I will deploy a terminal and start working through the real world issues. The key to getting complex systems going is taking tiny steps. Test and debug carefully at each step. It’s coming together quite nicely, and I’m enjoying a few hours of work on the project every weekend. It’s very satisfying to build the layers up one by one, and a pleasant surprise when the pieces start playing nicely together and packets move magically across the system. I’m getting to play with RF, radios, modems, packets, and even building up small parts of a protocol. Good fun!READING FURTHER
Open IP over UHF/VHF Part 1 and Part 2 . FSK LDPC Data Mode – open source data mode using a FSK modem and powerful LDPC codes. SM2000 Part 3 – PIN TR Switch and VHF PA GitHub repo for this project with build scripts, a project plan and a bunch of command lines I use to run various tests. The latest work in progress will be an open pullrequest.
Posted on November 16, 2020November 16, 2020Author david
Categories Radio
4 Comments on Open IP over VHF/UHF3
SPEECH SPECTRAL QUANTISATION USING VQ-VAE As an exercise to learn more about machine learning, I’ve been experimenting with Vector Quantiser Variational AutoEncoders (VQ VAE) . Sounds scary but is basically embedding a vector quantiser in a Neural Network so they train together. I’ve come up with a simple network that quantises 80ms (8 x 10ms frames) of spectral magnitudes in 88 bits (about 1100 bits/s). I arrived at my current model through trial and error, using this example as a starting point. Each 10ms frame is a vector of energies from 14 mel-spaced filters, derived from LPCNet . The network uses conv1D stages to downsample and upsample the vectors, with a two stage VQ (11 bits per stage) in the Autoencoder “bottleneck”. The VQ is also encoding total frame energy, so the remaining parameters for a vocoder would be pitch and(maybe) voicing.
This work (spectral quantisation) is applicable to “old school” vocoders like Codec 2 and is also being used with newer Neural Vocoders in some research papers. I haven’t used it to synthesise any speech yet but it sure does make nice plots. This one is a 2D histogram of the encoder space, white dots are the stage 1 VQ entries. The 16 dimensional data has been reduced to 2 dimensions using PCA. If the VQ is working, we should expect more dots in the brighter colour areas, and less in the darker areas. Here is a sample input (green) output (red) of 8 frames: This is a transition region, going from voiced to unvoiced speech. It seems to handle it OK. The numbers are (frame_number, SD), where SD is the Spectral Distortion in dB*dB. When we get a high SD frame, quite often it’s not crazy wrong, more an educated guess that will probably sound OK, e.g. a different interpolation profile for the frame energy across a transition. Formants are mostly preserved. The VQ seems to be doing something sensible, after 20 epochs I can see most VQ entries are being used, and the SD gets better with more bits. The NN part trains much faster that the VQ. Here is a histogram of the SDs for each frame: The average SD is around 7.5 dB*dB, similar to some of the Codec 2 quantisers. However this is measured on every 10ms frame in an 8 frame sequence, so it’s a measure of how well it interpolates/decimates in time as well. As I mentioned above – some of the “misses” that push the mean SD higher are inconsequential. POSSIBLE BUG IN CODEC 2 700C I use similar spectral magnitude vectors for Codec 2 700C – however when I tried that data the SD was about double. Hmmm. I looked into it and found some bugs/weaknesses in my approach for Codec 2 700C (for that codec the spectral magnitudes a dependant on the pitch estimator which occasionally loses it). So that was a nice outcome – trying to get the same result two different ways can be a prettyuseful test.
FURTHER WORK
Some ideas for further work: * Use kmeans for training. * Inject bit errors when training to make it robust to channelerrors.
* Include filtered training material to make it robust to recordingconditions.
* Integrate into a codec and listen to it. * Try other networks – I’m still learning how to engineer anoptimal network.
* Make it work with relu activations, I can only get it to work withtanh.
READING FURTHER
VQ VAE Keras MNIST Example – my starting point for the VQ-VAE work Neural Discrete Representation Learning My Github repo for this work Good introduction to PCA Codec 2 700C – also uses VQ-ed mel-spaced vectors LPCNet: DSP-Boosted Neural Speech Synthesis Posted on November 3, 2020November 3, 2020Author david
Categories Telephony 1 Comment on Speech Spectral Quantisation using VQ-VAEFSK LDPC DATA MODE
I’m developing an open source data mode using a FSK modem and powerful LDPC codes. The initial use case is the Open IP over UHF/VHF project, but it’s available in the FreeDV APIas a
general purpose mode for sending data over radio channels. It uses 2FSK or 4FSK, has a variety of LDPC codes available, works with bursts or streaming frames, and the sample rate and symbol rate can be set at init time. The FSK modem has been around for some time, and is used for several applications such as balloon telemetryand FreeDV
digital voice modes. Bill, VK5DSP, has recently done some fine work to tightly integrate the LDPC codes with the modem. The FSK_LDPC system has been tested over the air in Octave simulation form, been ported to C, and bundled up into the FreeDV API to make using it straight forward from the command line, C or Python. We’re not using a “black box” chipset here – this is ground up development of the physical layer using open source, careful simulation, automated testing, and verification of our work on real RF signals. As it’s open source the modem is not buried in proprietary silicon so we can look inside, debug issues and integrate powerful FEC codes. Using a standard RTLSDR with a 6dB noise figure, FSK_LDPC is roughly 10dB ahead of the receiver in a sample chipset. That’s a factor of 10 in power efficiency or bit rate – your choice!PERFORMANCE
The performance is pretty close to what is theoretically possible for coded FSK . This is about Eb/No=8dB (2FSK) and Eb/No=6dB (4FSK) for error free transmission of coded data. You can work out what that means for your application using: MDS = Eb/No + 10*log10(Rb) + NF - 174 SNR = Eb/No + 10*log10(Rb/B) So if you were using 4FSK at 100 bits/s, with a 6dB Noise figure, the Minimum Detectable Signal (MDS) would be: MDS = 6 + 10*log10(100) + 6 - 174= -142dBm
Given a 3kHz noise bandwidth, the SNR would be: SNR = 6 + 10*log10(100/3000)= -8.8 dB
HOW IT WORKS
Here is the FSK_LDPC frame design: At the start of a burst we transmit a preamble to allow the modem to syncronise. Only one preamble is transmitted for each data burst, which can contain as many frames as you like. Each frame starts with a 32 bit Unique Word (UW), then the FEC codeword consisting of the data and parity bits. At the end of the data bits, we reserve 16 bits for aCRC.
This figure shows the processing steps for the receive side: UNIQUE WORD SELECTION The Unique Word (UW) is a known sequence of bits we use to obtain “frame sync”, or identify the start of the frame. We need this information so we can feed the received symbols into the LDPC decoder in the correct order. To find the UW we slide it againt the incoming bit stream and count the number of errors at each position. If the number of errors is beneath a certain threshold – we declare a valid frame and try to decode it with the LDPC decoder. Even with pure noise (no signal) a random sequence of bits will occasionally get a partial match (better than our threshold) with the UW. That means the occasional dud frame detection. However if we dial up the threshold too far, we might miss good frames that just happen to have a few too many errors in the UW. So how do we select the length of the UW and threshold? Well for the last few decades I’ve been guessing. However despite being allergic to probability theory I have recently started using the BinominalDistribution to
answer this question. Lets say we have a 32 bit UW, lets plot the Binomial PDF and CDF: The x-axis is the number of errors. On each graph I’ve plotted twocases:
* A 50% Bit Error Rate (BER). This is what we get when no valid signal is present, just random bits from the demodulator. * A 10% bit error rate. This is the worst case where we need to get frame sync – a valid, but low SNR signal. The rate half LDPC codes fall over at about 10% BER. The CDF tells us “what is the chance of this many or less errors”. We can use it to pick the UW length and thresholds. In this example, say we select a “vaild UW threshold” of 6 bit errors out of 32. Imagine we are sliding the UW over random bits. Looking at the 50% BER CDF curve, we have a probablity of 2.6E-4 (0.026%) of getting 6 or less errors. Looking at the 10% curve, we have a probablity of 0.96 (96%) of detecting a valid frame – or in other words we will miss 100 – 96 = 4% of the valid frames that just happen to have 7 or more errors in the unique word. So there is a trade off between false detection on random noise, and missing valid frames. A longer UW helps separate the two cases, but adds some overhead – as UW bits don’t carry any payload data. A lower threshold means you are less likely to trigger on noise, but more likely to miss a valid frame that has a few errors in the UW. Continuing our example, lets say we try to match the UW on a stream of random bits from off air noise. Because we don’t know where the frame starts, we need to test every single bit position. So at a bit rate of 1000 bits/s we attempt a match 1000 times a second. The probability of a random match in 1000 bits (1 second) is 1000*2.6E-4 = 0.26, or about 1 chance in 4. So every 4 seconds, on average, we will get an accidental UW match on random data. That’s not great, as we don’t want to output garbage frames to higher layers of our system. So a CRC on the decoded data is performed as a final check to determine if the frame is indeed valid. PUTTING IT ALL TOGETHER We prototyped the system in GNU Octave first, then ported the individual components to stand alone C programs that we can string together using stdin/stdout pipes: $ cd codec2/build_linux$ cd src/ $ ./ldpc_enc /dev/zero - --code H_256_512_4 --testframes 200 | ./framer - - 512 5186 | ./fsk_mod 4 8000 5 1000 100 - - | ./cohpsk_ch - - -10.5 --Fs 8000 | ./fsk_demod --mask 100 -s 4 8000 5 - - | ./deframer - - 512 5186 | ./ldpc_dec - /dev/null --code H_256_512_4 --testframes--snip--
Raw Tbits: 101888 Terr: 8767 BER: 0.086 Coded Tbits: 50944 Terr: 970 BER: 0.019 Tpkts: 199 Tper: 23 PER: 0.116 The example above runs 4FSK at 5 symbols/second (10 bits/s), at a sample rate of 8000 Hz. It uses a rate 0.5 LDPC code, so the throughput is 5 bit/s and it works down to -24dB SNR (at around 10% PER). This is what it sounds like on a SSB receiver: Yeah I know. But it’s in there. Trust me. The command line programs above are great for development, but unwieldy for real world use. So they’ve been combined into single FreeDV API functions. These functions take data bytes, convert them to samples you send through your radio, then at the receiver back to bytes again. Here’s a simple example of sending some text using the FreeDV raw data API test programs: $ cd codec2/build_linux/src $ echo 'Hello World ' | ./freedv_data_raw_tx FSK_LDPC - - 2>/dev/null | ./freedv_data_raw_rx FSK_LDPC - - 2>/dev/null |hexdump -C
48 65 6c 6c 6f 20 57 6f 72 6c 64 20 20 20 20 20 |Hello World | 20 20 20 20 20 20 20 20 20 20 20 20 20 20 11 c6 | ..| The “2>/dev/null” hides some of the verbose debug information, to make this example quieter. The 0x11c6 at the end is the 16 bit CRC. This particular example uses frames of 32 bytes, so I’ve padded the input data with spaces. My current radio for real world testing is a Raspberry Pi Tx and RTLSDR Rx, but FSK_LDPC could be used over regular SSB radios (just pipe the audio into and out of your radio with a sound card), or other SDRs. FSK chips could be used as the Tx (although their receivers are often sub-optimal as we shall see). You could even try it on HF, and receive the signal remotely with a KiwiSDR. I’ve used a HackRF as a Tx for low level testing. After a few days of tuning and tweaking it works as advertised – I’m getting within 1dB of theory when tested over the bench at rates between 500 and 20000 bits/s. In the table below Minimum Detectable Signal (MDS) is defined as 10% PER, measured over 100 packets. I send the packets arranged as 10 “bursts” of 10 packets each, with a gap between bursts. This gives the acquisition a bit of a work out (burst operation is typically tougher than streaming): INFO BIT RATE (BITS/S)MODE
NF (DB)
EXPECTED MDS (DBM)
MEASURED MDS (DBM)
SI4464 MDS (DBM)
1000
4FSK
6
-132
-131
-123
10000
4FSK
6
-122
-120
-110
5000
2FSK
6
-123
-123
-113
The Si4464 is used as an example of a chipset implementation. The Rx sensitivity figures were extrapolated from the nearest bit rate on Table 3 of the Si4464 data sheet.
It’s hard to compare exactly as the Si4664 doesn’t have FEC. In fact it’s not possible to fully utilise the performance of high performance FEC codes on chipsets as they generally don’t have softdecision outputs.
FSK_LDPC can scale to any bit rate you like. The ratio of the sample rate to symbol rate Fs/Rs = 8000/1000 (8kHz, 1000 bits/s) is the same as Fs/Rs = 800000/100000 (800kHz, 100k bits/s), so it’s the same thing to the modem. I’ve tried FSK_LDPC between 5 and 40k bit/s sofar.
With a decent LNA in front of the RTLSDR, I measured MDS figures about 4dB lower at each bit rate. I used a rate 0.5 code for the tests to date, but other codes are available (thanks to Bill and the CMLlibrary!).
There are a few improvements I’d like to make. In some tests I’m not seeing the 2dB advantage 4FSK should be delivering. Syncronisation is trickier for 4FSK, as we have 4 tones, and the raw modem operating point is 2dB further down the Eb/No curve than 2FSK. I’d also like to add some GFSK style pulse shaping to make the Tx spectrum cleaner. I’m sure some testing over real world links will also show up a fewissues.
It’s fun building, then testing, tuning and pushing through one bug after another to build your very own physical layer! It’s a special sort of magic when the real world results start to approach what the theory says is possible.READING FURTHER
Open IP over UHF/VHF Part 1 and Part 2 – my first use case for the FSK_LDPC protocol described in this post.README_FSK
–
recently updated documentation on the Codec 2 FSK modem, includinglots of examples.
README_data
– new
documentation on Codec 2 data modes, including the FSK_LDPC mode described in this post. 4FSK on 25 Microwatts – Bill and I sending 4FSK signals across Adelaide, using an early GNU Octave simulation version of the FSK_LDPC mode described in this post. Bill’s LowSNR blog. Coded Modulation Library Overview– CML
is a wonderful library that we are using in Codec 2 for our LDPC work. Slide 56 tells us the theoretical mininum Eb/No for coded FSK (about 8dB for 2FSK and 6dB for 4FSK). 4FSK LLR Estimation Part 2 – GitHub PR used for development of the FSK_LDPC mode. Posted on October 20, 2020November 13, 2020Author david
Categories Radio
14 Comments on FSK LDPC Data Mode RTLSDR STRONG SIGNALS AND NOISE FIGURE I’ve been exploring the strong and weak signal performance of the RTLSDR. This all came about after Bill and I performed some Over the Air tests using the RTLSDR. We found that if we turned the gain all the way up, lots of birdies and distortion appeared. However if we wind the gain back to improve strong signal performance, the Noise Figure (NF) increases, messing with our modem link budgets. Fortunately, there’s been a lot of work on the RTLSDR internals from the open source community. So I’ve had a fun couple of weeks drilling down into the RTLSDR drivers and experimenting. It’s been really interesting, and I’ve learnt a lot about the trade offs in SDR. For USD$22, the RTLSDR is a fine teaching/learning tool – and apretty good radio.
STRONG AND WEAK SIGNALS Here is a block diagram of the RTLSDR as I understand it: It’s a superhet, with an IF bandwidth of 2MHz or less. The IF is sampled by an 8-bit ADC that runs at 28 MHz. The down sampling (decimation) from 28MHz to 2MHz provides some “processing gain” which results in a respectable performance. One part I don’t really understand is the tracking BPF, but I gather it’s pretty broad, and has no impact on strong signals a few MHz away. There are a few ways for strong signals to cause spurious signals toappear:
* A -30dBm signal several MHz away will block the LNA/mixer analog stages at the input. For example a pager signal at 148.6MHz while you are listening to 144.5 MHz. This causes a few birdies to gradually appear, and some compression of your wanted signal. * A strong signal a few MHz away can be aliased into your passband, as the IF filter stop band attenuation is not particularly deep. * A -68dBm signal inside the IF bandwidth will overload the ADC, and the whole radio will fall in a heap. The levels quoted above are for maximum gain (-g 49), and are consistent with and . If you reduce the gain, the overload levels get higher, but so does your noise figure. You can sometimes work around the first two issues, e.g. if the birdies don’t happen to fall right on top of your signal they can be ignored. So the first two effects – while unfortunate – tend to be more benign than ADCoverload.
At the weak signal end of the operating range, we are concerned about noise. Here is how I model the various noise contributions: The idea of a radio is to use the tuner to remove the narrow band unwanted signals, leaving just your wanted signal. However noise tends to be evenly distributed in frequency, so we are stuck with any noise that is located in the bandwidth of our wanted signal. A common technique is to have enough gain before the ADC such that the signal being sampled is large compared to the ADC quantisation noise. That way we can ignore the noise contribution from the ADC. However with strong signals, we need to back off the gain to prevent overload. Now the ADC noise becomes significant, and the overall NF of the radio increases. Another way of looking at this – if the gain ahead of the ADC is small, we have a smaller signal hitting the ADC, which will toggle less bits of the ADC, resulting in coarse quantisation (more quantisation noise) from the ADC. The final decimation stage reduces ADC quantisation noise. This figure shows our received signal (a single frequency spike), and the ADC quantisation noise (continuous line, with energy at every frequency): The noise power is the sum of all the noise in our bandwidth of interest. The decimation filter limits this bandwidth, removing most of the noise except for the small band near our wanted signal (shaded blue area). So the total noise power is summed over a smaller bandwidth, noise power is reduced and our SNR goes up. This means that despite just being 8 bits, the ADC performs reasonably well. OFF AIR STRONG SIGNALS Here is what my spectrum analyser sees when connected to my antenna. It’s 10MHz wide, centred on 147MHz. There are some strong pager signals that bounce around the -30dBm level, plus some weaker 2 metre band Ham signals between -80 and -100dBm. When I tune to 144.5MHz, that pager signal is outside the IF bandwidth, so I don’t get a complete breakdown of the radio. However it does cause some strong signal compression, and some birdies/aliased signals pop up. Here is a screen shot from gqrx when the pager signalis active:
In this plot, the signal right on 144.5 is my wanted signal, a weak signal I injected on the bench. The hump at 144.7 is an artefact of the pager signal, which due to strong signal compression just happens to to appear close to (but not on top of) my wanted signal. The wider hump is the IF filter. Here’s a closer look of the IF filter, set to 100kHz using the gqrx “Bandwidth” field: To see the IF filter shape I connected a terminated LNA to the input of the RTLSDR. This generates wideband noise that is amplified and can be used to visualise the filter shape. There has been some really cool recent work exploring the IF filtering capabilities of the R820T2 . I tried a few of the newly available IF filter configurations. My experience was the shape factor isn’t great (the filters roll off slowly), so the IF filters don’t have a huge impact on close-in strong signal performance. They do help with attenuating aliased signals. It was however a great learning and exploring experience, a real deepdive into SDR.
Gqrx is really cool for this sort of work. For example if you tune a strong signal from a signal generator either side of the IF passband, you can see aliases popping up and zooming across the screen. It’s also possible to link gqrx with different RTLSDR driver libraries, to explore their performance. I use the UDP output feature to send samples to my noise figure measuring tool.AIRSPY AND RTLSDR
The Airspy uses the same tuner chip so I tested it and found about the same strong signal results, i.e. it overloads at the same signal levels as the RTLSDR at max gain. Guess this is no surprise if it’s the same tuner. I once again measured the Airspy noise figure at about 7dB, slightly higher than the 6dB of the RTLSDR. This is consistent with other measurements , but quite a way from Airspy’s quoted figure (3.5dB). This is a good example of the high sample rate/decimation filter architecture in action – the 8-bit RTLSDR delivers a similar noise figure to the 12-bit Airspy. BUT THE RTLSDR NF PROBABLY DOESN’T MATTER I’ve spent a few weeks spent peering into driver code, messing with inter-stage gains, hammering the little RTLSDR with strong RF signals, and optimising noise figures. However it might all be for naught! At both my home and Bills – external noise appears to dominate. On the 2M band (144.5MHz) we are measuring noise from our (omni) antennas about 20dB above thermal, e.g. -150dBm/Hz compared to the ideal thermal noise level of -174dBm/Hz. Dreaded EMI from all the high speed electronics in urban environments. EMI can look at lot like strong signal overload – at high gains all these lines pop up, just like ADC overload. If you reduce the gain a bit they drop down into the noise, although its a smooth reduction in level unlike ADC overload which is very abrubt. I guess we are seeing are harmonics of switching power supply signals or other nearby digital devices. Rather than an artefact of Rx overload, we are seeing a sensitive receiver detecting weak EMI signal right down near thenoise floor.
So this changes the equation – rather than optimising internal NF we need to ensure enough link margin to get over the ambient noise. An external LNA won’t help, and even a lossy coax run loss might not matter much, as the SNR is more or less set at the antenna. I’ve settled on the librtlsdr RTLSDR driver/library for my FSK modem experiments as it supports IF filter and inter-stage gain control. I also have a mash up called rtl_fsk.c where I integrate a FSK modem and some powerful LDPC codes, but that’s another story!READING FURTHER
Evaluation of SDR Boards V1.0 – A fantastic report on the performance of several SDRs. RTLSDR: driver extensions – a very interesting set of conference slides discussing recent work with the R820T2 by Hayati Aygun. Many useful links. librtlsdr fork of rtlsdr driver library that includes support for the IF filter configuration and individual gain stage control discussed in.
My fork of librtlsdr – used for NF measurements and rtl_fsk mash up development. Some Measurements on E4000 and R802T tuners – Detailed look at the tuner by HB9AJG. Fig 5 & 6 bucket curves show overload levels consistent with and my measurements. Measuring SDR Noise Figure in Real Time Posted on October 17, 2020October 17, 2020Author david
Categories Radio
2 Comments on RTLSDR Strong Signals and Noise FigurePLAYING WITH PAPR
The average power of a FreeDV signal is surprisingly hard to measure as the parallel carriers produce a waveform that has many peaks an troughs as the various carriers come in and out of phase with each other. Peter, VK3RV has been working on some interesting experiments to measure FreeDV power using calorimeters. His work got me thinking about FreeDV power and in particular ways to improve the Peak to Average Power Ratio (PAPR). I’ve messed with a simple clipper for FreeDV 700C in the past, but decided to take a more scientific approach and use some simulations to measure the effect of clipping on FreeDV PAPR and BER. As usual, asking a few questions blew up into a several week long project. The usual bugs and strange, too good to be true initial results until I started to get results that felt sensible. I’ve tested some of the ideas over the air (blowing up an attenuator along the way), and learnt a lot about PAPR and related subjects like Peak Envelope Power(PEP).
The goal of this work is to explore the effect of a clipper on the average power and ultimately the BER of a received FreeDV signal, given a transmitter with a fixed peak output power. CLIPPING TO REDUCE PAPR In normal operation we adjust our Tx drive so the peaks just trigger the ALC. This sets the average power at Ppeak – PAPR Watts, for example Pav = 100WPEP – 10dB = 10W average. The idea of the clipper is to chop the tops off the FreeDV waveform so the PAPR is decreased. We can then increase the Tx drive, and get a higher average power. For example if PAPR is reduced from 10 to 4dB, we get Pav = 100WPEP – 4dB – 40W. That’s 4x the average power output of the 10dB PAPR case – Woohoo! In the example below the 16 carrier waveform was clipped and the PAPR reduced from 10.5 to 4.5dB. The filtering applied after the clipper smooths out the transitions (and limits the bandwidth to somethingreasonable).
However it gets complicated. Clipping actually reduces the average power, as we’ve removed the high energy parts of the waveform. It also distorts the signal. Here is a scatter diagram of the signal before and after clipping: The effect looks like additive noise. Hmmm, and what happens on multipath channels, does the modem perform the same as for AWGN with clipped signals? Another question – how much clipping should weapply?
So I set about writing a simulation (papr_test.m)
and doing some experiments to increase my understanding of clippers, PAPR, and OFDM modem performance using typical FreeDV waveforms. I started out trying a few different compression methods such as different compander curves, but found that clipping plus a bandpass filter gives about the same result. So for simplicity I settled on clipping. Throughout this post many graphs are presented in terms of Eb/No – for the purpose of comparison just consider this the same thing as SNR . If the Eb/No goes up by 1dB, so does the SNR. Here’s a plot of PAPR versus the number of carriers, showing PAPR getting worse with the number of carriers used: Random data was used for each symbol. As the number of carriers increases, you start to get phases in carriers cancelling due to random alignment, reducing the big peaks. Behaivour with real world data may be different; if there are instances where the phases of all carriers are aligned there may be larger peaks. To define the amount of clipping I used an estimate of the PDF andCDF:
The PDF (or histogram) shows how likely a certain level is, and the CDF shows the cumulative PDF. High level samples are quite unlikely. The CDF shows us what proportion of samples are above and below a certain level. This CDF shows us that 80% of the samples have a level of less than 4, so only 20% of the samples are above 4. So a clip level of 0.8 means the clipper hard limits at a level of 4, which would affect the top 20% of the samples. A clip value of 0.6, would mean samples with a level of 2.7 and above are clipped. EFFECT OF CLIPPING ON BER Here are a bunch of curves that show the effect of clipping on and AWGN and multipath channel (roughly CCIR poor). A 16 carrier signal was used – typical of FreeDV waveforms. The clipping level and resulting PAPR is shown in the legend. I also threw in a Tx diversity curve – sending each symbol twice on double the carriers. This is the approach used on FreeDV 700C and tends to help a lot on multipathchannels.
As we clip the signal more and more, the BER performance gets worse (Eb/No x-axis) – but the PAPR is reduced so we can increase the average power, which improves the BER. I’ve tried to show the combined effect on the (peak Eb/No x-axis) curves which scales each curve according to it’s PAPR requirements. This shows the peak power required for a given BER. Lower is better.Take aways:
* The 0.8 and 0.6 clip levels work best on the peak Eb/No scale, ie when we combine effect of the hit on BER performance (bad) and PAPRimprovement (good).
* There is about 4dB improvement across a range of operating points. This is pretty signficant – similar to gains we get from Tx diversity or a good FEC code. * AWGN and Multipath improvements are similar – good. Sometimes you get an algorithm that works well on AWGN but falls in a heap on multipath channels, which are typically much tougher to push bitsthrough.
* I also tried 8 carrier waveforms, which produced results about 1dB better, as I guess fewer carriers have a lower PAPR to start with. * Non-linear techniques like clipping spread the energy infrequency.
* Filtering to constrain the frequency spread brings the PAPR up again. We can trade off PAPR with bandwidth: lower PAPR, morebandwidth.
* Non-linear technqiques will mess with QAM more. So we may hit a wall at high data rates. TESTING ON A REAL PA All these simulations are great, but how do they compare with operation on a real HF radio? I designed an experiment to find out. First, some definitions. The same FreeDV OFDM signal is represented in different ways as it winds it’s way through the FreeDV system: * Complex valued samples are used for much of the internal signalprocessing.
* Real valued samples at the interfaces, e.g. for getting samples in and out of a sound card and standard HF radio. * Analog baseband signals, e.g. voltage inside your radio. * Analog RF signals, e.g. at the output of your PA, and input to your receiver terminals. * An electromagnetic wave. It’s the same signal, as we can convert freely between the representations with no loss of fidelity, but it’s representation can change the way measures like PAPR work. This caused me some confusion – for example the PAPR of the real signal is about 3dB higher than the complex valued version! I’m still a bit fuzzy on this one, but have satisfied myself that the PAPR of the complex signal is the same as the PAPR of the RF signal – which is what wereally care about.
Another definition that I had to (re)study was Peak Envelope Power (PEP) – which is the peak power averaged over one or more carrier cycles. This is the RF equivalent to our “peak” in PAPR. When driven by any baseband input signal, it’s the maximum RF power of the radio, averaged over one or more carrier cycles. Signals such as speech and FreeDV waveforms will have occasional peaks that hit the PEP. A baseband sine wave driving the radio would generate a RF signal that sits at the PEP power continuously. Here is the experimental setup: The idea is to play canned files through the radio, and measure the average Tx power. It took me several attempts before my experiment gave sensible results. A key improvement was to make the peak power of each sampled signal the same. This means I don’t have to keep messing with the audio drive levels to ensure I have the same peak power. The samples are 16 bits, so I normalised each file such that the peak was at +/- 10000. Here is the RF power sampler:
It works pretty well on signals from my FT-817 and IC-7200, and will help prevent any more damage to RF test equipment. I used my RF sampler after my first attempt using a SMA barell attenuator resulted in it’s destruction when I accdentally put 5W into it! Suddenly it went from 30dB to 42dB attenuation. Oops. For all the experiments I am tuned to 7.175 MHz and have the FT-817 on it’s lowest power level of 0.5W. For my first experiment I played a 1000 Hz sine wave into the system, and measured the average power. I like to start with simple signals, something known that lets me check all the fiddly RF kit is actually working. After a few hours of messing about – I did indeed see 27dBm (0.5W) on my spec-an. So, for a signal with 0dB PAPR, we measure average power = PEP. Check. In my next experiment, I measured the effect of ALC on TX power. With the FT-817 on it’s lowest power setting (0.5W), I increased the drive until just before the ALC bars came on: Here is the relationship I found with output power:BARS
TX POWER
0
26.7
1
26.4
2
26.7
3
27.0
So the ALC really does clamp the power at the peak value. On to more complex FreeDV signals. Mesuring the average power OFDM/parallel tone signals proved much harder to measure on the spec-an. The power bounces around over a period of several seconds the ODFM waveform evolves which can derail many power measurement techniques. The time constant, or measurement window is important – we want to capture the total power over a few seconds and average the value. After several attempts and lots of head scratching I settled on the following spec-an settings: * 10s sweep time so the RBW filter is averging a lot of time varying power at each point in the sweep.* 100kHz span.
* RBW/VBW of 10 kHz so we capture all of the 1kHz wide OFDM signal in the RBW filter peak when averaging. * Power averaging over 5 samples. The two-tone signal was included to help me debug my spec-an settings, as it has a known (3dB) PAPR. Here is a table showing the results for several test signals, all of which have the same peak power:SAMPLE
DESCRIPTION
PAPR THEORY/SIM (DB)PAPR MESURED (DB)
sine1000
sine wave at 1000 Hz0
0
sine_800_1200
two tones at 800 and 1200Hz3
4
vanilla
700D test frames unclipped7.1
7
clip0.8
700D test frames clipped at 0.83.4
4
ve9qrp
700D with real speech payload data11
10.5
Click on the file name to listen to a 5 second sample of the sample. The lower PAPR (higher average power) signals sound louder – I guess our ears work on average power too! I kept the drive constant and the PEP/peak just happened to hit 26dBm. It’s not critical, as long as the drive (and hence peak level) is the same across all waveformstested.
Note the two tone “control” is 1dB off (4dB measured on a known 3dB PAPR signal), I’m not happy about that. This suggests a spec-an set up issue or limitation on my spec-an (e.g. the way it averagespower).
However the other signals line up OK to the simulated values, within about +/- 0.5dB, which suggests I’m on the right track with mysimulations.
The modulated 700D test frame signals were generated by the Octave ofdm_tx.m script, which reports the PAPR of the complex signal. The same test frame repeats continuously, which makes BER measurements convenient, but is slightly unrealistic. The PAPR was lower than the ve9qrp signal which has real speech payload data. Perhaps because the more random, real world payload data leads to occasional frames where the phase of the carriers align leading to large peaks. Another source of discrepancy is the non flat frequency filtering in the baseband audio/crystal filter path the signal has to flow through before it emerges as RF. The zero-span spec-an setting plots power over time, and is very useful for visualing PAPR. The first plot shows the power of our 1000 Hz sine signal (yellow), and the two tone test signal (purple): You can see how mixing just two signals modulates the power over time, the effect on PAPR, and how the average power is reduced. Next we have the ve9qrp signal (yellow), and our clip 0.8 signal (purple): It’s clear the clipped signal has a much higher average power. Note the random way the waveform power peaks and dips, as the various carriers come into phase. Note very few high power peaks in the ve9qrp signal – in this sample we don’t have any that hits +26dBm, as they are fairly rare. I found eye-balling the zero-span plots gave me similar values to non-zero span results in the table above, a good cross check.Take aways:
* Clipping is indeed improving our measured average power, but there are some discrepencies between the measured and PAPR values estimated from theory/simulation. * Using a SDR to receive the signal and measure PAPR using my own maths might be easier than fiddling with the spec-an and guessing at it’s internal algorithms. * PAPR is worse for real world signals (e.g. ve9qrp) than my canned test frames due to relatively rare alignments of the carrier phases. This might only happen once every few seconds, but significantly raises the PAPR, and hurts our average power. These occasional peaks might be triggering the ALC, pushing the average power down every time they occur. As they are rare, these peaks can be clipped with no impact on perceived speech quality. This is why I like the CDF/PDF method of setting thresholds, it lets us discard rare (low probability) outliers that might be hurting our average power. CONCLUSIONS AND FURTHER WORK The simulations suggest we can improve FreeDV by 4dB using the right clipper/filter combination. Initial tests over a real PA show we can indeed reduce PAPR in line with our simulations. This project has lead me down an interesting rabbit hole that has kept me busy for a few weeks! Just in case I haven’t had enough, some ideas for further work: * Align these clipping levels and filtering to FreeDV 700D (and possibly 2020). There is existing clipper and filter code but the thresholds were set by educated guess several years for 700C. * Currently each FreeDV waveform is scaled to have the same average power. This is the signal fed via the sound card to your Tx. Should the levels of each FreeDV waveform be adjusted to be the same peakvalue instead?
* Design an experiment to prove BER performance at a given SNR is improved by 4dB as suggested by these simulations. Currently all we have measured is the average power and PAPR – we haven’t actually verified the expected 4dB increase in performance (suggested by the BER simulations above) which is the real goal. * Try the experiments on a SDR Tx – they tend to get results closer to theory due to no crystal filters/baseband audio filtering. * Try the experiments on a 100WPEP Tx – I have ordered a dummy load to do that relatively safely. * Explore the effect of ALC on FreeDV signals and why we set the signals to “just tickle” the ALC. This is something I don’t really understand, but have just assumed is good practice based on other peoples experiences with parallel tone/OFDM modems and on-air FreeDV use. I can see how ALC would compress the amplitude of the OFDM waveform – which this blog post suggests might be a good thing! Perhaps it does so in an uncontrolled manner – as the curves above show the amount of compression is pretty important. “Just tickling the ALC” guarantees us a linear PA – so we can handle any needed compression/clipping carefully in the DSP. * Explore other ways of reducing PAPR. To peel away the layers of a complex problem is very satisfying. It always takes me several goes, improvements come as the bugs fall out one by one. Writing these blog posts oftens makes me sit back and say “huh?”, as I discover things that don’t make sense when I write them up. I guess that’s the review process in action.LINKS
Design for a RF Sampler I built, mine has a 46dB loss. Peak to Average Power Ratio for OFDM – Nice discussion of PAPR for OFDM signals from DSPlog. Posted on September 11, 2020September 16, 2020Author david
Categories Radio
5 Comments on Playing with PAPRPOSTS NAVIGATION
Page 1 Page 2 … Page 41Next page
Proudly powered by WordPressDetails
Copyright © 2024 ArchiveBay.com. All rights reserved. Terms of Use | Privacy Policy | DMCA | 2021 | Feedback | Advertising | RSS 2.0