Serial Port Communication Help Needed Using a Sonic Distance Sensor

[BraveSirRobbin]

I am in need of some help as I'm out of my area of expertise here!

I recently purchased THIS Ultrasonic Range Finder. I'm trying to use the serial port interface and place the range data into a HomeSeer device.

HERE is the data sheet for that sensor.

I have COM1 connected to the sensor as follows. Pin#2 to "TX", Pin#5 to "GND" and a wall wart outputing 5.45 volts DC to pins "+5" and "GND". I am leaving "RX" on the sensor unconnected.

When I connect to the sensor via HyperTerminal I get an "R" followed by three digits which represents "inches" as stated in the data sheet. I can move my hand up and down over the sensor and it registers the correct distance.

From the data sheet:

Range information is sent in the form of a capital "R", followed by three ASCII character digits representing the range in inches up to a maximum of 255, followed by a carriage return (ASCII 13). The RS 232 data is sent immediately after an object is detected.

So now I'm trying to create a script using HomeSeer ver 1.7.44. I have installed 1.7.44 on a test machine (Windows XP with all latest SP's and updates) so I don't break my regular HomeSeer machine. Also, nothing else can conflict as this is the only scripting/application that this test HomeSeer is running.

I created two scripts as shown below. "Sonic1.txt" opens the Com Port One and (at least in my mind) gets the data until it receives a carriage return (ASCII 13), then calls the data handling subroutine "sonic" which is in "sonic2.txt" script.

There it places the "data" into HomeSeer device "R1" (I previously created a virtual R1 device in HomeSeer). Then that script closes the Com Port.

I created an event that runs the script "sonic1.txt" every ten seconds.

All works well till after a few minutes, then I get an error stating that "Com1 is already open".

I don't know what is wrong but I believe it has something to do with the way I'm opening and closing the com port, or the way I'm expecting the last ASCII character in my "hs.opencomportex" statement in the sonic1.txt script.

I know I get the "R" with the inches, but I wanted to get this working first before I figure out a way to trim the string to get the inches data only into the HomeSeer device.

Is this the best way to get this data from the sonic sensor? I don't need fast, but I'm not sure how to control its receive line to request only one reading. I thought the hsopencomportex statement would let me only read this device once as I'm looking for a carriage return as the terminating string (even though the sonic sensor is constantly spitting out data on the serial port).

sonic1.txt script: (runs every ten seconds via a HomeSeer Event)

sub main() 

e=hs.OpenComPortex(1,"9600,n,8,1",1,"sonic2.txt","sonic", chr(13), 1)

if e<> "" then msgbox "Error opening COM1: " & e

end sub

sonic2.txt script:

sub sonic (data)

hs.setdevicestring "r1", data    'write string to Homeseer device "r1"

hs.CloseComPort(1)

end sub

Help as always is very appreciated! Oh yes, I did close down HyperTerminal before operating the scripts so nothing else is accessing the serial port #1.

Thanks,

BSR

[Michael McSharry]

Unless you have a need to have multiple applications access that sensor then I would open the com port in your startup.txt and close it in shutdown.txt. You never need to worry about timing associated with open and close. The data will appear in chunks that you can stuff into a string and parse the string looking for complete segments.

[BraveSirRobbin]

Michael:

Thanks for the quick response!

I re-arranged my setup as follows. I now have the following in the startup.txt file:

sub main

e=hs.OpenComPortex(1,"9600,n,8,1",1,"sonic2.txt","sonic", chr(13), 1)

if e<> "" then msgbox "Error opening COM1: " & e
	
end sub

And the following in my shutdown.txt file:

hs.CloseComPort(1)

I also modified the sonic2.txt file as follows (took out the hs.CloseComPort(1) command):

sub sonic (data)

hs.setdevicestring "r1", data    'write string to Homeseer device "r1"

end sub

I restarted HomeSeer. I noticed that the device updates almost instantly, but on the bottom msg box area of HomeSeer (where it shows if an event is running) I noticed that it is rapidly and continually flashing:

"scripts running sonic2.txt".

At least that's what I think it is saying as it is flashing by so fast that I really cant read it.

Is this a problem? Is it OK to "continually" run a script in HomeSeer like this? Would it conflict with any of my regular setup scripts once I convert this to my regular HomeSeer machine?

I guess I'm just a little nervous as it is continually running like this (though CPU useage is only around five percent that is being used by HomeSeer).

Thanks again,

BSR

[BraveSirRobbin]

I further modified the data handling script to eliminate leading zeros as shown below. I realize there may be many, many ways of doing this more efficiently (please let me know).

sub sonic (data)   'This data handling routine is referenced in the HomeSeer Startup Script (startup.txt)

'Note: "data" is in the text form of "R" followed by a three digit number in inches (006 to 255).

dim data_trim
dim zero_check1
dim zero_check2

'Format data so any leading zeros are eliminated:

zero_check1 = Left (data, 2)  	'Check for "R0xx"
zero_check2 = Left (data, 3)	'Check for "R00x"


If zero_check2 = "R00" then   ' If the reading is under 10 inches (R006 to R009)
	data_trim = Right (data, 1)
End If


If zero_check1 = "R0" and zero_check2 <> "R00" then   'If the reading is 10 inches to 99 inches (R010 to R099)
	data_trim = Right (data, 2)
End If


If zero_check1 <> "R0" and zero_check2 <> "R00" then  'If the reading is 100 inches to 255 inches (R100 to R255)
	data_trim = Right (data, 3)
End If

hs.setdevicestring "r1", data_trim    'write string "data_trim" to Homeseer device "r1"

end sub

[Michael McSharry]

Based upon your observation it looks as if the sensor is continually sending data which does not hurt HS, but it does put a load that may not be desirable.

To answer your last question first...

sub sonic(data)
    if left(data,1) = "R" and len(data) = 4 then
        sDigits = mid(data,2)
        if isNumeric(sDigits) then
            hs.setdevicestring "r1", cstr(cint(sDigits))
            hs.setdevicevalue "r1", clng(sDigits)
        end if
    end if
end sub

You could also made is simplier if you did not do validity checking and just let the err object branch you out of bad data

sub sonic(data)
    hs.setdevicestring "r1", cstr(cint(mid(data,2)))
end sub

Many serial devices will have hardware flow control discretes such as DTR, RTS, etc. I think HS supports control of these from script. I do not know if your sensor supports it or not. I also do not know if you are looking for immediate distance measurements or just want to sample as some fixed period. If the sensor supports it then you can trigger the sampling of the sensor in a periodic event where the event turns on the flow discrete and the collection of the sample from the comm event turns it back off.

With knowing nothing more and assuming a reasonble baud rate then I would probably just run it full-out like you are doing. Of course if I was doing it then my sensor would be another xAP node and messages would be delivered based upon some criteria for delta distance. This would put the burden on the xAP node to deal with the comm interrupts and let the LAN deliver the events when distance changes. If you got your other xAP goodies working then I can give you this node if you are interested.

[BraveSirRobbin]

WOW, Michael! Talk about the difference between an amateur and a professional!!

Your method worked perfectly and I appreciate the time you took to post it.

This sensor operates at 9600 baud and I really don't see any way of controlling "when" it sends data (other than controlling the RX line and holding it high somehow for a few milliseconds per reading).

I'm not looking at any fast updating for my current application, but I can see where the fast, immediate response would be usefull, so I will just let it go "flat out" as you suggested.

For instance here in Las Vegas "heat profile" outdoor motion detectors are worthless. This sensor could be used as a outdoor motion detector that would be immune to the blazing sun. It could also be used as a garage parking indicator as well as other apps.

Thanks again for the xAP offer. I have not had the time to incorporate any xAP nodes (work and family matters). I barely had the time to play around with this sensor today (which is why the posts were late into the evening ).

I'll let you know when I need to incorporate this into xAP applications.

Regards,

BSR