 |
 |
| View previous topic :: View next topic |
| Author |
Message |
cinar
Joined: 03 Dec 2013
Posts: 6
|
| Manchester coding - RF control 16F628A |
 Posted: Wed Dec 04, 2013 12:50 pm |
 |
|
Hi,
I am trying to do one channel rf control system. The microcontroller is 16F628a. I decided to start with a led control. Actually, it works fine with solid wire. Unfortunately, it doesn't work through 434 MHz transmitter and receiver. I checked the transmitter and receiver with other codes. They are functioning. Thus, the problem must be related with codes. Pls. help me to find problem. Thanks in advance.
The datasheets of transmitter and receiver are;
http://www.dorji.com/docs/data/DRA886RX.pdf
http://www.dorji.com/docs/data/DRA887TX.pdf
I use the manual which is given below to create Manchester code and decoding it.
http://www.summitelectronics.co.uk/pages/articles/Manchester_encoding_using_RS232.pdf
Manchester coding/decoding are also checked via rs232 terminal on a ISIS model. They worked very well.
The transmitter code:
| Code: | #include <16f628a.h>
#fuses XT,NOPROTECT,NOCPD,NOBROWNOUT,NOPUT,NOWDT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=pin_B2, rcv=pin_B1,ERRORS)
void SEND_DATA(BYTE txbyte)
{
int i,j,b,me;
b = txbyte;
for (i=0; i<2; i++) {
me = 0; // manchester encoded txbyte
for (j=0 ; j<4; j++) {
me >>=2;
if (bit_test(b,0) )
me |= 0b01000000; // 1->0
else
me |= 0b10000000; // 0->1
b >>=1;
}
putc(me);
delay_ms(50);
}
}
main() {
while(1)
{
if(input(pin_a0))
{
}
else
{
SEND_DATA(0x53);
}
if(input(pin_a1))
{
}
else
{
SEND_DATA(0x41);
}
delay_ms(150);
}
}
|
The receiver code:
| Code: | #include <16f628a.h>
#fuses XT,NOPROTECT,NOCPD,NOBROWNOUT,NOPUT,NOWDT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=pin_B2, rcv=pin_B1,ERRORS)
char c,a,i,dec,dec1,dec2,enc,pattern,son;
char nib[2]; //
char x;
BYTE DECODE_DATA() //decode function for machester encoded data. This code is working fine. I checked it.
{
enc = nib[0];
if (enc == 0xf0) // start/end condition encountered
return 0xf0;
dec = 0;
for (i=0; i<4; i++) {
dec >>=1;
pattern = enc & 0b11;
if (pattern == 0b01) // 1
bit_set(dec,3);
else if (pattern == 0b10)
bit_clear(dec,3); // 0
else
return 0xff; // illegal code
enc >>=2;
dec1=dec;
}
enc = nib[1];
if (enc == 0xf0) // start/end condition encountered
return 0xf0;
dec = 0;
for (i=0; i<4; i++) {
dec >>=1;
pattern = enc & 0b11;
if (pattern == 0b01) // 1
bit_set(dec,3);
else if (pattern == 0b10)
bit_clear(dec,3); // 0
else
return 0xff; // illegal code
enc >>=2;
dec2=dec;
}
dec2<<=4;
son=dec1|dec2;
x=0;
dec=0;
dec1=0;
dec2=0;
return (son);
}
#int_rda
void komut_al() //interrupt for receiving manchester coded data
{
disable_interrupts(int_rda);
c=getc();
if (x<2)
nib[x]=c; // assign low and high nibble of data
x=x+1;
enable_interrupts(int_rda);
}
main()
{
x=0;
nib[0]=0;
nib[1]=0;
enable_interrupts(int_rda);
enable_interrupts(GLOBAL);
while(1)
{
if (x>1)
{
x=0;
a=DECODE_DATA();
if (a==0x41)
{
output_high(pin_b4);
}
if (a==0x53)
{
output_low(pin_b4);
}
enable_interrupts(int_rda);
}
}
}
|
And the circuit:
 |
|
 |
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Wed Dec 04, 2013 1:03 pm |
|
|
Encoding manchester is easy... decoding it is a bit harder...
read the wikipedia article on it... its pretty clear.
using 434MHz modules is going to be a rough ride...
Those simple modules have a lot of noise on the output channel.
some kind of filter and error checking/correcting routine will be needed.
i see you are trying to use #useRS232 to receive manchester?
.... that doesnt make much sense... you are encoding a byte in manchester and then sending the manchester encoded byte via uart?
I didnt really go through your manchester encoding routine... but again, read the wiki article...
http://en.wikipedia.org/wiki/Manchester_code
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
cinar
Joined: 03 Dec 2013
Posts: 6
|
|
| Posted: Thu Dec 05, 2013 2:46 am |
|
|
I read the link Gabriel. Also surprised with your comment. The manual that i gave the link is telling about "rs232" can be used for rf communication.
A quote from manual,
| Quote: | The main advantages of using Manchester encoding in PIC wireless applications are:
1. Serial bit stream has a DC component of zero
2. Error detection is simple to implement
3. Can be encoded using RS232 software/hardware
4. Simple to implement on target device (Microchip PIC [3])
|
If i can do this project, i will control a heater. Thus, it is important that the heater mustn't be opened by itself  That is why i tried to use Manchester code.
All suggestions will be appreciated to solve the problem. "other coding system or any other way etc...." |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Thu Dec 05, 2013 5:54 am |
|
|
You now know why we don't like ISIS.
I suggest you:-
1) Set up a simple repeating transmission of a test signal at say 1s intervals.
2) Have a look at your transmitted & recieved signals with a 'scope.
The 'scope should tell you everything you need to know.
Mike |
|
|
cinar
Joined: 03 Dec 2013
Posts: 6
|
|
| Posted: Thu Dec 05, 2013 7:57 am |
|
|
| Unfortunately, i dont have a scope. But the system is working with a solid wire. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19537
|
|
| Posted: Thu Dec 05, 2013 9:08 am |
|
|
Lets take a step 'sideways' here.
The point about Manchester encoding, is that it keeps the number of 1's and 0's in the data stream balanced, and to send it's own clock. This is important for some types of communications, where there is some form of auto-biasing in the receiver, and long term imbalances lead to this going out of alignment. Classic uses are RF communication over AM links, IR communication etc.. Sending it over async serial, throws away the second part of 'why Manchester encode', and unless the bias circuit has a very fast response, you might as well just send each nibble followed by it's bitwise inverse. Hence Gabriel's comment.
Very old code to encode/decode a byte as 16bits using Manchester encoding, is here:
<http://www.ccsinfo.com/forum/viewtopic.php?t=28186&highlight=manchester>
This would be easy to improve to take advantage of compiler improvements since.
However you still have to deal with how to improve data recovery, which is much the harder part of using a simple link. Generally, unless you have a lot of time to waste, buy better transceivers, that don't need Manchester encoded data, and include their own error recovery.....
Best Wishes |
|
|
Mike Walne
Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK
|
|
| Posted: Thu Dec 05, 2013 10:32 am |
|
|
| cinar wrote: | | Unfortunately, i dont have a scope. But the system is working with a solid wire. |
I'm not arguing about whether your system works with a solid wire or not.
You're missing the point about cheap receivers needing a balanced No. of 0's and 1's.
What we're all telling you is the fault lies in the RF link.
Before your transmission starts we don't know what state your receiver's in.
When transmission starts it will take time for your receiver to establish a stable condition.
During that time you will lose some or all of your data bits.
When viable data does start to emerge from the receiver your RS232 device will have little chance of finding a valid start bit.
Without a 'scope you could try sending a preamble of 0x00 0xFF several times in quick succession.
See if you can get your receiving RS232 to lock correctly onto that sequence.
Mike |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Dec 05, 2013 11:17 am |
|
|
I would _STRONGLY_ advise you against using those RF Links for a Heater control...
Get something more reliable and secure. Bluetooth, XBEE, or other "Intelligent" links...
It will not only be easier but you will also reduce your risk of Fire, False triggers, consistent operation, etc.
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
jgschmidt
Joined: 03 Dec 2008
Posts: 184
Location: Gresham, OR USA
|
|
| Posted: Thu Dec 05, 2013 12:31 pm |
|
|
If you are doing anything with raw RF modules like these you should plan on using encoder and decoder chips such as the Holtek HT12E and HT12D. They handle the noise, conditioning, etc. If you want just simple remote control you don't even need a processor. You can, of course, connect the I/O from the Holteks to the I/Os of a processor. Don't re-invent the wheel.
Google images for "HT12E circuit" and you'll see lots of examples. With a set of radios, an encoder and decoder, some LEDs and switches you should be able to have a working remote in very little time.
Here is an example:
http://www.botskool.com/tutorials/electronics/general-electronics/building-rf-remote-control
Cheers,
_________________
Jürgen
www.jgscraft.com |
|
|
cinar
Joined: 03 Dec 2013
Posts: 6
|
|
| Posted: Fri Dec 06, 2013 9:48 am |
|
|
Thank you very much for all replies. Now it is clear why cheap rf modules isn't suitable for this project.
Now, I will examine how i can handle it with bluetooth or HT12E.
Kind regards, |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Fri Dec 06, 2013 10:02 am |
|
|
| cinar wrote: | Thank you very much for all replies. Now it is clear why cheap rf modules isn't suitable for this project.
Now, I will examine how i can handle it with bluetooth or HT12E.
Kind regards, |
Regardless of what kind of link you use - simple RF or bluetooth or whatever - you will have to make some sort of decision about how to handle a failed link. Bluetooth can fail too. For example, you may want to design the heater control intelligence so that it requires a repeating signal to keep the heater on. If that repeating signal stops for a certain period of time, turn the heater off. If you adopt something like this, even the simple RF link might be suitable, provided to take steps to design a packet with synchronization in mind and lots of preamble to lock onto. I would not discard the RF entirely.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
cinar
Joined: 03 Dec 2013
Posts: 6
|
|
| Posted: Fri Dec 06, 2013 2:14 pm |
|
|
| RLScott wrote: | | Regardless of what kind of link you use - simple RF or bluetooth or whatever - you will have to make some sort of decision about how to handle a failed link. Bluetooth can fail too. For example, you may want to design the heater control intelligence so that it requires a repeating signal to keep the heater on. If that repeating signal stops for a certain period of time, turn the heater off. If you adopt something like this, even the simple RF link might be suitable, provided to take steps to design a packet with synchronization in mind and lots of preamble to lock onto. I would not discard the RF entirely. |
I exactly understood what you want to mention. The point that you want to mention, is really important. And i don't discard this cheap modules but i will give a break for this modules. i will try to find other way.
I didn't get any education about electronic or pic. I learned mostly through books. I just get only 3 hour basic electronic education(what is diode,transistor,relay etc..) from a friend. That is all i have. Thus, sometimes i need an advice from people who are practically more experienced.
Thx |
|
|
Arsenic
Joined: 23 Sep 2016
Posts: 13
|
| Re: Manchester coding - RF control 16F628A |
| Posted: Fri Sep 23, 2016 1:27 am |
|
|
| cinar wrote: | Hi,
I am trying to do one channel rf control system. The microcontroller is 16F628a. I decided to start with a led control. Actually, it works fine with solid wire. Unfortunately, it doesn't work through 434 MHz transmitter and receiver. I checked the transmitter and receiver with other codes. They are functioning. Thus, the problem must be related with codes. Pls. help me to find problem. Thanks in advance.
The datasheets of transmitter and receiver are;
http://www.dorji.com/docs/data/DRA886RX.pdf
http://www.dorji.com/docs/data/DRA887TX.pdf
I use the manual which is given below to create Manchester code and decoding it.
http://www.summitelectronics.co.uk/pages/articles/Manchester_encoding_using_RS232.pdf
Manchester coding/decoding are also checked via rs232 terminal on a ISIS model. They worked very well.
The transmitter code:
| Code: | #include <16f628a.h>
#fuses XT,NOPROTECT,NOCPD,NOBROWNOUT,NOPUT,NOWDT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=pin_B2, rcv=pin_B1,ERRORS)
void SEND_DATA(BYTE txbyte)
{
int i,j,b,me;
b = txbyte;
for (i=0; i<2; i++) {
me = 0; // manchester encoded txbyte
for (j=0 ; j<4; j++) {
me >>=2;
if (bit_test(b,0) )
me |= 0b01000000; // 1->0
else
me |= 0b10000000; // 0->1
b >>=1;
}
putc(me);
delay_ms(50);
}
}
main() {
while(1)
{
if(input(pin_a0))
{
}
else
{
SEND_DATA(0x53);
}
if(input(pin_a1))
{
}
else
{
SEND_DATA(0x41);
}
delay_ms(150);
}
}
|
The receiver code:
| Code: | #include <16f628a.h>
#fuses XT,NOPROTECT,NOCPD,NOBROWNOUT,NOPUT,NOWDT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=600, xmit=pin_B2, rcv=pin_B1,ERRORS)
char c,a,i,dec,dec1,dec2,enc,pattern,son;
char nib[2]; //
char x;
BYTE DECODE_DATA() //decode function for machester encoded data. This code is working fine. I checked it.
{
enc = nib[0];
if (enc == 0xf0) // start/end condition encountered
return 0xf0;
dec = 0;
for (i=0; i<4; i++) {
dec >>=1;
pattern = enc & 0b11;
if (pattern == 0b01) // 1
bit_set(dec,3);
else if (pattern == 0b10)
bit_clear(dec,3); // 0
else
return 0xff; // illegal code
enc >>=2;
dec1=dec;
}
enc = nib[1];
if (enc == 0xf0) // start/end condition encountered
return 0xf0;
dec = 0;
for (i=0; i<4; i++) {
dec >>=1;
pattern = enc & 0b11;
if (pattern == 0b01) // 1
bit_set(dec,3);
else if (pattern == 0b10)
bit_clear(dec,3); // 0
else
return 0xff; // illegal code
enc >>=2;
dec2=dec;
}
dec2<<=4;
son=dec1|dec2;
x=0;
dec=0;
dec1=0;
dec2=0;
return (son);
}
#int_rda
void komut_al() //interrupt for receiving manchester coded data
{
disable_interrupts(int_rda);
c=getc();
if (x<2)
nib[x]=c; // assign low and high nibble of data
x=x+1;
enable_interrupts(int_rda);
}
main()
{
x=0;
nib[0]=0;
nib[1]=0;
enable_interrupts(int_rda);
enable_interrupts(GLOBAL);
while(1)
{
if (x>1)
{
x=0;
a=DECODE_DATA();
if (a==0x41)
{
output_high(pin_b4);
}
if (a==0x53)
{
output_low(pin_b4);
}
enable_interrupts(int_rda);
}
}
}
|
And the circuit:
|
You forgot to send the header SS on the transmitter code. That's why it doesn't works. Fix the code of the Tx.
Take a look on the Rx code: the ucontroller is waiting for that "enc" but of course, never shows up. So he never will take any further data.
Why it works with ISIS? Simple: ISIS reads the entire frame and compares it until matches the address that make your led go on and off.
But the unit needs to be activated by that header that you or something else has been programmed.
Try that and tell me how your project is going. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Fri Sep 23, 2016 8:07 pm |
|
|
The OP was 3 years ago.
you are not going to get an answer i suspect..... |
|
|
Arsenic
Joined: 23 Sep 2016
Posts: 13
|
|
| Posted: Sun Sep 25, 2016 5:25 pm |
|
|
| asmboy wrote: | The OP was 3 years ago.
you are not going to get an answer i suspect..... |
Point taken. But I'm now with a similar project and I need to get it work. Strange think is that I can't decode the signal properly. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
