Help! Need to know how to doManchesterEncoding/Decoding
Archiver
Posts: 46,084
Hi Tracy,
For the shiftout I had the idea of providing a dummy pin for the clock and
use only the datastream output.
This output stops if the stamp executes another statement and that does pose
a serious problem.
Looks to me there is still need for a free running external clock to get
this going (same applies to receiver end).
Therefore I suggested the rs232 routines to work with rs232 based
transmitter/receivers.
Personally I do not see the benefits to apply manchester coding (at the data
logic level) as it creates
the word synchronization problem.
I provided them for Debu as he said it had to be used. I think byte oriented
datapackets with checksums
are much better suited to get reliable datatransfers. I think Debu should
really discuss with its instructor
the necessity to have this coding as there are better alternatives. So far I
have not seen any response
from Debu, so it is still a bit unclear to me why exactly this coding was
required.
Regards peter
Oorspronkelijk bericht
Van: Tracy Allen [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=xXCJd4zhPsGA7y3HNZRAk3x_2yNxTIsdHOnbVmd8OhbbbOg_0DRzFiIbUGChrlhA0FDl8iqPN1E7c_dZvj_b]tracy@e...[/url
Verzonden: zaterdag 3 november 2001 19:18
Aan: basicstamps@yahoogroups.com
Onderwerp: RE: [noparse][[/noparse]basicstamps] Re: Help! Need to know how to
doManchesterEncoding/Decoding
Hi Peter, and Debu,
>Hi,
>
>I meant the shiftout instruction, sorry about that.
>The serout can not be used for Manchester coding due to the serial
>start/stop bits.
Not only that, shiftout needs its clock signal, which the Stamp
provides on a separate pin. Are you proposing that the clock signal
be sent through a separate radio link? On the receiving end it seems
to me the system would require an external chip to receive the data,
because the stamp shiftin command does not use an external clock.
The shiftin command operates in master, not slave mode.
Manchester coding scheme does not need a separate clock signal,
because its hardware recovers the clock from the transmitted data by
means of a phase lock loop. There has to be a preamble to the data,
a steady stream of on-off-on-off so that the loop can phase-lock to
the "0" state of the signal and can then detect the "1" of the start
bit. The Stamp can't do any of that without help from external
hardware.
>Debu did not specify the transmitter/receiver set he uses, but the
available
>RF
>transmitter/receiver sets that accept/generate standard rs232 would already
>implement some coding like manchester to get rid of any DC component and
>to synchronize clocks. This is all transparent.
I think to get that, you have to spend more than $50 each for the
transmitter and receiver. Cheap modules that cost around $10 are
most certainly simple on-off keyed transmitters and straight-through
AM receivers.
>The best way to go is to
>focus
>on datapackets and perhaps some error recovery methods, as suggested by
>Tracy.
>There is really no need to implement manchester coding for these RF sets.
>However, if all you have is a very simple transmitter you must modulate
>the datastream yourself. That is no easy task for a stamp!
>
>Assuming you have an RF set that accepts rs232
The RF set accepts anything that turns the transmitter on and off, up
to a certain rate, that may max out at, say, 2400 baud.
>consider the following
>if you must apply manchester coding
>
>'TRANSMITTER
>charin var byte 'holds ASCII or binary character to send
>wordout var word 'holds manchestercode for charin
>bitcount var nib 'bitcounter
>
>wordout=0
>for bitcount=0 to 7
> wordout=(wordout<<2)+charin.bit7+1 'add 1 or 2 after shifting
> charin=charin<<1 'move next bit to bit7 position
>next
>serout pin,baud,[noparse][[/noparse]wordout.lowbyte,wordout.highbyte]
>
>'RECEIVER
>charout var byte 'holds ASCII or binary character to receive
>chkout var byte 'holds the 'inverse' bits of charout
>wordin var word 'holds received manchestercode for charout
>bitcount var nib 'bitcounter
>
>serin pin,baud,timeout,label,[noparse][[/noparse]wordin.low,wordin.high]
>charout=0
>chkout=0
>for bitcount=0 to 7
> charout=(charout<<1)+wordin.bit15 'bit15 is original
>bit of charin
> chkout=(chkout<<1)+wordin.bit14 'bit14 is inverse of bit15
> wordin=wordin<<2
>next
>if charout^chkout<>0 then errorlabel 'the xor result is 0 if ok
>'process charout here
>
>errorlabel:
>'handle errors here
>
>One special error is when the received wordin holds the highbyte of a sent
>word
>and the lowbyte of the next sent word. You could use a pause to synchronize
>the
>reception of words.
>
Nice program, Peter! I can't think of any way to eliminate the loop
structure to speed it up. Right, it is a tough one for the Stamp.
The issue of how to send and receive wordout and wordin remains,
given the need for a phase lock loop to recover the clock.
I think one could get pretty good results with asynchronous serout
and serin with this scheme though, kind of like you suggested in a
previous message. This would not be Manchester coding at the
physical layer, but it would address some of the issues of AM rf data
transmission. The main idea is to avoid long sequences of zeros in
the data stream. Set up the transmission and reception of the
Manchester encoded data as two serial bytes.
xmt:
'from Peter's code:
high 0 ' turn transmitter on
serout 0,$186,[noparse][[/noparse]wordout.byte0,wordout.byte1]
' transmitter is keyed off for start bit and zero bits only
' transmitter is otherwise on
low 0 ' turn transmitter off
rcv:
serin 0,baudmode,[noparse][[/noparse]wordin.byte0,wordin.byte1]
' to Peter's code
' the note about synchronization error still applies.
That addresses the issue that receivers are more sensitive to noise
in the off state than in the on state. The simple AM receivers do
not have any AGC circuitry, but if they did, that would kick in in
response to long sequences of 1s as well, and true Manchester would
certainly be called for. Simple receivers do not have AGC. They are
saturated by the rf signal, so that is why they are more sensitive to
noise when the transmitter is off. As the distance increases and the
signal to noise ratio degrades, the saturation in the on state is
also uncertain. The need for packetized data, CRCs etc becomes more
important. That is true whether or not Manchester encoding is
implemented.
Debu, do you think your instructor would let you get away with this
kind of "logic-layer" Manchester encoding for your assignment?
>
>
>Good luck, peter
--likewise,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
For the shiftout I had the idea of providing a dummy pin for the clock and
use only the datastream output.
This output stops if the stamp executes another statement and that does pose
a serious problem.
Looks to me there is still need for a free running external clock to get
this going (same applies to receiver end).
Therefore I suggested the rs232 routines to work with rs232 based
transmitter/receivers.
Personally I do not see the benefits to apply manchester coding (at the data
logic level) as it creates
the word synchronization problem.
I provided them for Debu as he said it had to be used. I think byte oriented
datapackets with checksums
are much better suited to get reliable datatransfers. I think Debu should
really discuss with its instructor
the necessity to have this coding as there are better alternatives. So far I
have not seen any response
from Debu, so it is still a bit unclear to me why exactly this coding was
required.
Regards peter
Oorspronkelijk bericht
Van: Tracy Allen [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=xXCJd4zhPsGA7y3HNZRAk3x_2yNxTIsdHOnbVmd8OhbbbOg_0DRzFiIbUGChrlhA0FDl8iqPN1E7c_dZvj_b]tracy@e...[/url
Verzonden: zaterdag 3 november 2001 19:18
Aan: basicstamps@yahoogroups.com
Onderwerp: RE: [noparse][[/noparse]basicstamps] Re: Help! Need to know how to
doManchesterEncoding/Decoding
Hi Peter, and Debu,
>Hi,
>
>I meant the shiftout instruction, sorry about that.
>The serout can not be used for Manchester coding due to the serial
>start/stop bits.
Not only that, shiftout needs its clock signal, which the Stamp
provides on a separate pin. Are you proposing that the clock signal
be sent through a separate radio link? On the receiving end it seems
to me the system would require an external chip to receive the data,
because the stamp shiftin command does not use an external clock.
The shiftin command operates in master, not slave mode.
Manchester coding scheme does not need a separate clock signal,
because its hardware recovers the clock from the transmitted data by
means of a phase lock loop. There has to be a preamble to the data,
a steady stream of on-off-on-off so that the loop can phase-lock to
the "0" state of the signal and can then detect the "1" of the start
bit. The Stamp can't do any of that without help from external
hardware.
>Debu did not specify the transmitter/receiver set he uses, but the
available
>RF
>transmitter/receiver sets that accept/generate standard rs232 would already
>implement some coding like manchester to get rid of any DC component and
>to synchronize clocks. This is all transparent.
I think to get that, you have to spend more than $50 each for the
transmitter and receiver. Cheap modules that cost around $10 are
most certainly simple on-off keyed transmitters and straight-through
AM receivers.
>The best way to go is to
>focus
>on datapackets and perhaps some error recovery methods, as suggested by
>Tracy.
>There is really no need to implement manchester coding for these RF sets.
>However, if all you have is a very simple transmitter you must modulate
>the datastream yourself. That is no easy task for a stamp!
>
>Assuming you have an RF set that accepts rs232
The RF set accepts anything that turns the transmitter on and off, up
to a certain rate, that may max out at, say, 2400 baud.
>consider the following
>if you must apply manchester coding
>
>'TRANSMITTER
>charin var byte 'holds ASCII or binary character to send
>wordout var word 'holds manchestercode for charin
>bitcount var nib 'bitcounter
>
>wordout=0
>for bitcount=0 to 7
> wordout=(wordout<<2)+charin.bit7+1 'add 1 or 2 after shifting
> charin=charin<<1 'move next bit to bit7 position
>next
>serout pin,baud,[noparse][[/noparse]wordout.lowbyte,wordout.highbyte]
>
>'RECEIVER
>charout var byte 'holds ASCII or binary character to receive
>chkout var byte 'holds the 'inverse' bits of charout
>wordin var word 'holds received manchestercode for charout
>bitcount var nib 'bitcounter
>
>serin pin,baud,timeout,label,[noparse][[/noparse]wordin.low,wordin.high]
>charout=0
>chkout=0
>for bitcount=0 to 7
> charout=(charout<<1)+wordin.bit15 'bit15 is original
>bit of charin
> chkout=(chkout<<1)+wordin.bit14 'bit14 is inverse of bit15
> wordin=wordin<<2
>next
>if charout^chkout<>0 then errorlabel 'the xor result is 0 if ok
>'process charout here
>
>errorlabel:
>'handle errors here
>
>One special error is when the received wordin holds the highbyte of a sent
>word
>and the lowbyte of the next sent word. You could use a pause to synchronize
>the
>reception of words.
>
Nice program, Peter! I can't think of any way to eliminate the loop
structure to speed it up. Right, it is a tough one for the Stamp.
The issue of how to send and receive wordout and wordin remains,
given the need for a phase lock loop to recover the clock.
I think one could get pretty good results with asynchronous serout
and serin with this scheme though, kind of like you suggested in a
previous message. This would not be Manchester coding at the
physical layer, but it would address some of the issues of AM rf data
transmission. The main idea is to avoid long sequences of zeros in
the data stream. Set up the transmission and reception of the
Manchester encoded data as two serial bytes.
xmt:
'from Peter's code:
high 0 ' turn transmitter on
serout 0,$186,[noparse][[/noparse]wordout.byte0,wordout.byte1]
' transmitter is keyed off for start bit and zero bits only
' transmitter is otherwise on
low 0 ' turn transmitter off
rcv:
serin 0,baudmode,[noparse][[/noparse]wordin.byte0,wordin.byte1]
' to Peter's code
' the note about synchronization error still applies.
That addresses the issue that receivers are more sensitive to noise
in the off state than in the on state. The simple AM receivers do
not have any AGC circuitry, but if they did, that would kick in in
response to long sequences of 1s as well, and true Manchester would
certainly be called for. Simple receivers do not have AGC. They are
saturated by the rf signal, so that is why they are more sensitive to
noise when the transmitter is off. As the distance increases and the
signal to noise ratio degrades, the saturation in the on state is
also uncertain. The need for packetized data, CRCs etc becomes more
important. That is true whether or not Manchester encoding is
implemented.
Debu, do you think your instructor would let you get away with this
kind of "logic-layer" Manchester encoding for your assignment?
>
>
>Good luck, peter
--likewise,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Comments
>logic level) as it creates
>the word synchronization problem.
>I provided them for Debu as he said it had to be used. I think byte oriented
>datapackets with checksums
>are much better suited to get reliable datatransfers.
I agree.