[How-To] Measure Salt Level in your Water Softener

[elcano]

But, this device has a simple analog output. Isn't this output good enough for polling from an A/D device? How would this be different from polling the status of a garage door? May be, you might want to add a damping circuit (RC) to smooth out any noise , but this could be just enough to prevent using up the CPU in serial or PWM protocols.

Edited to correct typo.

 

[BraveSirRobbin]

elcano;

Take a look at the datasheet linked in the How-To. The analog output only supplies 10mv/inch making it about as useful as an LM34 temp sensor.

 

[gduprey]

Actually, it has 3 outputs.

An Analog output
A PWM output
A Serial/Digital Output

I'd be only be using the later. The serial output would feed into the PIC which would receive the data, check to see if this is anything new (the sensor sends a continuous stream of readings, even if nothing is changing) and if it's new/changed, send a report to the PC.

To allow the PIC to handle multiple sensors, each sensor has it's RX line tied to an output on the PIC. When the RX line is pulled low, the sensor stops reporting and when pulled high, it starts reporting.

So all the sensors will have their serial output lines hooked to a common, single serial input on the PIC (diodes will prevent them all dragging the signal down) and then the PIC will enable reporting each a sensor, read its state, disable it, enable the next, read its state, etc, etc. This is done fast enough that each sensor can be read at least once a second or more -- depends on number of enabled sensors.

The values returned are in inches (whole inches -- per the datasheet, the sensors only deal with whole inches, no fractions and no metric).

Gerry

 

[elcano]

...making it about as useful as an LM34 temp sensor.

Great idea! So you solve the problem the same way:
http://www.hometoys.com/htinews/dec99/arti...nsen/hansen.htm

One LM10 and two resistors can amplify that signal as you wish.

I would have to check the specs to see if there is a loss in resolution, but I thing that given an investment in A/D input devices, I might consider the simpler analog way first.

 

[BraveSirRobbin]

elcano;

Don't get me wrong, your idea is a good one!

Do you already have an analog to digital unit? If so, which one?

If not, I'm not sure this is still the way to go unless you plan on having a lot of these sensors and only want to use one serial port (I mean, your A-D uses a serial port anyways, so why not just hook this unit directly to that port instead?).

I'm just curious on your line of thinking for your project!

 

[BraveSirRobbin]

Gerry;

I read your explanation of how you want to interface this unit and it sounds good except for the case of when you would like to use it for a motion detector. Here again, it would seem that a threshold report would be a good option.

Where I live I can not use typical motion sensors outside based on any kind of "heat" technology (to much sun) and wanted to use this methodology instead.

 

[FrankMc]

Hi Guys

Gerry i think the Hi + Lo Thresholds that Smee + BSR are suggesting would be very useful.....It means the HA host software doesnt have to continually poll the device if using it as a parking sensor......even as a motion sensor it would be useful i think....

Having a single trigger means the HA software would have to do regular polling for one direction ......Guys would it be an issue for the HA app to do this ...???

Frank

 

[gduprey]

Having a single trigger means the HA software would have to do regular polling for one direction

I really can't see the HA software having to poll at all. If the device is set to triggered mode, anytime there is a change, a report will be sent. So if you care about readings between X and Y inches, the HA sofware would just compare any report that came in against X and Y and discard it if out of range. It should never need to "poll" the PIC or anything else - it should all be event driven.

I'll see what I can do. It'll be a matter of time and resources (space in the PIC).

I really feel that with triggered mode, nearly any HA software I can think of would be able to easily implement it's own "range of interest". Such range of interest tracking is likely to involve more variables than the straight forward reporting modes previously discussed. So once that path is started down, what seems like a simple need trips across others very similar but slightly different needs. Consider some of these variation:

Report anytime measurement falls outside range X to Y
Report all movement inside rannge X to Y
Report all movement between range X to Y in S seconds
Report a measurement between X and Y when movement stops for S seconds

In short, what one person is going to see as a "basic" need, another person won't, but their "basic" need is close enough that they want it done at the PIC too. By keeping the PIC sensor modes simple, basic and easily parsable (i.e. very HA friendly), everyone can do what they need specific to their use.

As I said, I'll see if I can fit it in. But I wanted to explain a little about my reluctance. I really want to avoid having 15 different sensor modes, many of which are similar but different. I think that makes the device less approachable for integrators.

Gerry

 

[smee]

Gerry

I understand about time and resources. I do a lot of my stuff with AVRs and often use chips with only 2K of program memory. Squeezing everything in can be a challenge.

I also understand that you want to avoid feature creep. It's very easy to keep coming up with new things to put in.

I will grant that the basic functionality you have specified is sufficient when all of the higher level logic can be implemented in a PC. It's actually more than is necessary - you can obviously do everything with polled control from the PC if you have to. Not that I'm suggesting you do that.

I do think it's valuable to minimize some of the work being done on the PC, though. I see the high/low threshold mode as providing some basic capability - like motion detection. I don't necessarily want the PC flooded with events - a message every time the distance changes - when it should be doing things like sounding alarms, triggering cameras, sending email, etc. It's sufficient in that case to just send a message saying "motion detected."

Going back to the messages you will be sending to the PC, you should consider a set of messages which do not contain distance data but just indicate that something has changed. Here is another place where I think capability like the high/low threshold is also useful. I'm thinking about devices like the Elk controller. Unless things have changed, the programmer has minimal abilities to parse incoming serial messages. Essentially, it's just able to compare with incoming strings. A string that says "Motion detected on sensor 3" is much more useful for this type of setup than a message that says "Distance on sensor 3 has changed to 23 inches". The controller may not be able to easily parse the "Distance on sensor 3 has changed" part from the complete message - thereby requiring the program to recognize all possible distance measurements, taking up more memory for programs and strings.

 

[elcano]

I'm just curious on your line of thinking for your project!

I only use a hardware controller, an M1G, so this seems like a simple way to check the level of may water tank - and several other applications with the spare input expander that I have around. An if I find challenges with the M1 I can unpack an Ocelot that is also stored (too much work to do HA lately).

Where I live the water pressure drops during the day and goes up in the night, but sometimes the tank just dont fill up completely so I would like to know how is the tank to know how conservative we have to be while using the water. Its much better than having several level sensors.

The parking assistance sensor is another good application.

My suggestion came because the analog way seems very simple compared to the complicated programming challenges that you has posted before regarding CPU utilization, etc.

Now thinking about it, I believe that a microcontroller implementation to standardize the interface to the sensor is interesting too.

 

[BraveSirRobbin]

Hi elcano;

I see where you are going with this, but I think your methodology may be more complicated and result in accuracies you would not be happy with.

First you will have to have a method to drive/amplify that analog output to overcome the pull-up resistor of the Elk.

Second, if you use an expansion module, the information will only be updated every thirty seconds unless you cross the upper or lower threshold limits (initially set for EOL use) which is something like 8 volts for upper and 3 for lower (don't quote me on those numbers). This may or may not be a problem for you in your situation though.

The programming (I posted) is not the complicated part about this (just select a com port number and a HomeSeer device code. You do have to manually create the virtual device in HS). If you don't use HomeSeer you can use other apps such as VB.

Also, if you are going to go analog, how are you going to register the "actual" real time reading of the sensor with the Elk? As far as I know there is no way to actually "read" that number unless you extract it out of the serial port using something like electron's (my.elk) script (there is that “serial port†coming into play again!)

Also, MarkL's script (HomeSeer Elk plugin) (for those that may want to know this) has analog conversion capability! You just have to enter the values for m and b for a slope intercept formula via entries in an ini file and you will have a converted value in a HomeSeer device.

The Elk does not provide any native way of looking at the real time analog value.

The closest you could come to doing this with the elk is write rules for when the value crossed a certain threshold and act on that.

As far as CPU usage, you will not have much if you just have the unit on for a short (few seconds) that you want to take a reading for (tank level apps). For motion sensing (on all the time) you would burden the CPU, but hopefully Gerry can take care of that for us with his PIC solution/integration methods described above.

I have experimented a lot with the Elk's analog capabilities and found them very limited. I even went as far as removing a pull-up resistor, but then found the 30 second update problem with their expanders.

Don't get me wrong as I'm NOT bashing the Elk. It will suffice for most HA enthusiast’s capabilities. I (as well as my idol) am hoping that at least they offer a jumper setting for the capability of removing that surface mounted pull up resistor in the future though and also incorporate some way of "seeing" the real time data in analog format. A method of providing some math to the voltage level would also be nice, though not necessary as most people have auxiliary software to interface with their system (i.e. HomeSeer and CQC).

I'm not trying to discourage you either (you are the adventurous type that I like around here!! ) Just trying to give you some insights from my recent experiences.

Regards,

BSR

 

[elcano]

Very good points, BSR - as usual from you and your idol (which is not only yours, so you know ).

For the application that I had in mind, it might work if I build the amplifier circuit, but agree that I'll be very limited with the M1s rules. I dont want to implement this on a PC, so the next option would be the Ocelot.

 

[gduprey]

Howdy,

For those interested, I thought I'd report back on the maxbotix front end controller that I was writting about.

As of today, it's 95% done. It has the following reporting modes:

- Polled (no reports unless asked)
- Periodic (reports every N seconds)
- Triggered (reports anytime a sensor changes >= N inches)
- Inclusive Range (reports transitions in/out of range as well as readings in that range
- Exclusive Range (similar to inclusive, but inverted)

As for what the unit sends to the computer/controller, you can enable/disable each type of report
- Value Change report (send in periodic mode, triggered mode when the change is
sufficiant or in the range modes when there are changes inside the range).

Example: $91020C -- sensor 02 reports a change to 12 (hex C) inches

- Range Change reports (range modes only. Sends a report that tells you when
an object enters the range or exits the range and which direction it entered
or exited from (i.e. did it come into range from the low side or high side of
the range).

Example: $920911 -- Sensor 09 reports that an object has come into range
from the high end of the range (first 1 in 11 is "in range" vs 0 for out of range,
second "1" is "via high limit" vs "0" for "via low limit" -- so the possible values
of the last bytes are 00, 01, 10 and 11

- Simplified Range Change Reports (range modes only. Sends a constant text message for entering and exiting a range (no details on how it got in/out, just that it is in or out). Good for direct text matches for controllers that can't parse the serial reports.

Example: $920510 - Sensor 05 has come into range
Example: $920600 - Sensor 06 has gone out of range

Unlike normal range change reports, the last digit is always 0, allowing simple text matching to determine transitions in/out of range.

The range change reports occur only when transitioning in/out of range, so you'll not get repeats once an object is in range.

You can monitor from 1 to 12 sensors. While the ability to aggragate multiple sensors on the same serial port is nice, I expect that, for myself, I'll be using it most of the time with a single sensor somewhere. The front end processing (event reporting vs flood of constant reports) is where I see most of the value.

The front end can communicate with the host computer/controller at 9600 or 19200 baud. Response time to changes in a sensor is virtually immediate (typically, 1/100th a second).

As with the RGBLED and Sprinkler project, I'll be all materials (source code, compiled firmware, Java API, documentation, xPL gateway, schematics and PC Board CAD files) available for non-commercial use at no cost.

If you have any soldering experience, you should be able to build one from parts. For a single sensor controller, it requires only 8 parts -- a PIC 16F88/87 chip, a MAX232 chip and 6 capacitors (4 for the MAX232 chip, the other two as power supply filtering caps). If you want to monitor >1 sensor, add an additional diode in for each sensor (including the first -- so 3 diodes if monitoring 3 sensors) and a single pull down resistor (only one is needed, but only if you are using >1 sensor). Wirewrapping this in a perf/vero board should take about 20 minutes.

If anyone is interested in testing this out in the next few days (beta testers), pleae let me know. You'll need the ability to wire up the parts and the ability to program and PIC 16F87 or 16F88 chip. You'll be using the direct serial protocol (no java API or xPL gateway yet). The protocol is documented, pretty fully explained and text based.

All that is left before release (besides testing) is:

1) Final touch up of firmware
2) Writting Java API
3) Writing xPL Gateway
4) Writing GUI test app (maybe)
5) Packaging

I'll post a message here when it's all ready to go.

Also, Frank had asked if I would producing PC boards to simplify construction. I have the design for one, but I'm not sure I'm going to need enough to justify the expense. However, I figure that if there is interest in about 50 of the boards, it would be a break even case. So if you think you might want some please let me know how many. This isn't a binding contract, but please be reasonably sure you'd want to do this before saying so (I don't want to wind up sitting on a bunch of boards).

I'll make pre-programmed PICs available for those without programmers and if the PC board thing comes out, I'll also make optional kits (assembled and unassembled) available.

Gerry

 

[PiperPilot]

OK...I just recieved my MaxSonar device....VERY fast shipping btw...

I am anxious to wire it up and play with it...but I have read the How-To and just tested my Wall-Wart (from an old nokia cell phone). Sure enough, the 5.3V is actually 6.12V.

I understand I need an inline Diode on the hot lead...but what kind of diode? Not THAT familier with electronics parts. Any help would be appreciated.

My project I hope to use this for is monitoring the water level in my pool. Here in Florida we have to do a lot of adjusting...either letting water out due to too much rain or filling due to not enough rain.

Thanks for the assistance!!!

PiperPilot

 

[BraveSirRobbin]

Any switching diode would work such as a 1N4005.