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

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

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

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

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

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

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

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

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

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

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

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

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

David,

As I'm working with short data blocks (19 to 80 chars, around 216 symbols
and 4.5 seconds) I use Reed Solomon FEC, and although I use coherent
demodulation I don't think I need the overhead of pilot symbols on such
short packets. This is the fundamental difference between data and voice
modems which need to hold sync for long periods of time and can't use ARQ if
the FEC fails. Tuning, sync and phase tracking is achieved using the normal
ardop method. Of course it may turn out I'm wrong!

73,
John

-----Original Message-----
From: developers@ardop.groups.io [mailto:developers@ardop.groups.io] On
Behalf Of David Rowe
Sent: 17 July 2018 08:42
To: developers@ardop.groups.io
Subject: Re: [ardop_developers] FreeDV OFDM modem

Nice work John. Did you keep:

i) The pilot symbol based coherent demodulation?
ii) the LDPC FEC code?

Both are worth many dB.

Cheers,

David

On 17/07/18 16:47, John Wiseman wrote:

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

Hi John,

1/ LDPC codes are much (several dB) better than RS - we can help you
design suitable LDPC codes for your frames if you like. Like Turbo
codes - they approach the Shannon limit in performance.

Key difference between a data modem is that with FreeDV we don't have
ARQ. It's PTT speech so we want low latency, as we don't mind so much
if packet is lost for voice. We also let packets with bit errors
through to the voice decoder as some speech is better than none,
especially at very low SNRs. As speech is PTT we also need to sync
quickly (a few 100ms), no training sequences.

Recently with FreeDV 700D, we can operate at SNRs lower than SSB.

2/ The FreeDV 700D modem frames are 160ms, much shorter than 4.5
seconds. Plot symbols were required to track phase and amplitude
through rapidly changing HF channels.

My understanding from earlier discussions with Rick M was you use
differential detection, however that was many years ago now.

How do you perform phase estimation on the rapidly evolving HF channel
without pilot symbols?

3/ Can you point me at the source code please? Sorry of I missed
something but I can't seem to find a Git or SVN repo for the project.
What license is the ARDOP code?

Thanks,

David

On 18/07/18 04:45, John Wiseman wrote:

David,

As I'm working with short data blocks (19 to 80 chars, around 216 symbols
and 4.5 seconds) I use Reed Solomon FEC, and although I use coherent
demodulation I don't think I need the overhead of pilot symbols on such
short packets. This is the fundamental difference between data and voice
modems which need to hold sync for long periods of time and can't use ARQ if
the FEC fails. Tuning, sync and phase tracking is achieved using the normal
ardop method. Of course it may turn out I'm wrong!

73,
John

-----Original Message-----
From: developers@ardop.groups.io [mailto:developers@ardop.groups.io] On
Behalf Of David Rowe
Sent: 17 July 2018 08:42
To: developers@ardop.groups.io
Subject: Re: [ardop_developers] FreeDV OFDM modem

Nice work John. Did you keep:

i) The pilot symbol based coherent demodulation?
ii) the LDPC FEC code?

Both are worth many dB.

Cheers,

David

On 17/07/18 16:47, John Wiseman wrote:

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

Hi John,

1/ LDPC codes are much (several dB) better than RS - we can help you
design suitable LDPC codes for your frames if you like. Like Turbo
codes - they approach the Shannon limit in performance.

Key difference between a data modem is that with FreeDV we don't have
ARQ. It's PTT speech so we want low latency, as we don't mind so much
if packet is lost for voice. We also let packets with bit errors
through to the voice decoder as some speech is better than none,
especially at very low SNRs. As speech is PTT we also need to sync
quickly (a few 100ms), no training sequences.

Recently with FreeDV 700D, we can operate at SNRs lower than SSB.

2/ The FreeDV 700D modem frames are 160ms, much shorter than 4.5
seconds. Plot symbols were required to track phase and amplitude
through rapidly changing HF channels.

My understanding from earlier discussions with Rick M was you use
differential detection, however that was many years ago now.

How do you perform phase estimation on the rapidly evolving HF channel
without pilot symbols?

3/ Can you point me at the source code please? Sorry of I missed
something but I can't seem to find a Git or SVN repo for the project.
What license is the ARDOP code?

Thanks,

David

On 18/07/18 04:45, John Wiseman wrote:

David,

As I'm working with short data blocks (19 to 80 chars, around 216 symbols
and 4.5 seconds) I use Reed Solomon FEC, and although I use coherent
demodulation I don't think I need the overhead of pilot symbols on such
short packets. This is the fundamental difference between data and voice
modems which need to hold sync for long periods of time and can't use ARQ

the FEC fails. Tuning, sync and phase tracking is achieved using the

ardop method. Of course it may turn out I'm wrong!

73,
John

-----Original Message-----
From: developers@ardop.groups.io [mailto:developers@ardop.groups.io] On
Behalf Of David Rowe
Sent: 17 July 2018 08:42
To: developers@ardop.groups.io
Subject: Re: [ardop_developers] FreeDV OFDM modem

Nice work John. Did you keep:

i) The pilot symbol based coherent demodulation?
ii) the LDPC FEC code?

Both are worth many dB.

Cheers,

David

On 17/07/18 16:47, John Wiseman wrote:

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

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

  http://www.rowetel.com/?p=6103

Happy to discuss the modem more if it is of interest.

Cheers,

David