CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Manchester coding - RF control 16F628A
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
cinar



Joined: 03 Dec 2013
Posts: 6

View user's profile Send private message

Manchester coding - RF control 16F628A
PostPosted: Wed Dec 04, 2013 12:50 pm     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Wed Dec 04, 2013 1:03 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 2:46 am     Reply with quote

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 Smile 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: 1782
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 5:54 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 7:57 am     Reply with quote

Unfortunately, i dont have a scope. But the system is working with a solid wire.
Ttelmah



Joined: 11 Mar 2010
Posts: 18061

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 9:08 am     Reply with quote

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: 1782
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 10:32 am     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Thu Dec 05, 2013 11:17 am     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Thu Dec 05, 2013 12:31 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Dec 06, 2013 9:48 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Dec 06, 2013 10:02 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Dec 06, 2013 2:14 pm     Reply with quote

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

View user's profile Send private message

Re: Manchester coding - RF control 16F628A
PostPosted: Fri Sep 23, 2016 1:27 am     Reply with quote

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: 2127
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Fri Sep 23, 2016 8:07 pm     Reply with quote

The OP was 3 years ago.
you are not going to get an answer i suspect.....
Arsenic



Joined: 23 Sep 2016
Posts: 13

View user's profile Send private message

PostPosted: Sun Sep 25, 2016 5:25 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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