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

[David Ranch <linux-hams@trinnet.net>]

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