Recent Posts

31

Electronics / Atmel Atmega328P versus Atmega328PB MCU

« Last post by Cube on November 04, 2016, 09:11:28 AM »

I recently purchased a small batch of microcontrollers from Digikey for the Venturii VDAC-MID1 prototype board(s) I've been testing. Seeing that they were a whole dollar cheaper, I quickly browsed the datasheet and didn't notice anything drastically different from the standard 328P, so I bought 10 of them. I soldered the whole prototype together and powered it on. It was very exciting to see all the LEDs come to light, and optimism was mounting since nothing let out any smoke or even got warm. I pushed the VDAC firmware to the board and the status LED began to blink rapidly, indicating an idle CPU, and optimism was riding high.

That optimism was short-lived, however, as soon as I tried to connect to it through the VDAC module. Originally I used a USB-485 dongle but fell back to TTL when that didn't work, and quickly found that the TTL pins were inexplicably being pulled high by the MCU. I verified that there were no shorts in the PCB, and even removed the LED status indicators on the Tx and Rx pins, all to no avail. Suddenly that little B on the end of the MCU part number came back to mind, and I checked the datasheet for the UART pins. Relieved to find that they were unchanged from the 328P, other differences quickly became apparent and further reading on the Internet caused me to wonder if I had made a bad choice in selecting the cheaper option over the tried and true 328P?

I've got a batch of 328P MCUs coming in today, and hopefully Mark or Jeremie can float the 328PB off with their hot air rework stations. I don't have such a tool yet, and the prospect of removing the MCU with an iron is a little daunting, especially since I'd rather not damage the board in the process. I think I may have damaged one of the resistor pads when I removed it from the Rx pin - these prototype PCB's from OshPark are very nice, but I don't know how they will stand up to rework. Maybe that's why they give you three?

32

Sensors / Toilet Flush Sensor, Version II

« Last post by Cube on October 31, 2016, 03:37:13 PM »

This past weekend I replaced the float valve in one of my toilets because part of the plastic housing had cracked and the valve often ran away. (By running away I mean it continuously overflowed water into the bowl without shutting off, even though the the tank was full.) Sadly, I can only guess how many hundreds of litres of water were wasted needlessly down the drain. The new valve was installed in a matter of minutes, and as an added bonus was much quieter than the original valve. The kit was easy to install, came with all the hardware and decent instructions - in fact, the only down side was that this new model did not have a ball float on which I could mount a magnet for my Venturii float sensor. I need to come up with a new system for monitoring when this valve was allowing water to flow.

33

VDAC-MID-1 / The MID-1 is Introduced!

« Last post by Cube on October 06, 2016, 09:13:17 AM »

I am very excited to announce a new Venturii interface board, the MID-1. Standing for Multi-Purpose Interface Device, Model 1.

The MID-1 has a Swiss-Army knife's worth of inputs and outputs, and is built on the very versatile Atmega 328P microcontroller.

Features of the MID-1 include:

- 100mm x 100mm PCB size, designed to fit inside a 4 11/16" electrical box for easy termination of conduit carrying cables to / from this device. Can also be mounted standalone, and easily rotated to best accommodate wiring without changing mounting holes.
- Atmel 328P MCU
- Multidrop capable with DIP switch block for addressing & feature / option select.
- 4 x OWI (One-Wire Interface) terminals, for connection to DS18B20 Digital Temperature Sensors or AM230x Digital Temperature / Relative Humidity sensors. (These can also be used as Digital Inputs without PCB changes.)
- 4 x Digital Inputs
- 2 x Analog Inputs
- 2 x Digital Outputs with a footprint for SRT Form-C relays (capable of moderate current and voltage switching)
- 4 x Analog Outputs, whose wet output is relative to the input voltage. (VCC input to MID-1 is passed to each Analog Output - Ground is switched through a FET.)
- ICSP Header for easy firmware upgrades.
- 4-Pin Header for connection to an LCD display (2x16, 4x20, etc. using clock & data pins of MCU)
- Four 2-Pin Headers for connection to 4 discreet user interface buttons designated Up, Down, Enter, and Back.
- TTL level serial pins broken out for alternate communication options.
- RS-485 outputs and Power Input on 4-pin connector for easy daisy-chaining multiple devices on a 4-wire bus supplying power + data.
- Switch-Mode power supply based on a LM2695 regulator, 5V version.
- Main fuse protects circuitry from overload / short circuit etc.
- Individual PTC on the Analog Input bus, OWI bus, and on each Analog Output +12V supply protect circuit from overload / short circuit etc.

Applications I had in mind for this product:

- Environmental Monitoring.
- LED Strip Lighting Controller, RGB+W (hence the 4x Analog Outputs)
- Appliance monitoring & override (manual) control.
- Outdoor lighting control module.
- Water / Leak Detection & Electric Water Valve control.
- Underground Sprinkler Zone Controller (Analog Outputs can drive external relays.)
- Security System Distributed Zone Input collector / Output controller.
- DIY Thermostat to run HVAC equipment.
- Distributed User Interface / Feedback Device via LCD display & Menu Buttons.

OSH Park is presently making my first batch of prototypes, which should be here in a week or so. I will post the results (and some pictures) once the first couple are up and running!

34

General Discussion / Re: Oh How I Hate Spam!

« Last post by Cube on October 06, 2016, 08:29:50 AM »

... Reading this today it reminds me of the Bulletin Board Systems of olden days gone by, where lonely Sysops would sit by their computers, waiting for phone calls that never came... Kind of sad really.

35

V_ION / Smarthome's Insteon Power Line Modem (PLM) All-Link Database Corruption

« Last post by Cube on October 05, 2016, 10:29:32 AM »

I woke up early this morning and noticed that Venturii was not receiving events from some of my SwitchLinc devices. I have them linked to the PLM so that it receives manual activation commands from this device, which in turn triggers a timer in Decider to turn off that light after a certain period. When I looked at the ALDB in the PLM, it appeared to have 23 records in it, and all but one record was completely packed with 0xff bytes. The one "normal" record was fine, and proved working.

I am working on v_ion version 0.5.1 at the moment so transferred control of my PLM to my dev box and added some new PLM commands, namely "plm xx add link aa.bb.cc [mode]" where xx is the PLM number, aa.bb.cc is the device address of the unit to link the PLM to and mode is either ctrl or resp. This command "succeeded", but reloading the PLM ALDB showed the exact same results. Even manually linking the PLM to a device yielded no change in the ALDB in the PLM.

Scratching my head, I decided to implement the RESET command (factory reset) as well, so I did, and confirmed that the PLM's ALDB was now empty. Using the same command I'd tried before, I was now able to add links into the PLM's database manually, and it appeared to be fine. I have no idea why it's ALDB appeared to become corrupt, but I suspect this has happened a number of times as I've had to factory default it (usually with the SET button in the past) and then re-link every device in the house by hand before. Obviously managing the links via ION would be much preferable, especially since all the devices throughout the house are still linked to the PLM.

36

Web-Based User Interface / Averaging is Back!

« Last post by Cube on September 06, 2016, 10:59:00 PM »

New code in venturii_d.php introduced this evening allows SQL to do all the heavy lifting as far as averaging the results, allowing us to peruse minutes, hours, days, weeks, or months' worth of data as single data points to be passed to the graphing library. XRAD accomplished the same thing in a different way, creating individual tables for the averages of minuts, hour, and day and then calculating them as each minute, hour, and day passed. Both systems had their advantages and disadvantages. For example, it was very quick to query the XRAD tables for hourly averages since each query returned only a handful of results. This performance benefit came at the cost of disk and table space, creating half a dozen tables each month to hold the sets of computed values. This new system stores the data once, reducing table and disk space but paying for the optimization in data cost by increasing the CPU hit on retrieving it. Fortunately SQL is quite optimized at processing the kinds of requests we are making of it, and my tests so far on a data set of ~90k records shows the following benchmarks:

Raw Mode: (As before)

Code: [Select]

Processed : 93074 in 2 Graphs
Mysql Time: 0.6328840255737305 seconds
Graph Time: 3.743463039398193 seconds
Total Time: 4.376347064971924 seconds
Data / Sec: ~21268 data / second

Second Mode:

Code: [Select]

Processed : 55800 in 2 Graphs
Mysql Time: 0.8703169822692871 seconds
Graph Time: 2.293694972991943 seconds
Total Time: 3.16401195526123 seconds
Data / Sec: ~17636 data / second

Minute Mode:

Code: [Select]

Processed : 2883 in 2 Graphs
Mysql Time: 0.471541166305542 seconds
Graph Time: 0.1927869319915771 seconds
Total Time: 0.6643280982971191 seconds
Data / Sec: ~4340 data / second

Hour Mode:

Code: [Select]

Processed : 52 in 2 Graphs
Mysql Time: 0.4362599849700928 seconds
Graph Time: 0.1189849376678467 seconds
Total Time: 0.5552449226379395 seconds
Data / Sec: ~94 data / second

Day Mode:

Code: [Select]

Processed : 6 in 2 Graphs
Mysql Time: 0.4037258625030518 seconds
Graph Time: 0.1409800052642822 seconds
Total Time: 0.544705867767334 seconds
Data / Sec: ~11 data / second
As you can see, having SQL average the data before passing it to JPGraph only takes an additional 0.2 seconds on a days' worth of power meter readings for both phases, and in some cases actually returned results in LESS time than it took to fetch the raw results. This brings back the averaging functionality of the XRAD system, makes it retroactive to all recorded VINT data and also applies the capability across all numeric data types. This is a win in my book all around, and the slight performance hit it takes far outweighs any potential downfalls of not storing the averages in separate tables.

From the VINT selector window, the Select Report Resolution field has always been there, but until [today] it really didn't do anything. Now this has been fixed and it again affects the output graphs produced in the way expected by the user.

37

Sensors / MPX5010DP For Measuring Water Level in a Rain Barrel

« Last post by Cube on June 30, 2016, 03:38:02 AM »

I've been playing with a MPX5010DP Differential Pressure Sensor, using it to monitor the water level in a rain barrel. Now that we're getting a fair bit of rain and that I have a water pump system set up to water my lawn and plants from stored rain water, knowing how much rain water is in the barrel farm is important. Originally I was going to simply use a number of float switches evenly spaced on some sort of stick to give 25%, 50%, 75%, 100% "full" readings, but I stumbled across the idea of monitoring the water levels a different way, which seemed so simple it just might work. Other posts on the Internet showed how people had used sensors in the MPX family to measure water level readings, and I recall having purchased 5 of the required sensors several years ago, but never actually did anything with them. Now that I have 7 45 gallon barrels full of water, my interest in the subject was substantially renewed.

The setup was surprisingly straight forward. According to the datasheet, the MPX5010DP produces a signal in the 0-5V range proportional to the amount of pressure sensed on one of the two ports of the device. There has been a number of questions about what the 'other' port on the sensor is for. Being a differential pressure sensor, it is measuring the difference in air pressure between two hoses. One port is the for the positive side, the other port is for the negative (called vacuum) side. In my application I simply leave the vacuum side open to the atmosphere since that is my control in this experiment. For the pressure side, I have taken a length of 1/8" ID clear plastic tubing, pushed it through a section of 3/4" copper pipe long enough to stand on the bottom of a rain barrel, and taped the tube to it. What this accomplishes is it keeps the clear plastic tubing more or less straight, necessary for a good linear reading, and also makes sure that the opening of the plastic tubing is at the bottom of the barrel. The other end of the tube is clamped onto the pressure side of the MPX5010DP, and the analog output is connected to an Analog Input on a Venturii VDAC board.

According to the datasheet, the manufacturer recommends several capacitors for decoupling from the power supply, but the rest is done by the sensor. I didn't have the exact values recommended in the datasheet, but did install several capacitors next to the sensor for the same purpose. Immediately thereafter I began to get readings on the VDAC.

Observations:

• The sensor works very well for this purpose. I was able to monitor the water levels and see immediate changes when water was added to one of the barrels or removed (they are all inter-connected at the bottom and so self-levelling.)
• Due to the length to tubing between the barrel and the sensor, the apparatus is very sensitive to outside air (ambient) temperature changes! As the temperature increases, the air pressure that is detected inside the tubing increases. Conversely, as the air temperature decreases, so too the air pressure measured inside the tubing decreases.

My next step is to reduce the length of the tubing as much as possible to help mitigate the effect of air temperature on the reported air pressure. Once that has been stabilized somewhat, the  next step will be to calibrate the setup to read the pressure as a percentage of barrels being full. For example, as I type this the VDAC is reading a value of 530/1024 of the 5v analog input. Using some maths, 5V / 1024 Steps * 530 Measured Steps in the 10-bit ADC = 2.588 VDC. The datasheet gives the output formula as:

Code: [Select]

V[sub]out[/sub] = V[sub]s[/sub] * (0.09 * P + 0.04) +/- 5%.
It is three thirty in the morning, but if I re-arrange that formula to solve for P,

Code: [Select]

2.588 = 5 (0.09 * P + 0.04)
2.588 / 5 = 0.5176
0.5176 = (0.09 * P + 0.04)
0.5176 / 0.09 = 5.751
5.751 = P + 0.04
5.751 - 0.04 = 5.71
P = 5.71 kPa

With the barrels full to overflowing, my reading is 5.71 kilo-pascals. Discarding the temperature swing, I could call this the 100% full measurement. I would then need to empty the barrels down to the point where the jet pump starts to cavitate (suck in air), measure the air pressure at that water level and call that reading 0% full. Then going forward, I could convert all the pressure readings into percent of full and have a very accurate reading on how much water I have stored in the barrels.

Taken a step further, I could measure the volume of the barrels and convert that percent to gallons or liters. Considering their value, the slightly higher price-per-sensor of these guys, in light of the granularity they give, the simplicity of the implementation and usefulness of the data they provide makes them an excellent value for this purpose.

38

V_MAESTRO / Dead Out Of The Gate

« Last post by Cube on June 30, 2016, 02:49:26 AM »

Caller ID. I remember when it first came out, and what a revolutionary idea it was at the time. My friend Phil was the first person I knew to get the feature, and the novelty of seeing who was calling before you answered the phone never seemed to wear off when I was at his house. The little box on his coffee table had two buttons and an LCD screen, and the brand name (or model) was written below: Maestro.

Modems have long had the ability to do more than just modulate and demodulate computer data over voice telephone lines. First came the addition of fax capabilities, and shortly thereafter on some of the more expensive models came the ability to intercept and interpret the CallerID data. At one time I had an XT computer (Yes, that was not a typo. I neither meant to say AT nor XP but XT) whose sole purpose was to monitor a modem and display the caller ID information on a phosphorous CRT monitor from it while Procomm logged the session to a text file.

Fast forward to Venturii and a similar need arose. I came across a US Robotics Sportster V.92 external modem, and discovered that it, too, supported the CallerID standard. I created a Venturii module to capture and interact with the modem, intercepting the RING messages and the Caller ID data it displayed. This allowed me to invoke different actions within Venturii when certain people called, and even when the phone was ringing. For example I did not have a phone out in the garage at the time, but set up a beeper to beep in cadence with the ringing of the telephone in the house.

Since that time however, I've switched from a traditional telephone service costing over $35 / month to a VOIP service and my own Asterisk VM costing less than $1 / month. Not only that but it also gives me much more flexibility over who calls, when the phones ring, and I've even installed a number of IP phones including in the garage, all but negating the need for this Venturii module. My USR modem is still mounted to the wall with a Lantronix MSS-100 plugged into the back of it, iconifying the changing technology over time, however neither have been powered up in years.

If there is any interest in the Maestro module, I would be happy to support it and still have the tools and equipment to test/develop for it, however for my purposes there has really been no need and so it has fallen by the wayside.

39

V_KAD / Kramer VS-Series Vertical Interval Switchers

« Last post by Cube on June 30, 2016, 02:40:13 AM »

One of the Venturii modules that gets used around my house on a daily basis is the V_KAD module. Several years ago I assembled some parts to form a whole-home audio system, and needed some kind of distribution for it. I came across Kramer switches, and discovered that they had (most) of the features I was looking for, and so long as purchased used from eBay, were in the right ballpark. I bought two of them, and then proceeded to write a Venturii module to control them both. Fronted with a web-based interface that even my 6-year-olds can use, it has become part of our daily lives here.

The VS-series of Kramer switches are designed (from what I have read) to be production-ready audio and video matrices, and can be either manually operated or remotely controlled. The VS-606XL, for example, has 6 Composite + Audio inputs, and 6 Composite + Audio outputs. In my case I discard the video inputs and outputs, being interested in the audio only, however what drew me to these devices was the remote control option. Using a published protocol and supporting multi-dropped RS-485, these devices are perfect for my application.

Coupled with a Russound 12-channel (6 stereo channels) amplifier, the VS-606XL acts as a traffic cop to each of the amplifier's pair of stereo outputs. Using Venturii, I can then direct six different sources to six different sinks, or pairs of speakers located around the house. Or, all speakers can play a single source, plus any combination in-between.

The only feature that the VS does not have (although the protocol supports it which was a little misleading) is the ability to control the volume. Thus, the source volume is passed through to each output unaltered, and a change in source volume affects all connected speaker pairs. So far no one has really complained about this, but it has been on my long-term bucket list to build some sort of matrix with audio options. I've looked into a number of IC's designed for exactly this purpose, but so far my research into the matter has turned up no compelling results. (Plus the IC's I was looking at are quite expensive!)

In the mean time, the V_KAD module continues to happily switch audio through the Kramer VS's, and this is one of the most interacted-with modules of Venturii.

40

Sensors / AM2302 / AM2302 in Bathroom Gets Stuck at 99.9% Relative Humidity

« Last post by Cube on April 15, 2016, 08:58:54 AM »

I have encountered an annoying problem with the AM2302 and AM2303 series of sensors. I put one inside the bathroom fan housing in my master bathroom, and it reads the temperature and relative humidity in the room. Specifically, when the humidity gets above a set threshold, Venturii turns on the bathroom fan to expel the excess moisture in the air - typically from someone having a shower.

The first sensor I put in there was an AM2302 (white model) and it lasted for over a year without incident. Then one day, I noticed the bathroom fan was not coming on when it should, checked, and found that the sensor was reading 99.9% humidity. (Basically, maxed out.) I thought that it had perhaps saturated from a shower the night before or earlier in the morning, turned the fan on to help dry it off, and forgot about it. It never did restore, and I ended up replacing it with an AM2303 (grey model). I think they internally use a DS18B20 for temp but had the same humidity sensor. Anyway, it lasted for a month or so and then did the same thing. I checked the voltage this time, wondering if maybe it was too high or low - it was a bit low at 3.7 Vdc but this is the longest sensor run in the house, and I think I calculated by the cable numbers that this run is about 70'. I tweaked the power situation and brought it up to 4.9 Vdc when I replaced it a third time, a week ago.

Imagine my annoyance when I discovered that after only a week, the third AM2303 is now doing the same thing, pegging the RH output at 99.9%. Interestingly, the temperature readout is normal, and it's never spat out even one message that had a bad CRC check. Now I am stumped. I was going to set up another one of these in the other bathroom to perform the same task (fan control management) but I can't afford to keep replacing these sensors every week... Searching on the Goog doesn't seem to yield any results, which usually means that whatever my situation is [is] an anomaly and I must be doing something wrong. I've got two other 2302's connected to the same Venturii Sensor Acquisition (Prototype) Board and they have been working flawlessly for years, granted - in much lower occasional moisture environments.

Any ideas as to what might be causing these sensors to fail so rapidly? Is it just the moisture saturation that is killing [something] in the device that it never recovers? I've confirmed that they do dry out after each shower... Even after a few months in a box in the garage I hooked one up and found it still reporting 99.9% so it's definitely cooked. Is there a (better) / (more reliable) / (more resiliant in high moisture environments) sensor out there I should be considering?

Cube