So I received my neat little RLP/TLP units today, and I decided to jump right into Manchester encoding after a simple test of transmitting/receiving 'A’s.
Anyway, I’m using an ATTiny2313 and after a few hours I sorted everything out and finished the Manchester Encoding and Decoding routines. The Manchester Encoded Data is actually encapsulated in hardware UART transmissions, like this article shows it: http://www.quickbuilder.co.uk/qb/articles/.
I hope this helps others. I have only tested it with a wired serial port, but it seems to be 100% perfect through there. If I messed up anywhere, I’d be happy to know where to fix my mistake.
My hardware UART is setup for 8 data bits, and one stop bit (no parity). I know that the start bit is a logic 0, and that the stop bit is a logic 1, so the balance of number of ones and zeroes still remains when the data contained in the UART packet is manchester encoded.
I’m still looking into the preamble messages, but the article I mentioned established some system of using them (see under Application->Start data frame). I’ll get back to you here once I’ve figured some more of this stuff out
I like this idea. It seems like it wouldn’t be possible to send arbitrary Manchester-encoded messages, but if every fifth bit manchester bit is dedicated to the start/stop bits, then that’s OK.
On the other hand, the UART will only resynchronize on the start bit, not on every bit like in a real Manchester decoder. Probably good enough for almost all of the time, though.
Yeah, I guess in this case I’m just using Manchester encoding just to distinguish crap data from real data coming in. I don’t think the receiver will be able to maintain the clock as well as it would with real Manchester encoding/decoding.
Maybe I should have just written a CRC implementation and stuck with that to be more consistent with the applications behinds these encoding/decoding/hashing/etc. algorithms. I think I might do that as well.
Last night I also started some bitbang UART code, but the delays still need to be polished up. I could probably transform it into real Manchester encoding/decoding.
Yeah after thinking about it I think I’ll just stick with this implementation. I semi-tested it out (sending and receiving manchester encoded stuff only (disregarding all floating junk)) and it seems to work very smoothly.
I’m not really worried about losing clock synchronization because no matter what the data can have a maximum of two bits without a voltage transition. Then again, that doesn’t matter because the synchronization is done by the UART (like wiml mentioned, on the start bit), so nevermind that last sentence. So technically I could write a bitbang’d receiving end to synchronize on every bit but still recognize the UART frame :?
I don’t think manchester encoding and then transmitting async (NRZ) buys you very much. I’d be tempted to just cut the baud rate in half and bag manchester. yes, as was said, it adds a little validation but you not transmitting balanced due to the nature of NRZ.
I just got though debugging my first attempt at manchester receive and decode over the RLP/TLP. whew, that was fun… the asymetric pulse width was a real PITA. I spent more time fussing with timing issues than anything else. having only a 2 channel scope didn’t help much… Actually, it’s pretty cool to see it working correctly even with the cheesy RLP/TLP. man over machine…
George, I noticed that, indeed, the Receiver (transmitter?) is unbalanced when it comes to pulse width high vs low. high is almost 50% wider than the low period. The signal into the TLP was rock solid balanced. I am using 3.6V Vcc for both uC and TLP and one of my next tasks is to try the transmitter at a higher voltage. Ultimately, I’ll be using 12V for the transmitter. What voltage are you using? I suspect the problem will be less severe at higher voltage.
Hi vsergeev - I was looking on your blog and you mentioned a group buy of the miniLA. Has that oppurtunity already come and gone? It looks like a fantastic tool to have! If you already have one I’d be very interested to hear your thoughts on it.
I was using similiar units from Abacom, at first the tx/rx pair and then the am-rtd-315
transceivers. In all cases at 5 volts. The on/off times seemed to be a function
of bit rate and tx power. These radios work by turning the base frequency on and off.
The receiver needs to detect and latch the signal while rejecting noise. I suspect
that obtaing those goals and low cost are opposing forces.
The spec’ed bit rates appear to be under ideal conditions. I tried various schemes at
adjusting the ratio. Was working an a dynamic scheme when project got shelved.
George
interesting, I assume you were looking at transmitting shorter “on” pulses than “off”. Makes a lot of sense. I may give that a try. I’m moving the transmitter to a PIC (from an MSP430) so after I get it going again, I’ll give that a shot.
by the way, there appears to be a transmitter “turn off” delay that is invariant with the data rate. thus as data rate increases, the ratio between on and off increaases.
I modified the transmitter code to generate a low period that is 50% longer than a high and got a fairly symetric waveform at the receiver. I don’t know how voltage and temperature affect this but it’s a good start. I bet I’ll have to change this when I go to a higher Vcc.
I haven’t actually had the chance to test the units with real data transfer between them at any decent distance (when I said “semi-test” I actually was transmitting several times back to its own receiver, a few milimeters away, and reading it back fast enough just to see if the encoding/decoding was working in general). I should be getting into some real tests in a few days when I get the breadboards I ordered
ggallant:"I observed with a previous (canceled) project that transmitting an idle pattern
inbetween data message seemed to help. "
A friend of mine did the same thing when he was using units similar to these. He got fed up with trying out preambles and stuff, so he just kept a basic stream of idle messages going until he actually needed to transfer data… I hope I’ll have some luck avoiding that :-/
I think g1 sold all of the units, but like he says, some people bought extras and may be willing to sell them. I think right now he’s in the process of adding more features standard to it (USB and some other stuff) before distributing the parts to us, so we probably won’t have it for a while. If everything works out, he might make a second run and you can definitely get in on that one…
If you want even more information, you (and everyone else here) can come on ##microcontrollers,##electronics, and #Robotics on the FreeNode IRC network where all of us cool people hang out My nickname there is icebank.
I was redirected to this by another thread and have a few comments.
Detecting a preamble is very easy to do in C. Just send several unique bytes. I use 4 in another project. Every time you receive a byte , advance a pointer by 1 byte in the hardcoded string in the program. If it doesn’t match, reset the pointer back to the begining.
Also, in my other project I use a simple byte sum rather then a CRC. Just use a unsigned short or unsigned long to add up all the bytes in the packet except for the checksum. Allow overflows. If the transmitted checksum matches the computed, you probably have a good packet. It isn’t as robust as CRC, but it’s very easy to implement and is actually a technique used in some PC networking code.
Finally, in my opinion NRZ is better then manchester for a number of reasons.
You don’t need a preamble to synchronize the clock of the receiver.
You use almost half the bandwidth. Manchester sends 2 bits for every bit of data, where NRZ sends 10 bits for every 8 bits.
The sender can stop in the middle of the packet(maybe on interrupt fired and the sender got busy with another task ). Manchester requires the entire packet be send without interruption.
PIC chips have a hardware UART for NRZ.
From what I remember from school, Manchester had two advantages.
It has a balance of 1 and 0. My understanding is this is really only needed for FCC licensing where the average power is measured. By balancing the data, you guarantee a signal is only being sent half the time so the transmitter can use double the power and still be licensed. With NRZ you have to design for the worst case of all 1s or all 0s. Also some RF circuitry can’t handle DC or low frequency data( some FSK circuits for example ). With manchester you guarantee a transition on every bit, but with NRZ you are only guaranteed a transition on the start and stop bits or once every 10 bits.
You can change the bitrate of the sender without modifying the receiver. With NRZ, the bitrate needs to be hardcoded.
BTW, now that I’ve subjected everybody to my infinite “wisdom” :), I was wondering if anybody can answer my question. Does a 1 or a 0 represent signal off? Because I really do want to turn the transmitter off when I don’t have anything to send.
thanks for the post - its good to have someone to talk about this with.
An advantage to manchester is it allows you to extract clock from the stream. I do this in my code. I’ve tested several different frequencies and it works pretty well with no changes to the receiver. This is particularly nice with cheap components that don’t exhibit very good temperature and/or voltage stability.
for my preamble, I use an illegal (but balanced) manchester sequence, followed by a few encoded zeros which I use to determine the clock.
Interesting point on the FCC license. does that mean that I can crank up the radiated power to 2X legal as long as my transmitter is on for not more than a 50% duty cycle?
The answer on the FCC licensing is a definate yes! The FCC in the United States measures average power over some time period. I’ve heard other countries measure peak power. I got this by reading some of the application notes on www.linx.com which makes a module that I use in some of my projects. You can also see this on the FCC documents that they post on their webpage.
Apperently, this is one of the advantages of ASK(AM) over FSK(FM).
One note is that doubling the power of a signal doesn’t really buy that much in terms of range. You can only double the power in terms of Watts. Dbm is a logarithimic scale.
mzoran:
One note is that doubling the power of a signal doesn’t really buy that much in terms of range. You can only double the power in terms of Watts. Dbm is a logarithimic scale.
If anyone’s interested, I built radio packet controllers for multi-way half-duplex RF comms among a group of devices. RF was Manchester encoded. Documentation and code here: http://www.circuitcellar.com/AVR2004/wentries/A3522.zip
My nickname there is icebank.