Funny, I tend not to blog much but every once in a while I get the urge.

Not too long ago someone asked me what I really love doing. As in what would I do for free every day if I could (assuming I did not have to worry about paying the bills and such). I thought about the question for a while and looked back over my years as a developer and manager of technical types and realized that I love creating new things that are needed by someone, I also love teaching folks about technology. That explains why some jobs in my past have resonated with me more then others.

I recently took a small contract that was really fun, I got an email from a gent that wanted to send Morse Code via light. He wanted to be able to type a paragraph of text and send it over and over again via a light and not just any light, a bright enough light to cover a mile or more of distance. He had a few more requirements:

  1. It had to be self-contained, and portable
  2. Water resistant to water mist and or light rain
  3. Easy to use, he did not want to learn Morse Code, just wanted to type text and have it sent as Morse Code
  4. Able to send the text as Morse Code somewhere between 5 words per minute (WPM) and 75 WPM

As it turns out I am an amateur radio operator (HAM) here in the US and I have my general license (still studying for my extra license), so I know about Morse Code but I can’t actually send or receive it. I tried back in the 70’s to learn it but never could wrap my brain around it. Seems to fit in the same general area as speaking and understanding other human languages besides English (I can’t do that either). I’ve tried to learn Spanish, Italian, Esperanto and Klingon. I’ve never had any success, the closest I’ve come is I can count to 39 in Spanish….. and that was with 6 years of training in elementary school.

Hardware

Thinking over his requirements, I realized I needed some kind of a waterproof case about briefcase size, perhaps a bit deeper then a normal briefcase to allow for a large light to be stored in the case when not in use.

Clearly needed to be some kind of embedded computer to create the text and control the light. Cheap and small, how about a Raspberry Pi (Rpi) model 3B? It’s small, easy to program, has lots of general purpose input output pins (GPIO) and has an HDMI monitor output. Perfect. Of course if you are going to have a computer you need a keyboard/mouse and a display. MonitorInLidAll simple enough. Now what kind of light will be bright enough to be seen a mile away and yet be controllable to be able to send Morse Code. Needs to be bright, really bright. Can’t use Halogen, that gets too hot and will keep glowing even when the power is removed, incandescent same problem, florescent does not turn on fast enough and keeps glowing also. LED fit the requirement – it turns on and off fast and it’s very bright. When you replace a household 100 watt light with an LED you usually replace it with an 8 watt (W) LED, so what if I use a 100W LED? I hunted around and find a 100W spotlight that is normally used on trucks that go off-roading. Now that is BRIGHT, slight problem however it uses 12VDC – 30VDC for power and requires up to 8 amps of current.  Video of a super bright LED light flashing on a blue wall.

We have a computer and monitor that use 5VDC to run, the LED light that requires somewhere between 12V and 30VDC and is high amperage at least compared to the GPIO pins of the Rpi. For easy portability powering it from 12VDC makes sense, that is easily available from a vehicle or a wall power supply. Some bigger trucks use 24VDC so keep that in mind when designed the circuit….. OK I found a DC to DC step down power supply that can handle up to 35VDC input and can output 5VDC regulated for the Rpi and Monitor. Now all I had to handle was the current for the LED spotlight. First thought is use a cheap 5VDC mechanical relay, the Rpi can control a 5DCV relay easily, except one problem. Sending text at 75WPM means that the transition speed between on and off is fast, very fast, in fact much faster then a mechanical relay can handle. So back to the drawing board…… Wait one, how about a solid state DC relay? 3 – 32VDC input for control – 5VDC input from the Rpi check that works, can switch 5 – 200VDC output – the LED light works on 12 – 30VDC, check that works too. Alright a solid state relay it is. Solid state relays can generate heat so make sure I get a heat sink made for the relay. Some miscellaneous other parts, wires, mounts, case, etc and we are off to the races:

So far we have about a $800 parts list:

  1. VideoSecu LCD LED Monitor TV Wall Mount
  2. SAE Cable – iGreely Solar Weatherproof SAE Socket Sidewall Port
  3. MUYI 2 Set Inline Fuse Holder 10 Gauge Waterproof Pigtail Blade Fuse Holder
  4. Kenowa Portable Monitor 11.6 Inch 1920X1080 IPS with 2 Mini HDMI USB(5v)
  5. Logitech K400 Plus Wireless Touch TV Keyboard with Easy Media Control and Built-in Touchpad
  6. RS Components Raspberry Pi 3 B+ Motherboard
  7. Miuzei Raspberry Pi 3 B+ Case with Fan Cooling
  8. Seahorse SE-720 Waterproof Protective Hardcase Without Foam (Black)
  9. DROK Buck Converter Voltage Regulator DC 5V Power Supply
  10. Blue Sea Systems DualBus 100A BusBar – 5 Circuit
  11. Universal Compact Bench Power Supply – 30 Amp Regulated
  12. Universal 6″ LED Spot Lights For Cars – 100W Bright 8000LM LED Off-Road Spotlight
  13. TinaWood SSR-25DD Solid State Relay 25A 3-32V DC/5-200V DC
  14. 8’ Aluminum angle
  15. A 1/8” sheet of Aluminum to bolt the computer hardware too.
  16. Misc bolts, pop-rivets and connectors.

Time to build the system into a solid system. I took the Seahorse case and built an aluminum frame that had 3 compartments, 1 for the LED light, 1 for the computer, relay and DC-DC power supply, and one for the keyboard storage. The entire frame was pop-riveted together, painted black and then the frame was riveted to the 1/8” aluminum sheet. Then nuts and bolts were used to secure it inside the case.

The LED compartment had a slot to allow the LED to be bolted down so the LED could not bounce around in the case, if that happened it would be a disaster, the light was big enough and heavy enough to break everything else in the case if it broke loose. The Monitor mount was bolted to the inside of the lid of the case and the flat panel monitor mounted to it.Computer-Power-Relay

Now wire up the Rpi, monitor, solid state relay and step down power supply. Plug in the external power and it works, it powers up and I get the Rpi logo on the monitor. Fantastic. Now we need some software.PowerSupply

Software

I had told the gent that I was going to use Open Source software on his project, fortunately he knew what Open Source software is so I did not have to explain that to him. I installed Raspbian on the Rpi and did a search for any Open Source application that sent Morse Code, I found only a few. I downloaded the source code to all of them and had a look. My original plan was to crib as much as possible from an application and only write the controlling aspects. No luck there. The few applications I found were not suitable for the project. Most were for learning Morse Code, the best was fldigi that is a radio control application but it was far too complex for the project.

So I had to design from scratch an application that could take a paragraph of text and send it via flashing the LED light. I called the command line application “morse”, I know really original. I used the “C” language as I wanted the application to be compiled and fast. Morse code is “interesting” it’s all about timing, more about that below.

Quick Primer on Morse Code

Morse Code is all about the dot. All the timing in Morse code is based off the time of the dot. So:

  • A dot is one time unit.
  • A dash is three dot time units.
  • A dot dot or dot dash or dash dash separation is one dot time unit.
  • A letter separation is three dot time units.
  • A word separation is seven dot time units.

How fast a dot is depends on how many words per minute you are sending, and from there cascades the rest of the timing. There are two type of timing: “Standard” and “Farnsworth”, the “morse” application can do both types. For more info lookup Morse Code on a search engine.

I designed the application in several sections.

  1. First I built a header file that was a lookup table of dot and dashes for each Morse Code letter and punctuation. I ended up building the lookup table for the most of the entire ASCII table with either dots and dashes or NULL’s for things not in Morse Code.
  2. The next thing I did was write the code to display a letter from the lookup table from that I added the ability to process and display an array of text. That all ended up being in a single C file called “display_morse.c”.
  3. Now that I could display text, I needed a way to load a text file into memory so it could be displayed, that ended up being in a file called “process_file.c”.
  4. Next I needed a way to tell the application the name of the file to load, speed to display it, how many times to loop displaying it, etc. all of that ended up going into a file called “process_command_line.c”.
  5. Of course if you are taking command line input it might be handy to also have config files that set the defaults so you don’t have to use the command line options, that ended up being in a file called “process_config_file.c”.
  6. Finally all “C” applications start with a main() function that is in the file called “morse.c” and the include file called “morse.h” which contains the master structure of variables needed to control the application.

The application is under the gpl v2 license and is available on github  It does use two library’s one of the library’s is specific to the Rpi to run the GPIO pin that controls the LED light and would need to be replaced if a different embedded hardware system is used, the other library is to parse command line options and can be used no matter what hardware platform is chosen.

It was truly a fun project and met his needs. It’s used on a really large field where they fly drones and don’t allow any radio communications except the drone controllers. Turns out there are apps that will read Morse code signals sent on light by cell phones! Who would have thunk??? So you can receive Morse code via your cell phone for short range communications but for truly long range well that is where a special project like this comes in. So if you need a special device and you can’t buy it on Amazon or at Target or some other store, and you really need it, get it touch with me and likely I can create it for you.

 

I started a company about 18 months ago, Secured by THEM. It’s a small company that I created to help small businesses be more secure on their networks.   There are bigger business that do this but they are not targeted at small businesses.

It was shocking to me what I’ve discovered since I opened the business: Any company with a cable modem as their primary Internet access has it set up incorrectly.  If you get your Internet connectivity from a cable company your cable modem is your first line of defense against Internet intrusion (being hacked).  If it’s not configured correctly it leaves a gaping hole in which crackers can reach in and infect your machines.

Apparently the tech’s that install cable modems are taught to pull a cable into the house or office, attache the cable modem to it and power it up.  If it boots and turns on the correct lights in the right order, it’s “good” and ready for the customer!  Usually the cable person attached a computer to the device and if they can reach the cable companies web site they are done.  If the cable modem has a standard default password like “password” the tech will change that some something random and write it on the side of the modem, but now a days, most new cable modems come from the factory with a random password assigned.

Little or no testing is done and little to no configuration at all.  What makes this even worse is how little you can do to correct the situation especially if it’s a “business” installation,  you’ll have a little more luck with a “home” installation.

If you are a business class user with many cable companies business class service you are out of luck you, can’t get the password and you can’t log in, the only thing you can do is buy a firewall and ask the cable company to bridge the modem to the firewall. (And of course setup the firewall correctly.)  I’ve watched some of the folks do installs and they leave the modems as they come out of the box!

If it’s a home based business you have the password to the cable modem (it’s usually on the side or bottom of the device) so you can log in and correct some basic mistakes.  But depending on the company and the cable modem you might be better off buying a firewall too.

Lets talk about what settings I consider to be  critical:

  1. Firewall functions turned on and set to the highest settings that allow you to get work done. (Medium or High)
  2. Universal Plug and Play protocol  (UPnP) turned off. The UPnP protocol “Internet Gateway Device” is not secure and can be used open your firewall up and make it easy to access machines in your network.
    1. See http://www.upnp-hacks.org/igd.html
  3. Primary WiFi network security using WPA2 or better security turned on.  WPA1 and WPA2 were cracked in September of 2017 and requires patches to be secure.
  4. WiFi Guest network turned on with WPA2 or better security turned on. Never leave WiFi access unprotected, never.
  5. If possible turn on 2 or 3 separate Guest networks, one for any device you own that leave the network and come back (phones and laptops) and one for Internet of Things (IoT) devices, friends and acquaintances” that ask for WiFi access.
    1. Coffee Shops can be places of infection.
    2. IoT devices in many many cases have little to no security and no security updates available.  More security issues in 2018.
  6. Remote access turned off.
  7. Turn logging on, it’s normally turned off.

Settings I consider to be important but you might not, or might not have.

  1. Static IP addresses via the DHCP server for each computer on the network.
    1. MAC address lockdown on the DHCP server so that no computers can get an IP address on the network without being manually added.
    2. You might only have this for the WiFi connections, some devices limit MAC address lockdown to only WiFi.
  2. Remote logging of cable modem logs to a computer that can store them for a couple of weeks vs the usual couple of hours or a day.

This blog went a little longer then I expected, so I’ll pick up with my next blog showing how to secure a Motorola Cable modem.  From there I’ll show setting up a Linux Firewall.

Pondering

After writing the pseudo code for the watering program, I let it simmer for a few days and then started on real code.  First thing I did was write a config file in the json format.  The target was to describe the watering zones in the system. ow many there are, should the program use syslog to log actions, and finally is there a rain moisture gauge attached and if so what kind is it (for now I only tackled a digital gauge that is either open or closed on GPIO 15), and there is a version number so I know what the file might contain as it evolves.  And yes the zones are 0 based, this file is not really meant for human consumption, though its pretty easy to read really.

Config.json

It looks something like this:

{
    "version": 0.1,
    "controller_name": "this watering system name",
    "log": 1,
    "zones": {
    "total": 8,
    "zones": [
       {
           "zone": 0,
           "name": "Human name of zone 0"
       },
       {
           "zone": 1,
           "name": "z1"
       },
       {
           "zone": 2,
           "name": "z2"
       },
       {
           "zone": 3,
           "name": "z3"
       },
       {
           "zone": 4,
           "name": "z4"
       },
       {
           "zone": 5,
           "name": "z5"
       },
       {
           "zone": 6,
           "name": "z6"
       },
       {
           "zone": 7,
           "name": "z7"
       }
      ]
    },
    "gauges": {
        "rain_moisture": {
            "present": 1,
            "bus": "GPIO",
            "type": "D",
            "device": 15,
            "signal": "NO",
            "use": 1
        },
    }
}

Watering

Once that was done and tested I located an open source json parser library that could parse that in easily.  No point in reinventing a wheel when there are perfectly good ones available.  The parser I ended up choosing was parson.  It’s lightweight and pretty easy to use. You can find it here and it uses the The MIT License (MIT) so all good open source stuff. Next I needed a watering program stored in json format.  So it contains the human name of the watering program, an option to use or not use the rain moisture gauge, then the zone info, including the count and zone info including zone number, how much water to deliver, the amount to deliver at one time, and a version number so we can track the file as it evolves.

wp1.json

{
    "version": 0.1,
    "program_name": "3 second watering",
    "use_rain_moisture": 1,
    "zone_info": {
        "total": 8,
        "WaterCycleExtraDelay": 30,
        "zones": [
            {
                "zone": 0,
                "WaterLength": 3,
                "WaterCycle": 2,
            },
            {
                 "zone": 1,
                 "WaterLength": 3,
                 "WaterCycle": 2,
           },
           {
                  "zone": 2,
                  "WaterLength": 3,
                  "WaterCycle": 1,
           },
           {
                  "zone": 3,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 4,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 5,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 6,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 7,
                  "WaterLength": 3,
                  "WaterCycle": 1,
           }
        ]
    }
}

Got that done, used the json parser to read that into the application.  Now we are cooking.  That sets up 8 zones to be watered 3 seconds each (that makes it easy to test) with a cycle time of 1 to 2 seconds to each zone will get run at least twice and 2 of them will run for a third time. So then I wrote the main code that will actually run the watering program and it’s working.  It’s not final, it has some bugs to be fixed but it works….

What remains to be done?

What remains before I can start testing it with some alpha/beta testers?  Some code cleanup add minor features, really it’s pretty much ready, it reads a rain sensor now (NO  or NC) it waters according to cycle, it knows time and date.

OK, sat down over the weekend and did a bit of pseudo code for the watering program.

Easy when you think of it:

  1. Grab command line to see what watering schedule to run
  2. Load system config so I understand my hardware
  3. Load the designated watering schedule
  4. Set up a loop to run all of the zones, if zone is not active or does not have any more water time go, loop to next zone, else:
    1. Check the global gauges to see if we can water, if not exit program with reason
    2. Check zone gauges to see if the zone can be watered, if the zone gauges say no water, zero the zone and go back to the top of the loop
    3. Determine how long to water, either to the limit of the soil or for the full zone time
    4. Start watering the zone
    5. Sleep for the determined time
    6. Stop watering the zone
    7. Go back to the top of the loop and keep doing it until all water delivered to all zones or we are bumped by gauges.
  5. Shutdown any specific hardware as necessary (make sure the water and the pump (if you have one) are off.)
  6. Exit program with status

Now there are some nuances there, logging and other bits but really that is it.  Overly simplistic and lots of detail to pay attention to but at the highest level no need to check things second by second.  And if for some reason I determine I have to check things more frequently than at each zone change I can by using threading but I don’t currently see the need for it.

So the first thing I decided to have a look at is what format are my data files?  Gave that a lot of thought, XML, YAML, JSON or some home cooked format.  After careful consideration of both the input web program and the watering program I decided on JSON for a bunch of reasons, its light weight, there are standard validation tools that can easily tell me if the file if formatted correctly, and its easy to write a json file from web software and their are a bunch of parsers under open source licenses so I don’t need to reinvent the wheel.  Finally it’s pretty easy to hand craft a json file and get it correct so I can get the watering program done and tested without the web front end.

In some ways I don’t love JSON, the pure form does not support comments in the file.  Several parsers do support C and C++ style comments but its not part of the standard as best I can tell.  Of course some people don’t believe in comments so it matters not to them but I do like them..  Oh well the rest of the file format I like well enough.

The other thing I thought about was possible devices attached to the sprinkler system to determine if I should actually water now, or things on the Internet I can reach out to, they are:

  1. Weather report
  2. Temperature gauge (don’t water if too cold)
  3. Rain moisture gauge (don’t water if raining right now)
  4. Rain metering gauge (don’t water if we got enough water in the last day, tricker as we have to have something monitor this all the time)
  5. Wind gauge (don’t water if the wind is blowing too hard, you will just water the neighbors yard)
  6. Ground moisture gauge (one for the entire yard or one per zone, if the ground has enough water now why add more?)

Additionally some things you need to know are:

  1. How many zones are active in the system
  2. Does the system use a pump to pressurize the water, if it does you need to turn it on for each zone to water
  3. Do you want info logged about how much water is put out and what was skipped (if anything because of gauges)

The metering rain gauge is bothering me, I thought I’d only need a web front end and a watering program but to track a metering gauge will require monitoring it all the time.  So I guess that will call for a daemon program that watches the gauge if you have one and accumulates water over time so you can decide if you need to water at all. Hmm, I think I leave that to last, or maybe someone else will code that since I don’t even have such a gauge, though I know they exist.

On to the next step coding the load the config.json file into memory and parse it.  Language well that will be “C” since I prefer that over Python.  IMHO Python is nice for proof of concept and quick one off scripts but I really prefer “C” for the watering program.

So, now that I have a test platform (and I still have a system in my garage that is watering the grass) its time to think seriously about the design of the software and how it will work.

The OpenSprinkler Pi has at least two open source projects one written in python and one written in C/C++.  Both of them model the OpenSprinkler Arduino software, in fact I think both can be run on both platforms.  That makes the software usable across more installations BUT at a large cost, loss of flexibility and security. The app has to run on the least powerful hardware the Arduino.  The Arduino is an  8-bit Atmel AVR microcontroller,  just bare metal is it were.  There are no OS services running on such a device. So the current app’s have to do everything on the Arduino, be a web server, serving the programming interface and have a thread that runs all the time to execute the scheduled waterings.  Simply because there is no other way for it to work on an Arduino.  Now don’t get me wrong, I like Arduino’s, and I use them for simple tasks and data gathering, they are great but they are simple devices and sometimes you need more.  Of course being an Arduino it sort of limits the damage that can be caused by crackers, you can’t reflash it remotely (at least I’m not aware of being able to reflash it remotely) so it’s going to limit what you can do with the device if you can crack it.

However the RPi is a different can of worms in this regard.  Linux on the RPi is very powerful, it is after all a fully fledged computer, not just an embedded bare metal device. Running a unified single application that has to run as root (to control the RPi GPIO pins) opens potential security holes, because on the RPi if you crack it, you can easily reprogram it to do anything you want.  Best practices on the Internet for web servers is you run them at the lowest level of authority so that in the event someone cracks the web site they can’t get control of the entire system.  Imagine if you have a single program running as root and a cracker gets control of it they could run up your water bill into thousands of dollars by turning on your sprinklers every night from midnight to 06:00 AM and turn your Internet connection into a spambot or worse.  You might not notice the damage until you get your water bill, or my my case a citation for illegal water usage!

Nope, a web server needs to have as little permissions as possible, so what can we do to address this. Well we can break the program apart, the “user interface (UI)”, “the scheduler (TS)” and a “watering program (WP)” to take the watering times and lengths and actually water the grass.

OK so the “UI” is run on a web server, check, low permissions, write data files and tell the “TS” when things need to be run.   This is not a complex program but it does require study as interfacing with humans is a skill that not all programmers have.  What makes perfect sense to a developer can be gibberish to the average human.  You need to present the information needed in a way that makes sense and builds on each step.  There could be some configuration sections that only the installer of the system needs to set, and other screens that the average homeowner needs to use to water the grass.

Next you need the “TS”, here on Linux you don’t actually have to write anything, you have cron.  Cron is a time-based job scheduler in Linux and Unix-like computer operating systems.  It can schedule jobs minute by minute, with the addition of at least one handy dandy script to enhance  cron (cron-last-sunday) you can schedule quite intricate requirements.   If you need more than that can do, you can add your own special purpose script to assist cron.

Finally the “WP here you potentially do need root access (there are ways around even needing root here but that is a topic for another blog entry).  The “WP” can only do what is in it’s data files it does not interface to the public so to speak.  The first thing the “WP” should do when it is invoked by the “TS” is quickly validate it’s data files to tell if the data files are corrupt, if they are it does nothing harmful, it simply stops.  It can however send an email to you saying “I did not water the lawn today because my data files don’t make sense.

No harm done, all that happened is the lawn did not get watered so no water wasted and all is well. If you carry a smart phone you will see that email within minutes of when the watering was supposed to start.  You can go see what the heck happened to the data files potentially fix them and still get the lawn watered in the correct time slot.  And finally the “WP” can only read and not write to the data files, so the only thing that can change the data files is the “UI”.

With the single program broken up into three (3) smaller separate bits we get higher security, something that is much easier to debug and we save time as we don’t actually need to write the “TS” program, we have it and its well tested over years of time and 10s of thousands of servers.  So 1/3 of the project is already written for you, now that is a score! ;-D

So now what, do I focus on the “UI” or the “WP”.  I’m going to focus on the “WP” because I can focus on what it is supposed to do, water the grass the way I want to water it: when (per zone), how much water (per zone), absorption rate (how much water can be applied before it runs off)(per zone).  Other things the “WP” can be aware of is a rain gauge (global), local weather reports (did it rain yesterday, is it raining now, does it have a high probability of rain tomorrow and how much is expected)(global), moisture gauges in the soil (is the soil already wet enough, or does it become wet enough while the water is being applied)(per zone or globa depends on how you install them).  Oh and lets not forget a temp gauge, because if it’s near freezing you don’t want to water then either.  And somebody I know wanted to add a wind gauge as he does not want to water if it’s too windy, as it will simply blow the water away and never get to his lawn.

As you can see the “WP” can be really simple: turn on the water per zone for x time.  Or it can be very complex: Turn on the water per zone but if the duration is longer than the absorption rate then only water as long as the ground can absorb it, cycle on to the next zone until it’s reached its absorption  limit and keep doing that until all zones are watered then loop back and put the remainder of the water in each zone, oh yea don’t do it if it’s raining now, or rained more than an inch yesterday or it’s expected at more than an 80% chance of an inch of rain tomorrow, and don’t water if its near freezing or the wind is blowing too hard. Whew, that is really really complex and yet easily within reach with an RPi as the controller, not so much with an Arduino.

Really if all you need is the simple instance, an Arduino is perfect for the job, it’s only when you get really complex do you need a bigger computer.

Once again I’ve written a really long blog entry when I meant to write a short entry, oh well, I’m done for now.  So a question, Ideas anyone, what features do you want in your sprinkler controller?

So I finally hooked up the opensprinkler hardware version 1.4 (OSPi) with my RPi and the Adafruit LCD Plate.  I tried a few things, I purchased the hardware without the RPi connector installed with the intent of using a stacking connector instead. That sort of worked, I had to cut the bottom of the case open with my dremel tool, was expecting that.  But there is a problem with this: The stacking pins are so long that the case has to be mounted on the wall with large offsets to allow enough room under the case to install a ribbon cable.  So it will work, but not really what I want to do.

Next I tried to add a pin header to the OSPi, on version 1.4  they routed all 26 pins of the GPIO to the top left corner of their board, nice.  So I installed a pin header and that worked nicely (sort of), but the RPi won’t plug in anymore, the Audio jack now hits the pin header I just installed. Whoops! So since I don’t need the audio out in this application, I decided to unsolder the audio jack. Fine that works the RPi will install the ribbon cable fits under the RPi.  So then using the dremel tool again, cut a slot for the ribbon cable to exit the case. That works.  So then I tried to put the cover back on the OSPi case.  Another Whoops, the RPi is now too high for the case to close, why?  The stacking header is some taller then the standard header.  So we have another fail. Time to remove the RPi and just install the ribbon cable and route it out of the case. Finally was able to seal the case with the supplied screws, with only the OSPi in there.

When I assembled the LCD Plate I did not use the standard 26 pin socket that it comes with, instead I installed a stacking connector so I could connect a RPi and something else to the LCD.  So the RPi is at the bottom of the stack, the LCD Plate is next and the ribbon cable is plugged in on top.  So now everything is assembled together.  I’m going to have to be creative to make a case for the RPi and LCD Plate, the ribbon cable sticks up above the display but that I “think” I can work around.  I’ll worry about that later.

OK, plug the RPi into the monitor and keyboard (which normally won’t be used but hey I”m testing stuff right now ;-P ), and plug in the micro USB connector for power.  Yea, the RPi lights up, no magic smoke being released anywhere.  Score.  Next I look at the OSPi and it’s powered up too, at least the 5V DC section is.

So I run a quick python program to  check the I2C port, as there should be at least 2 things hanging off it, the RTC @ device 68, and the LCD Plate at device 20 so time to run:

i2cdetect -y 1

The result looked like:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Yep both there 20 is the LCD and 68 is the RTC.  Next setup the RPi to use the RTC, easy instructions are avalible with the OSPi. 🙂 Then run the LCD Plate test code and yes it is working fantastic.

Now I need to test the rest of the OSPi hardware, the sprinkler control section.  Thats going to be a bit harder, I don’t want to go buy a bunch of sprinkler control valves, that is expensive so what can I hook up that can: 1) Work on 24vac 2) See a visual to tell it is working. 3) Is cheap since I only need it for debugging code.  Hmmm, first thought is light bulbs, they run on AC but have you ever tried to find 24VAC light bulbs? Turns out that is both hard and expensive.  BUT 12V light bulbs are plentiful and pretty cheap < $10 will buy 8 low voltage yard light bulbs.  But can I rig 12 VAC lights to a 24VAC source? Not likely 12lights will turn into a fuse at 24V and blow out.  Could add a big honking resistor and waste a lot of heat but thats just stupid and adds cost.  Wait will the OSPi work on 12VAC?

Yep turns out the OSPi will work off of 12VAC for testing, it needs an AC source of 24VAC to run sprinkler zone valves but the internal DC2DC converter that makes the 5VDC power for the RPi is happy from 9VAC – 24VAC. Perfect  Off I go and I buy 8 light bulbs, a circuit board to mount them on, and a 12VAC wall wart.  Solder up a test board with the lights and plug up the 12VAC transformer to the OSPi.   Sure enough, the OSPi powers up fine, makes 5VDC to run the RPi and all is good.  Finally 🙂

Well spoke a bit too soon. 😦  I ran some test code to turn on zone 1 light, it lit for a split second and the RPi rebooted!!!!  What the heck?  Turned out the wall wart was too low an amperage transformer, worked fine just running the OSPi, RPi and the LCD but turn on a 4W light bulb and the voltage drop was too much for the regulator.   So plugged in both the 12VAC transformer and the micro USB connector so the RPi and the LCD and the 5VDC side of the OSPi got juice from the micro USB. Tried it again, yea, it works finally I have a functioning test platform, with a slightly butchered case.  Let the coding begin.

When its really hooked up in my garage it will be supplied from the mondo 24VAC wall wart so that won’t be a concern.

OK, it is the 3rd Monday of June and like clockwork, the water came on and all worked as expected with a simple cron entry.

But lots going on that will generate a longer blog entry soon, the rayshobby / open sprinkler folks have some really nice hardware in the opensprinklerPi hardware.  So I don’t need to design my own board, I can use their open hardware project.  That said I don’t care for any of the software that currently runs on it, it looks like a clone of the existing weekly software that comes on any < $300 USD controller.  Yes you can program it via a web browser and/or a mobile device but it still lacks monthly levels of control.  Also the layout of the hardware restrict adding displays easily.  I added a header and will use a 26 pin ribbon cable to remote the PI and display from the opensprinklerPi hardware.  More about that later.

 

Have a nice day, I am since I no longer have to worry about my lawn getting watered on the correct day…..