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 MID-1, News, Progress Report by cube with no comments yet.
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.
- 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 Analog Input, Analog Output, Digital Input, Digital Output, DIY Projects, MID-1, Multidrop, One-Wire Interface, Open Source Hardware, Open Source Software, RS-485, VDAC by cube with no comments yet.
We received a lot of rain this weekend, and all of my rain barrels are now full up. I know this because I’ve gone to them and looked, but the next logical step in this project is to find out a way to measure their contents electronically. To date I’ve tried three methods:
Method 1: Float Switches.
Definitely the simplest approach, a float switch is a device that has a mechanism made of a buoyant material, that when it rises with the water a switch is activated. Float switches provide binary data about the contents of the barrel. If they are off, the assumption is that the water level is below the position of the sensor; if they are on, it can be assumed that the water level is above the position of the float sensor in the barrel. Float sensors are great for telling you if a tank is full or empty, but you really get no feedback for everything in-between.
Sometimes this is all you need. In order to collect more rain water whenever it rains, I’ve set up buckets underneath each of the two downspouts on the house. Because our land is on a slope, one of these collection buckets naturally sits higher than the other. Therefore, I simply ran a 3/4″ poly from the higher of the two, and allow gravity to carry water from it down to the other bucket at a lower elevation.
The black poly pipe seen at the left of the bucket is threaded into the bottom of the bucket, so that any water that it collects travels down the poly pipe towards a lower bucket. Unless it is REALLY pouring continuously, the poly should be able to handle most of the rain water that lands in this bucket with the help of nothing but natural forces.
The water from the upper collection bucket runs down hill through the poly pipe until it reaches the lower of the two collection buckets. A gentle bend in the pipe raises it up to the top of the second five gallon bucket where the water pours into the lower bucket. This gentle slope in the pipe has an added benefit: Because the water is gravity-fed, it is fairly slow-moving. The slope allows much of the sediment that passes through the strainer atop the collection bucket to remain in the pipe, so only clear, clean water comes out the other end. After every major rainfall I have to tilt the pipe down into the swill and allow the crud to wash out of it, but this simple gravity-based filter is surprisingly effective.
The second collection bucket is placed beneath the other downspout on the house, so water from both downspouts ends up in the same bucket. Inside this lower bucket I installed a small utility pump, the output of which is directed into my barrel farm.
Inside a five-gallon bucket, I thought this little guy would be perfect for transferring water whenever it rained into the barrels. The bucket was too small for a normal-sized sump pump with an external float, so when I saw this model with a built in, enclosed float for $110, I thought that would be perfect. And it was, almost. Concealed within the plastic housing is not only a float switch and the starting capacitor for the motor, but also a small logic circuit that causes the pump to continue to run after the float has dropped for about 60 seconds to ensure that all the remaining water has been sucked up. Not only that, but the float turns the motor on with only an inch of water present. What I quickly observed was that when it rained, the pump would turn on quickly, blurt out the inch of water from the bottom of the bucket, and then sit there and hum-suck for another minute. If any of the house windows were open on that side of the building, the noise could be easily heard inside and was very distracting. A more intelligent control system was needed. Enter: Dual Float Switches.
I used a piece of vinyl siding material to create a “stick” with two float sensors strategically located thereupon: One sensor was placed so that it would trigger when water had reached the top of the bucket indicating that the bucket was full, and the other was placed near the bottom so that Venturii would get a signal when the water level had dropped low enough to turn the pump off without causing it to draw in air and start to cavitate. These two sensors would provide a hysteresis loop that would maximize the efficiency of the pump without wasting electricity trying to scrape up the last few milliliters from the bottom of the bucket.
Since I could no longer leave the pump plugged in directly, I expanded the Venturii VDAC Controller under the back deck and added four 12 VDC Wet outputs to drive power relays and 8 Digital Inputs to read the float switches from these and future sensors.
You can’t really tell but the output LEDs are green and the input LEDs are yellow. They all kind of wash out to a yellow-ish glow by the image sensor of my phone. After installing a number of ice cube relays to control the Jet Pump’s and now the Lift Pump’s 120V AC Power, I was ready to test the pump again with it’s new feedback sensors:
This worked very well during the first few garden hose tests. The pump did nothing until the bucket was full of water, then kicked on, quickly drained the five gallons into the rain barrel farm, and shut off before starting to suck in air. It was almost silent in doing so, and ran for considerably less time per cycle. I was very excited and thought this project was complete until it rained one night and excitedly I checked my logs and graphs the next morning. I discovered that it had pumped out a few buckets full of water, but then noticed that my other rain barrel was completely full. Clearly it had rained a LOT that night, but my rain barrel farm was still only half full. I went and looked at the bucket only to find that it was full of water but not pumping. I gave the bucket a bump with my knee and the pump jumped to life, emptied and then shut off. It turned out the floats needed a slight adjustment, so I re-worked the apparatus and tested again on the next rain fall, this time successfully.
Method Two for measuring water in a container is by using sound. See my article on measuring Salt with Sound for the specifics, and while this method works well for salt, with water there is so much echo and stray feedback, I’ve found the results largely un-usable.
Method Three: Differential Pressure Sensor.
This was an idea I had several years ago, bought the sensors for it and they’ve since sat in a shoe box on a shelf in my garage until now. The basic theory of operation is that you place a tube into the container so that it’s opening is as close to the bottom as possible, and measure the pressure at the other end with a sensitive pressure sensor. When water is placed into the container, it compresses the air inside the tube, increasing the pressure. The more water that is added to the container, the more air that is displaced and therefore the greater the pressure inside the tube. When water is drained out of the container, the pressure is relieved. By measuring the pressure and applying some mathematics to the result, one should be able to determine fairly accurately how full the container is.
The wires are a bit of a mess, but you can see in the foreground the MPX5010DP sensor on a small breadboard with a clear tube attached to it. I used a drip irrigation clamp to try to ensure there would be no leakage at this end of the tube, and the other end is submerged into the bottom of the barrel with the help of a section of copper pipe:
The copper pipe helps ensure that the tube remains straight and positioned at the bottom of the barrel. I’ve placed it on an angle to attempt to increase the amount of air that is displaced, giving higher resolution of the barrel contents. So far, with the water level near the top, the 10-bit analog input reads about 570 out of 1024, dropping to about 45 when the tube is removed from the water. Assuming a range of (570-45) 525 units to measure a 45 gallon barrel of water, this would give us almost 0.20% increments.
So far in the real world, I’ve discovered some variances throughout the day. I’m not yet sure how much ambient temperature and the excess tubing in my proof-of-concept apparatus is altering the results. The volume that is reported appears to change over the course of the day, despite the water level (supposedly) remaining constant. I was pleased to notice that when I run the Jet Pump, it is very obvious to see the effect on the water level reading, and whenever the lift pump transfers water into the barrel farm, the level rises quickly in the first barrel where the water is dumped and the level sensor is submerged, but then settles out as the water balances between all 5 of the barrels currently connected together. Time will tell how accurate this method is over the long haul. One thing I’m not sure about is how much escape there is through the MPX5010DP sensor itself – if it leaks air, the pressure inside the tube will decrease, indicating less water is present than there really is. Time will tell if this is the case, but so far this method appears to be the most detailed, and perhaps even the simplest. Is it the most reliable though? I will let you know what I find.
Posted in DIY Projects, Irrigation, Sensors, VDAC and tagged Bucket, Copper, Differential Pressure Sensor, Float Switch, Jet Pump, MPX5010DP, Pump, Rain Barrel, VDAC, Water, Water Level Sensor by cube with no comments yet.
Over the past couple of nights I’ve been working on building a prototype of the Venturii VDAC Water Meter Reader, and so far it is shaping up nicely. This collection of circuit boards, sensors and screens will form the test bed for a new PCB design to bring all this functionality into a single package, and also allow the new firmware to be tested. The goal of this project is to produce a system for reading [my] water meter, providing real-time flow rate data, along with incremental cumulative consumption data. This data will be incorporated into Venturii for storage, analysis and reaction (IE: leak detection, sprinkler head damage, toilet running away, etc.)
Posted in Energy Monitoring, Infrared Beam Sensor (IRBS), Sensors, VDAC and tagged Utility Meter Reading, Water Meter by cube with no comments yet.