Help with serin, serout, Manchester encoding

[skimask]

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.

[BrianT]

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

[skimask]

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.

[BrianT]

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

[skimask]

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.

[oneohthree]

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?

[skimask]

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?

And we're supposed to be able to help you fix that because we can see what your code looks like, right?