Nigels Manchester Encoding Tutorial

Status
Not open for further replies.

Baud rate doesn't apply, it's not RS232 - the whole point of Manchester coding is that it doesn't need to be accurately timed.

If it's running on a 16F628, then it's 4MHz, because it uses the internal oscillator.

Can't help you on the CRC though, I didn't write it, I just 'borrowed' the code and modified it for my own uses.
 
Hi,
I don't think the RF module can handle such high data rate. Some cheaper RF module that I've used has the data rate of only 3000 bps.
 
Exactly, it's a question of what the RF link will handle - but the important thing to remember is that the receive routine isn't looking for specific bit lengths, it's looking for transitions from 0 to 1, and from 1 to 0.
 
Again, they come from the original source, but you simply comment out the ones you don't want - the inverse ones are commented out above.
 
Try reading the MPASM/MPLAB helpfile!, in particular conditional assembly, with ifndef, else and endif.
 
It's not transmitting at any specific baud rate, and you are correct that Manchester coding at least halves the effective baud rate.

The routines 'as is' should work fine, try them and see. Bear in mind, you're not sending continuous data, but packets of data.
 
Like I said, try it and see, it should work fine - and forget baud rate, it doesn't apply - that's the whole point of Manchester.
 
The transmitter just sends a plain carrier, so doesn't cause any problems if there's no data being sent. Turning the transmitter OFF makes it worse, as the receiver is flooded by noise then, but the Manchester routines ignore it.

Just send the data as packets, separated by enough time to send all the data out as RS232.
 
If you're wanting duplex operation, I would suggest you get a transceiver module, rather than separate receiver and transmitter - this will have the required switching between the two. It's not just a matter of connecting them together, you would upset the loading on both - the usual method is to use PIN diode switches, which select the correct connection automatically.
 

Power makes no difference, both are still connected to (and loading) the aerial.

Please tell me what type of antenna you used or that you recommend.
Click to expand...

I've simply used a piece of wire as a 1/4 wave whip.
 
I've only used the ones in my tutorial, I can only suggest you check the datasheets and see what they say.
 

The input pin has protection diodes (like a PIC does), the 10K limits the current and the diodes clip the 5V signal to 3.3V.


Because without the 68 ohm the zener will short out the 5V rail, overheat very quickly, and go S/C itself - you MUST have a current limiter feeding a zener diode.
 

No you shouldn't, and you shouldn't connect an LED to a PIC pin without one either, it's VERY bad practice - and you could damage both PIC and RF module.
 
nigel i have two short questions if u could answer them please.

1)

is it possible that when you transmit manchester data from the pin of the pic, if i connect the pin to oscilloscope, is it possible to see the train of pulses? im not sure how to do it because, when i press the transmit button, it will transmit and go past the screen so fast that it wont be able to see. is there a way to "capture" this image and keep it on the oscilloscope screen in anyway?

also one more quick question,

2) obviously sychronous communication is better than asynchronous in the sense that it never goes out of synch, but it needs more set up time before the data transfer is carried out.... is it possible for asynchronous communication to never go out of synch also?

for example if i am sending data from the PICS USART to the PC, and i want to send a long long stream of bits, wont it eventually "come out of synch"... because the USART clock on the pc is not perfectly matched to the one on the PIC?

thank you
 

Using a storage scope - although the data rate should be plenty low enough for a 'sound card' PC scope to be all you need.


No, because it's synced every byte, that's the whole point of asyncronous comms. Manchester encoding is different, because speed doesn't matter, and it's effectively synced every bit.
 
Status
Not open for further replies.

Similar threads

A
SainSmart TB6560 tutorial
Replies
1
Views
2K
Musicmanager
my new 'Arduino -uno ' kit
Replies
10
Views
8K
DrG
D
Help with re-initializing Manchester connection
Replies
2
Views
1K
Vizier87
Tutorial 1 button 2 mode – press releases and holding
Replies
2
Views
5K
djsfantasi
Quadrature encoding sequence.
Replies
8
Views
3K
camerart
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…