Re: [Q15X25] QRM
- At 12:46 12/19/02 -0500, you wrote:
>I tried an interleave of 16 but went back to 8 as I noticed that my packetsRuss,
>became noticeably longer with the same amount of text typed.
Yes increasing the interleave seems to increase the packet
size. Interleaving by itself is good for a QSB channel. Interleaving is
one of the parameters that makes MT63 so robust. There must be some
redundancy in bits along with the interleaving in Q15X25, because
interleaving alone does not increase the packet size. Higher S/N ratio is
- I think the 20M band is dead right now. 14.115 USB might be a good
choice. I will hang out there and listen for a while.
At 18:40 12/19/02 +0000, you wrote:
>Let me know how 14113 does. I'm currently beaconing on 14103 Lower
>every ten minnutes but I'll switch up to 113 if that works out.
>To unsubscribe from this group, send an email to:
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- Hi all,
I just joined here as well...
> Yes increasing the interleave seems to increase the packetTrue. The interleaver implementation in Q15X25 is a compromise.
> size. Interleaving by itself is good for a QSB channel.
> Interleaving is
> one of the parameters that makes MT63 so robust. There must be some
> redundancy in bits along with the interleaving in Q15X25, because
> interleaving alone does not increase the packet size.
It is a simple self synchronizing interleaver, which makes things
easy but has the drawback of requiring rather long flushing.
The flushing is done with zeroes so it's completely wasted power...
This behaviour is seen nicely in the upper picture at
You can see how the interleaver first needs to be filled at the
start (after preamble) and then flushed at the end (the very last
part is the end-of-drame postamble). Increasing interleaving
makes the straight lines (sending zeroes) in the data part longer.
The same thing applies to MT63 by the way. The long latency in
MT63 is caused by exactly the same issue.