CounterMoon.org

The idea of the site is to enable as many people who want to, to take to the road and enjoy it as much as possible. And while the progress is slow, I think it's important to describe how to construct what I already have, as well as new things as they happen.

As changes to the onboard computer happen, this article will be updated.

The onboard computer, Tripstar is meant to handle HVAC controls, internet connectivity and security. That's a smaller job that a "modern" desktop; there's no need for a Pentium 4, for example, to get this much done. And that makes it a great add-on project for any RV'er.

The hardest part of the entire thing isn't in the programming or connectivity, or even heat dissipation.  It's finding a proper mounting device. But there's hope: several odd-looking models of HPs (those that look kinda like jellybeans) have a natural slide-out mounting device that's just almost ready to go.

The difficult part is to locate something to hold up daughterboards while at the same time supporting the motherboard.  But there are other options, if you have the money.  In fact, some of them are quite nice, some really 'hacky'.

The makers of my power supply also have enclosures and ATX motherboards built for this purpose. I've not tried one due to the money, but they seem pretty good. This kind of enclosure means there's no space wasted in creating an enclosure, less heat problems, and you can mount it almost anywhere.

I chose not to go this way because when I started the design it wasn't available, and I anticipated the computer taking up more space than it does.  In fact, before long, it'll be a tiny little thing I can almost walk around with.  For example, these days a $300 netbook can almost do all of it!

People look at me funny when I first mention the One-Wire sensor network. Electrical majors will instinctively assume the other wire is ground, and they'd be right. It's a means to hook up a number of great sensors with minimum fuss.

Using parts from Dallas Semiconductor, a One-Wire sensor network can use a single line, grounded at both ends, to communicate temperature, pressure, solar intensity, rain depth, humidity and other things with better-than-hobbyist accuracy.

There are several places that package this technology, but the simplest and most reliable for me has been Hobby-Boards.com. They use modular connectors on their parts, and make the most of 6- or 8- conductor cables. Why 8 conductors? Simplicity.

This way, the center two conductors, whether using 4,6, or 8 wires are always the data lines, other lines like unregulated +12 to +24 are available to all modules. No special lines to these devices. And if a device doesn't need/use +5v, it doesn't have to be wired. The flexibility this provides is stunning- everyone has a wire crimper for network devices, anymore.

Now, if you actually _prefer_ individual lines, or want to maintain backward compatibility with an older system, Hobby-Boards has gone to the trouble of having terminal connections, too. Using discrete wires, just slide'em under the terminals and be done.

Network 'Dongles' - there's only one

Using the USB dongle, or network device adapter, might seem convenient, but under Linux, it requires you to run all software as root. This complicates production of software and leaves the system less secure in the long run.  Get the serial dongle; it looks like this:

Once you have this dongle, and you're sure as to which serial port is using it, we can bring up OWSERVER to begin communications. Using OWSERVER isn't strictly necessary, but if you ever want a second use of the device, you'll be locked out. OWSERVER offers you a network-assessable form. Then you get OWFS or the others pointed to the local device, using the default ports and voila! you're reading temperatures, pressures, maybe even the neighbor's newspaper. :)

But all this discussion I'll leave for the Computer Software category- this is hardware.

Once you have a number of sensors, it becomes smart and effective to use a "hub" which powers and organizes network traffic. Done right, you could talk to several HUNDRED devices on a network with relative ease. Let's look at some of that, shall we?

Network Hubs

Hubs both power and organize your network. They're valuable parts, since they separate traffic. When you're reading a door switch several times a second on one line, while reading a world of sensors on the other, you too, will know why you need at least one. And considering how they power all the lines leaving it, it's a good thing! Mine is an eight-port.

The workhorse module

They have a multi-purpose module, show here, fully populated. It comes with a temperature, humidity, and/or solar intensity sensor all in one container.

Are there places where you solder-tail a temperature sensor and snake it down a tight spot? Sure! But more often than not, one of these will care for an entire room/section/department all by itself, beautifully and elegantly.

Optional but fun: The LCD

This is actually two devices; it's an adaptor between One-Wire and an industry-standard LCD made by Epson, but both have been a marvelous investment. Without it, I'd not be sure of the program's status- even when it's locked, it's telling my my program feeding it new data has 'taken a nap'. It's optional, but I wouldn't be without it.

The rest of the time it's feeding me pages of information, screen-by-screen. I have everything I need there, without having to rely on 110V power for a monitor, nor investing large-coin in a battery-sapping 12V monitor. The only thing I wish it could do more is read switches in a more simple way. But I believe someone's already working on a keypad, so it won't be long.

Summary

This demo comprises almost all the devices I currently use. I do so not because they pay me, but because when a product performs this wonderfully, when there's a good value out there I can actually crow about, I'm gonna crow!

Don't misunderstand: a lot of people offer this technology, including rain gauges and lightning-strike detectors, but no one I've seen offers them in such a simple, flexible, reliable way. In the last couple of years from dry to wet, from cold to hot, I've had not one second thought about this purchase.

If you visit them, let'em know I say hello.

It was the PicoPSU90, it was the M4-ATX. :)

Starting with the PicoPSU90, life was good until the power dropped. It was cool how a desktop PC could, in fact, be made to run on 12V. The thing was very small and generated little heat while doing almost everything I needed it to do, but it was sensitive to voltage. It was designed for rooms with clusters of machines all running from 12V lines, not vehicular use.

Once in a while someone pulls the 110V line where I'm docked to mow the lawn. Eventually I'll be pulling it myself as part of the undock-sequence. The old supply would run only for a short time on batteries alone; it had a narrow range of operating volts. It needed to work when the 110 was there, but also a reliable amount of time on batteries alone.  The idea was, after all, to send-for-help if the trailer was stolen. I'd just be happy if it'd email me to let me know the power cord had been pulled.

A year or two later I had the money for the M4-ATX. It had serious terminals for power, had to be wall-mounted, and a manual that was far from complete. It also has a voltage range of 6-30V. I was looking forward to seeing just how long it took my garden-variety battery to drain to 6.0V.

Well it's around 20 hours, actually. And when it went down, it took the motherboard and hard drive with it. While it showed a cable connecting the power supply to the "power switch" pins to turn off power at the right time, I didn't know it was required; I'm also not using the "ignition" line, because I don't have one.  I had to extend the line, another test is planned for sometime soon. I have a good feeling about the outcome, now.

One of the nice things about running an all-circa-2002 design for this application is that all the major bugs are out; you can read the sensors, the BIOS is as up to date as it'll get, and things go together well. While things may have been undecided back then, now Linux sees them for what they were trying to be, despite every manufacturer trying to corner the market in each and every possible way.

Like ACPI, the power-down sequence when the machine senses it's idle. Before 1999 *everyone* wanted to corner the technology. So no one's machine actually worked. Linux' kernel turns off ACPI at all for machines before 2000, for just such a reason. And by now, every tweak of every driver has been made. While they're old, and I wouldn't use them on a NASA mission, they're perfect for here.

An example of the settled technology is the view of the power supply and compartment temperature from a remote machine:

Life's pretty good now, both having the proper PSU and being able to monitor it from another room. (Or county) But there were some lessons learned:

• Mini-Box has good components at fair prices
• Mini-Box has documentation that needs work(!)
• Make sure to get the wide input range for ANY vehicle use
• Expect a month of emails if there's trouble with Mini-Box
• Despite the manual suggesting otherwise, their tech-support email is " This e-mail address is being protected from spambots. You need JavaScript enabled to view it "

Now that the power supply is doing it's job, and the parts are coming together, life's pretty sweet!