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
<LF>) with GPG and shared keys1.