Wireless link, reliable preamble end detection?

Hi everyone,

I have a project at the moment that requires a high-reliability one-way radio link.

I have decided on Viterbi encoding the data and then encapsulating that with Manchester encoding to keep everything DC balanced.

All that I can code fine it's the preamble, and specifically detecting when it ends, that I'm having trouble with.

The current format of the preamble is a single repeating byte of '1010001' chosen because it's asymmetric and I can easily align to the start of it. The detection of the start of actual data is giving me trouble; the channel is very noisy so about every preamble byte in five will have a single-bit error stopping me from simply waiting for data that 'isn't a preamble byte'.

The choices as I see them are:

  • Unique bytes at the start of real data.
  • Wait for two 'non-preamble' bytes to determine preamble end.

Neither of these look like very good solutions and I'm worried that the preamble may be the weak point in the scheme rather than the forward error correction side of things. I can't do anything really fancy as the preamble stripping/de-Manchestering is being done on a low-end RISC micro and I can at best examine two bytes in detail before I run out of time and have to start sampling again.

So does anyone have advice on how to best detect the end of the preamble?

Jon Starr

Design Engineer DFx Technology Limited

formatting link

Reply to
usenet
Loading thread data ...

I'm not sure why your approach is so complex. Typically, Manchester coding sends a string of zeros as a preamble. This encodes to a constant frequency wave used to 'lock' the recovery clock in the receiver. The first 'one' bit then signals the sync byte which can be any byte with a 'one' for its first bit.

Once the sync byte is detected, the rest of the data stream is decoded synchronously, 8 bits at a time. 8,16,or 32 bit checksums are appended to the end of the data block.

--
Luhan Monat: luhanis(at)yahoo(dot)com
http://members.cox.net/berniekm
 Click to see the full signature
Reply to
Luhan Monat

But with his bit error rate that becomes impractical.

--
-------------------------------------------
Tim Wescott
 Click to see the full signature
Reply to
Tim Wescott

Using Manchester encoding in such a noisy environment seems strange.

My knowledge of Viterbi decoding is limited, but I understand that it is a family of codes, not a single code. I know with block codes you can design schemes that guarantee zero DC content in the good code words -- could you possibly select a Viterbi code that did the same thing?

Alternately, why not a zero-DC-content block code?

With your probability of error I think you need to encode your preamble somehow. With block codes you could see if there is a code that has at least 257 valid code words and use one of them for a preamble message. With Viterbi coding there may be a similar way, but as I said, I'm not an expert on Viterbi codes...

------------------------------------------- Tim Wescott Wescott Design Services

formatting link

Reply to
Tim Wescott

Ooh, tough. What needs to be highly reliable?

  1. No false triggering.
  2. No missed transmissions.

You don't get both for free.

So far you seem to be concentrating on the preamble and haven't gotten to the actual payload?

How much payload is there? Is it "turn on/turn off" or are you sending megabytes?

Look at "Digital Fountain" if this is truly a large amount of one-way data.

Tim.

Reply to
Tim Shoppa

--
Since you can align your receiver with the preamble, it\'ll know where
in the sequence it is and since it knows what should be coming next,
 Click to see the full signature
Reply to
John Fields

If the preamble bytes are only off by one bit, how about finding the Hamming difference? If a byte is off by one bit, it's probably still preamble. If the preamble is followed by, say, a 0 byte, it'll be off by 3 bits, or maybe two. Then start the data.

The real problem is that you want high reliability, and the bit error rate is high. Why is it so high? Can the channel be cleaned up?

Barry

Reply to
Barry Jones

Look not for the whole bitstream. But, for 8 (or 16, if you're not completely sure of the timing) seperate counters, at each bit-time increment (or half or quarter of) add one if the bit is the expected bit, subtract one if it isn't. You may find it helpful to look up how spread spectrum recievers lock onto their signal.

Reply to
Ian Stirling

Why not call LPRS, just down the road from you in Witney - their 'Easy Radio' takes away a lot of this hassle - alledgedly.

formatting link

Alternatively look at my 'nkm2401' encoder/decoder

formatting link

I wouldn't bother with error correction as if the RF link is 'broken' than it's really ' broken' !

RF links don't work like this ! You WILL get missed transmissions sometimes it's a fact of life. They ain't like a piece of wire or even two pieces of wire.

Reply to
Mike Meakin

Jon,

As others have mentioned, your data transfer scheme is too complicated. You will have difficulty diagnosing problems, such as ISI (Intersymbol Interference.) Manchester is fine by itself.

Also, as everyone points out, your SNR is terrible. You have little hope of transferring data if the error rate is so bad you cannot even find the preamble.

The SNR problem boils down to excessive jitter. This could come from weak signals, or it could come from nose introduced anywhere in the transmit/receive path. For example, make sure the transmitted data is absolutely clean and jitter-free. That should be easy. You can trigger on the clock signal and look at the data transitions using delayed sweep and very fine timing.

Then, assuming your signal levels are adequate, there are many places noise can be introduced in the read chain. Look for poor filtering and bypassing in the low-level stages. Check for parasitic oscillations anywhere, including the power supply regulators. Check for excessive noise on the Vcc supplies.

The entire channel up the the zero cross detector is critical. You should be able to introduce a clean signal at a low level from a known good signal generator at the input to the read channel, and follow the signal through the chain. If the signal generator is roughly the same level as your incoming signal, you will get some jitter due to the Johnson noise at the input of the receiver.

You can measure this noise by monitoring the outpur of the channel at some suitable point where the signal is still linear, and increase the signal generator output from zero until the true rms noise increases by

3dB. The signal at the input to the read channel is equal to the noise at the input. The actual amount depends on the bandwidth of the channel, but it can easily be calculated to verify your input stage is clean.

Next, the zero cross detector can add lots of jitter. It can oscillate internally at a high frequency so you can't see it on a scope. You should be able to reduce the signal generator output to zero and watch the signal output of the zero cross detector degrade smoothly until it falls into the noise. If not, fix it. Spend a lot of time here so you get to know instinctively how the channel and zero cross detector behave.

Next is the pll. There are so many places noise can enter the loop that this is not a suitable place to list them all. But the pll is often the weakest link in the entire channel, and every aspect of the design and layout is critical.

For example, you may wish to adjust the loop response to speed up the syncronization to the incoming data. However, this means opening up the loop bandwidth during synchronization. Then, as soon as you are locked to the phase and frequency of the incoming data, you want to slow the loop down to minimize jitter while tracking.

Unfortunately, loops that switch bandwidth generally develop a large phase and frequency error during the transition to the slow bandwidth. This error must then be corrected while the loop is in the slow mode and you are trying to recover data. You can see how one approach works in this patent

formatting link

The issues are complex and unforgiving, and you might consider hiring someone near you who has demonstrated competence in these areas. There are quite a few people in this newsgroup who would probably do a good job.

Mike Monett

Reply to
Mike Monett

Thank you for all the replies; I should probably clarify the application a little more.

The requirement is skewed towards error detection, error correction is a lesser concern to the customer, the remote equipment has powerful motors and can be extremely dangerous if random radio noise generates valid command codes (as happens with the current version, this is a re-design).

The physical link is being taken care of by Radiometrix's RX2/TX2 FM modules and it just appears that the 433MHz band is extremely noisy so I can't see a way round that, I have been working with Radiometrix's app engineers to use the modules correctly so I don't think any higher performance can be obtained (and I also inhibit sampling using the carrier-detect pin to try to keep some noise out).

The actual link format is more complex than I described, the data is sent 'On-Off Keying' with the TX/RX processors using crystal oscillators to stop the clocks drifting apart too quickly, the previous version used an odd scheme of a narrow pulse for '0' and a long pulse for '1' I got rid of this because it slows down communications and I can't balance it easily.

The full data frame is:

  • Preamble '10100011' (10-20 repeats, mostly to settle receiver module).
  • Payload (16 Bytes).

The real data in the payload is 4 bytes (Viterbi (1/2 rate K=7) doubles that and Manchester doubles it again) :

| IDBYTE1 | IDBYTE2 | COMMAND | CRC-8 CHECKSUM (for command byte) |

My preamble lock-in process is currently:

  1. Wait for a '1' to appear.
  2. Check it lasts for 100 cycles (one bit).
  3. Adjust the 'bit-start' clock slightly over the next few '1' bits received.
  4. Grab an entire byte.
  5. Rotate the bits until the preamble is found (goto 1 if it isn't).
  6. Skip some bits until we are byte aligned to the preamble.
  7. Start sampling bytes constantly
  8. Wait for the preamble to end.

As for my thinking behind such complexity I want to be able to correct sporadic errors in the payload, which Viterbi is great for, the CRC-8 is a 'nuke-it-from-orbit' step to detect any errors the Viterbi decoding didn't catch. The Manchester encoding is simply to keep a net DC level of zero as that's recommended by Radiometrix, it is only used on the payload as the preamble is already balanced. I looked over the design of Viterbi encoders last night and I suspect you could rig the trellis to be DC balanced as suggested but that massively exceeds my maths abilities.

I was hoping that there was another good way to manage byte-aligning oneself to the preamble and getting an unambiguous transition from preamble to payload, but I see the sense in what Barry Jones said about looking at how similar to a preamble a byte is (or isn't).

I take on board the points people have made about excessive complexity but I see no other way to give the customer a link that has a low enough undetected error rate to satisfy him (i.e. extreme statistical outside).

Jon Starr

Design Engineer DFx Technology Limited

formatting link

Reply to
usenet

You seem to be a bit hung up on the preamble, what you need is more data redundancy in the payload, send everything 3 times and accept nothing less than a 2 out of three matches before using the data. Or go to 6 out of 7 or whatever it takes.

This is much like radio control airplanes, you need to be sure of good data before acting on it. Otherwise, define a safe state of operation for when reliable data is not present.

Have you considered switching from RF to IR for the link?

--
Luhan Monat: luhanis(at)yahoo(dot)com
http://members.cox.net/berniekm
 Click to see the full signature
Reply to
Luhan Monat

--
Or increasing transmitter power (or antenna gain or directivity on
both ends) to get the snr up where it needs to be?
Reply to
John Fields

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.