While being away doing other things, I was thinking about ways of improving the overall design. I decided that the main problem with the project was that it consumed too much power while in sleep mode. After all, it is intended to be in a truck that may be parked for a long time. So I designed a common power board for the CPU and the gauge, and redesigned the CPU and gauge to use more modern, low-quiescent regulators. Car power can be pretty spikey and dirty, so I made a filtering board that will also kill transients and noise in general. The output is an 8 volt bus that supplies the gauge and the CPU
The CPU itself received an upgrade. The main item was the MRF24EG0 WiFi module, which replaces the ‘b only’ module. In software, the IP stack got upgraded to the latest version to support the new module. In addition, the afore mentioned voltage regulator upgrade and a 5v software switch brought the sleep current down into single digit mA figures.
The most important redesign was probably to combine the geiger circuitry with the GPS, greating a sensor board with a minimum of cables.On the top side, you see the RYN25AI GPS module and the 400v high voltage module for the geiger counter. On the bottom side, you see the two SBM-20 geiger tubes. An additional feature of the new board is that it holds a RS232 level converter and an header (left in picture) that is pin compatible with the Iridium satellite 9601 SBD modem. I picked one up at a surplus sale, but haven’t decided whether to use it or not. Anyway, the hardware is there, just in case.
This is the CPU chassis, holding the CPU board and the power board. The display and buttons are for debugging – I may make another version without the display to be installed in an actual vehicle.
Here is a picture of the whole set-up, hooked up and working. Still doing some final wiring, so the back wall of the CPU enclosure is off. I found some neat military-style multi-pin plugs on ebay that came in handy for hooking up the cabling. It looks cool, but I still think they’re a bit flimsy to be real MIL-SPEC. Or, maybe, some military outfit will get in trouble when it rains… 🙂
Oh, yes, the relay board: also found on ebay, an 8-channel relay board with optocouples and everything. This enables the set-up to control a vehicle remotely via SMS, APRS, Iridium, Wifi, or BlueTooth. One of the relays is used to switch off the APRS radio when the unit is in sleep mode. The others can be used for door locks, horn, ignition cut-off, or whatever. I find that there’s a lot of good stuff listed under ‘Arduino’ when you search ebay. This board has of course nothing to do with that specific platform, it’s just in fashion right now…
So, what does it look like when you put this in your survivalist vehicle?
This is the geiger display, showing the ‘counts-per-minute’. The common bar graphs indicate the GPS coverage (satellites used/available), the GSM signal strength, the number of WiFi activity in the area, and the radiation level. Using a button, you can change which screen to display. If any parameters go outside the preset values, the screen will switch automatically and an alarm screen will be shown. These are the most important screens – there are many others.
This display gives us the raw GPS data, speed, disrection and elevation. Nothing is showing for the bearing since the speed is too low to give that reliably (5 km/h minimum)
There’s the WiFi hotspot list, giving the strongest access points seen…
One of my favourites – the APRS station radar view. This shows the bearing and distance to nearby APRS stations. It autoscales, so that you always see stations if there are any. This was probably the most tricky thing to make on the PIC32, requiring some pretty heavy floating point math on the CPU.
The APRS data screen is useful – it cycles through the data from all seen APRS stations. displaying data and the the relative position for each one.
And, finally, the mandatory reference to ‘the Matrix’ (yes, it moves) Useful? You decide!
It’s been a busy month. I’ve built and re-built the main board (leaving a soldered mess – I need to build a second one to clean it up). The CAN communications is working, and the main board is communicating with the external devices (FC301 2m tranceiver module w. opentracker packet radio modem, Siemens TC35 GSM, and a GTPA010 GPS). In addition, I have a 8 channel relay board, the geiger input, and an on-board temperature sensor attached using a one-wire protocol.
The modular plg in the center bottom is the programming plug for the Microchip ICD3 programmer. This allows for very fast software prototyping. Sure – I can emulate and single step the software before programming. However, with this many external devices being controlled by the software, I depend on being able to run the program ‘live’ and use a multimeter, scope, and protocol analyzer to troubleshoot the various components.
One of the most exiting aspects of this project (in my view) is the use of a CAN bus to communicate beween two CPU’s. CAN is not a super-fast way of doing networking. In a project like this, though, there is very little overhead from an OS, protocol headers, or anything else. The main CPU is running at 80 MHz, the display board at 32 MHz, and the bus speed is 250 kb/s. As it turns out, with everything going, the bus and CPU’s are mostly idle (!).
So, with the hardware mostly sorted, a whole range of possibilities present themselves. The software I have written so far will keep track of all APRS stations nearby and display them on a little radar screen (picture above). I can text the unit from my cellphone and get a position- and radiation report back. The position, radiation and other status info is reported in the APRS telemetry stream. The unit also reports telemetry to a web-server I have, every time it connects to an open WLAN network. Using GSM, APRS, or commands from the web server, I can control the relay board. The display board gives me correlated data continuously, showing radiation, nearby APRS stations, WLAN networks, GSM coverage, etc. etc. I can configure alarms that are displayed and transmitted when triggered. The optocouple inputs (4 on the main board, two on the display) allows me to read inputs like the state of the car alarm, ignition level, and other car-related things. The display board even has a photo diode that regulates the display brightness via the PIC18 A/D converter. This data is also part of the telemetry. My imagination is the limit, really.
I would welcome any questions, feedback and suggestions on this project – maybe it inspires similar projects?
A classic project problem is the so-called ‘scope creep’. A customer will revise specifications to include more features, and the project is not finished on time as a result. In this case, I can only blame myself since I create my own specs.
I wanted to combine more data sources than just the geiger counter, making better use of the display. I have been playing with the pic32 controllers lately, and come to realize just how powerful these little chips are. So the project scope increased: the goal now is to make a central unit that consolidates data from many sources and feeds the data to the display over a CAN connections.
The plan is to add a WLAN module, a GPS, and a GSM modem. This way, the set-up can be used to track a vehicle and communicate over the internet. A new PCB was made, and the project moves forward!