Primary Navigation

V4 Interleave

Hello Rick. I have a question about the interleave method you are using? I think I understand the term interleave but I d like to be sure, as you ve

Message 1 of 2
, May 24, 2011

0 Attachment

Hello Rick.

I have a question about the interleave method you are using? I think I understand the term “interleave” but I’d like to be sure, as you’ve implemented it.

In the RTTY days of old there used to be something frequently used in commercial and military called a “Time-Division Multiplexer” or also the “Time Diversity Modem” (TDM). The one we TDM is a mode resembling FEC AMTOR. TDM uses one sub-carrier, but assigns separate data channels to different time slots. The MD-1142 (aka TDM BR 6029C) has two modes of operation both are full duplex (the receiver and transmitter sections are fully independent), in the Internal Multiplexer Mode a single TTY signal is fed to 7 different channels and the signal in each channel is time delayed by 1 second form all the other channels. In addition there is a pilot tone at 561.1 Hz and the MARK/SPACE FSK shift of each tone was 85 Hz (if I recall). This mode of operation provides a high probability of getting the message through. In the External Multiplexer Mode each of the 8 channels is fed or receives a separate data stream so it does not have the redundancy of the IMM. In time order the channels are:

Chan # Center Freq Delay sec.

3 1530 Hz 0

7 2890 Hz 1

1 850 Hz 2

4 1870 Hz 3

6 2550 Hz 4

2 1190 Hz 5

5 2210 Hz 7

8 561.1 Hz pilot tone

Each of the channels transmitted the same information but each delayed by 1 second. The receiving TDM would receive all channels but vote on the best five matching channels to give an output. The redundant transmitted data on different tone pairs with the delay insured to get the data through on noisy channels. The result was an error free transmission nearly every time. The TDM worked very well for RTTY and I always thought they’d be good for implementation for the new PSK modes used in ham radio but never saw them. There is an initial 8 second latency from the start of transmission but that was never a problem for a long broadcast. Do you remember the TDM? They were pretty slick.

Anyway, does your interleave work in a similar manner, assigning the same data to different channels with a delay between channels? I’d like to understand better how you’ve implemented the interleave process in V4.

Also, could you send me the V4 ARQ version so I can test it in Europe? Thanks.

Mon May 23, 2011 1:32 pm (PDT)

All,

I am in the final stages of testing the new V4 ARQ mode. This is a niceimprovement allowing two stations to exchange error free data (after FEC andARQ) even in pretty poor conditions. I am in the final stages of testingand updating the help files for V4 and V4Chat. ARQ is a few percent slowerthan FEC (due to the ACK/NAK) but gives perfect copy (or no copy at all ifthings are really bad!).

I would like a few (no more than 5) brave individuals with some experiencewith the V4 FEC mode to test out the install, help and test ARQ and FECoperation before posting the files for the entire group (there is alwayssomething that will go wrong!)

One important thing on this new version: I am going to an interleavedtransmission scheme (where the symbols are sent in a more randomized orderand then deinterleaved at the receiver). My testing of this over manydifferent channel types suggests it offers some significant improvementespecially on burst noise, multipath and static crashes over the noninterleaved version that was used before. The only downside to interleavingis that it is NOT compatible with the current posted version so it willrequire an update. The interleaved version is the same speed, same 200 Hzbandwidth and sounds exactly the same as before .only the order of symboltransmission is changed. The new version 0.2.0.0 will include Monitor, FECand ARQ modes

If you are game for this and want to try and set up some test FEC or ARQsession I would appreciate it.

If interested contact me directly at rmuethingATcfl.rr.com and I will sendyou a zip package later this week. Thanks.

73,

Rick Muething, KN6KB

Rick Muething

Daniel, What you described is truly Time division multiplexing but using redundant interleaved data streams. That is not what is being used in V4. Here

Message 2 of 2
, May 24, 2011

0 Attachment

Daniel,

What you described is truly Time division multiplexing but using redundant
interleaved data streams. That is not what is being used in V4. Here
interleave is being used in the common code term where the sequence of code
symbols is rearranged (interleaved) to achieve a specific purpose.

The reason for interleaving coded symbols has to do with the type of Error
correcting code used and the expected type of channel errors. In V4 a fairly
powerful Viterbi code of rate 1/2 K=7 code is used (sometimes called the Viking
code after the Viking spacecraft that used it). The Rate 1/2 means that
the code contains 1 FEC (error correcting) bit per each bit of information (in
other words the code expands the data by a factor of 2). The length 7
means that the convolutional code used spreads each symbol out over 7 symbol
times in an overlapping sequence).

Now the Viterbi decoder is very powerful on random errors but clusters of
errors (2 or more errors in a row) significantly reduce the strength of the FEC
code and cause more symbol decode errors. One way to improve on this is to
take the Viterbi encoded symbols (in V4 there are 126 such 2 bit symbols per
data frame) and instead of sending them in the normal order (as they come out of
the Viterbi encoder) scramble them in some different sequence. In this
version I am using what is called a simple block interleaver to do this.
So instead of sending the Viterbi encoded symbols in normal sequence 1,2,3,
....126. They are sent “interleaved” like
1,10,19,28,...2,11,20,29....126. Now the receiving station (knowing the
interleave mechanism used) simply re orders the received symbols back to their
original Viterbi order BEFORE trying to decode them using the Viterbi decoder.
You can see if there were a burst error during transmission say from static
where 5 sequential symbols were wiped out this would now be spread in time to
the same 5 errors but spread out in time (non adjacent). The Viterbi
decoder handles these more randomly distributed errors much better. The
net result is a decrease in frame error rate for burst, static and short term
multipath errors. In simulations over thousands of frames I saw an improvement
in frame success from about 50% (no interleave) to near 80% (interleaved) over
poor channels (S/N = –5dB, CCIR Multipath poor channel). That is
equivalent to about doubling your transmission power. For random white noise
Interleaving is no benefit (but doesn’t harm) but most HF propagation is much
worse than white Gaussian noise channels.

The
only downside to interleaving is that you must capture and store all the
interleaved symbols before decoding. For V4 this is not a concern since there
are only 126 symbols per frame and the frame is not decoded until the entire
frame is captured.

I have a question about the
interleave method you are using? I think I understand the term
“interleave” but I’d like to be sure, as you’ve implemented
it.

In the RTTY days of old there
used to be something frequently used in commercial and military called a
“Time-Division Multiplexer” or also the “Time Diversity Modem” (TDM). The
one we TDM is a mode resembling FEC AMTOR. TDM uses one sub-carrier, but assigns
separate data channels to different time slots. The MD-1142 (aka TDM BR 6029C)
has two modes of operation both are full duplex (the receiver and transmitter
sections are fully independent), in the Internal Multiplexer Mode a single TTY
signal is fed to 7 different channels and the signal in each channel is time
delayed by 1 second form all the other channels. In addition there is a
pilot tone at 561.1 Hz and the MARK/SPACE FSK shift of each tone was 85 Hz (if I
recall). This mode of operation provides a high probability of getting the
message through. In the External Multiplexer Mode each of the 8 channels
is fed or receives a separate data stream so it does not have the redundancy of
the IMM. In time order the channels are:

Chan # Center
Freq Delay sec.

3 1530
Hz 0

7 2890
Hz 1

1
850 Hz 2

4 1870
Hz 3

6 2550
Hz 4

2 1190
Hz 5

5
2210 Hz
7

8
561.1 Hz pilot tone

Each of the channels
transmitted the same information but each delayed by 1 second. The
receiving TDM would receive all channels but vote on the best five matching
channels to give an output. The redundant transmitted data on different
tone pairs with the delay insured to get the data through on noisy channels. The
result was an error free transmission nearly every time. The TDM worked
very well for RTTY and I always thought they’d be good for implementation for
the new PSK modes used in ham radio but never saw them. There is an initial 8
second latency from the start of transmission but that was never a problem for a
long broadcast. Do you remember the TDM? They were pretty
slick.

Anyway, does your interleave
work in a similar manner, assigning the same data to different channels with a
delay between channels? I’d like to understand better how you’ve
implemented the interleave process in V4.

Also, could you send me the V4
ARQ version so I can test it in Europe? Thanks.

Mon May 23, 2011 1:32 pm (PDT)

All,

I am
in the final stages of testing the new V4 ARQ mode. This is a
niceimprovement allowing two stations to exchange error free data (after FEC
andARQ) even in pretty poor conditions. I am in the final stages of
testingand updating the help files for V4 and V4Chat. ARQ is a few percent
slowerthan FEC (due to the ACK/NAK) but gives perfect copy (or no copy at
all ifthings are really bad!).

I would like a few (no more than 5)
brave individuals with some experiencewith the V4 FEC mode to test out the
install, help and test ARQ and FECoperation before posting the files for the
entire group (there is alwayssomething that will go wrong!)

One
important thing on this new version: I am going to an
interleavedtransmission scheme (where the symbols are sent in a more
randomized orderand then deinterleaved at the receiver). My testing of this
over manydifferent channel types suggests it offers some significant
improvementespecially on burst noise, multipath and static crashes over the
noninterleaved version that was used before. The only downside to
interleavingis that it is NOT compatible with the current posted version so
it willrequire an update. The interleaved version is the same speed, same
200 Hzbandwidth and sounds exactly the same as before .only the order of
symboltransmission is changed. The new version 0.2.0.0 will include Monitor,
FECand ARQ modes

If you are game for this and want to try and set up
some test FEC or ARQsession I would appreciate it.

If interested
contact me directly at rmuethingATcfl.rr.com and I will sendyou a zip
package later this week. Thanks.

73,

Rick Muething,
KN6KB

Your message has been successfully submitted and would be delivered to recipients shortly.