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?
Time flies, and the project has been dormant for a while. Since my last post, I decided to expand the project a little, making sure that the geiger display would allow for other kinds of data as well. The main progress for now was to get data displayed on the screen. First the obligatory ‘Hello World!’, and then one of the background bitmaps that I will use for the main information display. The colored ‘scales’ will show the radiation level and other information that I have yet to figure out. But, I’ve got the communications with the 4D Goldelox controller sorted, and that’s a good start!
Now that the geiger counter is working and giving me TTL pulses in an orderly fashion, it is time to decide on how the radiation level will be displayed inside my apocalyptic survival vehicle. For the last few days, I have been designing a computer circuit that can display stuff in a car, based on a Microchip 18F4680 18-bit microcontroller. The display is going to be an OLED module from Australian 4d systems, a display module that has a built-in graphics controller and can be controlled by a serial data line. Read more about the module here: http://www.4dsystems.com.au/prod.php?id=84
This module can fit inside a 52mm instrument housing with a bit of modifications. The computer will also have to fit inside this housing. I have designed the computer to be in-circuit programmable (I foresee an endless series of firmware upgrades before I get everything right). I am using a couple of optocouples as inputs, in addition to a CAN bus interface (a CAN controller is available in this particular microcontroller). Who knows what I can expand this project to cover in the future 🙂
Got the Geiger Counter finished. The tricky part with building a Geiger Counter is that the Geiger-Müller tube requires a high voltage across it. Whenever a Beta- or Gamma particle enters the tube, it shorts out for a tiny fraction of a second. The high voltage is fed through a large resistor, and when the tube shorts, the particle creates a tiny voltage drop across the resistor.
Home-made geiger counter with tube at the top and HT board at the bottom. The board was printed on plastic foil, and a photo-sensitive print was then exposed and etched to create the circuit board. I know, the soldering leaves a bit to be desired, but I was trying out various component values to make the counter work correctly.
The tricky part with the high voltage was solved using the KU-3294V high voltage generator. This circuit board came out of a broken LCD display that used a fluorescent backlight. With 5 volts in, it generates about 500 volts out in this case. Two 200V Zeners pulls the voltage down to the 400V that is needed for the tube. Furthermore, the detection pulse is formed and fed into the good old SN74121 monostable multivibrator with schmitt-trigger input. This is a brilliant circuit, and makes it really easy to generate nice TTL square pulses on the output when a radioactive particle is encountered. I am not simply hooking up a speaker to get the classic geiger ticking sound – I want to interface this with a computer so that I can make calculations. More about those plans in the next post.