Nigels Manchester Encoding Tutorial

[cyprio7]

circuit

post deleted

 

[Nigel Goodwin]

Sorry I have just remembered something else as well. In transmit tutorial1 for manchester encoding, what oscillator speed has been used, is it 4Mhz? Also what is the baud rate trying to be achieved?

Say for example its 9600, and you want to send bit 1's, you use this code

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.

 

[cyprio7]

Ok that makes sense

 

[bananasiong]

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.

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

Try reading the MPASM/MPLAB helpfile!, in particular conditional assembly, with ifndef, else and endif.

 

[cyprio7]

Try reading the MPASM/MPLAB helpfile!, in particular conditional assembly, with ifndef, else and endif.

will do .......

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

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.

 

[Nigel Goodwin]

how about if i connect vdd of the transmitted to ra0 on the PIC, the vdd of the reciever to ra1. The reciever is usually on and transmitter off, which means ra1=on ra0=off. When i want to transmit something, i can turn ra1=off, and make ra0=on, then transmit. Because only one of the modules are only ever on at one time, it should be seen as an open circuit by the rest of the circuit, therefore not affecting the load if rx and tx are using the same antenna? Will this work do you think?

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.

I've simply used a piece of wire as a 1/4 wave whip.

 

[Nigel Goodwin]

I've only used the ones in my tutorial, I can only suggest you check the datasheets and see what they say.

 

[Nigel Goodwin]

hi nigel, just wanted to ask a couple of questions about your schematic for the RF transmitter board. You have used a 10k resistor, with one end being connected to 5V power rail, and the other end going into the data input of the tx module which requires 3.3V. If the input impedance to the data pin is very high, isnt almost all of the 5V dropped over the resistor therefore making almost 5V appear on the pin instead of 3.3V? i think im wrong so please could you explain how this works?

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.

also reguarding the 3.3V zener diode you have used, why did you have to use a 68ohm resistor with that? could you not just use the zener diode by itself reverse biased to provide max voltage of 3.3V, seeing as the module will draw as much current as it needs anyway, why do you need to limit the current with the 68 ohm resistor?

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.

 

[Nigel Goodwin]

thats cleared a lot up, thanks nigel. but just to clarify my first question you answered. Ok the tx module has protection circuitry inside which will change the 5V to 3.3V, however, i still dont understand why you have to put a resistor there to limit the current.

Ok the tx module has a max current it can take without burning the chip, however, If only 3.3V is being supplied (with 4V being max voltage), doesnt the tx module just draw off as much current as it needs based on the voltage supplied (3.3V) and its own circuitry resistance? Isnt the current business taken care of automatically? For example, if i want to light an LED from a PIC, i just connect a PIC pin to the LED which in turn is connected to earth.

If i were to add a resistor, it would make the LED less bright. Isnt the potential range of the transmitter being limited by adding that resistor? Like, how do you know, what value resistor to use? How comes you have used 10k? cant you get away with not using a resistor and just directly connecting them?

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 Goodwin]

No idea, it's perhaps country specific?.

 

[cyprio7]

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

 

[Nigel Goodwin]

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?

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

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?

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.