Help with serin, serout, Manchester encoding


Closed Thread
Results 1 to 31 of 31

Hybrid View

  1. #1
    Join Date
    Mar 2007
    Posts
    42


    Did you find this post helpful? Yes | No

    Default

    Do you have any suggestion on how I can get my serin command to work correctly?

  2. #2
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by oneohthree View Post
    Do you have any suggestion on how I can get my serin command to work correctly?
    Yes, READ the WHOLE 'Serin SerOut Problem' thread, not to mention a half a dozen other PIC-PIC communication threads in the 'Serial' section of the forum, just like I've suggested in the other thread and more than once. And start simple and build up. You're still using the RF modules, but I don't see anything that says you're sure it all works without the RF modules. I don't see anything that says you're sure the whole thing works just between the 2 PIC's, a couple of buttons and a couple of LEDs.

  3. #3


    Did you find this post helpful? Yes | No

    Default Encoding for RF communications

    Simple RF receivers need a preamble to condition the data slicer. I have had great success with low power Rf comms by using a pseudo Manchester strategy.

    Manchester code is usually recommended because it guarantees at least one transition per bit so a long run of 000 or 111 can be successfully decoded.

    The following also works. Assuming a 4 bit nibble is to be sent, build a character of start bit, 8 data bits and one or preferably 2 or more stop bits. Use Char_Pacing to get extra stop bits. 8 bit bytes need to be broken into two halves before sending. A checksum on any data block is highly recommended.

    Byte bit 0 is nibble bit 0
    Byte bit 1 is inverted nibble bit 0
    Byte bit 2 is nibble bit 1
    Byte bit 3 is inverted nibble bit 1
    Byte bit 4 is nibble bit2
    Byte bit 5 is inverted nibble bit 2
    Byte bit 6 is nibble bit 3
    Byte bit 7 is inverted nibble bit 3

    Now transmit this character many times - say 32 or more. The first few characters act as the preamble and the data stream is very nearly 50:50 duty cycle so the receiver data slicer is happy. Depending on link characteristics you may be able to cut the transmitted data down to 16 or even less repetitions.

    Perform tests on the received character stream to make sure you receive it, say, at least 3 consecutive times, where the characters are identical to each other AND the data structure of bit/inverted-bit is obeyed. Activating parity can also give you an extra check.

    I have used this with expensive 154 MHz transceivers and cheap 315 and 433 MHz Tx/Rx modules with great success.

    HTH
    Brian

  4. #4
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by BrianT View Post
    The following also works. Assuming a 4 bit nibble is to be sent, build a character of start bit, 8 data bits and one or preferably 2 or more stop bits. Use Char_Pacing to get extra stop bits.
    Brian
    I agree with your strategy almost 100% ('cept I use lookup/lookdown tables).
    But about the Char_Pacing above...
    If the Char_Pacing value is too large (over a few of ms, 5ms for the TX/RX modules I use according to the spec's), the data slicer will lose it's mind and basically every byte will need a preamble.

  5. #5


    Did you find this post helpful? Yes | No

    Default Char_Pacing limits

    You are correct that setting Char_Pacing too long will defeat the purpose. The reason for adding an extra one or two stop bits is to prevent the problem where the SERIN software UART can misframe on a repetitive pattern and what it takes for the start bit may well be bit 3, 4, 5, etc. By giving the system 2 or 3 stop bits the SERIN command will fall into sync in just a couple of characters.

    HTH
    Brian

  6. #6
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by BrianT View Post
    You are correct that setting Char_Pacing too long will defeat the purpose. The reason for adding an extra one or two stop bits is to prevent the problem where the SERIN software UART can misframe on a repetitive pattern and what it takes for the start bit may well be bit 3, 4, 5, etc. By giving the system 2 or 3 stop bits the SERIN command will fall into sync in just a couple of characters.

    HTH
    Brian
    Good call, never really thought of that. I'm going to add that to a couple of my RF projects and see what happens. As it is, at 9600, I'm losing a few bytes here and there at the longer ranges. Maybe the 'extra stop bit' will help out.

  7. #7
    Join Date
    Mar 2007
    Posts
    42


    Did you find this post helpful? Yes | No

    Default

    I got serin to partially work on the receiver side (with and without wireless). The problem I am having now is it seems like after I decode it I have about 4 extra bits at the end of my decoded sequence. How do I get rid of it?

Similar Threads

  1. A Serial GLCD 128x64 Simple Project
    By Oldspring in forum Off Topic
    Replies: 0
    Last Post: - 8th March 2010, 20:58
  2. Serout to serial servo
    By azmax100 in forum mel PIC BASIC Pro
    Replies: 20
    Last Post: - 12th August 2009, 16:46
  3. PIC16f877 code crosses boundary @800h
    By inventosrl in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 6th April 2009, 22:03
  4. Advice-scrutiny for my serial controller
    By kevlar129bp in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 13th December 2008, 17:11
  5. SerIn and SerOut
    By Dwayne in forum FAQ - Frequently Asked Questions
    Replies: 0
    Last Post: - 21st July 2004, 15:54

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts