Building a Better VDAC

Venturii VDAC MID-1 Rev 2.0 PCB showing version info on LCD Display

Venturii VDAC MID-1 Rev 2.0 PCB showing version info on LCD Display

Today’s news in bullet form:

  • Soldered a second Rev 1.0 board, first “official” test of the multi-drop protocol.
  • While troubleshooting an intermittent communication issue, discovered that the RS-485 transceiver I ordered for the MID-1 project is a 3.3V model, not a 5V. Replaced with an equivalent 5V variant – no difference in comm issue.
  • Studied other designs and reference material, installed a 10k pull-down resistor between A and ground – scope edges became square where they had been ski hills before. Comm issue went away.
  • Two days after soldering up my second Rev 1.0 prototype, the Rev 2.0 prototype PCB’s arrived in the mail. !!! Yay!
  • Testing on the first multi-device comm bus has yielded a new, interesting problem.

 

The second revision of the VDAC MID-1 board has been assembled and so far it looks like this revision has indeed fixed all of the design flaws and “bugs” of the Rev 1.0 board. That was very encouraging to see so many things work right from the get-go, and this version also includes numerous new features as well. With three fully-assembled MID-1 VDAC’s, I have been finally able to do some proper testing of the multi-drop protocol. The results of those tests have been mixed. Some aspects of it have worked as expected, and I’ve encountered two new problems – one which appears to be in hardware and one which appears to be in software. Since I love to write, teach, and to tell stories, perhaps this new problem can best be explained in a story of sorts. Here goes.

 

Suppose there are two people trying to have a conversation with each other. Let’s make these people both in the army: one is a commanding officer and the other is a soldier. The commanding officer barks questions at the soldier, and he replies to the commander’s order when spoken to. No trouble with the communication in this situation. This is the same as it is with a single device on the communication bus. The VDAC module software queries the VDAC device, and it replies. There is no other traffic on the bus, so either side can safely assume that anything that is said is coming from the other party.

 

Now let’s add two more officers into the room. The commander speaks to each officer with a list of instructions. He might say something like, “Soldier A: I have three things to say to you. Thing 1 … Thing 2 … Thing 3.” As long as the commanding officer is speaking to one of the other two soldiers, the remaining two need not necessarily pay attention to the commander. In fact, they could all be working at desks, filling out paperwork or some other orderly task. It is only when the commanding officer calls out “Solder x” that all three must pay attention to ensure that if the commander is talking to them, that they pay attention, focus on what he is saying and then respond appropriately.

Now we enter into the area where my present dilemma exists. During the conversation between the commander and Solder A, the commander (or even the soldier) may actually say something that sounds like the commander addressing one of the other soldiers. This causes that soldier to perk up and start listening, but since it is a “false alarm” and neither of the other two were actually talking to him, he neither does his regular work anymore (because he is trying to find out how many things the commander has to say to him, nor does he actually get what he is waiting for from the conversation in the room – further instructions. Now he is basically “out of sync” with the conversation, and when the commander actually does address him, he is confused and does not reply until the commander repeats the question.

 

Ok, so it’s a loose analogy, and perhaps it does a better job of explaining my problem than of describing a likely real-world situation. However, it is, in effect what is happening. All three devices start to converse on the bus, but at seemingly random intervals, one of them will simply stop responding. The way the timeouts are set up at the moment, this causes everyone else to wait too in order to exaggerate the problem, and everyone has to essentially time out, clear their incoming packet buffers and the VDAC module has to re-send the last command before the addressed device responds properly. Originally I thought this might be the result of a problem with the hardware, since it seemed to work fine when there were fewer devices (1) on the bus. However inspection of the last packet “sent” to the devices reveals that there is in fact a segment of data sent on the wire that resembles the beginning of a packet addressed for one of the other devices on the bus. Appropriately, it begins to capture the data on the wire, waiting for the correct number of bytes to be received but this quantity is not satisfied. The conversation between the VDAC Module and the (other) device ceases, the VDAC Module now queries the perked up device, but this query too does not fill the required quotient of bytes, so it waits for more and does not respond, so both sides timeout and the module re-sends the query. Having purged it’s listening buffer now, the new message makes sense, is captured correctly and responded to appropriately. However, it is usually only a matter of seconds or minutes before another mischievious packet triggers this mysterious timeout problem again.

 

Some of the techniques I’ve seen used in other similar protocols include things like having a single, unique start-of-packet byte that no other message could possibly include. I’m not entirely sure that’s possible with this protocol since I want to be able to use the full range of 8-bit characters in the data payload, and there are no characters that are “off limits” to the onboard device types, and indeed some of them make use of all the characters.

 

One other technique I have seen amounts to using fixed-length messages, which I’d like to avoid if at all possible. The very nature of the VDAC protocol is such that it is very efficient, but needs to be flexible to ensure that efficiency.

 

Another technique I’ve encountered includes a multi-byte SOP sequence. This might make more sense for my case, although it is still not impossible for a multi-byte SOP to be encountered within the body of a message’s payload.

 

The solution that might make the most sense is to re-arrange the byte order a tiny bit, moving the checksum byte from the end of the packet to a fixed location closer to the beginningĀ  of the packet. Nope, nevermind – that won’t work either. We can’t effectively compute the checksum byte until the entire packet has been received, and if the packet length byte is [wrong], we’re right back where we started: potentially waiting for data that isn’t coming. Perhaps a variant of this could be used though, computing a checksum of the packet “envelope” bytes: the SOP, address byte, and length byte. If we added a header checksum byte after this sequence, any listening devices could detect early on that something is amiss with the header and discard it early. It would still be mathematically possible for the correct sequence of bytes to be encountered by accident in the wild, but the probability of this would now be exponentially lower. At some point I want to enable devices that share the same comm bus to “listen” to updates from other devices on that bus and use their data as inputs for local operations. For example, it would be possible to set up an analog output on one device to “follow” an anlog input on a different VDAC device by listening to the comm bus traffic and parsing out the bits that are of interest to it. This would require no server or host intervention, apart from querying the bus. Perhaps there could even be an “offline mode” where devices hold an election and choose one device to query the bus in the absence of a VDAC Module.

 

Anyway, this project is making good progress now, and most of the work to be done now is in the software. There are a few things I’d like to add, fix, or improve but they can all be done in code. This board has come together rather nicely.


Posted in VDAC, Venturii and tagged , , by with no comments yet.

The Venturii VDAC MID-1 Revision 2.0

A 3D render in KiCad of the second revision of the Venturii VDAC MID-1 Interface board.

A 3D render in KiCad of the second revision of the Venturii VDAC MID-1 Interface board.

This evening I submitted the second revision of the Venturii VDAC MID-1 Interface board to OshPark for fabrication. I have taken a few weeks off of my day job this Christmas and really hope that these boards arrive during my vacation so that I can solder them up and test them out. They’ve got some cool new features that I think users will like, particularly the DIY crowd.

Some “New” features of this revision:
– This revision should actually work without any mods. šŸ˜‰ I have verified each footprint matches the data sheets of the products purchased and verified that against the schematic and even examples online. It turned out that my understanding of FETs was incorrect and my original schematic had the Drain connected to Ground and the load connected to the Source, but at 12V the 5V signal was nowhere near high enough to turn it on. Also compared against my working Rev 1.0 prototype that was modded. 95% confident that there should be no surprises on this one.
  • OWI (One-Wire Interface) ports now have some cool new features thanks to suggestions from Mark and Jordan.
    • Each OWI port now has it’s own select-able Pull Up/Down 10K Potentiometer.
    • A 3-position jumper selects whether the data pin will be pulled up, down, or left floating, and a 10K Potentiometer determines how hard the data pin is pulled in the selected direction.
    • A 220 Ohm resistor in series with the wiper of the pot prevents the pin from being railed.
    • Ā Because of the Pull Up / Down selection, two status resistors had to be used as the polarity changes depending on which way the pin is pulled. This was FAR cheaper than trying to go to a SMD bi-color LED.
    • The status resistors on each OWI port are enabled with a jumper so that they can be disabled if their load / capacitance causes any interference on the data line.
  • As before, each OWI port can be used to talk to Dallas DS series temperature sensors (IE: the DS18B20), products in the AM230x family (digital temperature & humidity sensors) or can be used as a digital input or output pin.
  • The two shift registers that collect the four Digital Input pins, the four User Interface buttons and the 8 Configuration DIP switches have had their order changed so that the Digital Input Pins and the button register can be read without having to read the DIP switch register, which will reduce CPU load when the DIP switch is not expected to change very often (typically at all.)
  • Many mechanical refinements such as trying to align SMD components wherever possible to aid in the automatic placement thereof, etc.

Posted in VDAC and tagged , , , , , , , , , , , by with no comments yet.