Category: inventions

Posted on

Automating my sprinklers

I have been spending a few hours creating a sprinkler controller.  The basic structure is to have a Perl program do the hard core logic, and then issue a webservice request to trigger the sprinkler controller on for a watering cycle.  So far, I have the embedded controller ready to interface to a hacked sprinkler controller .  The controller just takes a simple command to water a zone for so many seconds.  There is no higher level sequencing that is in place yet.  In reality, I probably need to send a sequence to the embedded controller so the power supply only powers one water solenoid at a time. The alternative is  to put that logic in the Perl program, so that’s where I am now.

I have been working on the Perl program to figure out my watering algorithm.  So far, I just make a request to a NOAA weather site for an airport  about 2 miles from me. The document is slurped as XML data that XML::Simple throws into a hash.  From there, I take the relative humidity and integrate the “dryness”,  or 100 minus the humidity, for the given time span.  I have decided to water my grass every 3 days as a ballpark until I see how things are working. The program just prints out a trigger message for now.  In the future, this will spawn off a sequence of webservice requests to water the lawn.

So far, we have been having some interesting weather.  There have been off-and-on rain storms coming through, and this week is setting up for a rapid change into hotter weather.  A weather description that matches “Rain” will cause a reset of the integration so the lawn is not watered.  The script logs some pertenant data to the end of the script so I can rerun a scenario in the future with real world data.

A side product of this project is to tie it to my Doggie Dumpcam, which captures realtime image changes on my front lawn.  The tree is growing bigger lately, which is creeping outside of the mask area and triggering a lot of image captures.  Some interesting things have been captured, including dogs, birds, and hornets.  This Perl program will have the capability to trigger a particular sprinkler zone between, say, the 6am and 8am hours for a small timespan.

Posted on

How to increase gas milage

For a few years now before green was the thing, I’ve had this idea.  It seems kind of obvious to me, and I’m a bit puzzled why it has not happened.  See, the real solution for increasing vehicle MPG is not with the vehicle, it’s with the system. By my tracking for over 5 years (another topic for another post), my 4WD Isuzu Rodeo gets about 13 MPG in the city, and 22 MPG on the highway. Most cars are like that.  Our Toyota Sienna gets around 16 MPG city and 22 MPG highway (3 years worth of data).

The thing that really kills the MPG is stoplights.  You waste all the energy slowing down, then dump all the gas accelerating back up to the speed limit, where you hit another red light and the cycle repeats.  What’s really needed is a way to give the driver some feedback on what the optimum speed is to make the next green light.

So here’s how it works.  You cannot really change the stoplights — it just costs too much to synchronize them.  Sure it can be done, but then you have to squabble over city borders, etc. What you do is add a device to the existing signals.  So here goes.

The invention consists of the Monitoring Segment and the User Segment.  The Monitoring Segment consists of devices that are installed in existing stoplights that ideally interface with the signal timers and contain GPS receivers.  They are configured to know their nearest neighbor stoplights, the contact information for these stoplights, and the distance to those neighbor stoplights. They transmit their own timing information, and also the nearest neighbor contact information and distance.

By using CDMA technology, you can create efficient frequency reusage.  Heck, the whole thing could probably be implemented without any FCC registrations by using 802.11 or some ISM band. The important part is that by using a CDMA architecture, you can have low powered local signals that overlay eachother, streaming the contact information (code) for the next signal. To everyone else, including the incumbent user, there’s a higher noise floor.

The user segment is implemented as a receiver in the car.  This could be a built-in device, or an aftermarket add-on;  think GPS navigation device.  It  should have a GPS receiver anyway, as the car needs to know where it is in relation to the approaching stoplight.  The basic jist is that the car scans for a stoplight RF signal, locks when found, and begins to build a table of neighbors. As the car travels the city, it is picking up timing information for the next stoplight, and is far enough for the stoplight to transmit its timing information to the approaching vehicle.  By using the timing information and distance from the stoplight, the device can display the optimum speed that is necessary to make the next green light.

So there. If you do make a device, all I ask is that you send a receiver to me so I don’t have to think about these things while sitting at a red light.

And it’s not my fault my MPG is lousy.  See, the improvement has to come from the system side.  The government has to solve the problem. Heck, the have an obligation to solve this problem.  It’s probably cheaper than synchronization.