Topics

R: [ardop_developers] FreeDV OFDM modem


Raffaello IZ0QWM
 

Hi John,

i can use the ardop port of my bpq gateway with this new mode if it can be usefull for testing purposes.

20 and 40m



Raffaello IZ0QWM


Inviato dallo smartphone Xperia di Sony



---- John Wiseman ha scritto ----

I've done quite a lot of work on OFDM over the last month or so. I got
David's modem working in a ARDOP environment, but the requirements of a
data modem are different from one suitable for voice, so in the end I
used his basic modulation parameters (data rate, carrier spacing and
cyclic prefix ) but the ARDOP framing structure and using the ARDOP DSP
code. I also adapted the parameters to suit the 12000 sample rate used
by ARDOP . I've implemented 500 and 2500 wide modes, using 9 or 43
carriers with 55.55 bit rate and carrier spacing, and 2PSK 4PSK 8PSK
16PSK and 16QAM modulation modes. I have limited facilities for testing,
but under ideal conditions it is  a little over 2.5 times a fast as
ARDOP 16qam or about 80% of VARA maximum rate. Testing under fairly
difficult (Northern latitude 80M NVIS) conditions in Finland has shown
it to be reasonably robust. Each carrier is acked separately so it can
operate with reduced throughput when error rates are relatively high.

The 500 mode allows it to be used in bands or band segments where only
narrow band data is permitted.

Data block length is a little under 5 seconds, giving potential
throughput for 2500 mode of

16OFDM 80 bytes/carrier, 3440 bytes per frame, approx 4600 BPS Net
 8OFDM 60 bytes/carrier, 2580 bytes per frame, approx 3440 BPS Net
 4OFDM 40 bytes/carrier, 1720 bytes per frame, approx 2300 BPS Net
 2OFDM 20 bytes/carrier,  860 bytes per frame, approx 1150 BPS Net

For comparison 16QAM.2500.100

120 bytes/carrier, 1200 bytes per frame, approx 2225 BPS Net

Code is available for Windows, Linux and the Teensy TNC. It is an
extension to ardop2, so is compatible with ardop2 stations.

If anyone is interested in helping with testing please get in touch. I'm
going to be away sailing for the next 2 - 3 weeks so although I'll have
access to email most of the time I'll have limited time to work on this
project for a while.

73,
John G8BPQ


On 09/06/2018 22:18, David Rowe wrote:
> Hi John,
>
> Sounds like a plan.  We use the gcc tool chain and although it
> supports debuggers, for one reason or another I don't use them much.
>
> Happy to help with the cross platform work, and look forward to seeing
> what can be done with the code.
>
> There are not to many Hams that can program, and the number who can do
> DSP and modems is even smaller.  Be great if we can work together on
> open source modems.
>
> Cheers,
>
> David
>
> On 09/06/18 16:34, John Wiseman wrote:
>> David,
>>
>> My aim is to target Linux and if possible ARM Cortex embedded
>> platforms such as the Teensy 3.6. I'm using Windows for initial
>> development as I'm much more familiar with the Windows development
>> environment. I tried using the original code with
>> Codeblocks, and though it would compile I couldn't get the debugger
>> to single step, or the winmm sound card interface library that I use
>> for ARDOP to work, and it was much slower than the MSDev IDE. So to
>> get started I modified ofdm.c. If/when I get a proof of concept
>> working I'll go back and get it working on Windows with the original
>> code.
>>
>> 73,
>> John
>>
>> On 08/06/2018 21:45, David Rowe wrote:
>>> Hi John,
>>>
>>> Sounds like a good plan for a way forward.
>>>
>>> However I have some concerns about Microsoft specific changes.
>>>
>>> Can we please work together to ensure the modem code remains cross
>>> platform?  While I understand your work is Microsoft-centric, with
>>> care it is possible to ensure the code compiles on many platforms. 
>>> We have done this for FreeDV - one set of code that compiles for
>>> Linux, Windows and OSX.  We can already compile this modem source
>>> for Windows - unmodified.
>>>
>>> If the code is "forked" with MS-specific changes it will be
>>> difficult for us to work together, share improvements and help each
>>> other. There is a lot of talent  in the Linux/open source community
>>> - this modem is just one example.
>>>
>>> The good news is it's not too hard to ensure the code remains cross
>>> platform - I am happy to help.  However it's something that is best
>>> designed in earlier, rather than later.
>>>
>>> It might be easier if we talk on the phone or Skype, pls email me
>>> directly for contact details.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On 08/06/18 23:21, John Wiseman wrote:
>>>> Thanks, David.
>>>>
>>>> I've got the mod and demod test program running on Windows. It took
>>>> a while, as the Microsoft compilers don't support complex addition
>>>> and multiplication, so I had to rewrite some of the code. As a
>>>> first test I think I'll just use your existing packet structure and
>>>> wrap it with ARDOP headers. Once that is working I'll have a look
>>>> at optimising it for data - the requirements for voice and data are
>>>> rather different. Ideally I'd like modes that work in 500 or 2500
>>>> bandwidth, and with the latter I should be able to get raw data
>>>> rates of around 4.5K with the existing encoding and perhaps twice
>>>> that with 16QAM. Even with a fair degree of FEC overhead that would
>>>> be pretty fast!
>>>>
>>>> I'll let you know how I get on.
>>>>
>>>> 73,
>>>> John
>>>>
>>>>
>>>>
>>>> On 05/06/2018 11:17, David Rowe wrote:
>>>>> Hi John,
>>>>>
>>>>> Couple of thoughts on the code, assuming you have checked out
>>>>> codec2-dev:
>>>>>
>>>>> 1/ ofdm_internal.h has a bunch of defines, these would best be
>>>>> converted to variables to accommodate different rates.  The big
>>>>> one is OFDM_NC, which is the number of carriers, e.g. OFDM_NC 34
>>>>> would give you a 34 carrier or 2 kHz wide waveform.
>>>>>
>>>>> OFDM_TCP set the cyclic prefix (currently 2ms), this could be
>>>>> longer, e.g. 3 or 4ms if you like, at a slight loss in AWGN
>>>>> channel performance (< 1dB).
>>>>>
>>>>> 2/ Acquisition is a bit different for your use case.  I have to
>>>>> worry about fast PTT-like sync from different transmitters with
>>>>> unknown frequency offsets which is very challenging. This will be
>>>>> easier for you use case, during a file transfer you'll already
>>>>> have freq offset, so will most likely get timing sync in the first
>>>>> modem frame.
>>>>>
>>>>> 3/ You would need different state machine logic, which would be
>>>>> part of the ARQ system I guess.
>>>>>
>>>>> 4/ It's currently 160ms modem frame, with 112 payload bits per
>>>>> frame, and a (224,112) LDPC code.  Possibly other codes could be
>>>>> used for high rates.  We need short frames as it's low-ish latency
>>>>> voice.  I have an optional interleaver of up to 16 frames that
>>>>> helps a lot on HF channels. We haven't used it much for voice,
>>>>> better suited to your application I think.
>>>>>
>>>>> 5/ The QAM code would drop in OK I think, we already have
>>>>> functions for BPSK/QPSK, and pilot symbols are already used for
>>>>> amplitude normalisation.  The QAM input mapping for the LDPC
>>>>> decoder would need some thought, it's set up for QPSK. However I
>>>>> know people who can advise how to do that.
>>>>>
>>>>> 6/ For an initial test you could just try sending a bunch of your
>>>>> data frames through the current, unmodified modem on a simulated
>>>>> channel and count how many checksums make it through and measure
>>>>> the through put.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>> On 05/06/18 17:20, John Wiseman wrote:
>>>>>> David,
>>>>>>
>>>>>> Thanks for the information. I'll have a look at the code and see
>>>>>> how easy it would be to adapt it for use for ARQ data modes. It
>>>>>> looks very interesting, and if it can be adapted to run with
>>>>>> different numbers of carriers to fit different bandwidths (for
>>>>>> example Region 1 limits data signals to 500 Hz on 30 Meters) then
>>>>>> that would be great. I'll let you know how I get on with it.
>>>>>>
>>>>>> 73,
>>>>>> John G8BPQ
>>>>>>
>>>>>>
>>>>>> On 04/06/2018 04:02, David Rowe wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> My name is David, VK5DGR, the primary developer of FreeDV and
>>>>>>> Codec 2. To further my digital voice work, I have developed a
>>>>>>> series of open source HF modems since 2012.
>>>>>>>
>>>>>>> The most recent OFDM modem sends 700 bits/s (5200 bytes/min) at
>>>>>>> -2dB SNR (AWGN) and +2dB (CCIR poor HF, 2ms path delay 1Hz
>>>>>>> Doppler) at a 10% packet error rate. It uses a powerful rate 1/2
>>>>>>> LDPC code.
>>>>>>>
>>>>>>> If I've done my sums right this seems to be about 4dB better
>>>>>>> than VARA over the same channels (2116, 989 bytes/min).
>>>>>>>
>>>>>>> However this modem is just a "data pump", as it's used for
>>>>>>> digital voice we don't have ARQ, so there will be some overhead
>>>>>>> for that.
>>>>>>>
>>>>>>> The modem is pretty modular and could fit into other
>>>>>>> applications like WINMOR.  Its currently configured for 700
>>>>>>> bit/s QPSK in a 1000 Hz RF bandwidth, but it would be reasonably
>>>>>>> straight forward to support other data rates and higher order QAM.
>>>>>>>
>>>>>>> The source code is open source (LGPL 2.1 license).
>>>>>>>
>>>>>>> Here is the README file for the modem, specs at the bottom:
>>>>>>>
>>>>>>> https://svn.code.sf.net/p/freetel/code/codec2-dev/README_ofdm.txt
>>>>>>>
>>>>>>> And FYI here is a blog post on the new FreeDV 700D mode, that
>>>>>>> employs the modem, and is outperforming SSB on low SNR HF channels:
>>>>>>>
>>>>>>>   http://www.rowetel.com/?p=6103
>>>>>>>
>>>>>>> Happy to discuss the modem more if it is of interest.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>