Shop OBEX P1 Docs P2 Docs Learn Events
1 byte data via Rs485 to P1 — Parallax Forums

1 byte data via Rs485 to P1

Looking for a tutorial or simple explanation of getting data from a sensor to P1 via Rs485. I'm new to RS485.


  • RS-485 is a hardware interface. On the P1/controller side, you're either sending or receiving serial data. Do you have a link to the datasheet of the sensor? I've attached a half-duplex RS-485 object that I use in my projects.

  • Thanks Jon. I'll study your code with data sheet in hand.

  • Is it a top-secret device? :D

    RS-485 is a shared bus, so I'm betting it's sending more than one byte.

  • It's for my weather station. I have tower mounted sensors that are displayed on a monitor in my basement. I'm looking for a more stable means of communication between the two locations. Most of the outputs from the sensors are or can be represented by bytes, hence a way to send bytes of data is what I'm trying to achieve.

  • evanhevanh Posts: 15,319
    edited 2023-08-27 14:54

    I did a quick hack just last year on the full-duplex-serial driver to manage the interface chip via just two pins. One pin for direction control and the other for half-duplex data. TX and RX pins on the interface chip get tied together.

    I made no attempt to optimise nor even adjust the buffer size. It works fine when managed from a dedicated second Cog performing as 9600 baud Modbus slave function. Haven't tested it any other way.

    EDIT: Oops, had the A/B pin labelling inverted in the diagram.

  • evanhevanh Posts: 15,319
    edited 2023-08-27 11:29

    Of course, naming it fullduplex isn't ideal but since it was a tiny change within the original driver I just added the 485 to the name. It does still perform as full-duplex when not in half-duplex mode.

    PS: Setting TX pin and RX pin to the same pin number triggers automatic half-duplex config. CTS pin is then internally assumed to be the direction control to the transceiver chip. EDIT: Hmm, probably should have called that RTS since TX and RX are using DTE naming, whereas CTS is correct for DCE naming.

  • It's for my weather station.


    My half-duplex driver defaults to receive mode. Once instantiated, you can check for a byte with:

      b := h485.rxcheck
      if (b => 0)
        ' there is a byte to process

    If you want to transmit data back to the weather station you can use


    The object will see that you want to transmit and put the RS-485 chip into transmit mode. Once the transmit buffer is empty, the driver will put the RS-485 circuit back into receive mode.

  • JonnyMacJonnyMac Posts: 8,973
    edited 2023-08-28 01:41

    If you're putting controller in the weather station, another thing you might consider is sending plain text, for example


    Using the = sign as a marker, it would be easy to parse out the value from the string. I do this with commands from the Nextion into the Propeller. The upshot is you can look at the data on a terminal without processing. I suggest using CR at the end of a report string; if you do decide to parse the data, this is easy to look for as and end-of-line marker.

  • I hadn't thought of putting all the sensor and other inputs together locally. All the manipulated data such as HI's, low's, gusts and trends could be done right there. I've never sent that sort of info from one controller to another but i know it can be done.
    Thanks for the idea!

  • My friend John at makes camera platform controllers that run over RS-485. We send a command packet from the master controller (where the joystick and other controls are located) to the "head" which controls axis motors, lens motors, and other signals. The head returns position, speed, and motor status. This happens 30x/second. It's easy to use and works well. His products use the same driver I attached above. Good luck with your project. I used to work in the golf course industry, so I am very sensitive about the weather and love when people build their own weather stations.

Sign In or Register to comment.