Re: 300bps Packet (and EHAS) - what is pam, psk, and newpsk,

[Ray Wells <vk2tv@exemail.com.au>]

Dave,

You might look for two articles by James Miller, G3RUH, '9600 Baud 
Packet Radio Modem Design' and 'The Shape Of Bits To Come', which 
describes various modulation methods and their bandwidth.

I have the article in an ARRL publication called 'Packet: Speed, More 
Speed & Applications'. However, both articles reference ftp.amsat.org 
where they can be found at  /amsat/articles/g3ruh/a109.zip and  
/amsat/articles/g3ruh/a108.zip respectively.

Ray vk2tv

On 28/11/10 04:30, David Ranch wrote:
>
> Hello Tomi,
>
>> You have used the "AFSK" input to do something that the Yeasu
>> manual describes as "AFSK based data modes". The manual seems to
>> happily use terms that are at the very least confusing, even
>> downright wrong if you ask me...
> Oh yes, and a lot of documentation out there online and in the books 
> has lots of conflicting information.
>> "“Packet” operation also applies to SSB-based AFSK data modes, such 
>> as PSK31, etc." -- yeah, right.. :)
> Well, on the FT-950, the dedicated button for RTTY is enables the FSK 
> inputs and also activates some specific narrow filters and 
> processing.  The PACKET button activates the AFSK inputs but also 
> enables different specific filters and processing.  I do realize that 
> Packet can be FSK but it's not on this radio.
>
>> It is also important to realize that for example in the
>> G3UH case, the pulses are not rectangular, they are shaped.
>> This greatly affects the used bandwidth.
> You've mentioned a few times of how the G3UH does unique things such 
> as scrambling and now waveform shaping.  I'm going to have to look 
> around to see if I can find some documentation on all this that 
> doesn't quickly go into hardcore math.  I've always loved the concept 
> of signal processing but I don't know if my brain can handle it.
>
>
>>
>>>  I think most HAMs are in agreement that HF packet doesn't work well 
>>> for various reasons.  Since you mentioned "FM", I assume this mode 
>>> is not suitable for use with SSB on the HF bands?   Any thoughts on 
>>> its width of spectrum it uses, etc?
>>
>> Like I said, feeding PAM to an FM modulator results in (shaped)
>> FSK signals over the air and that is the ultimate goal in a
>> system like "G3RUH packet".
>>
>> Feeding this kind of PAM to an SSB modulator would result in
>> a completely different kind of modulation over the air. Of the
>> top of my head, I can't say what it would actually be but
>> most probably nothing useful. I'm quite sure it wouldn't
>> work at all as like Dave Platt said, this needs a very
>> low frequency response and the typical ham SSB modulator
>> cuts at around 300Hz in the low end.
>
> Ahhh... understood and from this thread, I never realized that a 
> souncard mode needs to be specifically designed for say SSB vs. FM.  I 
> naively thought that the modulation would only impact the noise 
> immunity, spectrum used (and the resulting power) use, etc.  The 
> concept that an digital waveform from a soundcard sent into a SSB vs 
> FM modulator and the results being very different is a foreign concept 
> to me.  I'm going to have to read up on this... interesting!
>
>>
>>> 1) You mentioned a "DSP56002EVM"... is that a specific DSP chip and 
>>> this mode was then ported into Soundmodem running on X86? 
>>
>> Yes, the Motorola 56002 was a member of an old DSP chip family
>> and the DSP56002EVM was an evaluation kit with the dsp chip,
>> memories, codecs etc.
>>
>> Pawel wrote the original modem in assembler for the 56002
>> and I ported it to C to be run on Linux.
>
> You know, I was optimizing my Linux packet system startup scripts 
> yesterday ( 
> http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh 
> ) and when playing around with the Linux AX.25 "kissparms" program, I 
> noticed that the man page states:
> -- 
>       -e FEC error correction level
>                   Sets the FEC error correction level in a DSP card 
> based modem  (KISS  parameter  8).  Larger
>                   correction  level means better noise resistance, but 
> slower throughput on a good connection.
>                   This is an experimental feature found in a QPSK 
> modem for the Motorola DSP56001  based  DSP4
>                   and EVM cards only.
> -- 
>
> Maybe this support is derived from some of the work you and Pawel did?
>
>
>
>>
>>> 3) This mode is interesting to me and I think I once saw it on the 
>>> air.  If there are 15 carriers, how wide is each carrier, and what 
>>> is the spacing between them?  What's the total consumed spectrum at 
>>> say 2500?   It seems that 300BAUD AFSK packet is a bit less than 400Hz.
>>
>> Carrier spacing is 125Hz at 2500 and thus occupied bandwidth
>> is about 15 * 125 Hz, ie. little less than 2 kHz.
> Right.. and what I expected you to say.  That's a chunk of bandwidth 
> and I was hoping that if I was to lower the speed, maybe I could lower 
> the BW but it doesn't sound like the mode supports that approach.  
> Again, my goal would be to use a FEC-enabled mode for AX.25 that would 
> give an effective 300BAUD throughput.  Even if I was to dig through 
> your code, hacked out a few carriers,  I highly doubt the mode would 
> find any real traction.  It seems most hams have a general disdain for 
> packet though I think it's fantastic (though slow).
>
>
>> The carrier frequencies, their spacing, the occupied bandwidth, the 
>> symbol rate all scale 1:1 with the "bps" setting.
>>
>> But like I said, don't do that. I really regret that I made
>> the soundmodem implementation so flexible.
> QSL and when I try this out (if I can find any other HAMs to maybe 
> test this with), I'll keep this in mind.
>
>
>> Besides, you are now confusing Baud (ie. symbols per second) with
>> bits per second. They are not the same. At 2500 bps the newqpsk
>> modem runs at 83.333 Baud (symbols per second).
> Right, and I know better.  Sorry.
>
>
>
>> However as to IP over AX.25 over newqpsk on HF. Been there, done that,
>> it was fun. :)
> So, if that was been there, done that.  What's fun for you now?   
> Maybe data and CODEC2 over GMSK?  Maybe WinMor?
>
>
> --David
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html