[tonyarkles]

Very curious what the hinted at issues were with using regular unidirectional serial before introducing the pair of Pis.

[nelop]

The problems was all my fault :-) I was trying to use a port that was not designed for serial data. When data was sent across it was getting mashed. I think it's because both ports were not uart, therefore when the binary data was sent if they were not perfectly in sync it would get mashed, I might have been able to solve it by sending a clock as well. But the easier option was to just change everything to the uart ports and it magically worked.

[StevenThompson]

It was probably due to the lack of flow control. Serial doesn't work well when it's one-way. I did something similar to send logs waaaay back in the day, and it would constantly flip bits or send characters out of sequence, etc. I had to transmit very slowly to get it to work stably without any flow control. I want to say that I limited it to 9600 kbps before it started to become reliable.

[nancyminusone]

For that matter, why the optocoupler at all? You only need it if the systems are at different electrical potentials, and even then they are galvanically isolated on the Pis by the magnetics in the Ethernet.

But I guess it's not the same as being asked "where's the air gap" pointing at the optocoupler, and saying "there it is"

[nelop]

There are lots of ways to solve this problem.

In the past I have worked in defence, for highly sensitive stuff they wouldn't even allow a common ground between two networks.

That's why I chose an option iolsator, it ensures the two devices are electrically isolated.

It's overkill for this application, but I wanted to set something up right, and if I ever have another project like this that needs to be more secure, it's ready to go.