Date   

Re: VARA or Winmor station ?

W6IDS <w6ids@...>
 

Any BPQ gateway can have multiple protocols at the ready.

PACTOR

Winmor

VARA

The system responds to the protocol being used by the calling station.  Just monitor your transfer as it proceeds, or maybe look at the logs.

Trimode the same, though it isn't ready for VARA I believe.

Howard W6IDS

On 2/25/2018 10:21 AM, Andrew OBrien wrote:
FYI, on 40M today via VARA I sent 22005 bytes with 2860 Bpm  results

*** Messages sent: 1.  Total bytes sent: 22005,  Time: 07:41,  bytes/minute: 2860

Is there a station that will do both Winmor or VARA depending on what client the calling station is using ?  It would be interesting to compare the two under real conditions from my station. I don't recall getting close to 3000 bpm with Winmor in the past but perhaps I am mistaken.

Andy K3UK


Re: VARA please excuse my ignorance

John G8BPQ
 

At the moment VARA can operate in 3 modes:

Client, where Winlink Express connects to it via a local TCP connection and VARA connects out to a remote VARA system in Gateway or BPQ Mode. Winlink Express is configured to connect to a Telnet Winlink session.

Gateway, where VARA accepts incoming connections and passes them to a Winlink CMS via the Internet.

BPQ Link, where VARA works as a Modem to a BPQ32 Node. With this setup VARA can be used like any other modem connected to a BPQ32 Node, for Winlink connections, Peer to Peer mail forwarding etc.

Work is currently under way to support VARA in Winlink Express and RMS Trimode. I would expect that once that is done it could be used for peer to peer between Winlink Express systems, but I don't know that for sure.

73,
John G8BPQ


On 25/02/2018 14:34, kim campbell wrote:
1. Can VARA be used peer-peer
2. How is the VARA modem integrated with RMS express to utilize the Winlink system.

I am not a computer guru so I all ways struggle.73

Best
Kim W4OSS


Re: VARA or Winmor station ?

KC9SGV
 

Don't think so.
The server would also need two fully functional HF setups running a few kcs apart.
One server would like to grab the Signalink USB for both programs anyways.
We really need a Beta version of Trimode with all the new modes for this kind of testing.

Any thoughts, and I will try to set up some solution with what I have here ?

Bernie,
KC9SGV



On Feb 25, 2018, at 9:21 AM, Andrew OBrien <k3ukandy@...> wrote:

FYI, on 40M today via VARA I sent 22005 bytes with 2860 Bpm  results

*** Messages sent: 1.  Total bytes sent: 22005,  Time: 07:41,  bytes/minute: 2860

Is there a station that will do both Winmor or VARA depending on what client the calling station is using ?  It would be interesting to compare the two under real conditions from my station. I don't recall getting close to 3000 bpm with Winmor in the past but perhaps I am mistaken. 

Andy K3UK




VARA or Winmor station ?

Andrew OBrien
 

FYI, on 40M today via VARA I sent 22005 bytes with 2860 Bpm  results

*** Messages sent: 1.  Total bytes sent: 22005,  Time: 07:41,  bytes/minute: 2860

Is there a station that will do both Winmor or VARA depending on what client the calling station is using ?  It would be interesting to compare the two under real conditions from my station. I don't recall getting close to 3000 bpm with Winmor in the past but perhaps I am mistaken. 

Andy K3UK




VARA please excuse my ignorance

kim campbell <swamprabbit1951@...>
 

1. Can VARA be used peer-peer
2. How is the VARA modem integrated with RMS express to utilize the Winlink system.

I am not a computer guru so I all ways struggle.73

Best
Kim W4OSS


Re: Vara Vs. Pactor-III - Maximum Data Speed

Rick Muething
 

Tony,

Yes latency (delay through the simulator) is a factor.  Here is what I did to work up a solution.

I contacted the author of the Ionospheric Simulator Mike Keller DL6IAK and explained the issue of latency and its affect on ARQ modes. He wrote this code some time ago  but went in and was able to reduce the latency from over 1 second to about 100 ms or so and that seems to be sufficient (at least it worked testing ARDOP and VARA...I haven't tried Pactor yet....(might have to use the "long path" option in Pactor). 

I am out of town now and just using my laptop so can't set up or run any tests. You basically need an audio mixer to mix the two audio outputs (one from the Sending station, one from the receiving station) and send the mixer output to the simulator input (the sound card input of the computer).  The simulator output (computer's sound card output) is then fed to the sound input of the modems for both sending and receiving ends.  I can send you a copy of Mikes modified simulator if you contact me directly via email. It is only about 360K zipped. I would strongly recommend using a separate computer (e.g. laptop) for the simulator if you try and run everything (Simulator, sending station, receiving station) from one computer you will probably have timing issues.

You have to be careful with all this not to get confused with compression.  You want to look at the ACTUAL bytes transferred (AFTER compression if used ) . You also need to have a fairly sizeable file (at least 5 min or so for transfer).  This doesn't however test how fast a particular protocol adapts or level shifts which can be important as in some conditions net throughput is also dramatically affected how fast the protocol adapts to changing conditions which of course are always present in the real world.   You can however easily change the simulator parameters (delays, doppler, and S:N) easily during a session if desired.

73,

Rick KN6KB




On 2/23/2018 8:46 PM, Anthony Bombardiere wrote:
Rick:

I wasn't sure if data compression was independent of the protocol so thanks for clearing that up. It would be wonderful to have a path simulator capable of handling ARQ modes. But as Andy mentioned, the only ones I've worked with are software simulators which do not have that capability.

I suspect latency might be a problem with a software-based simulators, especially with Pactor modems that have fast Tx/Rx switching. I believe you've tested Pactor modems with a hardware simulator? Wonder if you could elaborate on that.

In the meantime, most of us can only run on-air comparisons taking the results with a BIG grain of salt.

Thanks Rick.

Tony -K2MO


On 2/23/2018 3:59 PM, Rick Muething wrote:

Tony,

First forget about compression mechanisms. The same compression mechanism will work with all protocols as long as the protocol can send true binary data (no special codes)  The amount of compression is highly dependent on the entropy of the source data.  In Winlink for example ALL protocols are sent using the standard FBB B1 compression mechanism (used since the 1980's) packaged in a B2 envelope that allows multiple files per message.  This is independent of protocol used.

The theoretical maximum data rate of a protocol itself doesn't mean much.....E.g. it is straightforward to develop a high throughput mode (e.g. 256QAM that sends one byte/symbol)l but unless the signal is strong and the propagation has minimal fading and minimal multpath it will not be usable in practice.  So the best way to compare modes or protocols is this:

1) Use a HF channel simulator that can model specific S:N across a 3 KHz bandswidth.  The simulator is statistically repeatable so allows measurements to be duplicated and confirmed INDEPENDENT of changing HF conditions. 

2) The simulator must be able to model the important standard channels used in HF propagation modeling. E.g.  Multipath quiet, multipath moderate, multipath severe.  These are well documented and used in industry.

3) Run a real ARQ connection using large blocks of typical data using ARQ sessions of at least 5 minutes duration. over the standard HF channels above at S:N (3KHz) levels of -5 to +20 dB.  Compute the NET (after all repeats, mode shifts etc) ARQ throughput.  Repeat the measurements using longer times if necessary until repeatable results (throughput vs channel type @ given S:N) is obtained.

On HF transmission it is rare to see channels much better than 10-15 dB S:N and multipath quiet.  More often we have signals of 0 to 5 dB S:N and multipath moderate or worse.  Real world performance prediction is to use these more typical conditions to evaluate and compare protocols.

I have a MSEE degree in Computer and Communications have been working with HF protocols now for over 20 years and have come to understand that casual over the air comparisons or comparing protocols based on just their specs alone is not usually productive and not repeatable.

VARA does look to be a promising protocol and newer high symbol rate modes like P4 and STANAG /Mil STD 188 variations can achieve high throughput in challenging conditions.  What we should be doing is pushing for using updated rules (like regulations by protocol bandwidth and not symbol rate/carrier)    which will encourage more DSP development for faster and more robust HF and VHF data transmissions.

73, Rick Muething, KN6KB



On 2/23/2018 3:02 PM, Anthony Bombardiere wrote:

 All:

I'm having difficulty discerning the maximum data rate for Pactor-3 and  Vara and I was wondering if the experts on the reflector could clarify?

According to the developer, Vara has a maximum, uncompressed data rate of 5,629 bps while Pactor-3 has a maximum uncompressed data rate of 2,722 bps. SCS says the maximum compressed data rate is 5,200 bps.

If my interpenetration is correct, then it appears that Vara is twice as fast as Pactor-3 at top speed. If one assumes each mode uses the same data compression technique, then Vara would still be twice as fast. 

Assuming this is true, it's quite and achievement. The question is how often Vara can achieve top-speed under average HF channel conditions. My guess is that the modem uses techniques to reduce PAPR, but it may be difficult to reach the required SNR to get near top speed very often.

Tony -K2MO





Re: Vara On-Air Test Video - High-Speed Transfer

Andrew OBrien
 

Good work Tony, interesting results.
Andy

On Sat, Feb 24, 2018 at 9:15 PM, Anthony Bombardiere <DXDX@...> wrote:
Andy:

I had the chance to test Vara via KB3PCY's 80 meter gateway this evening. As you'll see in the video, the signal maintained good SNR throughout the test. There was a fair amount of multi-path noted by the notches in the waterfall.

After a dozen test sessions, my impression is that the modem is quite fast, but it does take some time to ramp up to speed (even with good signal-to-noise ratios) so it doesn't shift "gears" nearly as fast as Pactor-3.

Having both modems here, I think it compares well with Pactor-3: it may even download files faster during Winlink sessions. However, I noticed that the total session time seems to be about the same when downloading the same files with above average SNR's.

The only way to tell if my observations are even close to being accurate would be to run each mode through a path simulator. I'm hoping Rick will take on that task. I'd do it, but I don't have a simulator capable of testing ARQ modes. Even if I did, I'd need to borrow another Pactor-3 modem : )

See Video: https://www.youtube.com/watch?v=3rivvZjgD3s

Tony -K2MO






Vara On-Air Test Video - High-Speed Transfer

Tony
 

Andy:

I had the chance to test Vara via KB3PCY's 80 meter gateway this evening. As you'll see in the video, the signal maintained good SNR throughout the test. There was a fair amount of multi-path noted by the notches in the waterfall.

After a dozen test sessions, my impression is that the modem is quite fast, but it does take some time to ramp up to speed (even with good signal-to-noise ratios) so it doesn't shift "gears" nearly as fast as Pactor-3.

Having both modems here, I think it compares well with Pactor-3: it may even download files faster during Winlink sessions. However, I noticed that the total session time seems to be about the same when downloading the same files with above average SNR's.

The only way to tell if my observations are even close to being accurate would be to run each mode through a path simulator. I'm hoping Rick will take on that task. I'd do it, but I don't have a simulator capable of testing ARQ modes. Even if I did, I'd need to borrow another Pactor-3 modem : )

See Video: https://www.youtube.com/watch?v=3rivvZjgD3s

Tony -K2MO


Re: Quick video of VARA in action today 40M.

KC9SGV
 

14467 bytes per minute...


On Feb 24, 2018, at 4:46 PM, KC9SGV <kc9sgv@...> wrote:

Good !
Winmor is a great mode !



On Feb 24, 2018, at 4:41 PM, Andrew OBrien <k3ukandy@...> wrote:

Just did a re-test amidst major RTTY QRM. .  Sent about 13000 file size and held the connection despite the QRM.  Transfer was around 1500 bps,   Will test further . Glad it held under heavy QRM, as Winmor would.
Andy 

On Sat, Feb 24, 2018 at 5:11 PM, KC9SGV <kc9sgv@...> wrote:
Retest, please 😀
KC9SGV
> On Feb 24, 2018, at 3:35 PM, Anthony Bombardiere <DXDX@...> wrote:
>
>> On 2/24/2018 4:24 PM, Andrew OBrien wrote:
>> Thanks Tony, new rig... did not catch that.  It was set to 1Khz ...
>> oops! Andy K3UK
>
> Been there, done that Andy!
>
> Tony -K2MO
>
>
>
>
>
>





Re: Quick video of VARA in action today 40M.

KC9SGV
 

Good !
Winmor is a great mode !



On Feb 24, 2018, at 4:41 PM, Andrew OBrien <k3ukandy@...> wrote:

Just did a re-test amidst major RTTY QRM. .  Sent about 13000 file size and held the connection despite the QRM.  Transfer was around 1500 bps,   Will test further . Glad it held under heavy QRM, as Winmor would.
Andy 

On Sat, Feb 24, 2018 at 5:11 PM, KC9SGV <kc9sgv@...> wrote:
Retest, please 😀
KC9SGV
> On Feb 24, 2018, at 3:35 PM, Anthony Bombardiere <DXDX@...> wrote:
>
>> On 2/24/2018 4:24 PM, Andrew OBrien wrote:
>> Thanks Tony, new rig... did not catch that.  It was set to 1Khz ...
>> oops! Andy K3UK
>
> Been there, done that Andy!
>
> Tony -K2MO
>
>
>
>
>
>





Re: Quick video of VARA in action today 40M.

Andrew OBrien
 

Just did a re-test amidst major RTTY QRM. .  Sent about 13000 file size and held the connection despite the QRM.  Transfer was around 1500 bps,   Will test further . Glad it held under heavy QRM, as Winmor would.
Andy 

On Sat, Feb 24, 2018 at 5:11 PM, KC9SGV <kc9sgv@...> wrote:
Retest, please 😀
KC9SGV
> On Feb 24, 2018, at 3:35 PM, Anthony Bombardiere <DXDX@...> wrote:
>
>> On 2/24/2018 4:24 PM, Andrew OBrien wrote:
>> Thanks Tony, new rig... did not catch that.  It was set to 1Khz ...
>> oops! Andy K3UK
>
> Been there, done that Andy!
>
> Tony -K2MO
>
>
>
>
>
>





Re: Quick video of VARA in action today 40M.

KC9SGV
 

Retest, please 😀
KC9SGV

On Feb 24, 2018, at 3:35 PM, Anthony Bombardiere <DXDX@...> wrote:

On 2/24/2018 4:24 PM, Andrew OBrien wrote:
Thanks Tony, new rig... did not catch that. It was set to 1Khz ...
oops! Andy K3UK
Been there, done that Andy!

Tony -K2MO






Re: Quick video of VARA in action today 40M.

Tony
 

On 2/24/2018 4:24 PM, Andrew OBrien wrote:
Thanks Tony, new rig... did not catch that.  It was set to 1Khz ...
oops! Andy K3UK
Been there, done that Andy!

Tony -K2MO


Re: Quick video of VARA in action today 40M.

Andrew OBrien
 

Thanks Tony, new rig... did not catch that.  It was set to 1Khz ... oops!

Andy K3UK

On Sat, Feb 24, 2018 at 4:22 PM, Anthony Bombardiere <DXDX@...> wrote:
Andy:

Looks like you have a narrow filter switched in? Incoming signal appears constricted in the waterfall. 

Tony -K2MO

On 2/24/2018 4:04 PM, Andrew OBrien wrote:
I strung up a bit of wire today to get on 40M and test VARA on KC9SGV gateway.  My antenna is only 15 foot off ground at the moment .  Here is the video https://youtu.be/JVIh8deMh_I  
Seems fine, I probably need to send longer files to give a real test.  path is 720 Km , 447 miles. On my transceiver KC9SGV was S9  and my power out was reading about 20 watts.
Andy K3UK




Re: Quick video of VARA in action today 40M.

Tony
 

Andy:

Looks like you have a narrow filter switched in? Incoming signal appears constricted in the waterfall. 

Tony -K2MO

On 2/24/2018 4:04 PM, Andrew OBrien wrote:
I strung up a bit of wire today to get on 40M and test VARA on KC9SGV gateway.  My antenna is only 15 foot off ground at the moment .  Here is the video https://youtu.be/JVIh8deMh_I  
Seems fine, I probably need to send longer files to give a real test.  path is 720 Km , 447 miles. On my transceiver KC9SGV was S9  and my power out was reading about 20 watts.
Andy K3UK



Quick video of VARA in action today 40M.

Andrew OBrien
 

I strung up a bit of wire today to get on 40M and test VARA on KC9SGV gateway.  My antenna is only 15 foot off ground at the moment .  Here is the video https://youtu.be/JVIh8deMh_I  
Seems fine, I probably need to send longer files to give a real test.  path is 720 Km , 447 miles. On my transceiver KC9SGV was S9  and my power out was reading about 20 watts.
Andy K3UK


Useful FT8 guide

Andrew OBrien
 


Re: Vara Vs. Pactor-III - Maximum Data Speed

Tony
 

Rick:

I wasn't sure if data compression was independent of the protocol so thanks for clearing that up. It would be wonderful to have a path simulator capable of handling ARQ modes. But as Andy mentioned, the only ones I've worked with are software simulators which do not have that capability.

I suspect latency might be a problem with a software-based simulators, especially with Pactor modems that have fast Tx/Rx switching. I believe you've tested Pactor modems with a hardware simulator? Wonder if you could elaborate on that.

In the meantime, most of us can only run on-air comparisons taking the results with a BIG grain of salt.

Thanks Rick.

Tony -K2MO


On 2/23/2018 3:59 PM, Rick Muething wrote:

Tony,

First forget about compression mechanisms. The same compression mechanism will work with all protocols as long as the protocol can send true binary data (no special codes)  The amount of compression is highly dependent on the entropy of the source data.  In Winlink for example ALL protocols are sent using the standard FBB B1 compression mechanism (used since the 1980's) packaged in a B2 envelope that allows multiple files per message.  This is independent of protocol used.

The theoretical maximum data rate of a protocol itself doesn't mean much.....E.g. it is straightforward to develop a high throughput mode (e.g. 256QAM that sends one byte/symbol)l but unless the signal is strong and the propagation has minimal fading and minimal multpath it will not be usable in practice.  So the best way to compare modes or protocols is this:

1) Use a HF channel simulator that can model specific S:N across a 3 KHz bandswidth.  The simulator is statistically repeatable so allows measurements to be duplicated and confirmed INDEPENDENT of changing HF conditions. 

2) The simulator must be able to model the important standard channels used in HF propagation modeling. E.g.  Multipath quiet, multipath moderate, multipath severe.  These are well documented and used in industry.

3) Run a real ARQ connection using large blocks of typical data using ARQ sessions of at least 5 minutes duration. over the standard HF channels above at S:N (3KHz) levels of -5 to +20 dB.  Compute the NET (after all repeats, mode shifts etc) ARQ throughput.  Repeat the measurements using longer times if necessary until repeatable results (throughput vs channel type @ given S:N) is obtained.

On HF transmission it is rare to see channels much better than 10-15 dB S:N and multipath quiet.  More often we have signals of 0 to 5 dB S:N and multipath moderate or worse.  Real world performance prediction is to use these more typical conditions to evaluate and compare protocols.

I have a MSEE degree in Computer and Communications have been working with HF protocols now for over 20 years and have come to understand that casual over the air comparisons or comparing protocols based on just their specs alone is not usually productive and not repeatable.

VARA does look to be a promising protocol and newer high symbol rate modes like P4 and STANAG /Mil STD 188 variations can achieve high throughput in challenging conditions.  What we should be doing is pushing for using updated rules (like regulations by protocol bandwidth and not symbol rate/carrier)    which will encourage more DSP development for faster and more robust HF and VHF data transmissions.

73, Rick Muething, KN6KB



On 2/23/2018 3:02 PM, Anthony Bombardiere wrote:

 All:

I'm having difficulty discerning the maximum data rate for Pactor-3 and  Vara and I was wondering if the experts on the reflector could clarify?

According to the developer, Vara has a maximum, uncompressed data rate of 5,629 bps while Pactor-3 has a maximum uncompressed data rate of 2,722 bps. SCS says the maximum compressed data rate is 5,200 bps.

If my interpenetration is correct, then it appears that Vara is twice as fast as Pactor-3 at top speed. If one assumes each mode uses the same data compression technique, then Vara would still be twice as fast. 

Assuming this is true, it's quite and achievement. The question is how often Vara can achieve top-speed under average HF channel conditions. My guess is that the modem uses techniques to reduce PAPR, but it may be difficult to reach the required SNR to get near top speed very often.

Tony -K2MO




Re: Vara Vs. Pactor-III - Maximum Data Speed

Andrew O'Brien
 

Thanks for the details Rick. Tony had good experience with path simulators , perhaps he will do one with VARA and PIII since he has access to both . 

In my limited experience with VARA , two connects to my station with around S1 to S2 signals  on 20M failed to hold . In the past Winmor has tenaciously held the connection in similar conditions , albeit with very low throughput. 

Andy K3UK 

On Feb 23, 2018, at 3:59 PM, Rick Muething <rmuething@...> wrote:

Tony,

First forget about compression mechanisms. The same compression mechanism will work with all protocols as long as the protocol can send true binary data (no special codes)  The amount of compression is highly dependent on the entropy of the source data.  In Winlink for example ALL protocols are sent using the standard FBB B1 compression mechanism (used since the 1980's) packaged in a B2 envelope that allows multiple files per message.  This is independent of protocol used.

The theoretical maximum data rate of a protocol itself doesn't mean much.....E.g. it is straightforward to develop a high throughput mode (e.g. 256QAM that sends one byte/symbol)l but unless the signal is strong and the propagation has minimal fading and minimal multpath it will not be usable in practice.  So the best way to compare modes or protocols is this:

1) Use a HF channel simulator that can model specific S:N across a 3 KHz bandswidth.  The simulator is statistically repeatable so allows measurements to be duplicated and confirmed INDEPENDENT of changing HF conditions. 

2) The simulator must be able to model the important standard channels used in HF propagation modeling. E.g.  Multipath quiet, multipath moderate, multipath severe.  These are well documented and used in industry.

3) Run a real ARQ connection using large blocks of typical data using ARQ sessions of at least 5 minutes duration. over the standard HF channels above at S:N (3KHz) levels of -5 to +20 dB.  Compute the NET (after all repeats, mode shifts etc) ARQ throughput.  Repeat the measurements using longer times if necessary until repeatable results (throughput vs channel type @ given S:N) is obtained.

On HF transmission it is rare to see channels much better than 10-15 dB S:N and multipath quiet.  More often we have signals of 0 to 5 dB S:N and multipath moderate or worse.  Real world performance prediction is to use these more typical conditions to evaluate and compare protocols.

I have a MSEE degree in Computer and Communications have been working with HF protocols now for over 20 years and have come to understand that casual over the air comparisons or comparing protocols based on just their specs alone is not usually productive and not repeatable.

VARA does look to be a promising protocol and newer high symbol rate modes like P4 and STANAG /Mil STD 188 variations can achieve high throughput in challenging conditions.  What we should be doing is pushing for using updated rules (like regulations by protocol bandwidth and not symbol rate/carrier)    which will encourage more DSP development for faster and more robust HF and VHF data transmissions.

73, Rick Muething, KN6KB



On 2/23/2018 3:02 PM, Anthony Bombardiere wrote:

 All:

I'm having difficulty discerning the maximum data rate for Pactor-3 and  Vara and I was wondering if the experts on the reflector could clarify?

According to the developer, Vara has a maximum, uncompressed data rate of 5,629 bps while Pactor-3 has a maximum uncompressed data rate of 2,722 bps. SCS says the maximum compressed data rate is 5,200 bps.

If my interpenetration is correct, then it appears that Vara is twice as fast as Pactor-3 at top speed. If one assumes each mode uses the same data compression technique, then Vara would still be twice as fast. 

Assuming this is true, it's quite and achievement. The question is how often Vara can achieve top-speed under average HF channel conditions. My guess is that the modem uses techniques to reduce PAPR, but it may be difficult to reach the required SNR to get near top speed very often.

Tony -K2MO



Re: Vara Vs. Pactor-III - Maximum Data Speed

Rick Muething
 

Tony,

First forget about compression mechanisms. The same compression mechanism will work with all protocols as long as the protocol can send true binary data (no special codes)  The amount of compression is highly dependent on the entropy of the source data.  In Winlink for example ALL protocols are sent using the standard FBB B1 compression mechanism (used since the 1980's) packaged in a B2 envelope that allows multiple files per message.  This is independent of protocol used.

The theoretical maximum data rate of a protocol itself doesn't mean much.....E.g. it is straightforward to develop a high throughput mode (e.g. 256QAM that sends one byte/symbol)l but unless the signal is strong and the propagation has minimal fading and minimal multpath it will not be usable in practice.  So the best way to compare modes or protocols is this:

1) Use a HF channel simulator that can model specific S:N across a 3 KHz bandswidth.  The simulator is statistically repeatable so allows measurements to be duplicated and confirmed INDEPENDENT of changing HF conditions. 

2) The simulator must be able to model the important standard channels used in HF propagation modeling. E.g.  Multipath quiet, multipath moderate, multipath severe.  These are well documented and used in industry.

3) Run a real ARQ connection using large blocks of typical data using ARQ sessions of at least 5 minutes duration. over the standard HF channels above at S:N (3KHz) levels of -5 to +20 dB.  Compute the NET (after all repeats, mode shifts etc) ARQ throughput.  Repeat the measurements using longer times if necessary until repeatable results (throughput vs channel type @ given S:N) is obtained.

On HF transmission it is rare to see channels much better than 10-15 dB S:N and multipath quiet.  More often we have signals of 0 to 5 dB S:N and multipath moderate or worse.  Real world performance prediction is to use these more typical conditions to evaluate and compare protocols.

I have a MSEE degree in Computer and Communications have been working with HF protocols now for over 20 years and have come to understand that casual over the air comparisons or comparing protocols based on just their specs alone is not usually productive and not repeatable.

VARA does look to be a promising protocol and newer high symbol rate modes like P4 and STANAG /Mil STD 188 variations can achieve high throughput in challenging conditions.  What we should be doing is pushing for using updated rules (like regulations by protocol bandwidth and not symbol rate/carrier)    which will encourage more DSP development for faster and more robust HF and VHF data transmissions.

73, Rick Muething, KN6KB



On 2/23/2018 3:02 PM, Anthony Bombardiere wrote:

 All:

I'm having difficulty discerning the maximum data rate for Pactor-3 and  Vara and I was wondering if the experts on the reflector could clarify?

According to the developer, Vara has a maximum, uncompressed data rate of 5,629 bps while Pactor-3 has a maximum uncompressed data rate of 2,722 bps. SCS says the maximum compressed data rate is 5,200 bps.

If my interpenetration is correct, then it appears that Vara is twice as fast as Pactor-3 at top speed. If one assumes each mode uses the same data compression technique, then Vara would still be twice as fast. 

Assuming this is true, it's quite and achievement. The question is how often Vara can achieve top-speed under average HF channel conditions. My guess is that the modem uses techniques to reduce PAPR, but it may be difficult to reach the required SNR to get near top speed very often.

Tony -K2MO


1461 - 1480 of 51793