This video is a quick walk-thru of the basic design and operation of the access control system I’ve been working on for Milwaukee Makerspace and Bucketworks. The code on the server side is still in a bit of flux. As soon as I have it polished off I’ll post all the code and schematics.
UPDATE: Oy! There was no noise. Or at least……
practically no noise. I put TomG’s awesome logic analyser on the case to make sure that some how my protocol rules messed up and allowed the two RS-485 transcievers to talk over one another. What I found instead was the server interface dropping the transmit enable line prematurely on a fairly random basis. I think its USB Serial port latency. Its looks like it can be +/- 30ms or so. Kinda bad.
You can see the problem in the picture above. The yellow line is the TX line coming out of the server as it appears on the server-to-RS485 interface circuit. The orange line is the RTS line, which is wired to the TX enable on the RS-485 transceiver chip. As you can see the orange line drops BEFORE the packet has fully shifted out the door. The green line at the bottom of the picture shows the RX line of the RS-485 transceiver chip on the interior unit. As you can see, once that orange line drops, the interior unit doesn’t get any more bits and winds up with a corrupt packet that it discards. However the server thinks it has transmitted OK and waits the full timeout period of 300ms before it retries.
It only did this about 10% of the time, but it did slow the bus down a little. I’ve since tuned the code with well placed delays and sleeps so that it’s down to something more like 2% of the time, but I worried that the latency is going to vary with the operating system and the system load.
To really fix this right I think I need add another Arduino at the server to be the real master of the RS-485 bus and communicate with the server over a full duplex link using a variant of the protocol that is not timing sensitive.