Date   

Re: Ardop 1.0.4 AMSAT QO100 - Help

bjorn
 

Has there been any progress on ARDOP for satellite?


Re: Codec 2/FreeDV OFDM modem update

Rafael Diniz
 

This is great news, David, thanks!

Rafael

On 12/18/20 8:15 PM, David Rowe wrote:
Starting a new thread to provide an update:

1/ We now have three HF Data waveforms running in C, see "OFDM Raw Data
Modes" in
 https://github.com/drowe67/codec2/blob/master/README_data.md
<https://github.com/drowe67/codec2/blob/master/README_data.md,>

Next step is to tune these a little more, test over the air,  and add a
QAM16 waveform to get a payload bit rate of > 3000 bits/s @ 15dB SNR on
Multipath Poor.


2/ I've developed some waveforms that can handle fast fading, up to 4Hz
Doppler/5ms delay spread in simulated channels.  Currently being tested
on FreeDV voice modes, but same techniques usable for HF data.

3/ We're testing compression techniques for OFDM that gives us a Peak to
Average Power Ratio of about 4dB - comparable to single carrier systems
like Pactor 4.  I'm getting 40WRMS out of my 75W PEP radio.

- David

 

 


Codec 2/FreeDV OFDM modem update

David Rowe
 

Starting a new thread to provide an update:

1/ We now have three HF Data waveforms running in C, see "OFDM Raw Data Modes" in
 https://github.com/drowe67/codec2/blob/master/README_data.md

Next step is to tune these a little more, test over the air,  and add a QAM16 waveform to get a payload bit rate of > 3000 bits/s @ 15dB SNR on Multipath Poor.


2/ I've developed some waveforms that can handle fast fading, up to 4Hz Doppler/5ms delay spread in simulated channels.  Currently being tested on FreeDV voice modes, but same techniques usable for HF data.

3/ We're testing compression techniques for OFDM that gives us a Peak to Average Power Ratio of about 4dB - comparable to single carrier systems like Pactor 4.  I'm getting 40WRMS out of my 75W PEP radio.

- David

 

 


Re: FreeDV OFDM modem

Rafael Diniz
 

Rick, from where can I download the simulator code?

Thanks,
Rafael

On 11/25/20 11:30 AM, Rick Muething wrote:
Rafeal,All,

The HF simulator we developed (based on the Watterson model and is fully
open sourced including C++ code, schematics, mech drawings etc.) will be
featured in a future QEX issue. It is stand alone hardware (needing only
a +5 v USB power and audio connections ) and has very low latency (~3ms)
compared to software simulators...that can be important especially on
ARQ testing)  It is built to implement the CCIR/ITU 520 standard HF and
common VHF/UHF channels over a S:N range of -40 to +40 dB.

https://www.itu.int/dms_pubrec/itu-r/rec/f/R-REC-F.520-2-199203-W!!PDF-E.pdf


Here is a link to some details of the simulator and ARQ testing efforts
we recently did as part of the Beta testing of the Simulator.

https://winlink.org/content/ionos_simulator

The main goal of using this or some other simulator of course is to
provide a statistically repeatable simulation of a channel type.  This
allows going back and comparing results after changes are made or new
protocols developed.

73,

Rick Muething, KN6KB








Re: FreeDV OFDM modem

Rick Muething
 

Rafeal,All,

The HF simulator we developed (based on the Watterson model and is fully open sourced including C++ code, schematics, mech drawings etc.) will be featured in a future QEX issue. It is stand alone hardware (needing only a +5 v USB power and audio connections ) and has very low latency (~3ms) compared to software simulators...that can be important especially on ARQ testing)  It is built to implement the CCIR/ITU 520 standard HF and common VHF/UHF channels over a S:N range of -40 to +40 dB.

https://www.itu.int/dms_pubrec/itu-r/rec/f/R-REC-F.520-2-199203-W!!PDF-E.pdf

Here is a link to some details of the simulator and ARQ testing efforts we recently did as part of the Beta testing of the Simulator.

https://winlink.org/content/ionos_simulator

The main goal of using this or some other simulator of course is to provide a statistically repeatable simulation of a channel type.  This allows going back and comparing results after changes are made or new protocols developed.

73,

Rick Muething, KN6KB


Re: FreeDV OFDM modem

Rafael Diniz
 

Thanks David! Already noticed the "cohpsk_ch".

Rafael

On 11/23/20 9:04 PM, David Rowe wrote:
Re channel simulation models I use ITU-R F.1487 

There is a free open source GUI program called PathSim that is a very
neat implementation.  It's a Windows program but runs on Wine OK.

I also have C and Octave versions in codec2 which you will see if you
play with the code.

Rick is part of a team developing a real time channel simulator, however
I'm not sure what standard that is based on.

- David


Re: FreeDV OFDM modem

Rafael Diniz
 

Hi David,

Thanks for the recommendation. I'll work to make a set up here to test
the waveforms and record everything with as much details I can get. It
will be mostly on 40m band, different times of day/night.

Thanks,
Rafael

On 11/23/20 8:14 PM, David Rowe wrote:
Hi Rafeal,

Feel free to play with those modes in C or Octave form, the PRs links
were posted previously.  You might be able to post any questions on
using them directly to the PRs.

UW means Unique Word - a discussion of UWs and how to choose them here
http://www.rowetel.com/?p=7467 <http://www.rowetel.com/?p=7467>;

Re feedback. My experience with FreeDV has been that anecdotal feedback
is difficult to use for development.  For example I get this sort of
thing all the time: "FreeDV doesn't work".  Or "On 23 Dec while using it
with my friends in the UK we had poor audio". The problem with this sort
of feedback is I have no way of reproducing the problem.

Recorded files of off-air received audio is very useful - as I can play
the exact same signal through the demodulator at my end.  Even better
are automated tests that send modem signals over a channel and capture
the results.  If this is repeated say every hour we can gather a sample
of real world HF channels over time, and the modems performance against
those channels.  This can help trap any corners cases the HF channel
simulations missed.

automated testing might be something you (or other list members) can
help with - it's basically scripting: play an audio file into a SSB Tx,
record output from remote SDR via the web.  Publish Rx file on a web
server. Repeat.

Thanks,
David


Ardop call and respone timing

Bradley Glen
 

Good day 

Concern when I compare ARDOP to other modes for HF  , the call and ack responses appear to be slighly delayed .at times .
 Can anyone confirm the modes timing for various conditions or point me to the correct document to read .

Thanks 

Bradley Glen
ZS5BG


Re: FreeDV OFDM modem

David Rowe
 

Re channel simulation models I use ITU-R F.1487 

There is a free open source GUI program called PathSim that is a very neat implementation.  It's a Windows program but runs on Wine OK.

I also have C and Octave versions in codec2 which you will see if you play with the code.

Rick is part of a team developing a real time channel simulator, however I'm not sure what standard that is based on.

- David


Re: FreeDV OFDM modem

David Rowe
 

Hi Rafeal,

Feel free to play with those modes in C or Octave form, the PRs links were posted previously.  You might be able to post any questions on using them directly to the PRs.

UW means Unique Word - a discussion of UWs and how to choose them here http://www.rowetel.com/?p=7467

Re feedback. My experience with FreeDV has been that anecdotal feedback is difficult to use for development.  For example I get this sort of thing all the time: "FreeDV doesn't work".  Or "On 23 Dec while using it with my friends in the UK we had poor audio". The problem with this sort of feedback is I have no way of reproducing the problem.

Recorded files of off-air received audio is very useful - as I can play the exact same signal through the demodulator at my end.  Even better are automated tests that send modem signals over a channel and capture the results.  If this is repeated say every hour we can gather a sample of real world HF channels over time, and the modems performance against those channels.  This can help trap any corners cases the HF channel simulations missed.

automated testing might be something you (or other list members) can help with - it's basically scripting: play an audio file into a SSB Tx, record output from remote SDR via the web.  Publish Rx file on a web server. Repeat.

Thanks,
David


Re: FreeDV OFDM modem

Rafael Diniz
 

Hi David,

Thanks a lot! So we should start playing with the datac1/datac2/datac3
modes, right? Should we just apply the pull request in a local branch
and play with it, or use a specific branch?

Two questions: what "UW" means, and which standard should I look for HF
the channel definitions?

I have now a colleague 630km from home which is carrying on air tests
with me. I can help giving feedback on the waveforms.

Cheers,
Rafael

On 11/21/20 4:22 PM, David Rowe wrote:
I'll use this opportunity jot down my development plans in this area:

There are a couple of open PRs in the codec2 repo on HF data that show
roughly where I'm at (Nov 2020):

https://github.com/drowe67/codec2/pull/142
https://github.com/drowe67/codec2/pull/130

So several new HF data "waveforms" in development that, are a bit like
UDP. You Tx frames and will Rx some of them at the other side of the
link. So far I've put about 2 months of development time into them,
which some kind help from other Codec 2 developers (Bill and Steve).
Initial tests show promising results over real HF channels:

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

They have also been carefully simulated over a variety of HF channels.

My next steps are to get the new waveforms hooked up to the FreeDV raw
data API. I've recently done some similar work for a FSK/LDPC waveform
that I'm using for VHF/UHF work and might use similar framing:

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

I will then test and tune the new waveforms over the air using some
automated tests from my QTH and remote KiwiSDRs up to 3000km away. I've
used these SDRs in the past for FreeDV testing.

Above that is the ARQ, TNC, and applications layers. I do not plan to
work on these at this time.

These could be written in any language, e.g. some guys wrote (in one
weekend!) a KISS TNC in python that talks to the FreeDV raw data API:

https://github.com/xssfox/freedv-tnc

They hooked it up to AX25 and did some toy demos of IP over an 800km HF
path with the current FreeDV raw data waveforms. It was really slow due
to the current waveforms/protocol but did demo several cool ideas, such
as using languages other than C to accelerate development and allow
non-C developers to use the low level waveforms.

- David

On 21/11/20 8:33 am, David Rowe wrote:
Hi Rick,

Yes I've noticed the wide range of encoding/modulation combinations
available. As a starting point I've currently developed 4 HF data
"waveforms" (my term for modem/FEC combination) that cover -5 to +15 dB
SNR. They overlap to some extent, so you don't need to gear shift
immediately.

However like ARQ this is not an area I have experience in, so welcome
your guidance. I would suggest that as a starting point we keep it
basic, and get _something_ going at a few SNR levels only.

My comment was regarding the slope of the PER versus Eb/No curve for
multipath channels. Compared to say coded AWGN, where a 3dB increase
means you can double your bit rate, and the slope is vertical.

A cheeky approximation I have for FreeDV is you can add as much power as
you like - the PER will be 10%! This refers to those multipath nulls
where the packets head down into the noise. However we can do better
now with longer frames that ride over fades and modern FEC.

Good point on the # of carriers. Trade off there with frequency
selective fading I guess, a small number of carriers means losing one
hurts more.

- David

On 21/11/20 6:57 am, Rick Muething wrote:
David,

Thanks for the feedback. I agree with many of your points and will look
more into your DV codec box.

One thing you mentioned that I think is much different with ARQ data
than Digital Voice: "The PER versus SNR curve is quite flat for HF
channels,"    For ARQ data there is usually a direct (but varying)
correlation between Energy/bit / Noise  (Eb/No) and most successful ARQ
data protocols include an automatic and wide range (sometimes 20-30:1)
of encoding/modulation to handle varying conditions. On a multipath poor
channel for example it is not that unusual to have slow long and deep
fades that require wide variations in encoding and transfer rates. 
Typical high performance protocols VARA, Pactor 3 and Pactor 4 have very
wide range of encoding.  These can be implemented by combinations of
changes in modulation 4FSK, 4PSK, 16 QAM etc and/or FEC code
puncturing.  The goal in a message system is to transfer the message
accurately (exactly!) as fast as the (usually changing) propagation path
and available power permits.  In many recent simulations it is easy to
observe throughput levels (net ARQ bits/sec) change over fairly wide4:1
to 10:1 range under the same HF multipath propagation channel.   Since
the number of active carriers has a direct impact on the Eb/No (with a
given peak power limit) the advantages of being able to use few/one
carriers reduces the Crest Factor and improves the Eb/No and hence
available channel capacity. 

David, again thanks for your inputs and contributions.  I look forward
to working on next generation protocols with you.

73,

Rick Muething, KN6KB


------------------------------------------------------------------------
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#501)
<https://ardop.groups.io/g/developers/message/501>; | Reply To Group
<mailto:developers@ardop.groups.io?subject=Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Reply To Sender
<mailto:david@rowetel.com?subject=Private:%20Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Mute This Topic <https://groups.io/mt/21211944/146082>; | New Topic
<https://ardop.groups.io/g/developers/post>;
Your Subscription
<https://ardop.groups.io/g/developers/editsub/146082>; | Contact Group
Owner <mailto:developers+owner@ardop.groups.io> | Unsubscribe
<https://ardop.groups.io/g/developers/leave/defanged>;
[rmuething@cfl.rr.com]





Re: FreeDV OFDM modem

David Rowe
 

I'll use this opportunity jot down my development plans in this area:

There are a couple of open PRs in the codec2 repo on HF data that show
roughly where I'm at (Nov 2020):

https://github.com/drowe67/codec2/pull/142
https://github.com/drowe67/codec2/pull/130

So several new HF data "waveforms" in development that, are a bit like
UDP. You Tx frames and will Rx some of them at the other side of the
link. So far I've put about 2 months of development time into them,
which some kind help from other Codec 2 developers (Bill and Steve).
Initial tests show promising results over real HF channels:

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

They have also been carefully simulated over a variety of HF channels.

My next steps are to get the new waveforms hooked up to the FreeDV raw
data API. I've recently done some similar work for a FSK/LDPC waveform
that I'm using for VHF/UHF work and might use similar framing:

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

I will then test and tune the new waveforms over the air using some
automated tests from my QTH and remote KiwiSDRs up to 3000km away. I've
used these SDRs in the past for FreeDV testing.

Above that is the ARQ, TNC, and applications layers. I do not plan to
work on these at this time.

These could be written in any language, e.g. some guys wrote (in one
weekend!) a KISS TNC in python that talks to the FreeDV raw data API:

https://github.com/xssfox/freedv-tnc

They hooked it up to AX25 and did some toy demos of IP over an 800km HF
path with the current FreeDV raw data waveforms. It was really slow due
to the current waveforms/protocol but did demo several cool ideas, such
as using languages other than C to accelerate development and allow
non-C developers to use the low level waveforms.

- David

On 21/11/20 8:33 am, David Rowe wrote:
Hi Rick,

Yes I've noticed the wide range of encoding/modulation combinations
available. As a starting point I've currently developed 4 HF data
"waveforms" (my term for modem/FEC combination) that cover -5 to +15 dB
SNR. They overlap to some extent, so you don't need to gear shift
immediately.

However like ARQ this is not an area I have experience in, so welcome
your guidance. I would suggest that as a starting point we keep it
basic, and get _something_ going at a few SNR levels only.

My comment was regarding the slope of the PER versus Eb/No curve for
multipath channels. Compared to say coded AWGN, where a 3dB increase
means you can double your bit rate, and the slope is vertical.

A cheeky approximation I have for FreeDV is you can add as much power as
you like - the PER will be 10%! This refers to those multipath nulls
where the packets head down into the noise. However we can do better
now with longer frames that ride over fades and modern FEC.

Good point on the # of carriers. Trade off there with frequency
selective fading I guess, a small number of carriers means losing one
hurts more.

- David

On 21/11/20 6:57 am, Rick Muething wrote:
David,

Thanks for the feedback. I agree with many of your points and will look
more into your DV codec box.

One thing you mentioned that I think is much different with ARQ data
than Digital Voice: "The PER versus SNR curve is quite flat for HF
channels,"    For ARQ data there is usually a direct (but varying)
correlation between Energy/bit / Noise  (Eb/No) and most successful ARQ
data protocols include an automatic and wide range (sometimes 20-30:1)
of encoding/modulation to handle varying conditions. On a multipath poor
channel for example it is not that unusual to have slow long and deep
fades that require wide variations in encoding and transfer rates. 
Typical high performance protocols VARA, Pactor 3 and Pactor 4 have very
wide range of encoding.  These can be implemented by combinations of
changes in modulation 4FSK, 4PSK, 16 QAM etc and/or FEC code
puncturing.  The goal in a message system is to transfer the message
accurately (exactly!) as fast as the (usually changing) propagation path
and available power permits.  In many recent simulations it is easy to
observe throughput levels (net ARQ bits/sec) change over fairly wide4:1
to 10:1 range under the same HF multipath propagation channel.   Since
the number of active carriers has a direct impact on the Eb/No (with a
given peak power limit) the advantages of being able to use few/one
carriers reduces the Crest Factor and improves the Eb/No and hence
available channel capacity. 

David, again thanks for your inputs and contributions.  I look forward
to working on next generation protocols with you.

73,

Rick Muething, KN6KB


------------------------------------------------------------------------
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#501)
<https://ardop.groups.io/g/developers/message/501>; | Reply To Group
<mailto:developers@ardop.groups.io?subject=Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Reply To Sender
<mailto:david@rowetel.com?subject=Private:%20Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Mute This Topic <https://groups.io/mt/21211944/146082>; | New Topic
<https://ardop.groups.io/g/developers/post>;
Your Subscription
<https://ardop.groups.io/g/developers/editsub/146082>; | Contact Group
Owner <mailto:developers+owner@ardop.groups.io> | Unsubscribe
<https://ardop.groups.io/g/developers/leave/defanged>;
[rmuething@cfl.rr.com]


Re: FreeDV OFDM modem

David Rowe
 

Hi Rick,

Yes I've noticed the wide range of encoding/modulation combinations
available. As a starting point I've currently developed 4 HF data
"waveforms" (my term for modem/FEC combination) that cover -5 to +15 dB
SNR. They overlap to some extent, so you don't need to gear shift
immediately.

However like ARQ this is not an area I have experience in, so welcome
your guidance. I would suggest that as a starting point we keep it
basic, and get _something_ going at a few SNR levels only.

My comment was regarding the slope of the PER versus Eb/No curve for
multipath channels. Compared to say coded AWGN, where a 3dB increase
means you can double your bit rate, and the slope is vertical.

A cheeky approximation I have for FreeDV is you can add as much power as
you like - the PER will be 10%! This refers to those multipath nulls
where the packets head down into the noise. However we can do better
now with longer frames that ride over fades and modern FEC.

Good point on the # of carriers. Trade off there with frequency
selective fading I guess, a small number of carriers means losing one
hurts more.

- David

On 21/11/20 6:57 am, Rick Muething wrote:
David,

Thanks for the feedback. I agree with many of your points and will look
more into your DV codec box.

One thing you mentioned that I think is much different with ARQ data
than Digital Voice: "The PER versus SNR curve is quite flat for HF
channels,"    For ARQ data there is usually a direct (but varying)
correlation between Energy/bit / Noise  (Eb/No) and most successful ARQ
data protocols include an automatic and wide range (sometimes 20-30:1)
of encoding/modulation to handle varying conditions. On a multipath poor
channel for example it is not that unusual to have slow long and deep
fades that require wide variations in encoding and transfer rates. 
Typical high performance protocols VARA, Pactor 3 and Pactor 4 have very
wide range of encoding.  These can be implemented by combinations of
changes in modulation 4FSK, 4PSK, 16 QAM etc and/or FEC code
puncturing.  The goal in a message system is to transfer the message
accurately (exactly!) as fast as the (usually changing) propagation path
and available power permits.  In many recent simulations it is easy to
observe throughput levels (net ARQ bits/sec) change over fairly wide4:1
to 10:1 range under the same HF multipath propagation channel.   Since
the number of active carriers has a direct impact on the Eb/No (with a
given peak power limit) the advantages of being able to use few/one
carriers reduces the Crest Factor and improves the Eb/No and hence
available channel capacity. 

David, again thanks for your inputs and contributions.  I look forward
to working on next generation protocols with you.

73,

Rick Muething, KN6KB


------------------------------------------------------------------------
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#501)
<https://ardop.groups.io/g/developers/message/501>; | Reply To Group
<mailto:developers@ardop.groups.io?subject=Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Reply To Sender
<mailto:david@rowetel.com?subject=Private:%20Re:%20Re%3A%20%5Bardop_developers%5D%20FreeDV%20OFDM%20modem>
| Mute This Topic <https://groups.io/mt/21211944/146082>; | New Topic
<https://ardop.groups.io/g/developers/post>;
Your Subscription
<https://ardop.groups.io/g/developers/editsub/146082>; | Contact Group
Owner <mailto:developers+owner@ardop.groups.io> | Unsubscribe
<https://ardop.groups.io/g/developers/leave/defanged>;
[rmuething@cfl.rr.com]


Re: FreeDV OFDM modem

David Rowe
 

Hi Andrew,

Of course it is. But it's the kind of significant effort that we've
seen communities take on, and succeed, in other fields.
I've been doing open source development in the Ham field for 10 years.
I'll believe it when I see the code.
P3 (about 20 years old) to my
knowledge is NOT opens sourced...it is a SCS proprietary protocol that
is now surpassed by VARA.
Yes, we can do much better, and I've prototyped the lower layers already.

There are pros and cons there, but mostly it's a culture thing. You
can develop a spec in the open, as long as people agree that *someone*
gets to put a final seal on it. Then you get a reference
Actually this is pretty easy to solve. He or she who actually codes
sets the standard.

Aaaand.... I'm running a Flex over here. My PC already talks digital
audio directly to the radio, with no soundcard involved. If you gave
me a modem in a box with USB on the PC end and analog audio on the
radio end, that'd actually be adding a couple DACs and a couple ADCs
to my chain. Just saying. SDRs aren't going to become *less* popular.
This is a good point. RIP non-SDR in a few years. Everything I release
in FreeDV starts off as a C library (the FreeDV API). Some people
integrate that straight into their SDR.

So we need a way to handle variable latency.

- David


Re: FreeDV OFDM modem

Rick Muething
 

David,

Thanks for the feedback. I agree with many of your points and will look more into your DV codec box.

One thing you mentioned that I think is much different with ARQ data than Digital Voice: "The PER versus SNR curve is quite flat for HF channels,"    For ARQ data there is usually a direct (but varying) correlation between Energy/bit / Noise  (Eb/No) and most successful ARQ data protocols include an automatic and wide range (sometimes 20-30:1) of encoding/modulation to handle varying conditions. On a multipath poor channel for example it is not that unusual to have slow long and deep fades that require wide variations in encoding and transfer rates.  Typical high performance protocols VARA, Pactor 3 and Pactor 4 have very wide range of encoding.  These can be implemented by combinations of changes in modulation 4FSK, 4PSK, 16 QAM etc and/or FEC code puncturing.  The goal in a message system is to transfer the message accurately (exactly!) as fast as the (usually changing) propagation path and available power permits.  In many recent simulations it is easy to observe throughput levels (net ARQ bits/sec) change over fairly wide4:1 to 10:1 range under the same HF multipath propagation channel.   Since the number of active carriers has a direct impact on the Eb/No (with a given peak power limit) the advantages of being able to use few/one carriers reduces the Crest Factor and improves the Eb/No and hence available channel capacity. 

David, again thanks for your inputs and contributions.  I look forward to working on next generation protocols with you.

73,

Rick Muething, KN6KB



Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#501) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rmuething@...]

_._,_._,_


Re: FreeDV OFDM modem

Andrew Rodland
 

On Fri, Nov 20, 2020 at 2:25 PM Rick Muething <rmuething@cfl.rr.com> wrote:

Andrew,

Designing AND MAINTAINING a protocol is a significant effort even if you
have a strong background in communications and programming.
Of course it is. But it's the kind of significant effort that we've
seen communities take on, and succeed, in other fields.

VARA is now
available at a very reasonable price (I know it is not on all OS) but it
has quite respectable performance.
Yes, it does, but being Windows-only makes it 100% useless for quite a
few people, and having *one guy in the universe* who knows the secret
sauce isn't very encouraging either.

P3 (about 20 years old) to my
knowledge is NOT opens sourced...it is a SCS proprietary protocol that
is now surpassed by VARA.
I'm aware that it's not, I'm saying that P3 is pretty much the minimum
benchmark that a community-built modem should meet to be taken
seriously. Naturally, I would be happy with something even faster.

But P4 (where legally allowed...read in most
of the known world EXCEPT the US!!!) has twice the measured throughput
as VARA but about 80% of the bandwidth. It is the result of MANY
manyears of continued development by SCS but it is expensive.

Part of the challenge of doing an Open source protocol in addition to
the design, optimization and extensive testing required is trying to
manage and maintain splinter variations. A protocol really must be very
well documented, stable and standardized ...so that variations can talk
to each other.....but open source makes that more difficult or sometimes
impossible.
There are pros and cons there, but mostly it's a culture thing. You
can develop a spec in the open, as long as people agree that *someone*
gets to put a final seal on it. Then you get a reference
implementation. Then maybe you get multiple/competing implementations,
and there you need someone to stand on people a little bit, to say
"either conform with the spec, or else make it clear that you're doing
your own thing and you're not compatible". A total free-for-all does
lead to failure, but again, there are models for how to do it right in
the open-source world.

With today's high performance and low cost DSP/High performance MPUs it
is often easier to design and support if instead of trying to implement
the DSP part of the protocol on native Windows, Mac OS,or Linux ...all
non-real-time OS) to just implement the entire protocol in a "Signalink
type" box (but with the protocol processing) that uses a standard and
universal USB and audio interfaces
Not arguing with that, but there are trade-offs, and one of them is
barrier to entry. If someone wanted to develop a codec with the
intention that the gold-standard implementation would be on an FPGA, I
could totally see that, and the latency benefit would be obvious. But
modern CPUs have more than enough power to do the job reasonably, and
VARA is proof of that much.

Aaaand.... I'm running a Flex over here. My PC already talks digital
audio directly to the radio, with no soundcard involved. If you gave
me a modem in a box with USB on the PC end and analog audio on the
radio end, that'd actually be adding a couple DACs and a couple ADCs
to my chain. Just saying. SDRs aren't going to become *less* popular.

Andrew


Re: FreeDV OFDM modem

David Rowe
 

Designing AND MAINTAINING a protocol is a significant effort even if you
have a strong background in communications and programming. 
Yup. People who will consistently volunteer effort into maintenance of
open source projects over time are very rare.

With today's high performance and low cost DSP/High performance MPUs it
is often easier to design and support if instead of trying to implement
the DSP part of the protocol on native Windows, Mac OS,or  Linux ...all
non-real-time OS) to just implement the entire protocol in a "Signalink
type" box (but with the protocol processing) that uses a standard and
universal USB and audio interfaces
I have just such a box:

http://www.rowetel.com/?page_id=3902

It's running the FreeDV OFDM/LDPC waveforms on HF already, although not
sure how it would go with larger block size/codes due to memory.

- David


Re: FreeDV OFDM modem

David Rowe
 

Thanks Rick - the effect of latency on ARQ efficiency is a new one for me.  I will ponder that. For FreeDV I've had several fights with sound cards.  I can see how a generic soft modem that runs across a range of operating systems and radios would complicate that issue.

I've always considered PTT digital voice to be more sensitive to latency that data. I'm actually enjoying being able to use longer block sizes for HF data and get better fading channel performance.

I have recently been experimenting with OFDM modems and PAPR/Crest factor: http://www.rowetel.com/?p=7382

I've had advice from the FreeDV/codec2 community that running radios at high average powers is fine, e.g. RTTY/PSK31 have high crest factors.  Haven't tried it myself as the FreeDV OFDM waveforms have low average power as your pointed out.  These OFDM waveforms also work fine on real world HF data and can deliver error free data despite the crest factor - so I don't see this as a show stopper.  The PER versus SNR curve is quite flat for HF channels, so a few dB less average power is not a big deal.

I'm sure the latency/ARQ issue is solvable - as other people are solving it.

I don't feel the modem/FEC is secondary - there is a lack of quality high performance, well tested modems and FEC in open source - especially for HF.  But agree there are challenges at all levels.  I have recently developed several waveforms for HF data and tested them over simulated and real channels, see earlier in this thread.

Biggest problem I have encountered with FreeDV development is not technical but "human factors".  Everyone talks about what should be done but very few will step up and actually write code.

- David


Re: FreeDV OFDM modem

Rick Muething
 

Andrew,

Designing AND MAINTAINING a protocol is a significant effort even if you have a strong background in communications and programming.  VARA is now available at a very reasonable price (I know it is not on all OS) but it has quite respectable performance.  P3 (about 20 years old) to my knowledge is NOT opens sourced...it is a SCS proprietary protocol that is now surpassed by VARA. But P4 (where legally allowed...read in most of the known world EXCEPT the US!!!) has twice the measured throughput as VARA but about 80% of the bandwidth.  It is the result of MANY manyears of continued development by SCS but it is expensive.

Part of the challenge of doing an Open source protocol in addition to the design, optimization and extensive testing required is trying to manage and maintain splinter variations.  A protocol really must be very well documented, stable and standardized ...so that  variations can talk to each other.....but open source makes that more difficult or sometimes impossible.

With today's high performance and low cost DSP/High performance MPUs it is often easier to design and support if instead of trying to implement the DSP part of the protocol on native Windows, Mac OS,or  Linux ...all non-real-time OS) to just implement the entire protocol in a "Signalink type" box (but with the protocol processing) that uses a standard and universal USB and audio interfaces

73,

Rick Muething KN6KB

On 11/20/2020 1:18 PM, Andrew Rodland wrote:
I'm not much use with DSP (I'm a respectable dev, but not in that
field) but I do just want to cheer on the effort. As much as I do
appreciate the effort that's gone into ARDOP, I think it's a bit of an
embarrassment to amateur radio that the best free and cross-platform
HF modem still runs such a *distant* third place behind PACTOR and
VARA. The principles are out there, it seems like a concerted
engineering effort should be able to do the job.

If we could reach something like P3's performance, "it's a bit slower
but it's open-source and it runs on anything" would hold water in a
community that's supposed to be about experimentation and openness —
but a modem that's only 10% as fast as the competition under
real-world conditions is hard to defend to anyone but the hard-core.

My two cents,

Andrew KC2G




Re: FreeDV OFDM modem

Andrew Rodland
 

I'm not much use with DSP (I'm a respectable dev, but not in that
field) but I do just want to cheer on the effort. As much as I do
appreciate the effort that's gone into ARDOP, I think it's a bit of an
embarrassment to amateur radio that the best free and cross-platform
HF modem still runs such a *distant* third place behind PACTOR and
VARA. The principles are out there, it seems like a concerted
engineering effort should be able to do the job.

If we could reach something like P3's performance, "it's a bit slower
but it's open-source and it runs on anything" would hold water in a
community that's supposed to be about experimentation and openness —
but a modem that's only 10% as fast as the competition under
real-world conditions is hard to defend to anyone but the hard-core.

My two cents,

Andrew KC2G

1 - 20 of 516