Experimenting with Arduino and MikroEektronika’s click boards – Part 3

Part 3 – Wrapping it all up

It’s finally done!

burst

I had some problems fitting everything inside the box:

dav

…which was big enough or so I thought!? E.g. powering the RPi through the dedicated micro USB port proved to be a challenge no matter how I rotated the boards, so I decided to  go an alternative route. I ended up using two test points on the RPi and soldered a couple of wires:

power to the rpi

Yes, I know – it’s after the RPi’s protective fuse, but I figured it’s a controlled environment so it shouldn’t be a problem.

The board is powered from the car’s 12VDC lighter connector and this voltage is further lowered to 5VDC with a small buck boost converter board.

The red LED lights up as soon as the RPi starts the Python script as a background service. The first green LED indicates the GSM modem is powered up, while the second LED indicates the status of the GPS modem. If all three LEDs are ON, then the fourth yellow LED blinks each time the GPS coordinates (along with the other parameters e.g. a tank’s level, albeit random numbers in this test) are written on the RPI’s micro SD card.

The red button – if pressed for at least 5 seconds – gracefully power offs the RPi, while the black button – it too if pressed and held for at least 5 seconds – resets the two modems. I actually reset the entire Arduino with this button and I do this through SW, but in order to accomplish it, you need to wire the RESET pin to one of the available IO pins. Instead of soldering directly on the Arduino, I chose to do so on the Mega shield:

dav

The entire code is on my Bitbucket repo.

I need to get clear something out right away. This was an exercise in getting to know the two modems, how they operate and what they provide and it’s in no way a definitive solution!

The RPi for one, is a needless addition – I use it mainly for debugging purposes. It connects to (only!) my personal WiFi hotspot, after which I can connect to it through SSH and get the file with the GPS coordinates. For the controller I would use in the future something based on TI’s LaunchPad series.

Furthermore, I used the delay function (perhaps too excessively) when in fact it should be avoided at all costs! It’s what is called a blocking code and there are other ways to handle things.

tracking system _ map overview

tracking system _ point details

I am happy with this proof-of-concept and what I have learned in the process! I’ll be definitely looking into packaging this properly i.e. making it as small as possible (e.g. by using a different controller and ultimately ditching the RPi) and do the code properly (without the use of any delay functions!).