Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Manchester routines in C for PIC ?

Status
Not open for further replies.

pkshima

Member
Hi,

This is something I could never quite find on the net.
The only routines I find are the ones in assembly by Peter Jakab found on Nigel's site. Apart from that I only find discussions acknowledging that encoding is easy but decoding is not (obvious to note).

So just before I give up and start writing them myself, I need to be wise and ask. Does anybody here happen to know of a place to find open source C routines for manchester encoding and decoding for PIC to use for wireless communication using RF modules ?

Thanks & Regards,
Pradeep
 
Encoding Manchester is easy, just XOR the data and clock lines together, the output is Manchester code. Decoding... That's a little tougher.

What's wrong with Nigel's and Peter's code? It shouldn't be excessively difficult to write your own C code using that as a reference. I've similarly had difficult finding Manchester decoding code anywhere.

I do know the main problem with Manchester decoding is that if you're off by half a bit the data will come out garbage, so the initial syncing is the hard part.
 
Last edited:
Encoding Manchester is easy, just XOR the data and clock lines together, the output is Manchester code. Decoding... That's a little tougher.

That rather assumes you have separate data and clock lines, usually you would be generating it in software, where it's trivial anyway.

What's wrong with Nigel's and Peter's code? It shouldn't be excessively difficult to write your own C code using that as a reference. I've similarly had difficult finding Manchester decoding code anywhere.

It's VERY difficult to find anything about Manchester, Peter's routines were the only one's I could find.

I do know the main problem with Manchester decoding is that if you're off by half a bit the data will come out garbage, so the initial syncing is the hard part.

You shouldn't be reading Manchester like that, and for radio (or IR) it's a very bad idea, because pulse widths are changed by the transmission medium. You should be looking for the changes from high to low, and low to high, not the gaps in between. This is what makes it more difficult to read.
 
Hmmm I didnt imagine it was that difficult to find some already written stuff.
I wonder then, how do people use RF modules after all ? Is it any easier to find stuff by changing the uC, language or encoding scheme ?


You shouldn't be reading Manchester like that, and for radio (or IR) it's a very bad idea, because pulse widths are changed by the transmission medium. You should be looking for the changes from high to low, and low to high, not the gaps in between. This is what makes it more difficult to read.

Interesting, this makes it sounds not just difficult but quite impossible. how would a poor PIC know when to read input pin without measuring the gaps during the preamble. Does using 'some' extra HW make it any simple ?
 
Hmmm I didnt imagine it was that difficult to find some already written stuff.
I wonder then, how do people use RF modules after all ? Is it any easier to find stuff by changing the uC, language or encoding scheme ?

You can buy RF modules with it already built-in, or the routines in my tutorial work fine.

Interesting, this makes it sounds not just difficult but quite impossible. how would a poor PIC know when to read input pin without measuring the gaps during the preamble. Does using 'some' extra HW make it any simple ?

Basically all 'gaps' (high or low) should be within reasonable limits, if those limits are exceeded, then the packet is cancelled as been invalid.

Try studying the assembler in my tutorial routines, but it's VERY hard going.

You can use hardware to restore the original 'clock', giving you essentially a syncronous system to contend with.
 
It should be worth noting that there are better bandwidth saving encoding methods for RF. A popular one is 8b10 which can be encoding using a pair of lookup tables and decoded similarly with a good pre-amble packet for syncing. Manchester encoding doubles the bandwidth of the data signal. 8b10 (so called because it converts 8 data bits to 10 DC balanced bits and allows special control codes to be sent with the extra bits as well) only uses 20% more bandwidth.
 
Radiotronix website is down, but I have used their encoding/decoding routines. The code is freely available and is for a PIC, looks like CCS compiler. It's a 2 byte -> 3 byte scheme, not Manchester.

The site is https://www.radiotronix.com/ if it ever comes back up.

I've attached the C code and the pdf document for it.
 

Attachments

  • an401.c
    7.2 KB · Views: 2,134
  • an401.pdf
    204.6 KB · Views: 2,624
Thank you all for the help.

Would I be oversimplifying things if I set up a PIC's two interrupt lines one for rising edge and one for falling edge and building up the packet in the ISRs one bit at a time ?

Obviously it causes interrupt storming but would it work at all ?
 
Can't you use a single pin change interrupt and use the last known state of the pin to determine rising or falling edge? I don't know if PIC's have pin change interupts or if they're required to be rising/falling edge.
 
Yes that would be an important optimization if possible. But I am wondering if the basic approach has any other issues ?
 
Radiotronix website is down, but I have used their encoding/decoding routines. The code is freely available and is for a PIC, looks like CCS compiler. It's a 2 byte -> 3 byte scheme, not Manchester.

The site is RF Modules for Embedded Wireless Applications if it ever comes back up.

I've attached the C code and the pdf document for it.

Hey dirtylude,

I just used the above encoding/decoding routine. I connected it to my PIC16F690, and checked the encoded and decoded pulses on the oscilloscope. I was wondering if you managed to recover the sent signal properly by any chance using this. If so, how did you test for it? I dont have a rs232 connected as yet, so did you have an LED test or something.

On my oscilloscope, the recovered signal, while it 'followed' the sent signal to an extent, wasnt as near as perfect as it is on the pdf document attached.

Also, is there any additional circuit required between the receiver and the PIC. Or between the PIC and the transmitter?

Thanks
 
I received your PM.

One thing here, I do not use PIC's, so I can't answer any questions specifically about PIC's. I use the Z8 Encore!. The code I posted was only for the encoding/decoding routines, which I extracted for my own program.

I actually scrapped my original code with those routines and started using an adaptation of the VirtualWire library for the Arduino. The source code is available and can be adapted to any uC pretty easily by just attaching the ISR to a timer that triggers 8x your data rate. The encoding in that software uses a similar, if not exactly the same 2byte -> 3byte encoding, but the supporting code for timing is pretty nice. If you google 'VirtualWire arduino' you can find the code.

Now, I'm not using any of that on any new designs at all. I'm using the RFM12B which is both a transmitter/receiver with SPI interface and frequency hopping. It's a pretty nice solution and works out to be as cheap or cheaper than those 'dumb' modules. Google RFM12B and you can see what people have done with it for P2P networks, and the Strobit project.
 
I received your PM.

One thing here, I do not use PIC's, so I can't answer any questions specifically about PIC's. I use the Z8 Encore!. The code I posted was only for the encoding/decoding routines, which I extracted for my own program.

I actually scrapped my original code with those routines and started using an adaptation of the VirtualWire library for the Arduino. The source code is available and can be adapted to any uC pretty easily by just attaching the ISR to a timer that triggers 8x your data rate. The encoding in that software uses a similar, if not exactly the same 2byte -> 3byte encoding, but the supporting code for timing is pretty nice. If you google 'VirtualWire arduino' you can find the code.

Now, I'm not using any of that on any new designs at all. I'm using the RFM12B which is both a transmitter/receiver with SPI interface and frequency hopping. It's a pretty nice solution and works out to be as cheap or cheaper than those 'dumb' modules. Google RFM12B and you can see what people have done with it for P2P networks, and the Strobit project.

Hey, thanks for the reply. Sorry I had to contact you on pm

Like I mentioned, Im very new to microcontrollers. In my current project, my PIC (which has only 1 rx/tx pin) is connected to the PC. I now need to attach a RF transmitter and receiver to the same PIC. Hence the need for the above code.

My problem is this : If i were to connect the oscilloscope to the tx and rx pins, does a captured message HAVE to have the same waveform? can it be displayed different on the scope, but the message still get through. Currently, the data on the TX is identicle to the one in the PDF file, and while similar, the RX isnt identicle. I just wanted to know what tests you had in place to check if the mssage was actually delivered. My uC isnt connected to the computer as I dont have the tools are yet. Do you have any tips on this?

Thanks mate.
 
I don't really have any tips if you don't have the ability to log to rs232 or display on an LCD. If you have in circuit programming with debug, you can save everything to buffer and breakpoint on full message receive. Check your buffer using the debugger.
 
I've written a program in C that will decode RC5 data, which is of course Manchester coded, and I'm more than happy to share it with you, but it would require substantial modifications for a data "stream".

Alternatively if you decide to write your own program I can give you some help with techniques for manchester decoding.

Brian
 
Thanks Brian. After hearing from big shots that its very hard, I am excited to try my hand first at it :) Just waiting for a few free days from work. I will ping you if/when I fail :)

I see on the Internet that HT12E and HT12D can make communication possible. The encoding scheme used in them is not exactly Manchester so I couldnt understand if its supposed to work or if it just works somehow.
 
Last edited:
hi, did anybody found some CCS library to encode/decode in Manchester to use it trough a couple of RF modules?

Tanks
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top