PDA

View Full Version : 1200 bps limit?



KC2UGV
09-28-2010, 10:51 AM
Ok, so, from what I gather, from 10 meters - 2 meters, 1200 bps is the top "modulation speed" allowed for digital operations.

So, I got the idea, that one could plunk compression on top of that, in order to squeeze about 9.6K onto that line (Top speed for phone lines are 14.4K, add in compression technology, and you can get 56K).

Which leads me to this question: Is there any work on applying compression techniques to amateur packet? Seems somewhere along the lines, we just settled on Bell 202 technology for packet, and stayed there.

N2CHX
09-28-2010, 11:40 AM
Ok, so, from what I gather, from 10 meters - 2 meters, 1200 bps is the top "modulation speed" allowed for digital operations.

So, I got the idea, that one could plunk compression on top of that, in order to squeeze about 9.6K onto that line (Top speed for phone lines are 14.4K, add in compression technology, and you can get 56K).

Which leads me to this question: Is there any work on applying compression techniques to amateur packet? Seems somewhere along the lines, we just settled on Bell 202 technology for packet, and stayed there.

I think a general lack of interest in packet stifled any innovation and advancement there could be.

KC2UGV
09-28-2010, 12:59 PM
A quick test of compression (Gzip) on a dump file from my sm0 port on Linux shows a 75% compressible rate (I understand inline compression will show a much different result).

Hm... Now, on to figuring out if I can pump the ax25 stack through a gzip-type routine before sending it out on the wire...

KC2UGV
09-28-2010, 01:25 PM
I think a general lack of interest in packet stifled any innovation and advancement there could be.

Well, thankfully, there seems to be quite a bit of packet here in WNY... I'm working to get some TCP/IP routing done here, but TCP/IP over 2 meters is dog slow, to the point of time-outs being quite prevalent.

ki4itv
09-28-2010, 01:32 PM
I think a general lack of interest in packet stifled any innovation and advancement there could be.

You'll find that PVL's theory on this subject has more international conspiracy, intrigue, personal vendetta, and pseudo encryption than your version. :yes::lol:

Not that you're in any way, wrong...at all.:shhh:

KC2UGV
09-28-2010, 02:03 PM
You'll find that PVL's theory on this subject has more international conspiracy, intrigue, personal vendetta, and pseudo encryption than your version. :yes::lol:

Not that you're in any way, wrong...at all.:shhh:

Yeah, he basically thinks there is a conspiracy for WinLink to take over the world :) He's pretty sharp as far as packet goes, but he is a bit out there :)

NQ6U
09-28-2010, 02:12 PM
Yeah, he basically thinks there is a conspiracy for WinLink to take over the world


Which is BS since we all know that it's the IRLP that's the real threat.

W3WN
09-29-2010, 10:38 AM
Ok, so, from what I gather, from 10 meters - 2 meters, 1200 bps is the top "modulation speed" allowed for digital operations.

So, I got the idea, that one could plunk compression on top of that, in order to squeeze about 9.6K onto that line (Top speed for phone lines are 14.4K, add in compression technology, and you can get 56K).

Which leads me to this question: Is there any work on applying compression techniques to amateur packet? Seems somewhere along the lines, we just settled on Bell 202 technology for packet, and stayed there.
N5PVL Chuckles might be one to ask. Don't be surprised if you get a long winded reply from the bearded one that doesn't directly answer the question.

IIRC the main problem is that the higher the baud rate, the wider the bandwith. Which is why at one time the FCC had some very severe restrictions. I haven't looked at the regs on that for awhile, so I couldn't tell you if that is still the case.

N8YX
09-29-2010, 10:39 AM
MSYS used LZH compression for forwarding BBS traffic. FBB did as well.

KC2UGV
09-29-2010, 10:47 AM
N5PVL Chuckles might be one to ask. Don't be surprised if you get a long winded reply from the bearded one that doesn't directly answer the question.

IIRC the main problem is that the higher the baud rate, the wider the bandwith. Which is why at one time the FCC had some very severe restrictions. I haven't looked at the regs on that for awhile, so I couldn't tell you if that is still the case.

I think I'm on his ignore list :) It's a bit of a shame, like I said, he's pretty sharp in the way of packet, but his people skills are lacking at times. He "Doesn't Play Well With Others" I think would be the appropriate term.

Maybe I'll drop him a line on his uspacket site.


MSYS used LZH compression for forwarding BBS traffic. FBB did as well.

Yeah, I saw that, and it's would work. But, you get more gains by using wireline compression for things like routing and the like.

KA5PIU
10-01-2010, 10:51 PM
Hello.

Look at the settings on most modern radios, 1200/9600 is the option.
56(53) k will work just fine, I did this before WiFi could be found everywhere.
In fact the old 46/49MHz telephone line extenders work just fine.
A telephone line is 300 to 3000Hz bandwidth, about the same low end but a bit greater high end for a ham rig.
So, set your radios for 9600 and interface correctly and you can get around 46 to 48k with no problems with a good signal.

KC2UGV
10-10-2010, 09:38 AM
Hello.

Look at the settings on most modern radios, 1200/9600 is the option.
56(53) k will work just fine, I did this before WiFi could be found everywhere.
In fact the old 46/49MHz telephone line extenders work just fine.
A telephone line is 300 to 3000Hz bandwidth, about the same low end but a bit greater high end for a ham rig.
So, set your radios for 9600 and interface correctly and you can get around 46 to 48k with no problems with a good signal.

That is true. However, there are legal restrictions applicable to the max baud rate.

WØTKX
10-10-2010, 11:35 AM
1200 baud is too slow for twirling cursors and ANSI art. :cry:

http://www.vintagecomputing.com/wp-content/images/dialup_bbs/colossus_login_large.jpg



http://farm1.static.flickr.com/62/160183128_24125ae57a_o.gif