It is all on GitHub now.
However, one thing I also did was wire up the kids' playhouse in the garden.
Yes, that is a kids' playhouse with swings, and slide, and Galaxy Max Reader, and big green exit button, and Galaxy keypad, and small (cabinet/drawer) mag-lock and (large) reed switches. The grandkids love it.
It has been, however, a good test, as I expected it to be. I wanted a platform with a working door that I could test on more accurately than my work bench but not messing up my house alarm and doors to my office here. An alpha test site, if you will. It has raised some fun issues.
First off, I needed a way to configure it so they could not in fact set the alarm and lock the door - yes they can get out by other means, but they were rather puzzled the door would not open. Easy enough.
However, the biggest issue I have is the bus is showing a lot of errors. I have retries, and they work, and the door works and the max reader works, but there are errors, several a second.
One thought is bus termination resistors. This is maybe 20m or 30m of cable, outside. The screen is not (yet) earthed. No termination resistors. The reason is that I found the whole thing fell apart when I added them.
I have worked out on a bench test that this seems to be a relatively simple matter. With the resistors, the bus comes cleanly back to zero after we transmit, and that causes us to catch a BREAK after we transmit, which we were taking as the start of a response message. A simple bit of code to ignore that and it looks like they will no longer be a problem. So that is one mystery solved.
Now I have a scope I can also see that we are nowhere near seeing nasty bus reflections or ringing to get in the way of things working without resistors. They are a good idea, yes, and will help in some noisy environments or long lines I am sure, but at 9600 they are probably not strictly necessary. In some ways the flaw in the design is the long (10ms) bus idle periods. A protocol with message lengths and overlapping bus driving turn around could have eliminated the bus ever being idle and made the whole thing a lot cleaner.
So lack of resistors does not explain all the errors on the bus.
So, time to play with an oscilloscope on that bus... This looks wrong!
Top (yellow) is the "A" side, bottom (blue) is the "B" side, and middle (red) is the difference.
As you can see, we only have one side. It looks a lot like this bugger is broken... The RS485 driver. This is the second one I have seen like this, the first was when I first was started the project and I wasted hours trying to find why I could not transmit. It seems only one side of the bus is driving!I'll get another and I bet all of the errors go away. To be honest it is a miracle that the bus works at all with only one leg. Somehow it limps along and the devices cope.
It has, however, been a good test of the logging and fault reporting which clearly shows the bus errors and retries.
In the mean time, it is quite amusing watching a neighbours RF PIR tripping as they move about!
It is common (or was at one time) to need to bias RS485 busses so that when nobody is driving they float to an appropriate idle state which doesn't look like a break (or the start-bit of a new word).
ReplyDeleteThis document - http://www.ti.com/lit/an/snla049b/snla049b.pdf -
is the canonical reference on how to do lots of aspects of RS485 properly and has a bunch of info on "fail-safe biasing", which is what you want to achieve. (Many modern RS485 transceivers do this anyway, but it sounds like your setup isn't working like that - but clearly if you're one-legged then biasing isn't really a solution anyway)
Both A&B moving together rather than in anti-phase is often a sign that one is actually open-circuit and just being dragged by the coupling of the twisted pair.
Nice post.
ReplyDelete