Re: Wireless link, reliable preamble end detection?
- From: Mike Monett <no@xxxxxxxx>
- Date: Thu, 26 May 2005 22:58:43 -0400
usenet@xxxxxxxxxxxxx wrote:
>
> 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
> http://www.dfxtech.co.uk
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
http://www3.sympatico.ca/add.automation/patents/3810234.htm
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
.
- Follow-Ups:
- Re: Wireless link, reliable preamble end detection?
- From: usenet
- Re: Wireless link, reliable preamble end detection?
- References:
- Wireless link, reliable preamble end detection?
- From: usenet
- Wireless link, reliable preamble end detection?
- Prev by Date: Re: RoHS, practically speaking
- Next by Date: Re: OT - Firefox tweaks
- Previous by thread: Re: Wireless link, reliable preamble end detection?
- Next by thread: Re: Wireless link, reliable preamble end detection?
- Index(es):
Relevant Pages
|