I would like to connect some sensors to one Pi and have it collect data from the sensors exclusively. This Pi will have only sensors and no display attached. Another Pi will act as a computer in general so this one will be connected to a display.

I would like to be able to transfer data from the Pi with the sensors to the second Pi to relay whatever data it is currently reading off the sensors. I would like this data transfer to be one-way only. If possible, I would like the Pi+sensor combo to act as a module so that I can hot-plug it and collect data in realtime at any time. The data needs to be transfered through a wired connection, so wireless modes of communication are not an option.

What is the best way to do this, and is there any way to secure such a communication?

  • 1
    if the comminacion is only one way, then how will you validate that the data was actually received?
    – jsotola
    Feb 6, 2020 at 8:21
  • 1
    Over what distance would the wired connection need to work? How much data is going to be sent and how often? Is the number of sensors going to be fixed or variable? Feb 6, 2020 at 8:58
  • @Roger Jones Short distance, maybe 1-2m. It's going to be a fixed number of sensors.
    – user942937
    Feb 6, 2020 at 9:03
  • @jsotola Since the connection is wired, I'm assuming any losses will be negligible.
    – user942937
    Feb 6, 2020 at 9:04
  • If you are using a wired connection. Why are you worrying about security?
    – kwasmich
    Feb 6, 2020 at 9:12

2 Answers 2


I would consider using the UART: connect two ground pins together and connect the TX pin on the Pi+sensor to the RX pin on the PI+display, a twisted pair or shielded cable would be ideal for this. Then have the Pi+sensor board to just continuously stream readings out of it's UART in "packets". The Pi+display then just needs to listen for the data packets and interpret them.

To make this easier, rather than just print out readings on the UART try to come up with a format for the packet that makes it clear where each one starts and ends, where each bit of information sits in the packet and possibly includes some sort of checksum so you can at least ignore the corrupted ones. For example you might use something like the following:

  • All packets start with the ASCII STX character (0x02) and end with the ASCII LF charcter (0x0A or '\n').
  • Packets consist of at least two sections, separated by the ASCII "," character:
    • First is the "length" section and consists of a two ASCII characters in the "0" to "9", this is the number of "data" sections the packet contains (so between zero and 99).
    • After the "length" section a series of optional "data" sections contain the sensor data, each section contains two ASCII digits ("0" to "9") to represent the sensor ID in decimal followed by a colon (":") and then five ASCII digits for the decimal reading.
    • The last section in the packet is a four digit CRC16-CCIT checksum of the "length" and any "data" sections as hexadecimal. Frames with incorrect checksums should be discarded
  • Frame data is transmitted at 9600baud N-8-1 and a new frame will be sent at least every 30 seconds.

Typical stream of packets might be...


This is just an example mind, you might want to add other features like a station ID or timestamps to the frame. You could also use an existing data encapsulating format like JSON or XML if that makes it easier to code and/or parse.

As for your security concerns you could encrypt and base64 encode the packet content (between the <STX> and <LF>) with GPG and shared keys1.


Have a look at Emoncms which does most of what you ask and more, I've been using it for years to store and display data from many sensors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.