Announcement

Collapse
No announcement yet.

Manchester Encoding

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Manchester Encoding

    I'm planning to use the UARTs in conjunction with OOK RF transmitters and receivers to communicate between two Diablo modules. I'm not a RF person, but read that the bitstream should have a zero DC component and that Manchester encoding is the way to achieve this. It appears that I need to break each byte into nibbles and construct a Manchester encoded byte for each nibble, then write these bytes to the UART transmit buffer . . . with the inverse process at the receiver end.

    I'm unclear at this point about the best header/footer approach.

    Is this the best encoding approach?

    Might there be a Designer example of this encoding and decoding and other details of data packet construction?

    Thanks,
    Hunter

  • #2
    A complete novice to noisy channel data communications, my Manchester encoding question is clearly only the tip of the iceberg.

    But, for anyone interested, I found that this article provides enough information to implement Manchester: http://www.quickbuilder.co.uk/qb/articles/
    I'm sure there are others, but the translation from the C code in this article to Designer code was easy.

    Again, just for interest . . .

    My project includes two Diablo modules. The master module is a hand held unit (6"x4"x1.5") which provides a variety of functions associated with amateur astronomy viewing. It looks like this:


    Click image for larger version

Name:	27s.jpg
Views:	1
Size:	61.9 KB
ID:	59863

    The second Diablo module, a slave, mounts at a telescope and transmits optical encoder (quadrature) data (as well as, ultimately, other data) to the master, with a RF link permitting use of the master without cables. The master is powered by a 6.7 Ahr, RavPower rechargeable battery pack. While the master is currently connected to the encoders with a cable, I wanted to eliminate the cable with a RF link. The master will issue commands to the slave with the slave responding with appropriate data.

    The first decision was choosing the RF hardware. I had Microchip (mine are branded Micrel) 433 MHz transmitter and receiver demo boards available (MICRF113-433 EV and MICRF220-433 EV), so began using these as seen installed here in the master:


    Click image for larger version

Name:	33s.jpg
Views:	1
Size:	99.1 KB
ID:	59862

    The green PCBs are the transmitter (left) and receiver (right). These RF boards fit the packaging constraints and each board included the required antenna. These boards are probably a poor choice since they may no longer be available (at least DigiKey and Mouser are currently out of stock) and were expensive, but they offered a chance to learn something. A little experimenting demonstrated that the user selectable squelch feature of the receiver was important.

    While the design range for the RF link is only about 1 to 10 feet, I was concerned about noise from the nearby Diablo modules, large masses of aluminum in the signal path at the telescope, and potentially saturating the receivers due to the close proximity of the transmitters. Currently, I feel comfortable with the noise generated by the Diablo modules and short range, but haven't field tested with the aluminum in the signal path.

    While I'm currently still playing with error detection and correction, it appears that this RF hardware solution may be satisfactory but further research suggests better, and less expensive, solutions. I'm particularly interested in the LINX HumPRO transceivers combined with their MicroSplatch antenna. These transceivers appear to include sophisticated and very robust error detection and correction . . . a subject about which I'm totally ignorant and just beginning to appreciate.

    I wonder if anyone has implemented a similar data link and might have alternate hardware suggestions. I realize that there are some very inexpensive RF modules available but wonder if they are suitable for reliable, low data rate (say 2,400 to 9,600 baud range) communications. I'm willing to pay a bit more for easy implementation, both in hardware and software.

    Hunter




    Comment


    • #3
      Hello Hunter,

      That is amazing. All this RF stuff go's right over my head so I find anything to do with RF impressive but very much blown away by this.I very much like the enclosure you are using, very neat.

      Many thanks for sharing this on the forum.

      Best regards

      Paul

      Comment


      • #4
        Update:

        After some bad starts and even making a quick and dirty RF field strength meter, I'm not finished but seem to have a stable and reliable 2-way RF link operating. Certainly no news for those who know anything about this business, but a few things that helped:
        • Obvious (but I had to learn) . . . the receiving side transmitter needs to be turned off at the receiving end. The transmitter I used (the MICRF-113) doesn't provide a standby control so I had to add a high side, P-channel MOSFET switch controlled by an I/O port to cycle the transmitter power. I include a short delay after turning on transmitter power to let it stabilize but haven't identified the minimum delay required.
        • Even with the receiver squelch (which seems mandatory), the receiver output is sufficiently noisy to require some care to reliably identify the beginning of a data frame. I'm using a fairly long string (8 bytes) of 0xF0, not Manchester encoded, as this header. Testing for two successive 0xF0 bytes seems to work (only one results in frequent errors) but, for a reason I don't understand, I get occasional framing errors for 5 header bytes. I think this may be a requirement to stabilize the receiver AGC as well as for noise rejection. Just looking for a byte that's not 0xF0 (after detecting the header) seems to reliably detect the beginning of the Manchester encoded data frame. Anyway, it works with this approach.
        • This received data approach was too difficult to implement using the buffered UART mode but works well just polling the UART. A long period with no activity can quickly fill an input buffer from noise. Polling does limit baud rate but this isn't a problem for my application.
        • The Master initiates all communications and the slave always responds, allowing the master to detect erroneous or missed data frames. The slave response is verified with a CRC check as is the frame received by the slave. Occasionally a response is missed and a timer is used to detect missed replies. In this event, the master simply re-transmits the message. The timer check is implemented in the serial input poll which is a very tight repeat-until loop. A timeout during this loop sets a no-reply flag which bubbles up to the top of the code.
        • The small, simple on board antenna of the transmitter and receiver appear adequate. While my application requires a range of only 10 feet or less, I've verified operation up to about 40 feet. It also works at a close range of only a few inches so receiver saturation doesn't seem to be a problem.

        While the MicroChip/Micrel demo boards I used are expensive and seemingly not currently stocked, the transmitter and receiver ICs on these boards are inexpensive and available. For those with the capability, duplicating the demo board from the layouts in the IC datasheets should prove satisfactory. It appears that MicroChip/Micrel offer another transmitter that may be a bit easier to use. Still, transceivers such as those by LINX and others might prove easier to implement; although, I'm happy to have used the small demo boards, eliminating the need to design and make PC boards. A more rigorous search (than I performed) of available hardware would be useful. I certainly didn't understand the hardware/software trades involved when I started and think I was just lucky to have something that seems to work.

        Hunter



        Comment


        • #5
          Oops . . .

          Was thinking about the addition of a transmitter "power switch" and realized the foolishness of this added complexity. There is a need to disable the OOK transmitter output at the receive end but a little software would do the same thing.

          I was playing with the bubble gum and bailing wire RF field strength meter . . . which looks, embarrassingly, like this:

          Click image for larger version

Name:	03s.jpg
Views:	1
Size:	57.6 KB
ID:	60065

          noting that the RF level halved and was constant when data was being transmitted. This is reasonable since a proper, symmetrical data stream (equal amounts of mark and space) created by the Manchester encoding should create a constant, average RF level. But this made me realize that an OOK transmitter switches the carrier on and off (obvious from the name . . . On-Off-Keying . . . but I'd been thinking that there was a non zero carrier at all times . . . thus needing to switch transmitter power). When no data is being transmitted the UART outputs a mark (logic 1 . . . high voltage) which was evident as a maximum RF output on the meter. A mark turns the carrier on. When not in use, the transmitter was transmitting a carrier which interfered with the adjacent receiver. A UART defaults to a mark when not transmitting data. All that was needed to inhibit this carrier was a space at the transmitter input.

          Not knowing how to force the UART to a quiescent space, the solution was to disconnect the UART from the transmitter input, e.g., COM1_TX_pin(0), and remap the pin as an output set LO (space). Just remap the UART to the pin to turn the transmitter back "on" to transmit data. So far, it works.

          Just for interest, here's the master (packaged) and slave (not yet packaged) doing close proximity testing:

          Click image for larger version

Name:	01ss.jpg
Views:	1
Size:	28.0 KB
ID:	60066











          Comment

          Working...
          X