Searching \ for '[PIC]:Manchester Lookup table' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=table
Search entire site for: 'Manchester Lookup table'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Manchester Lookup table'
2003\09\09@011500 by David Huisman

flavicon
face
I am looking for a fast Manchester Encode/Decode algortithm.

At present I use "for" loop in "C" with bit comparison for bit generating the 2 byte
Manchester code from the source byte and visa versa for decode.

The encode is straight forward using a 16 entry lookup table and applying
to High and then Low nibble of source byte but the decoding seems a little more involved.

I cannot see how to implement a lookup table for decode without having 256 entries but I only need 16 entries with values. (ie. each byte being
received represents 1 nibble only).

The type of structure I would like to end up with is... (Assume MSB = true,RXByte = incoming data with Manchester values 55,56,59....)

if (MSB)
{
  RxChar = Decode[RXByte] << 4;
}
else
{
 RXChar |= Decode[RXByte];
}
MSB = !MSB;

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@071951 by Eduardo Garcia

flavicon
face
Hi David.
I am needing a lot of infos about Machester Encoding.
I am developing a communication system through Radiometrix Modules and I
think this is the best way to implement it.
Are you doing anything near it too?
Can you point me a literature or tutorial about Manchester or Radio Data
Encoding?

Thanks in advance!

{Original Message removed}

2003\09\09@074101 by Mike Harrison

flavicon
face
On Tue, 9 Sep 2003 08:20:25 -0300, you wrote:

>Hi David.
>I am needing a lot of infos about Machester Encoding.
>I am developing a communication system through Radiometrix Modules and I
>think this is the best way to implement it.
>Are you doing anything near it too?
>Can you point me a literature or tutorial about Manchester or Radio Data
>Encoding?
>
>Thanks in advance!
>
>{Original Message removed}

2003\09\09@075554 by Olin Lathrop

face picon face
> I am looking for a fast Manchester Encode/Decode algortithm.

This is a useless question without defining "fast".  I've got a PIC
decoding two "fast" received manchester streams serially bit by bit, and
it's doing a few other things at the same time.

So, how fast is "fast"?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@080555 by Hulatt, Jon

flavicon
face
Here's me not being an expert at manchester encoding... But if my
assumptions are correct and a

1   encodes as 10
0   encodes as 01

Then if you have two bytes of received data, you cunningly could decode in
one line like this:-

       char h = 0xAA; char l = 0xAA;
       char o ;

       o = (h & 128) + ((h << 1) & 64) + ((h << 2) & 32) + ((h << 3) & 16)
+ ((l >> 4) & 8) + ((l >> 3) & 4) + ((l >> 2) & 2) + ((l >> 1) & 1);

... Because the second bit in each pair of bits is irrelevant. For decoding
purposes.

jon


{Original Message removed}

2003\09\09@100047 by Bob Ammerman
picon face
I believe the OP is running Manchester over ASYNC or something like that.
This provides a 'balanced' signal for the RF side.

If this is the case, the OP is relying on the UART to sync to the byte
framing and then decoding what comes in, 4 bits for each byte.

So, we have already determined the bit boundaries. If the signal wasn't
corrupted then each bit pair will consist of a zero and a one bit.

If we are willing to assume no corruption, we could decode the bits as
follows:

getmanchester:
   clrf      output
   call      getandstore
   swapf  output,f
   ; fall thru into getandstore to get second input byte
getandstore:
   <get input byte>
   btfsc    input,7
   bsf       output,3
   btfsc    input,5
   bsf      output,2
   btfsc    input,3
   bsf      output,1
   btfsc    input,1
   bsf      output,0
   return

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@104038 by Tal

flavicon
face
I think that Manchester code defines bits not by levels but by
transitions. That is, you always have a transition between bits and have
another transition in the middle of a '1' bit.

BTW, it can easily speed up by 25% (average), without increasing the
required bandwidth, by eliminating the second half of a '1' bit slice.
That is, you end up with transitions only between bits, and the time
period of a '1' is half the time period of a '0' (or the other way
around if your data is likely to contain more 0's than 1's).

This also simplifies the encoding/decoding of the signal.

The disadvantage is that the bit stream is not at constant rate but in
many application this does not matter.


Encoding:

   get next bit

   if bit is 1 then delay for 1/2T else delay for 1T

   toggle output line

Decoding:

   Wait for next transition

   t = time from previous transition

   if t is 'close' to 1T than next bit is '0'

   else, if t is 'close' to 1/2T than next bit is '1'

   else error.



> {Original Message removed}

2003\09\09@114244 by

picon face
Tal wrote:
> I think that Manchester code defines bits not by levels but by
> transitions.

In a way...

> That is, you always have a transition between bits and have
> another transition in the middle of a '1' bit.

Not at all, each bit *has* a transition in the middle. A "1" in one
direction, a "0" in the other. The directions could be either
way round. There *is* a transition between two bits *if*
the two bits are *different*. There is *no* transition
between two bits if both bith are the *same*.

Let's say "1" is a transition from "low" to "high" and a "0"
is a transtions from "high" to "low". Then the following bit-
streams would be encoded in the following way :

Bits to send              Manchexter code

1                         01
0                         10
10                        01 10
01                        10 01
1100                      01 01 10 10
0011                      10 10 01 01
00100                     10 10 01 10 10

and so on. (I added spaces for clearity.)

> BTW, it can easily speed up by 25% (average), without increasing the
> required bandwidth, by eliminating the second half of a '1' bit slice.

Not sure that is possible...

> That is, you end up with transitions only between bits, and the time
> period of a '1' is half the time period of a '0' (or the other way
> around if your data is likely to contain more 0's than 1's).

Then it isn't Manchester code any more, is it ?


Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@114503 by

picon face
Soryy, there was an error in my last post.
A corrected version below.
Jan-Erik.

-----Original Message-----
From: Jan-Erik Soderholm XA (TN/PAC)
Sent: den 9 september 2003 17:42
To: spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU
Subject: Re: [PIC]:Manchester Lookup table


Tal wrote:
> I think that Manchester code defines bits not by levels but by
> transitions.

In a way...

> That is, you always have a transition between bits and have
> another transition in the middle of a '1' bit.

Not at all, each bit *has* a transition in the middle. A "1" in one
direction, a "0" in the other. The directions could be either
way round. There *is* a transition between two bits *if*
the two bits are the *same*. There is *no* transition
between two bits if both bits are *different*.

Let's say "1" is a transition from "low" to "high" and a "0"
is a transtions from "high" to "low". Then the following bit-
streams would be encoded in the following way :

Bits to send              Manchexter code

1                         01
0                         10
10                        01 10
01                        10 01
1100                      01 01 10 10
0011                      10 10 01 01
00100                     10 10 01 10 10

and so on. (I added spaces for clearity.)

> BTW, it can easily speed up by 25% (average), without increasing the
> required bandwidth, by eliminating the second half of a '1' bit slice.

Not sure that is possible...

> That is, you end up with transitions only between bits, and the time
> period of a '1' is half the time period of a '0' (or the other way
> around if your data is likely to contain more 0's than 1's).

Then it isn't Manchester code any more, is it ?


Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@132932 by Olin Lathrop

face picon face
> If you reset timer 0 immediately after each
> transition, you don't need to worry
> about how long the processing of each transition takes.

It is better to let timer 0 free run and just keep a snapshot of the timer
value at the last edge.  Subtract the previous from the new to get the
elapsed time since the last edge, then promote new to previous.  Any
number of streams can be measured with the same timer this way.  The
unsigned math makes everything just work out with no special cases as long
as the maximum interval of interest is less than the timer wrap period.

I have one application that receives two separate IR bit streams this way.
Assembly time calculations are used to set up the timer 0 prescaler so
that the maximum time of interest is less than the timer wrap time.  This
same PIC also decodes and processes two separate 10KHz manchester streams
at the same time.  These are captured with CCP modules because software
measurement would have too much jitter at that frequency.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@145725 by Olin Lathrop

face picon face
> I think that Manchester code defines bits not by levels but by
> transitions. That is, you always have a transition between bits and have
> another transition in the middle of a '1' bit.

Yes, the direction of the transition between bits identifies the bit
value.  For example, a rising bit edge is a 1 and a falling bit edge is a
0.  However, that means another way to look at it is that the bit value is
the level for the next 1/2 bit time following the bit edge.

{Quote hidden}

Another difference is that always averages to 50% duty cycle over a short
interval, whereas this modified scheme doesn't.  This can be important for
radio modulation.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@154147 by

picon face
Olin Lathrop wrote:

> > That is, you always have a transition between bits and have
> > another transition in the middle of a '1' bit.

> Yes, the direction of the transition between bits identifies the bit
> value.

All my Manchester code (MC) docs do *not* say that.

>  For example, a rising bit edge is a 1 and a falling bit edge
>  is a 0.

Partly correct, but it's not *between* the bits, it's in the *middle*
of the bits. (The 1 and 0 could also be interchanged)

> However, that means another way to look at it is that the bit value is
> the level for the next 1/2 bit time following the bit edge.

No, two logical "1" after each other with have *three* edges, first
the 0->1 in the middle of the first bit, then the 1-> between
the bits and at last the other 0->1 in the middle of the second bit.
*But*, if you with "bit edge" meen the edge in the *middle* of
each bit, then yes.

A logical "1" coded with Manchester code is a "bit" with the first
half low and the second half high.

A logical "0" coded with Manchester code is a "bit" with the first
half high and the second half low.

(Or the other way round, as I said above.)

Now, this meens that *if* two identical bits, "11" or "00",
follows directly after each other, there *will* be a transition
between the two bits.

If two different bits, "01" or "10", follows directly after each other,
there will be *no* transition between the two bits.

Or have I totaly missunderstod how Manchester coding works ?
I'm only aprox 97,5 % sure :-)


Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@162757 by smurph

flavicon
face
Tal wrote:
>
> I think that Manchester code defines bits not by levels but by
> transitions. That is, you always have a transition between bits and have
> another transition in the middle of a '1' bit.
>
[]


For a good drawing comparing various data encodings go to:

http://techtrain.microchip.com/masters2002/masters2002.html

Choose the 625 BRF page. On page 17 of the pdf is the drawing.

Any replies to this should probably be tagged as EE or OT.

Regards,

Steve

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@164423 by

picon face
smurph@METRONET.COM wrote :
> Tal wrote:
> >
> > I think that Manchester code defines bits not by levels but by
> > transitions. That is, you always have a transition between bits and have
> > another transition in the middle of a '1' bit.
> >
> []
>
>
> For a good drawing comparing various data encodings go to:
>
> http://techtrain.microchip.com/masters2002/masters2002.html
>
> Choose the 625 BRF page. On page 17 of the pdf is the drawing.


All right, that document verifies that Tal (and Olin, I think)
described "Bi-phase" encoding, *not* Manchester encoding.

Thanks for the URL to the Masters docs, b.t.w !

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\09@184350 by Olin Lathrop

face picon face
>> Yes, the direction of the transition between bits identifies the bit
>> value.
>
> All my Manchester code (MC) docs do *not* say that.
>
>>  For example, a rising bit edge is a 1 and a falling bit edge
>>  is a 0.
>
> Partly correct, but it's not *between* the bits, it's in the *middle*
> of the bits. (The 1 and 0 could also be interchanged)

Remember that "middle" is somewhat up for interpretation.  The same
manchester signal can be thought of or described in various ways.  You are
thinking of an edge that defines a bit, and you've got 1/2 bit time on
either side of that edge you are calling the "bit time".  That's perfectly
valid, but there is no standard.  Other descriptions say the bit time
follows this edge.  That's why I like to refer to this edge as the "bit
edge", with other edges only added as needed to make sure the transition
at the next bit edge is correct.

In this view, each bit can be thought of as being represented by the
polarity of the bit edge, or the level of the 1/2 bit time immediately
following the bit edge, or the inverse of the level of the 1/2 bit time
immediately preceeding the bit edge.  These are all perfectly valid ways
of talking about the same signal.  The difference is only in the words we
use to describe it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\09\10@035124 by

picon face
Olin wrote:
> Jan-Erik wrote :
> > Partly correct, but it's not *between* the bits, it's in the *middle*
> > of the bits. (The 1 and 0 could also be interchanged)
>
> Remember that "middle" is somewhat up for interpretation.

Well, you have to start and stop your transmission with whole bits,
right ? And "middle" would be referenced from the start of this
first bit, not ?

Yes, there are similarites between Bi-Phase and
Manchester encoding. And I still claim that the coding
Tal and you described matches (best) Bi-Phase, not Manchester.
And that's why I got a bit lost in your descriptions.


Tal wrote :
> That is, you always have a transition between bits and have
> another transition in the middle of a '1' bit.

100% correct for Bi-Phase, 100% wrong for Manchester (no matter how
you shift the Manchester stream to redefine the "middle" of a bit).
(And Olin started his reply to this specific part with "Yes,...")


Olin wrote:
> Yes, the direction of the transition between bits identifies the bit
> value.

Wrong for both Bi-Phase *and* Manchester. Manchester coding does not
*have* to have a transition between bits.(But correct, in a way, if
you shift the Manchster code a half-bit to redefine the "middle"
and "between" of bits, but, IMHO, that does not make it easier to
understand how Manchster coding works...)

The Masters 2002 document that Steve pointed at clearifies this
pretty well.

Olin wrote:
> In this view, each bit can be thought of as being represented by the
> polarity of the bit edge, or the level of the 1/2 bit time immediately
> following the bit edge, or the inverse of the level of the 1/2 bit time
> immediately preceeding the bit edge.  These are all perfectly valid ways
> of talking about the same signal.  The difference is only in the words we
> use to describe it.

Correct for Manchester code, if we define "bit edge" as the edge in the
*middle* of a transmitted bit, yes. Now, other things written in this
thread has clearly been wrong for Manchester coding, so it's been a bit
confusing.. :-)

I'm stopping here, there are fine docs that clearly shows all this, the
Master PDF docs beeing on of the best, since it shows Bi-Phase and
Manchster side-by-side which clearly shows the confusion in this thread.


Regards, and my apologies to everyone who thought this should have been
moved out of [PIC] long ago...

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\10@223617 by David Huisman

flavicon
face
Olin,

"FAST" in this application means that I want to decode the incoming Serial bytes up to 64K Baud as they arrive with "plenty" of time left to do other tasks between
UART interrupt for next byte.
"plenty" = as much as I can get. as opposed to "not much" meaning very little time to perform other tasks. The oscillator is 16 MHz. I do not want to increase the
oscillator frequency or use the 4 x PLL.

where "other tasks" vary depending on the application.

Kind Regards

David Huisman


{Original Message removed}

2003\09\10@224024 by David Huisman

flavicon
face
Thanks all for your comments,

I have implemented a lookup table for now (with most of the values being 0).

I do want to consider the complement bit as this is a means of detecting
bytes that are in error (not part of Manchester code set), I then do not need to wait for the entire packet to arrive and process CRC etc to know it is invalid, I
can reset the UART and my starte machine immediately an incorrect byte is received.

Kind Regards

David Huisman


{Original Message removed}

2003\09\11@001931 by Scott Dattalo

face
flavicon
face
On Thu, 11 Sep 2003, David Huisman wrote:

> Olin,
>
> "FAST" in this application means that I want to decode the incoming Serial bytes
> up to 64K Baud as they arrive with "plenty" of time left to do other tasks between
> UART interrupt for next byte.
> "plenty" = as much as I can get. as opposed to "not much" meaning very little time
> to perform other tasks. The oscillator is 16 MHz. I do not want to increase the
> oscillator frequency or use the 4 x PLL.

David,

My interrupt driven Manchester decoder takes about 40 cycles to process an
edge. Of course, I could make it smaller, but there are several error
checks performed as well. For example, the width of the pulses are
validated (the skinny pulses can't be too narrow and the fat ones can't be
too wide), the Manchester stream must be valid (e.g. in between all wide
pulses are an even number of skinny pulses), etc. I use the CCP peripheral
to capture both the rising and falling edges. In fact my algorithm sounds
similar to what Olin described earlier. I posted this code snippet before,
but here it is again:


       MOVF    TC_LastRisingEdgeLo,W   ;Compute the time since the last
       SUBWF   CCPR1L,W                ;rising edge
       MOVWF   TC_CaptureLo            ;and save it.
                                       ;
       MOVF    TC_LastRisingEdgeHi,W   ;Compute the time for the high
       SUBWFB  CCPR1H,W                ;byte.
       MOVWF   TC_CaptureHi

       BTG     CCP1CON,CCP1M0          ;Toggle the polarity we'll capture
next.
       BCF     PIR1,CCP1IF             ;Clear the pending interrupt

       MOVF    TC_CaptureLo,W          ;Save the time captured for this
       ADDWF   TC_LastRisingEdgeLo,F   ;edge. if  X = new - old then
       MOVF    TC_CaptureHi,W          ; old + X = old + (new- old) =
new.
       ADDWFC  TC_LastRisingEdgeHi,F   ;


(this is for an 18f452, btw).

I'm not going to post the rest of the code here. If you want to see the
rest, contact me off line.

My Manchester data stream comes from an RF transmitter that emit's a
preamble pulse followed by 32 Manchester encoded bits. The preamble pulse
is carefully chosen to be an integer multiple of the width of the bit
time. In this way, I can accept a wide range of Manchester frequencies.


> where "other tasks" vary depending on the application.

This is not too untypical! In my case, there are about 6 other major
tasks (two other comm links, a data base for storing these Manchester
streams, low power management, etc...)


To achieve 64k data rates, it's going to be hard to have all of the error
checking too. But then again, you're data stream may be constrained in
some other way (thus making it unnecessary to verify the pulse widths are
valid, for example).  So, what does your data stream look like?

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@010437 by David Huisman

flavicon
face
Scott,

The data stream is generated by a UART at the remote end.
The 8 bit NRZ data (Start,data,Stop) is converted to "pseudo" Manchester and sent as 2 bytes per value. The over-air rate is up to 64K Baud.
The packet structure is Preamble, lead-in sequence, data, CRC1,CRC2(16 bit CRC)
(Data is prefixed by a routing header of 5 bytes and the data field itself
can be 1 to 235 bytes -encapsulated Modbus packet).
Kind Regards

David Huisman


{Original Message removed}

2003\09\11@023816 by Mike Singer

picon face
David Huisman wrote:
> The data stream is generated by a UART at the remote end.
> The 8 bit NRZ data (Start,data,Stop) is converted to "pseudo"
> Manchester and sent as 2 bytes per value. The over-air rate
> is up to 64K Baud.

Why Asynchronous mode, why not synchronous transmission?

Are you guaranteed to send bytes each after each with
0 delay not to compromise Manchester synchronization?

Regards,

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@031215 by David Huisman

flavicon
face
Mike,

Why Synchronous ?
Why not let the UART do the work instead of processing each Bit, you only have to process at byte times ?

To answer your question (it seems many of us would make good politicians by answering a question with another question).

To date I have been using Asychronous "psuedo" manchester encoded packet transmissions to achieve
reliable radio data communications. The implementation is simple and been in operation over the last 3 years in hundreds of locations. The question has come about because I want to achieve MORE processing between reception of data bytes from the rf link. The current firmware uses a bit shifting comparison and construction technique that is time consuming compared to using say a lookup table (particularly on the RX side). I want to process the bytes as soon as they arrive and check for invalid manchester codes as well as determining if this particular radio node is currently being addressed, if it is not then the unit can reset it's RX state machine and go away and do other things till another packet header is received.
ie. At present, the entire packet is placed into a buffer 506 bytes (can be reduced by half if I decode the bytes before placing them in a buffer), and then decoded and checked.

So... back to the original issue. I can implement a lookup table of 256 entries for decode and 16 for encode. positions within the 256 byte array only have values if they are valid mancehster codes.
(if I receive say "0x56", then the valuer in the array at 0x56 would be "1". (Nibble decoded).

What I was asking is if there is another way of implementing some form of pointer to a value that is significantly faster than how it was being done before.

Yes, the data is sent as a continuous stream.
Even though the longest string of "1" or "0" using this method is 3 bit periods, the average DC over a byte time is still 50%. My slicer is set to integrate over 3 byte periods so the DC reference does not
change enough to noticebly effect reliability. The integration also helps to reduce transient noise from effecting recovered bits in the data stream.


Kind Regards

David Huisman

{Original Message removed}

2003\09\11@031423 by

picon face
part 1 618 bytes content-type:text/plainScott Dattalo wrote:
>..., the Manchester stream must be valid (e.g. in between all wide
> pulses are an even number of skinny pulses)

I don't understand this. Is this in accordance with the picture
on page 17 of document 625BRF.PDF from Masters 2002 ? And if so,
what on this picture is an "even number of skinny pulses" ? Do
you count both high and low pulses as "pulses" ?

I'v cut out that picture and attached it. I hope it gets throught...

Jan-Erik.


--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




part 2 18563 bytes content-type:image/jpeg; (decode)

2003\09\11@080922 by Olin Lathrop

face picon face
> "FAST" in this application means that I want to decode the incoming
> Serial bytes
> up to 64K Baud as they arrive with "plenty" of time left to do other
> tasks between
> UART interrupt for next byte.

Then you do need some sort of hardware assist.  However, how are you going
to run a manchester stream into a UART?  Where does the clock information
come from?  Even if the incoming clock rate is accurately known, you still
need to synchronize the phase of a local clock.  The PIC UART won't do
this for you.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@095028 by Scott Dattalo

face
flavicon
face
On Thu, 11 Sep 2003, Jan-Erik Soderholm XA (TN/PAC) wrote:

> Scott Dattalo wrote:
> >..., the Manchester stream must be valid (e.g. in between all wide
> > pulses are an even number of skinny pulses)
>
> I don't understand this. Is this in accordance with the picture
> on page 17 of document 625BRF.PDF from Masters 2002 ? And if so,
> what on this picture is an "even number of skinny pulses" ? Do
> you count both high and low pulses as "pulses" ?
>
> I'v cut out that picture and attached it. I hope it gets throught...

Hmm, I guess my scientific description is too vague!


By a skinny pulse, I mean one that is equal to one half of a bit time. A
fat pulse is one equal to a whole bit time. Now, by pulse I mean both high
and low (i.e. most often "pulse" means just high). In the example you
attached, start in the middle of the first bit:

fat high
skinny low
skinny high
fat low
fat high
fat low
skinny high
skinny low
fat high


All I'm saying is that there always an even number of skinny pulses
between a fat pulse.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@103320 by Herbert Graf

flavicon
face
> David Huisman wrote:
> > The data stream is generated by a UART at the remote end.
> > The 8 bit NRZ data (Start,data,Stop) is converted to "pseudo"
> > Manchester and sent as 2 bytes per value. The over-air rate
> > is up to 64K Baud.
>
> Why Asynchronous mode, why not synchronous transmission?

       Doing synchronous over an air interface becomes "interesting", much easier
to do it async. TTYL

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@130753 by Mike Singer

picon face
part 1 324 bytes content-type:text/plain; (decoded 7bit)

Jan-Erik Soderholm XA wrote:
> I'v cut out that picture and attached it. I hope it gets throught...

The same picture but 1.8K instead of 18K :-)

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




part 2 1883 bytes content-type:image/tiff; (decode)

2003\09\11@152653 by Ian Bell

flavicon
face
On Thursday 11 Sep 2003 3:41 am, you wrote:
> Olin,
>
> "FAST" in this application means that I want to decode the incoming Serial
> bytes up to 64K Baud as they arrive with "plenty" of time left to do other
> tasks between UART interrupt for next byte.

Assuming 64K baud, one UART byte (data nibble) comes in every 125uS.  With a
16MHz clock that gives us four instructions per uS so we have 500
instructions available per UART byte to split between decode and other
things.

> "plenty" = as much as I can get. as opposed to "not much" meaning very
> little time to perform other tasks. The oscillator is 16 MHz. I do not want
> to increase the oscillator frequency or use the 4 x PLL.
>
> where "other tasks" vary depending on the application.
>

So the big question is what percentage of these 500 instructions are you
prepared to allocate to the decode?  It is not necessary to be exact at this
stage but a rough guess like 10%, 25% or 50% will do.

Ian

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@153240 by Ishaan Dalal

flavicon
face
> The same picture but 1.8K instead of 18K :-)
>
> Mike.

I believe you've just invented the "Fax and then photocopy and fax again"
effect! :-D

Cheers,
Ishaan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@160226 by

picon face
Scott Dattalo wrote:

> On Thu, 11 Sep 2003, Jan-Erik Soderholm XA (TN/PAC) wrote:
>
> > Do you count both high and low pulses as "pulses" ?
>
> By a skinny pulse, I mean one that is equal to one half of a bit time. A
> fat pulse is one equal to a whole bit time. Now, by pulse I mean both high
> and low...

Aha ! That clarifies things :-)

Best Regards
Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@161301 by Mike Singer

picon face
David Huisman wrote:
> Why Synchronous ?
>
> Why not let the UART do the work instead of processing
> each Bit, you only have to process at byte times ?
>
> To answer your question (it seems many of us would make good
> politicians by answering a question with another question).

I have a question to answer your question too :-)

Who said that in synchronous mode you have to process each Bit?

Let's take "USART Synchronous Master Reception" for 18F PICs.
Internal synchronization, even double buffered byte reception.

Let remote transmitter work at double frequency in a synchronous
mode. Line idle state is continues Manchester-2 "0".

Each edge resets some timer on receiver (well, processing each
Bit, but just a little); Non-resetting the timer triggers
interrupt to start receiving data packet.( Non-resetting the
timer is caused by long enough "0"). Perhaps there is a better
way to start receiving.

Since receiver works at half transmitter frequency, it can see
only every other (i.e. data) transmitted bit.

Correct me if I'm wrong, please.

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@182529 by

picon face
Mike Singer wrote:

> Each edge resets some timer on receiver (well, processing each
> Bit, but just a little); Non-resetting the timer triggers
> interrupt to start receiving data packet.( Non-resetting the
> timer is caused by long enough "0"). Perhaps there is a better
> way to start receiving.
>
> Since receiver works at half transmitter frequency, it can see
> only every other (i.e. data) transmitted bit.

Isn't the receiver sampling the line three times each "bit" ?
You have to have these three samples in the first half of
each bit, not ? If not, you will always end up with
at least one sample that is different from the other two ?
And you don't know (or the UART don't know) if it's the single
different value that is correct, or if it's the other two.
I think it will always select the two similar, but in this case
it can be the single different value that is the correct one,
depending on how the three samples are spread inside the "bit".

I might be missing something...

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@183241 by David Huisman

flavicon
face
Olin,
What on earth are you talking about ?

The data transmission is Asynchronous. No clock required. The data is sent
at a fixed Baud rate. The Uart synchronizes at the frame level using START and STOP bits.
Reread my orgininal question, it relates to finding a "faster" way of decoding
the received data, the problem is not in decoding data. The current algorithm
does this fine, I want to speed up the decode process to enable more idle time between
each incoming byte to perform other processes.

Kind Regards

David Huisman

{Original Message removed}

2003\09\11@184033 by

picon face
David Huisman wrote:

> The data transmission is Asynchronous. No clock required. The data is sent
> at a fixed Baud rate. The Uart synchronizes at the frame level using START
> and STOP bits.


Sorry, I don't follow...

You are using a start and a stop bit, right ?
And what in between ? 8 bits ?
Are these 8 bits sent as Manchester code ? So they represent
4 "real" bits ?

So two "bytes" sent over your link, represents one "real" byte
after the Manchester coding is decoded ?

Jan-Erik.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@184653 by David Huisman

flavicon
face
What is difficult with the idea of "getting as much free idle time as possible" ?

The lookup table I recently implemented works and speeds up the process but I don't
like the idea of having over 200 buts of ROM used up as place holders in the decode table.
Only 16 are used.

Thus the original question, does someone have a better way of implementing the lookup table (or some similar algorithm) that is more efficient.

"More" meaning does not require 256 bytes of ROM.

The perfect scenario is that it could do the decoding in ZERO time. (unless we operate in some other dimension rather than time, this may be difficult).
The least amount of time sent in the interrupt processing the incoming bytes, the better.

This is simply a tool. It is a solution that goes into a code library and is common to
many of my new developments that allows "more" processing to occur between incoming bytes
regardless of the application.


Kind Regards

David Huisman


{Original Message removed}

2003\09\11@184904 by David Huisman

flavicon
face
Mike,


We cannot have a transmitter sending ANYTHING in idle state.

The radio network is multipoint and must be free as much of the time as possible.
An idle condition in my system is no transmission at all.

Kind Regards

David Huisman


{Original Message removed}

2003\09\11@185524 by David Huisman

flavicon
face
YES, exactly

0x23 (00100011)

becomes 01011001  01011010

then the uart adds start and stop bit and sends lsb first
So, transmitted data = ST  DATA   STOP   ST   DATA   STOP
0 10011010  1     0  01011010  1  
Each byte is DC balanced over the byte period.
Coding is "psuedo manchester" wher a "0" = "01" and 1" = "10"
Framing is standard Asynchronous Start Data Stop and is UART compatible.

(Of course there is a header that provides preamble for data slicer conditioning
and run in byte pattern to ensure UART sunchs to correct start bit and CRC16 at end)

Kind Regards

David Huisman

{Original Message removed}

2003\09\11@193928 by Andrew Warren

flavicon
face
David Huisman <.....PICLISTKILLspamspam@spam@mitvma.mit.edu> wrote:

> The lookup table I recently implemented works and speeds up the
> process but I don't like the idea of having over 200 buts of ROM
> used up as place holders in the decode table. Only 16 are used.
>
> Thus the original question, does someone have a better way of
> implementing the lookup table (or some similar algorithm) that is
> more efficient.

David:

I don't know how you do it; I wouldn't have the patience to keep
replying to the useless responses to your simple query.  Anyway,
here's code that does what you want, I think, and requires no lookup
table:

   RRF   INPUT,W     ;Rudimentary error-checking... Make sure
   XORWF INPUT,W     ;each pair of bits contains a 1 and a 0.
   ANDLW 01010101B   ;
   XORLW 01010101B   ;
   BNZ   ERROR       ;If there's an error, exit.  Otherwise,
                     ;continue with W = 0.

   BTFSC INPUT,0     ;Copy INPUT bits 0, 2, 4, and 6
   ADDLW 1           ;to W bits 0, 1, 2, and 3.
   BTFSC INPUT,2     ;
   ADDLW 2           ;
   BTFSC INPUT,4     ;
   ADDLW 4           ;
   BTFSC INPUT,6     ;
   ADDLW 8           ;The decoded nibble is in bits 0-3 of W.

14 cycles per decoded nibble; you'll need a few more to combine pairs
of nibbles into bytes, but it should be under 40 cycles per decoded
byte, including loop overhead... Which means that it'll use about
four percent of the time you have available, leaving 96 percent for
other stuff.

-Andy

P.S.  As usual with the code I post here, the above has neither been
     tested nor even assembled.  You get, at most, what you pay for.

=== Andrew Warren -- aiwspamKILLspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\11@233049 by Scott Dattalo

face
flavicon
face
On Thu, 11 Sep 2003, David Huisman wrote:

> Scott,
>
> The data stream is generated by a UART at the remote end.
> The 8 bit NRZ data (Start,data,Stop) is converted to "pseudo"
> Manchester and sent as 2 bytes per value. The over-air rate is up to 64K Baud.
> The packet structure is Preamble, lead-in sequence, data, CRC1,CRC2(16 bit CRC)
> (Data is prefixed by a routing header of 5 bytes and the data field itself
> can be 1 to 235 bytes -encapsulated Modbus packet).


Got it.

What was confusing to me (and many others too I imagine), is that your
data stream is not a Manchester stream per se. Instead, you're using
Manchester simply as a means of getting a balanced or zero averaged (or
should I dare say a Scottish Mean :) data stream.

If all you really want is to maintain a balanced data stream, have you
consider other encodings other than Manchester? For the 8 bit positions,
you're only going to get 4-bits of data with manchester. However, I
believe there are 70 combinations of 8-bit patterns where there are 4 1's
and 4 0's (8! / (4! * 4!)). It may make since to reduce this down to just
64. BTW, Nikolai made this suggestion.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\09\12@003424 by Mike Singer

picon face
David Huisman wrote:
> We cannot have a transmitter sending ANYTHING in idle state.
> The radio network is multipoint and must be free as much of
> the time as possible. An idle condition in my system is no
> transmission at all.

  Don't send ANYTHING in idle state. Trigger data packet
receiving in some other way.

Best Regards,

Mike.


> {Original Message removed}

2003\09\12@004132 by Mike Singer

picon face
Jan-Erik Soderholm XA wrote:
{Quote hidden}

  The idea is that a receiver shifts data automatically on it's
own clock (half the transmitter frequency).
  How to trigger receiving? That's another question.

Mike.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@044425 by Ian Bell

flavicon
face
On Thursday 11 Sep 2003 11:39 pm, you wrote:
> David Huisman wrote:
> > The data transmission is Asynchronous. No clock required. The data is
> > sent at a fixed Baud rate. The Uart synchronizes at the frame level using
> > START and STOP bits.
>
> Sorry, I don't follow...
>
> You are using a start and a stop bit, right ?
> And what in between ? 8 bits ?
> Are these 8 bits sent as Manchester code ? So they represent
> 4 "real" bits ?
>
> So two "bytes" sent over your link, represents one "real" byte
> after the Manchester coding is decoded ?
>
> Jan-Erik.
>


That's how I read the original post.

Ian

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@044632 by Ian Bell

flavicon
face
On Thursday 11 Sep 2003 11:46 pm, you wrote:
> What is difficult with the idea of "getting as much free idle time as
> possible" ?
>
> The lookup table I recently implemented works and speeds up the process but
> I don't like the idea of having over 200 buts of ROM used up as place
> holders in the decode table. Only 16 are used.
>
> Thus the original question, does someone have a better way of implementing
> the lookup table (or some similar algorithm) that is more efficient.
>
> "More" meaning does not require 256 bytes of ROM.
>

So to give us a marker for what would be 'better', how long does you current
look up table take to decode and what total memory (code plus table) does it
use?

Ian

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@071716 by Olin Lathrop

face picon face
> What on earth are you talking about ?
>
> The data transmission is Asynchronous. No clock required. The data is
> sent
> at a fixed Baud rate. The Uart synchronizes at the frame level using
> START
> and STOP bits.

You had originally said this was a manchester encoded bit stream.  Such a
bit stream does not have start and stop bits.  There is no hardware module
on a PIC that will interpret native manchester data directly.  You finally
explained you weren't doing real manchester in a post after mine you are
replying to.

So, I think we finally understand what you are really doing.  You are
sending bytes over RS-232, except that the transmission medium is RF
instead of a wire.  Because of that, you need the average DC level to be
about 1/2 way between the 1 and 0 bit states so that the receiver AGC and
descriminator can be most effective.  Is this correct?  (If it is, you
could have saved a lot of trouble by saying so in the first place).

Assuming the above is correct, you then decided to use manchester encoding
on the 8 data bits because this is known to produce an equal number of 1s
and 0s over short intervals.  This is the part that doesn't make sense.
There are lots of ways to encode 4 bits into 8 so that there are always 4
0s and 4 1s.  I doubt the RF receiver will have a problem if the signal
averages to 1/2 over an 8 bit interval instead of a 2 bit interval.  Why
not just send the 4 bits in the low nibble and the complement of the bits
in the high nibble?  This makes both encoding and decoding trivial.  I
have done exactly this with RF communication, and it worked fine.

> Reread my orgininal question,

I've got things to do, and that's not one of them.

> it relates to finding a "faster" way of
> decoding
> the received data, the problem is not in decoding data. The current
> algorithm
> does this fine, I want to speed up the decode process to enable more
> idle time between
> each incoming byte to perform other processes.

As is often the case, the wrong question was asked in the first place or
the explanation was inconsistant.  You seem frustrated that someone didn't
just plunk down a solution for the question you asked.  It doesn't work
that way, get over it.  There were inconsistancies and things that didn't
make sense in your problem statement, which is why most people were trying
to drill down to what is really happening rather than giving the solution
to the wrong problem.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@090112 by Bob Ammerman

flavicon
face
The OP  is just sending normal ASYNC over the air.

He is encoding bits within a byte in a pseudo-Manchester scheme to ensure
long term 0:1 ratio is 50% on the  wire to keep the data slicer happy.

The user is depending on  the receiver recognizing the start bit correctly,
which is problematic at best. I have written a document on piclist.com
(http://www.piclist.com/techref/microchip/ammermansync.htm) that outlines
how you can use a specially formatted preamble to assure byte
synchronization. Hopefully this prefix won't confuse the data slicer too
much trouble.


Bob Ammerman
RAm Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@093647 by Mike Harrison

flavicon
face
On Thu, 11 Sep 2003 18:34:19 -0400, you wrote:

>The OP  is just sending normal ASYNC over the air.
>
>He is encoding bits within a byte in a pseudo-Manchester scheme to ensure
>long term 0:1 ratio is 50% on the  wire to keep the data slicer happy.
>
>The user is depending on  the receiver recognizing the start bit correctly,
>which is problematic at best. I have written a document on piclist.com
>(http://www.piclist.com/techref/microchip/ammermansync.htm) that outlines
>how you can use a specially formatted preamble to assure byte
>synchronization. Hopefully this prefix won't confuse the data slicer too
>much trouble.

Of course another really easy to get DC balance would be to send each byte then send the same byte
inverted - this would ensure DC balance over 2 bytes, which may well be enough.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@110204 by

picon face
Bob Ammerman wrote:

> The user is depending on  the receiver recognizing the start bit correctly,
> which is problematic at best.

Why ?
He is using the UART as an async UART, and hence uses normal,
standard start/stop bits. It's of no importance that the
higher level software then decodes the "bytes" as Manchster code...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@112037 by Tal

flavicon
face
Why do radio link care about the average DC of the encoded data ? Does
this apply to all forms of radio modulation ?

Thanks,

Tal

> {Original Message removed}

2003\09\12@112038 by Tal

flavicon
face
There are seventy eight-bit numbers with exactly four 1's which means
that you can send 6 bits per byte. This may require a larger table
though (e.g. 64 entries for encode table and 256 entries for decode
table).

If you are sending only 4 bits per byte, you may have more evenly spaced
combinations such as Olin's 4 complement bits idea but interleaving the
data and the complement bits.

Tal

> {Original Message removed}

2003\09\12@112834 by Wouter van Ooijen

face picon face
FYI for anyone following this discussion: a constant average amplitude
(which is the issue here, at least in my idea) encoding will also
greatly benefit IR transmission that is received by a standard packaged
IR receiver (TSOP, Sharp, Waytronics, etc). The reason is the same as
for radio transmission: an AVR circuit can not work wel if the (average)
amplitude varies a lot.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@112835 by Olin Lathrop

face picon face
> Why do radio link care about the average DC of the encoded data ?

It makes it easier to set the gain, and to decide where the threshold
between a 0 and 1 is.

> Does this apply to all forms of radio modulation ?

No, but it does apply to AM (amplitude modulation).  In most cases, the
bit stream into the transmitter is just used to key the carrier on and
off.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@120820 by

picon face
It also applys to fiber optic transmissions.

The laser diod transmitters uses a design where a specific
fraction (a few %) of the output power is reflected back
to a photodiod. The measured level on this photodiod (after
smothing/integration) is then used to adjust the power to
the laser diod to keep a consistent laser output level.
Having a signal that has a known on/off ratio (as 50% in
the Manchester code case) makes it much easier to adjust
the power.

Jan-Erik.


> > Why do radio link care about the average DC of the encoded data ?
>
> It makes it easier to set the gain, and to decide where the threshold
> between a 0 and 1 is.
>
> > Does this apply to all forms of radio modulation ?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@142749 by Ian Bell

flavicon
face
On Friday 12 Sep 2003 4:01 pm, you wrote:
> Bob Ammerman wrote:
> > The user is depending on  the receiver recognizing the start bit
> > correctly, which is problematic at best.
>
> Why ?
> He is using the UART as an async UART, and hence uses normal,
> standard start/stop bits. It's of no importance that the
> higher level software then decodes the "bytes" as Manchster code...
>

Indeed not, but it IS important that there is no dc connection between the
transmitting and receiving UARTS which is what makes sart bit detection
difficult.

Ian

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@152405 by Daniel Serpell

flavicon
face
El Thu, Sep 11, 2003 at 08:30:08PM -0700, Scott Dattalo escribio:
>
> If all you really want is to maintain a balanced data stream, have you
> consider other encodings other than Manchester? For the 8 bit positions,
> you're only going to get 4-bits of data with manchester. However, I
> believe there are 70 combinations of 8-bit patterns where there are 4 1's
> and 4 0's (8! / (4! * 4!)). It may make since to reduce this down to just
> 64. BTW, Nikolai made this suggestion.

Or he could also use some ECC code, so single bit errors can be
corrected. If it's allowed to have up to one "1" more than "0"'s,
then you can use the ECC sequence:

  07 19 2b 34 4c 65 8a 9c a6 ad b1 c9 d2 d5 e3 f8

to encode 4 bits. Perhaps better would be:

  13 1c 27 4d 56 75 7a 8e 95 ab b6 b8 c2 d9 e1 ec

if large runs of zeros or ones are not allowed.

   Daniel.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@202320 by Bob Ammerman

picon face
> Bob Ammerman wrote:
>
> > The user is depending on  the receiver recognizing the start bit
correctly,
> > which is problematic at best.
>
> Why ?
> He is using the UART as an async UART, and hence uses normal,
> standard start/stop bits. It's of no importance that the
> higher level software then decodes the "bytes" as Manchster code...

Because he really doesn't have a good idea of where the start of the message
is. Typically the receiver will either be generating noise on its digital
output, or possibly squelch will keep it quiet. In either case, the UART can
easily see the wrong bit as the start of things (it can't tell a real start
bit from a data bit).

Bob Ammerman
RAm Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@203603 by Mike Harrison

flavicon
face
On Fri, 12 Sep 2003 12:54:39 -0400, you wrote:

>> Bob Ammerman wrote:
>>
>> > The user is depending on  the receiver recognizing the start bit
>correctly,
>> > which is problematic at best.
>>
>> Why ?
>> He is using the UART as an async UART, and hence uses normal,
>> standard start/stop bits. It's of no importance that the
>> higher level software then decodes the "bytes" as Manchster code...
>
>Because he really doesn't have a good idea of where the start of the message
>is. Typically the receiver will either be generating noise on its digital
>output, or possibly squelch will keep it quiet. In either case, the UART can
>easily see the wrong bit as the start of things (it can't tell a real start
>bit from a data bit).

I think there may be some confusion arisin here - I was under the impression that the issue was
generating RF -suitable data patterns from TX uart. I don't think anyone was proposing trying to receive it via a uart - if so, it's really not a good
idea. What you typically see is noise, then the preamble, which stabilises the gain and the data slicer,
then you need some synchronisation pattern or gap to define the byte framing. A bit-bashed receiver (or interrupt driven, or using input capture hardware) which can deal with all
the rubbish correctly is not hard to implement and will be much more reliable than trying to bend a
UART into doing something it's not deaigned for.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\09\12@213706 by Bob Ammerman

picon face
Mike Harrison:

I think there may be some confusion arisin here - I was under the impression
that the issue was
generating RF -suitable data patterns from TX uart.
I don't think anyone was proposing trying to receive it via a uart - if so,
it's really not a good
idea.
What you typically see is noise, then the preamble, which stabilises the
gain and the data slicer,
then you need some synchronisation pattern or gap to define the byte
framing.
A bit-bashed receiver (or interrupt driven, or using input capture hardware)
which can deal with all
the rubbish correctly is not hard to implement and will be much more
reliable than trying to bend a
UART into doing something it's not deaigned for.

Bob Ammerman:

Ah.... but that is the neat trick here. You can use the way the UART handles
framing errors to get you properly into byte sync. See
http://www.piclist.com/techref/microchip/ammermansync.htm for the details.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2003\09\13@053958 by Mike Harrison

flavicon
face
On Fri, 12 Sep 2003 21:33:45 -0400, you wrote:

{Quote hidden}

Very clever solution , but quite a few downsides : Very wasteful of airtime (4 bytes to sync instead of 2 bits) - a significant issue wheer you have
several transmitters sending short packets,  and the sync patterns are not DC free. Using a UART for receive also requires that the TX and RX have reasonable clock frequeny accuracy
(at least a cearmic resonator), and it will have poorer margin for the varying pulse widths that are
typical typically occur under poor link quality conditions. A true manchester encode/decode system is very simple to code, and overcomes all these restrictions.
I recently did this on an AVR - 20 instructions for byte-transmit, and about 40 for receive. Of course this is a little more CPU intensive, although doing it under interrupts would not be much
harder and would allow other stuff to be happenning simultaneously with receive.
--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2003\09\13@134214 by Marcelo Puhl

flavicon
face
On 13 Sep 2003 at 10:35, Mike Harrison wrote:

> A true manchester encode/decode system is very simple to code, and overcomes
> all these restrictions. I recently did this on an AVR - 20 instructions for
> byte-transmit, and about 40 for receive.

       Would it be possible to see that AVR code? ;-)

       Thanks.
       Mark, PY3SS

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2003\09\13@190155 by Mike Harrison

flavicon
face
On Sat, 13 Sep 2003 14:38:29 -0300, you wrote:

>On 13 Sep 2003 at 10:35, Mike Harrison wrote:
>
>> A true manchester encode/decode system is very simple to code, and overcomes
>> all these restrictions. I recently did this on an AVR - 20 instructions for
>> byte-transmit, and about 40 for receive.
>
>        Would it be possible to see that AVR code? ;-)

Sorry, no as it was developed for a customer's product. If you look at an earlier post from me on
this thread it outlines how it works.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu

2003\09\14@211348 by David Huisman

flavicon
face
Yes, I do receive via the UART. The signal out of the radio module
is TTL level with practically no noise in absence of a transmitted signal. The UART does synchronize reliably due to the run-in header
after the preamble.
The question was never how to get reliable RF coms link (I already have this)



Kind Regards

David Huisman

{Original Message removed}

2003\09\14@212427 by David Huisman

flavicon
face
Olin,

Very simple. If you don't understand the question or don't have the
time or interest to ask further questions then why bother to reply ??

I am grateful to all those who replied.
If you are involved in commercial enterprise, how do you deal with
customers (in the real world) who invariably do not supply all relevant information from the beginning ?
As much as I appreciate your desire to help develop my communication
skills, I would appreciate it even more if you took the time to ask
if you needed more information in order to offer constructive advice.

Some people are more intuative than others (as shown by others on the list
who did understand the context of my question from the beginning).

As for frustration, my only frustration (mild), is those who have time to
find a point of argument but not the time to find out the real issue
and help.

Kind Regards

David Huisman


{Original Message removed}

2003\09\15@071509 by Mike Harrison

flavicon
face
On Mon, 15 Sep 2003 11:12:29 +1000, you wrote:

>Yes, I do receive via the UART. The signal out of the radio module
>is TTL level with practically no noise in absence of a transmitted
>signal. T
Until a new local interference source comes along.....

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\09\16@073246 by Morgan Olsson

flavicon
face
part 1 911 bytes content-type:text/plain; charset="us-ascii"Mike Singer wrote 03-09-11:
>Jan-Erik Soderholm XA wrote:
>> I'v cut out that picture and attached it. I hope it gets throught...
>
>The same picture but 1.8K instead of 18K :-)

How clumsy! ;)
Why not use png?  http://www.libpng.org/
Attached 1.1K png exact copy of your tif, converted by http://www.irfanview.com/

Interesting discussion all - thanks!

Another way of somewhat balancing is to use NRZ and allow to send X number of consecutive hi or low, and whwen X is reached the sender inserts a dummy bit of opposite polarity.  As also the reciever is aware and counts to X it now expects the dummy bit and ignores it.
This give high bitrate and enough "balance" for most applications.

IIRC, CAN does this on the physical level, with X=5.

/Morgan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



part 2 1199 bytes content-type:image/png; name="manch.png" (decode)


part 3 164 bytes content-type:text/plain; charset="us-ascii"
--
Morgan Olsson, Kivik, Sweden

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...