Topics

[EXTERNAL] Re: [RaspberryPi-4-HamRadio] TNC-Pi Now Available


Zonker Harris
 

  I’ve been using 9600 for APRS in the SF Bay Area, documented here…

 

    http://d72aclues.pbworks.com/

 

Sadly, there is not much adoption, since I haven’t managed to find a way for 9600 users to hear local 144.39 stations, or vice-versa. We thought it could alleviate some of the local congestion, but never completed a gateway that filtered only for “nearby” stations to repeat to the “other” band.

 

         Best regards,

 

              N6UOW@...

 

 

From: RaspberryPi-4-HamRadio@groups.io <RaspberryPi-4-HamRadio@groups.io> On Behalf Of Mark Griffith via groups.io
Sent: Monday, October 19, 2020 12:33 PM
To: RaspberryPi-4-HamRadio@groups.io
Subject: [EXTERNAL] Re: [RaspberryPi-4-HamRadio] TNC-Pi Now Available

 

Yeah, it's not such a great deal.  I've been wondering if I should offer it as an option for pre-built PiGate systems.  Since nearly all of the packet users in the US are at 1200 baud, and all of the TNC-Pi9k6 boards that I send out are setup for 1200 baud, I wonder if the capability to go to 9600 baud is a pressing need.  Given that is also takes a radio that is designed to do that, it seems unlikely that 9600 baud will become a common mode in the US.

 

I have encouraged 9600 baud usage, but I have no idea if anyone is taking up the challenges to use the higher speed, given the requirements for a really good signal, which means much more attention needs to be made to antennas, betters radios, attention to RF in the shack, etc etc.  Since 9600 baud that is running without a lot of packet resends is faster than any of the other current modes, I'm surprised.

 

I guess it depends upon the usage.  9600 baud doesn't really achieve it's best usage until the size of the file to transfer gets fairly large (by RF standards), such as around 25k.  Smaller than that you only get a fairly few seconds faster file transfer than at 1200 baud, or no advantage at all.  So if sending fairly small email messages is the goal, 1200 baud may be as good as you'll get in nearly all cases.  Since the vast majority of packet RMS stations operate at 1200 baud, having a larger number of receiver stations is a definite advantage.

 

So perhaps I'll stop offering the 9k6 board unless it is a special request.  Still thinking in it.

 

Mark

KD0QYN

 

 

On Monday, October 19, 2020, 2:10:28 PM CDT, N5XMT <dacooley@...> wrote:

 

 

Wow. 80 bucks and it's not even the 9K6...

On Oct 19, 2020, at 09:39, John Hansen <john@...> wrote:

For those who have been patiently waiting for MFJ to begin to offer the TNC-Pi, it is now available here:

https://mfjenterprises.com/products/mfj-1270pi-pitnc-board?_pos=1&_sid=6fa95bcea&_ss=r

John W2FS


David Ranch
 


There is a reason why it hasn't been really adopted for APRS:  diminishing returns   Check out WB2OSZ's write up on this:

   https://github.com/wb2osz/direwolf/blob/dev/doc/Why-is-9600-only-twice-as-fast-as-1200.pdf


Basically, higher speed needs faster key-up and settling times which is just not available in HAM voice-grade FM radios.  Once upon a time, there were HAM data-grade radios from vendors like Tekk, SCS, which were more than an order of magnitude faster but all of those are essentially gone now.  Also remember that for an effective network, both sides of the link needs fast radios.

--David
KI6ZHD



On 10/19/2020 12:43 PM, Zonker Harris via groups.io wrote:

  I’ve been using 9600 for APRS in the SF Bay Area, documented here…

 

    http://d72aclues.pbworks.com/

 

Sadly, there is not much adoption, since I haven’t managed to find a way for 9600 users to hear local 144.39 stations, or vice-versa. We thought it could alleviate some of the local congestion, but never completed a gateway that filtered only for “nearby” stations to repeat to the “other” band.

 

         Best regards,

 

              N6UOW@...

 

 

From: RaspberryPi-4-HamRadio@groups.io <RaspberryPi-4-HamRadio@groups.io> On Behalf Of Mark Griffith via groups.io
Sent: Monday, October 19, 2020 12:33 PM
To: RaspberryPi-4-HamRadio@groups.io
Subject: [EXTERNAL] Re: [RaspberryPi-4-HamRadio] TNC-Pi Now Available

 

Yeah, it's not such a great deal.  I've been wondering if I should offer it as an option for pre-built PiGate systems.  Since nearly all of the packet users in the US are at 1200 baud, and all of the TNC-Pi9k6 boards that I send out are setup for 1200 baud, I wonder if the capability to go to 9600 baud is a pressing need.  Given that is also takes a radio that is designed to do that, it seems unlikely that 9600 baud will become a common mode in the US.

 

I have encouraged 9600 baud usage, but I have no idea if anyone is taking up the challenges to use the higher speed, given the requirements for a really good signal, which means much more attention needs to be made to antennas, betters radios, attention to RF in the shack, etc etc.  Since 9600 baud that is running without a lot of packet resends is faster than any of the other current modes, I'm surprised.

 

I guess it depends upon the usage.  9600 baud doesn't really achieve it's best usage until the size of the file to transfer gets fairly large (by RF standards), such as around 25k.  Smaller than that you only get a fairly few seconds faster file transfer than at 1200 baud, or no advantage at all.  So if sending fairly small email messages is the goal, 1200 baud may be as good as you'll get in nearly all cases.  Since the vast majority of packet RMS stations operate at 1200 baud, having a larger number of receiver stations is a definite advantage.

 

So perhaps I'll stop offering the 9k6 board unless it is a special request.  Still thinking in it.

 

Mark

KD0QYN

 

 

On Monday, October 19, 2020, 2:10:28 PM CDT, N5XMT <dacooley@...> wrote:

 

 

Wow. 80 bucks and it's not even the 9K6...

On Oct 19, 2020, at 09:39, John Hansen <john@...> wrote:

For those who have been patiently waiting for MFJ to begin to offer the TNC-Pi, it is now available here:

https://mfjenterprises.com/products/mfj-1270pi-pitnc-board?_pos=1&_sid=6fa95bcea&_ss=r

John W2FS



 

This is nuts.  We are using 1200,2400,4800 and 9600 on our local network using Raspberry PIs and NinoTNC.  NinoTNC does all 4 bit rates without reprogramming and costs $30.  You just have to pick good radios for the high speed stuff.  Tait TM8105 is great if you get the 2m model.  

Http://tarpn.net/d 



Tadd --- Sent from Planet X

On Oct 19, 2020, at 5:05 PM, David Ranch <rpi4hamradio-groupsio@...> wrote:


There is a reason why it hasn't been really adopted for APRS:  diminishing returns   Check out WB2OSZ's write up on this:

   https://github.com/wb2osz/direwolf/blob/dev/doc/Why-is-9600-only-twice-as-fast-as-1200.pdf


Basically, higher speed needs faster key-up and settling times which is just not available in HAM voice-grade FM radios.  Once upon a time, there were HAM data-grade radios from vendors like Tekk, SCS, which were more than an order of magnitude faster but all of those are essentially gone now.  Also remember that for an effective network, both sides of the link needs fast radios.

--David
KI6ZHD



On 10/19/2020 12:43 PM, Zonker Harris via groups.io wrote:

  I’ve been using 9600 for APRS in the SF Bay Area, documented here…

 

    http://d72aclues.pbworks.com/

 

Sadly, there is not much adoption, since I haven’t managed to find a way for 9600 users to hear local 144.39 stations, or vice-versa. We thought it could alleviate some of the local congestion, but never completed a gateway that filtered only for “nearby” stations to repeat to the “other” band.

 

         Best regards,

 

              N6UOW@...

 

 

From: RaspberryPi-4-HamRadio@groups.io <RaspberryPi-4-HamRadio@groups.io> On Behalf Of Mark Griffith via groups.io
Sent: Monday, October 19, 2020 12:33 PM
To: RaspberryPi-4-HamRadio@groups.io
Subject: [EXTERNAL] Re: [RaspberryPi-4-HamRadio] TNC-Pi Now Available

 

Yeah, it's not such a great deal.  I've been wondering if I should offer it as an option for pre-built PiGate systems.  Since nearly all of the packet users in the US are at 1200 baud, and all of the TNC-Pi9k6 boards that I send out are setup for 1200 baud, I wonder if the capability to go to 9600 baud is a pressing need.  Given that is also takes a radio that is designed to do that, it seems unlikely that 9600 baud will become a common mode in the US.

 

I have encouraged 9600 baud usage, but I have no idea if anyone is taking up the challenges to use the higher speed, given the requirements for a really good signal, which means much more attention needs to be made to antennas, betters radios, attention to RF in the shack, etc etc.  Since 9600 baud that is running without a lot of packet resends is faster than any of the other current modes, I'm surprised.

 

I guess it depends upon the usage.  9600 baud doesn't really achieve it's best usage until the size of the file to transfer gets fairly large (by RF standards), such as around 25k.  Smaller than that you only get a fairly few seconds faster file transfer than at 1200 baud, or no advantage at all.  So if sending fairly small email messages is the goal, 1200 baud may be as good as you'll get in nearly all cases.  Since the vast majority of packet RMS stations operate at 1200 baud, having a larger number of receiver stations is a definite advantage.

 

So perhaps I'll stop offering the 9k6 board unless it is a special request.  Still thinking in it.

 

Mark

KD0QYN

 

 

On Monday, October 19, 2020, 2:10:28 PM CDT, N5XMT <dacooley@...> wrote:

 

 

Wow. 80 bucks and it's not even the 9K6...

On Oct 19, 2020, at 09:39, John Hansen <john@...> wrote:

For those who have been patiently waiting for MFJ to begin to offer the TNC-Pi, it is now available here:

https://mfjenterprises.com/products/mfj-1270pi-pitnc-board?_pos=1&_sid=6fa95bcea&_ss=r

John W2FS



Mark Griffith
 

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Inline image

The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.


Inline image

When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

Mark
KD0QYN


On Monday, October 19, 2020, 4:05:22 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



There is a reason why it hasn't been really adopted for APRS:  diminishing returns   Check out WB2OSZ's write up on this:

   https://github.com/wb2osz/direwolf/blob/dev/doc/Why-is-9600-only-twice-as-fast-as-1200.pdf


Basically, higher speed needs faster key-up and settling times which is just not available in HAM voice-grade FM radios.  Once upon a time, there were HAM data-grade radios from vendors like Tekk, SCS, which were more than an order of magnitude faster but all of those are essentially gone now.  Also remember that for an effective network, both sides of the link needs fast radios.

--David
KI6ZHD



On 10/19/2020 12:43 PM, Zonker Harris via groups.io wrote:

  I’ve been using 9600 for APRS in the SF Bay Area, documented here…

 

    http://d72aclues.pbworks.com/

 

Sadly, there is not much adoption, since I haven’t managed to find a way for 9600 users to hear local 144.39 stations, or vice-versa. We thought it could alleviate some of the local congestion, but never completed a gateway that filtered only for “nearby” stations to repeat to the “other” band.

 

         Best regards,

 

              N6UOW@...

 

 

From: RaspberryPi-4-HamRadio@groups.io <RaspberryPi-4-HamRadio@groups.io> On Behalf Of Mark Griffith via groups.io
Sent: Monday, October 19, 2020 12:33 PM
To: RaspberryPi-4-HamRadio@groups.io
Subject: [EXTERNAL] Re: [RaspberryPi-4-HamRadio] TNC-Pi Now Available

 

Yeah, it's not such a great deal.  I've been wondering if I should offer it as an option for pre-built PiGate systems.  Since nearly all of the packet users in the US are at 1200 baud, and all of the TNC-Pi9k6 boards that I send out are setup for 1200 baud, I wonder if the capability to go to 9600 baud is a pressing need.  Given that is also takes a radio that is designed to do that, it seems unlikely that 9600 baud will become a common mode in the US.

 

I have encouraged 9600 baud usage, but I have no idea if anyone is taking up the challenges to use the higher speed, given the requirements for a really good signal, which means much more attention needs to be made to antennas, betters radios, attention to RF in the shack, etc etc.  Since 9600 baud that is running without a lot of packet resends is faster than any of the other current modes, I'm surprised.

 

I guess it depends upon the usage.  9600 baud doesn't really achieve it's best usage until the size of the file to transfer gets fairly large (by RF standards), such as around 25k.  Smaller than that you only get a fairly few seconds faster file transfer than at 1200 baud, or no advantage at all.  So if sending fairly small email messages is the goal, 1200 baud may be as good as you'll get in nearly all cases.  Since the vast majority of packet RMS stations operate at 1200 baud, having a larger number of receiver stations is a definite advantage.

 

So perhaps I'll stop offering the 9k6 board unless it is a special request.  Still thinking in it.

 

Mark

KD0QYN

 

 

On Monday, October 19, 2020, 2:10:28 PM CDT, N5XMT <dacooley@...> wrote:

 

 

Wow. 80 bucks and it's not even the 9K6...

On Oct 19, 2020, at 09:39, John Hansen <john@...> wrote:

For those who have been patiently waiting for MFJ to begin to offer the TNC-Pi, it is now available here:

https://mfjenterprises.com/products/mfj-1270pi-pitnc-board?_pos=1&_sid=6fa95bcea&_ss=r

John W2FS



David Ranch
 


Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( https://github.com/amedes/fx25-kiss-tnc : https://www.seeedstudio.com/FX.25-KISS-TNC-g-1238591 ), and there might be others as well.


The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.


The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 


When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 


From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: http://www.danplanet.com/blog/2009/11/09/winlink-1988/ ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.

--David
KI6ZHD


Pierre Martel
 

Guys, you should take a look at the implementation of high speed communication on the 70 cm band.

With 2 pluto sdr (running linux) you can establish a high speed link that runs tcp-ip stacks. But that is not the only thing. the pluto-sdr is able to run the same code on the 33cm band, same as 23cm. 

Some people are testing what would be the feasibility of doing a cross band packet network with a central node on 70 cm and a client on 33 cm.  

That fix a lot of the problem of fast or slow switching of radio as the pluto-sdr is a full duplex radio. with separate tx and rx port. It is also possible to put a RF amplifier at the TX side to have a bit more punch and since the tx side dont need to be switched on/off the speed in not impeded at all. 

Pierre
VE2PF




Le mar. 20 oct. 2020 à 12:00, David Ranch <rpi4hamradio-groupsio@...> a écrit :

Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( https://github.com/amedes/fx25-kiss-tnc : https://www.seeedstudio.com/FX.25-KISS-TNC-g-1238591 ), and there might be others as well.


The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.


The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 


When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 


From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: http://www.danplanet.com/blog/2009/11/09/winlink-1988/ ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.

--David
KI6ZHD


David Ranch
 


Pierre,

I would love to try out HNAP but it currently doesn't support any real RF power levels (required for real world deployments).  I understand that's being worked on but it's also not legal in the US as it's 200Khz minimum bandwidth and symbols/sec rates on 70cm are not allowed per the FCC.  Maybe it could be used on the 23cm band but the propagation and creating real RF power for that band is a lot more difficult than 70cm.

--David
KI6ZHD



On 10/20/2020 11:28 AM, Pierre Martel wrote:
Guys, you should take a look at the implementation of high speed communication on the 70 cm band.

With 2 pluto sdr (running linux) you can establish a high speed link that runs tcp-ip stacks. But that is not the only thing. the pluto-sdr is able to run the same code on the 33cm band, same as 23cm. 

Some people are testing what would be the feasibility of doing a cross band packet network with a central node on 70 cm and a client on 33 cm.  

That fix a lot of the problem of fast or slow switching of radio as the pluto-sdr is a full duplex radio. with separate tx and rx port. It is also possible to put a RF amplifier at the TX side to have a bit more punch and since the tx side dont need to be switched on/off the speed in not impeded at all. 

Pierre
VE2PF




Le mar. 20 oct. 2020 à 12:00, David Ranch <rpi4hamradio-groupsio@...> a écrit :

Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( https://github.com/amedes/fx25-kiss-tnc : https://www.seeedstudio.com/FX.25-KISS-TNC-g-1238591 ), and there might be others as well.


The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.


The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 


When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 


From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: http://www.danplanet.com/blog/2009/11/09/winlink-1988/ ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.

--David
KI6ZHD


Siegfried Jackstien
 

Any band is easy
Ra 60h1315m for 2m
Ra 60h4047m for 70cm
Ra18h1213g for 23cm if zhaz is not enough then add an ldmos amp behind it.. 
13cm??look what all the qo100 users use
... 
You will find power modules in different power levels for near any band
And for fast switching if you use  single band just take that rf switching ic from hnap project
Greetz sigi dg9bfc 

Am 20.10.2020 23:40 schrieb David Ranch <rpi4hamradio-groupsio@...>:


Pierre,

I would love to try out HNAP but it currently doesn't support any real RF power levels (required for real world deployments).  I understand that's being worked on but it's also not legal in the US as it's 200Khz minimum bandwidth and symbols/sec rates on 70cm are not allowed per the FCC.  Maybe it could be used on the 23cm band but the propagation and creating real RF power for that band is a lot more difficult than 70cm.

--David
KI6ZHD



On 10/20/2020 11:28 AM, Pierre Martel wrote:
Guys, you should take a look at the implementation of high speed communication on the 70 cm band.

With 2 pluto sdr (running linux) you can establish a high speed link that runs tcp-ip stacks. But that is not the only thing. the pluto-sdr is able to run the same code on the 33cm band, same as 23cm. 

Some people are testing what would be the feasibility of doing a cross band packet network with a central node on 70 cm and a client on 33 cm.  

That fix a lot of the problem of fast or slow switching of radio as the pluto-sdr is a full duplex radio. with separate tx and rx port. It is also possible to put a RF amplifier at the TX side to have a bit more punch and since the tx side dont need to be switched on/off the speed in not impeded at all. 

Pierre
VE2PF




Le mar. 20 oct. 2020 à 12:00, David Ranch <rpi4hamradio-groupsio@...> a écrit :

Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( https://github.com/amedes/fx25-kiss-tnc : https://www.seeedstudio.com/FX.25-KISS-TNC-g-1238591 ), and there might be others as well.


The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.


The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 


When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 


From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: http://www.danplanet.com/blog/2009/11/09/winlink-1988/ ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.

--David
KI6ZHD



Pierre Martel
 

David, that is a bummer. for you US guys. 
In here we are ok to tx any symbols/sec as long as it does not exceed the maximum BW of the band. and it is larger than 200 khz for 70 centimeter and much more on 33 and 23cm

crazy how a line can create such inequity. 

Pierre
VE2PF


Le mar. 20 oct. 2020 à 17:40, David Ranch <rpi4hamradio-groupsio@...> a écrit :

Pierre,

I would love to try out HNAP but it currently doesn't support any real RF power levels (required for real world deployments).  I understand that's being worked on but it's also not legal in the US as it's 200Khz minimum bandwidth and symbols/sec rates on 70cm are not allowed per the FCC.  Maybe it could be used on the 23cm band but the propagation and creating real RF power for that band is a lot more difficult than 70cm.

--David
KI6ZHD



On 10/20/2020 11:28 AM, Pierre Martel wrote:
Guys, you should take a look at the implementation of high speed communication on the 70 cm band.

With 2 pluto sdr (running linux) you can establish a high speed link that runs tcp-ip stacks. But that is not the only thing. the pluto-sdr is able to run the same code on the 33cm band, same as 23cm. 

Some people are testing what would be the feasibility of doing a cross band packet network with a central node on 70 cm and a client on 33 cm.  

That fix a lot of the problem of fast or slow switching of radio as the pluto-sdr is a full duplex radio. with separate tx and rx port. It is also possible to put a RF amplifier at the TX side to have a bit more punch and since the tx side dont need to be switched on/off the speed in not impeded at all. 

Pierre
VE2PF




Le mar. 20 oct. 2020 à 12:00, David Ranch <rpi4hamradio-groupsio@...> a écrit :

Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( https://github.com/amedes/fx25-kiss-tnc : https://www.seeedstudio.com/FX.25-KISS-TNC-g-1238591 ), and there might be others as well.


The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.


The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 


When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 


From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: http://www.danplanet.com/blog/2009/11/09/winlink-1988/ ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.

--David
KI6ZHD