Maxbotic Ultrasonic Range Finders

[Steve]

How well (and how difficult would it be) to use this as a car monitor? I've been looking at all the methods and was thinking I like the potential of this. What about if you install one of these say in the ceiling of the garage where the car goes? Would it be able to detect the presence of the car (distance changes from like 8 feet to like 4?) I guess it could be subject to false detection if a person walks under it when a car is not there?

 

[BraveSirRobbin]

How well (and how difficult would it be) to use this as a car monitor? I've been looking at all the methods and was thinking I like the potential of this. What about if you install one of these say in the ceiling of the garage where the car goes? Would it be able to detect the presence of the car (distance changes from like 8 feet to like 4?) I guess it could be subject to false detection if a person walks under it when a car is not there?

You could install this sensor on the ceiling and it will measure between six inches and 255 inches with one inch accuracy. If you open the serial port and let the system "free run" it automatically has the data available on its TX port and will update a few times a second. The response is very fast and accuracy as stated during my testing.

You can look at the HomeSeer link referenced above for VB script code that can be used (HomeSeer specific, but commands could easily be adapted for other software systems).

There are some tradeoffs as described above. When I tested this sensor in the above scenario I found that it placed a five percent burden on my CPU usage. This may or may not be a problem for you.

There is an analog output also, but I did not want to go that way due to the limited voltage differential output over my measurement range (plus if you use an Elk Analog Input Zone you have the problem of the "pull-up" resistor that I described in other posts).

You could always play around with the options described above about "polling" the device for data to minimize CPU usage.

You could also power the device on and off with an appliance module and just "write off" the first few readings via code (requires a very small warm up time and self calibration).

True you would get a reading as a person passes under the detector, but again, you could check for "stability" in the reading via code (say the "change" has to occur for x number of seconds before becoming a valid vehicle status indicator).

In my case, I'm thinking about using this for my water softener "salt level" detector. I only need a reading twice a day and will just use an appliance module with software methods described above to validate the data via HomeSeer.

I like the fact that I can measure salt level without having any type of string touching the salt/water. I haven’t implemented this as I've been busy with my son graduating HS and all.

Another reason for cycling power to the device is my garage gets well over 100 degrees F in the summer and I only want power for a few seconds in this environment.

I couldn't find operating temperature recommendations for this device, but it may be a concern if placed in very hot environments.

 

[BraveSirRobbin]

You know, I was thinking about Steve's question a little more, and what would really be cool is IF you were going to use this sensor for a vehicle detector in the garage, is not to mount it on the ceiling, but rather on the back wall of the garage in line with where the vehicle parks.

Then you could do a variety of things for this to act as a "position sensor" so you can park the vehicle in an exact position (I know there are other methods that perform this operation, I was just pointing out that you may want to include this feature if you are using this system in the garage anyways).

You could maybe use the analog output with a comparator circuit that woud trip and LED indicator, or just have your HA computer/system turn a light on/off/on (garage light is probably automated anyways) when the vehicle reaches a certain distance (probably use a "less than" logic since this thing is accurate within an inch). A variety of options.

 

[FrankMc]

Hi Guys


Have now built the prototype hardware for the Maxbotic device and im currently doing some tests . Got my bitscope monitoring the Pulse width output and it appears to be a little outside the 1" resolution ......but its good enough to suit my applications......

Im still leaning towards gating the Maxbotic , but i would also like my pic micro to be able to also use the transmit line ....Theres no issue with both using it at once as the pic controls the data flow from the Maxbotic , just not sure how to implement the hardware....As the Maxbotic tx pin requires inversion if connected to a max232 chip im wondering if im going to have a conflict when the pic transmit and the Maxbotic is idle..
My hoping both devices have the same idle logic ......??

In the meantime im going to write some code for the auto report delay ,which will read a 4 way dipswitch which will allow up to 15 minutes between auto reports....

More Soon
Frank

PS.......I see the Maxbotic device is featured in the New Products section of this months Circuit Cellar......

 

[FrankMc]

Hi Guys

Did some more work on Maxbotic today .....Have got the Auto report interval timer running ......Have inverted the Maxbotic TX signal and connected it to a max232 chip....Have the auto report timer set for 1 minute (for testing)....But i was getting inconsistant readings...

The sensor is on my computer table pointed to the roof ,which is a distance of 56 and1/4 inches away from the sensor.......

Most readings were 55 but some were way off ....My test board is powered from my MPLAB ICD2 and i noticed it was a little low on voltage so thought maybe the ultrasonic unit was loading it or glitching ,so i have added a 220mF electro cap close to the Maxbotic and also a .1 cap and now im getting consistant readings

I enable the Maxbotic for approx 200mSec and this allows 6 reports to go thru to the terminal program ......Cant believe the readings im getting ... ALL ...56 :lol: Im impressed with this little device.........

So looks like gating the Maxbotic shouldnt be a problem..

Next task is to see if i can also use the same transmit line to transmit data from my pic controller....
More Soon
Frank

 

[FrankMc]

Hi Guys

Looks like the issue of the two devices having different idle levels is inhibiting the pic from transmitting ....

What i have done to fix the issue is .. I have added a cmos 4066 quad bilateral switch...

I have each devices TX line connected to its own switch and joined the other side of each switch which goes to the TX line of the max232 chip....
Im using the signal that gates the Maxbotic to Enable the Maxbotic TX line switch....

The same gating signal also goes to an inverting transistor which connects to my pic controller TX line........This means when the Maxbotic TX line is enabled my pic TX line is disabled and vise versa......

It all appears to be working ok ....This would mean your HA software / hardware would be able to check to ensure the pic is alive and there are 2 spare i/o pins which could also be controlled via your HA software / Hardware.....
If any others are interested in this i will do a schematic and put it up on my Hoby site as well as the pic source (when finished) ....I would really like to get a bootloader for the pic16f88 so bug fixes and enhancements can be done without the user having to have a pic programmer....

Frank

 

[FrankMc]

Hi Guys

Looks like we have an xPL Plugin for the Maxbotic Soon <_<

Gerry Duprey has kindly offered to write the plugin and has also made some suggestions (see below)......

Frank
****************************************************************
I've been thinking about it off and on all day (and I just ordered a 5 pack of
the sensors). Here's what I think I would find use for in a "preprocessor".

1) Turn the data stream into a more parsable stream (may not be needed, I've
not looked into the serial format it's using, but my guess is it's pretty
binary).

2) Ability to hook multiple sensors to the chip so one chip can handle X
sensors (with a 16F88, I suspect X could easily be 10 or so). That means
sending back some sort of ident byte with each report

3) Ability to set reporting period to once every X seconds (like you were
suggesting).

4) Ability to disable reports, but still be able to send a request for a
report (i.e. polling).

5) Ability to send a report only when the sensor distance changes Y steps
(motion sensing and such).