Boards, Firmware and Stuff - Part 9 of the Springtime Project

Just to wind things up here are the parts and designs I used in the Springtime Project GPS/APRS for the car. If you have any questions feel free to post a comment.

The 5V 2A supplies are used to power the MCUs and the LCD screens.

The voltage regulators are 5V@2A LDO voltage regulators, with .8V dropout at full current rating

The smaller Caps are 47uf, and the larger caps are 100uf. 

I didnt use the connectors for the inputs and the outputs but soldered 12 gauge pre-tinned wire to the pads directly.

The 3.3V GPS power supply:

This provides 3.3Vdc to the GPS

The Voltage regulator is a 3.3LDO surface mounted regulator

You could redesign it for a traditional regulator, I needed this to fit into the enclosure

The caps are 47uf, the resistor is 1K, and the LED is optional

I did solder in a surface mounted LED in place of the regulator LED, for space savings

The headers can be redesigned, they are labelled VCC,GND, TX and RX for the serial communications from the GPS

Note: On the header on the bottom, VCC is replaced with 5v0, this is the 5V input to the power supply! The GPS I used, runs only on 3.3V. If you find a 5V version this power supply is unnecessary!

Both of these boards are available at OshPark.com in my personal projects listings, if you want the actual boards, contact me, Ill give you access to order them. 

Firmware:

 Since I ran into the issue of the LCDs using the same address, and I was under a time constraint, I used my original arduino sketch and busted it into 2 parts, one for the time and temp, the other for the GPS. Here is the sketch in its entirety. You can do what I did, or use a serial LCD and a I2C LCD, or in my next version Im using a larger OLED screen, which Ill be able to fit all the information on one screen. This sketch can help you get started.

The sketch is an adaptation of the demo sketch from the TinyGPS++ library for arduino. That about wraps up everything I did. Hope it helped someone a little. Again if you would like any or all of the materials I used, help with the firmware, or want to adapt it for your car, feel free to comment below and as always

Happy Coding!

Post Install.........Final Part

I can safely say that this project was fun, and version two of this is already in my head. I do think Ill wait a while though before I change things and enjoy the fruits of my labor. The console is now officially in the car, and aside from trying out the cell phone chargers, its working like a charm.

The console contains:

2 - Pro-Mini328 Arduino compatible MCUs ( one runs the time/temp, the other the GPS)
2 - cell phone chargers  ( one offering a cigarette lighter type, the other USB)

All the switches. Those controlling 12V are lighted.
1 - ICOM2100H 144MHz radio for APRS broadcasts

Power distrubution

2 - Self designed 2A 5V power supplies

Also included in this install

1 - 144Mhz collinear whip antenna
1 - GPS unit/ self designed 3.3V power supply
1 - Byonics APRS Tinytrak3 GPS encoder

Initial test show that my 1second updates to the LCD screens are more than enough to show an near real time position indication. I cross checked this against my Yeasu350 and they are both dead on. Its kinda nice now to have near real time readout of position, as well as other features in the car.

Final thoughts:

After working on this I think that I would have used a different medium for the actual console shell. You can see in the final picture above that the wood has imperfections on the milling process, and additional sanding on my behalf still left some " hills and valleys" in the side of the console. Im opting for an all plexiglass body in the next version.

Wiring: The wiring started out neat and looked good, but when I added in the GPS cable, and and the pigtails to power the unit from the car, I could have done better. There are no " barely hanging wires", or possible shorts or problems , " just waiting to happen, but I dont like being rushed and the wiring can be done better with more time. You dont see any of this because its inside the console shell, but I know its there :-)

I was glad I added a switch for the 20x4 LCD back light. I tested this at night, and the large LCD is VERY BRIGHT! I knew this going in, and added the switch so that while driving at night, it can be turned off and on as needed, but not disturb the driver.

Lock up time on the GPS ( not pictured but its in its enclosure on the dash) is fast. Way faster than when I was testing in my house. Its around 30 seconds from a cold boot. It often locks up before I leave the driveway.

What about performance? On 25watts, I am able to reach the distant digipeater. The 6dbi gain of the collinear antenna makes up for the lower power Im using. The first morning commute test run of the system was good

I dont have great coverage in the town I live in due to hills, but once I got out of town I was able to access the APRS digipeater and get my position reported in the system! Im taking a long trip in a few days...time will tell.

All in all this was fun, there is a lot of room for improvement, but it was a great project to meld together, arduinos, GPS, cars and amateur radio all in one project. Look for Version 2 of this in the coming months, but for now, I think its pretty cool!

Happy coding!

Part 7- Finishing up for the final installation

With a few of the bugs worked out, the system is running through its final paces, before its to be installed in the car. While this is testing, time to turn my attention to the other part of this, my bike.

This will be the first time I have equipped the bike with APRS. I ordered the Byonics TinyTrak3, and they arrived ready to put together. I was surprised, both were easy to put together, once all the resistors were sorted, and the parts inventoried.

I did make a small modification for the bike tracker. I changed out the big T3 LEDs for some smaller, less power consuming SMT leds, and changed the current limiting resistors from 1K up to 3.3K. This reduced the intensity, and the power pulled by the LEDs, and saved me a few milliamps when operating. Getting the system working was easy, Byonics provides a free configuration software package in both Windows and Linux, to configure these guys. Hooking them up requires a null modem between the encoder and the computer...not a problem, I just used female to female jumpers and crossed Pins 2 and 3 on the serial ports, and passed Pin 5 (gnd) straight through. They connected to the computer instantly, and I configured them in a couple of minutes.

Finally I hooked up the cable I bought from Byonics to the UV5R handheld radio I have, applied power and checked my FTM-350 for a broadcast packet....in 3 minutes, success!

The GPS wasnt attached, so there is no location info, but I still need to whip up a serial cable for the GPS, in all accounts, this part is done! I have a handlebar bag, that all of this will fit nicely into. Im still trying to decide whether to add a small whip antenna, or just see how the UV5R does on its own. If I have time, I might whip up a little antenna, but its not necessary. Supposedly where I am riding in a couple of weeks is covered by some wide coverage digipeaters, so we will see how it works.

Also with the configuration software available for Linux, if I run into a problem, Ill have my laptop with me with the software on it, I can hook up a quick null modem, and reconfigure if necessary.

Finally the burn in for the console is about done. I had a wiring mistake on one of the controllers. I made the software serial pins 6 and 7 not 7 and 8.....so instead of unsoldering the headers and moving them one pin up, I just reloaded the code, and changed the software serial ports to pins 6 and 7....done.

The new finish is dried. I used a textured finish that adds just a little texture to the overall console. I didnt want to use glossy black paint, the texture added a nice touch

Next is to obtain the power taps for the cars fuse box, and run the wires. Since its Thursday, Im gonna wait until the weekend, when Im not rushed. So thats all for now

Happy coding!

GPS project Part 6

So the project continues, and really its almost done. I ran into a major snag, and maybe by posting it Ill get a little feed back to fix the problem.

I ordered a TFT screen. Its nice and in earlier posts you see that I had it working. Its was working in a static state. Static state being that I could input the labels I wanted on the screen, and enter in dumby data to see where things lined up on the screen, how colors looked, and placement. What I didnt know was TFT really really sucks for displaying real time data, especially in SPI interface mode. What happens is the data is written to the screen, in order to then display a new piece of data the screen must be erased and rewritten. When using  say a 20x4 LCD this is not an issue you can simply print some blank data " lcd.print( "       "); and you are done. Then all is needed is the new data written back. It works and is pretty fast, especially on I2C bus. What I discovered with the TFT screen is the whole screen needs to be blanked out and then refreshed, or one trick is to write and fill a black rectangle where the old data was, then print the new data. While this is similar to the LCD screen printing blank spaces...its too slow, at least for now. At a later date Im gonna try using the 8 bit mode instead of SPI, but Im under a time constraint, itll have to wait.

SO, yet another change. What I did was use 2 LCD screens...so why two? If driving down the road and you just want to have time and temp displayed, then you can turn off the bigger GPS screen and vice versa...or any combination there of. SO I broke the original sketch up into two parts, rewrote a few line of code for the LCD screen I2C bus displays.....enter my next problem

When I ordered the 16x2 LCD it came with an I2C bus module already soldered on the back. What I found out after tracing down the problem was BOTH displays were using the same address 0x27...great. You can fix this pretty simply by demuxing the clock (SCL) line so that one display sees the SDA line HIGH, and will ignore the data on the bus, allowing the other display to change...and vice versa...again Im under a time constraint, no time for rewiring things and adding boards. I could have done it, I chose not to. I fixed the problem by just adding another MCU. I have several of these Pro-Mini328 MCUs, fully arduino compatible, and there are cheap, at just a few dollars each. I think I paid like $4.50 each. I cant make them that cheap...SO I always keep a few around. In this case, it saved me a lot of time.

This is obviously the 16x2 undergoing testing. You can see the Pro-Min328 on the beardboard. The gray cable is connected to the GPS, and I stripped off the code to display just the time and the cars interior temp. Hard to see but the LM35DZ is on the breadboard in the upper right corner.

This is the final design for the 20x4 LCD, nothing fancy. Im displaying the latitude, longitude, the number of satellites the GPD receiver is seeing, and the current Altitude in feet. The "GPS" in the upper right corner means the receiver is locked on, if the receiver is not locked on, then the "GPS" is simply absent from the display.

Around each display, as you can see in the upper picture I made a Plexiglas bevel to go around each display. Its just .20inch think Plexiglas you can get at any home supply store, then just measure and cut it out. Be prepared to do a lot of filing to make the LCD fit. I now dream of owning a 65W LASER so I can cut my own, in the meantime, I do a lot o filing.....

That's all for this addition. In the next part, we will finish the wiring, and mount all the stuff ready for the final install in the car!

Happy Coding!

Part 5.... the firmware

So having all these parts and assemblies together really means nothing if they dont do something cool, and the firmware is what glues that all together. As I mentioned I was under a bit of a time constraint, so it was easier to look and some examples and libraries to get what I needed, and understand whats being done. Normally I write all my code, but right now, I need stuff to work, Ill make mods later.

Credit where its due. I looked at several libraries, .cpp and header files, and examples from folks like Limor Fried ( LadyAda), Mikal Hart ( TinyGPS++) and others to see what I could find. Mikal Hart has written a great GPS library, and Ladyada some great code on the TFT screen, so why reinvent the wheel...

The firmware:

First we need to set up the libraries, and the initialize things

I need the library SPI to run the TFT screen since its SPI interfacing. The TinyGPS++ library is to interface with the GPS receiver, and gives us the tools to parse out what we need from the NEMA stream. The two ADAFruit libraries are to use the graphic capabilities of the TFT screen. Finally we set up the Software serial, address the pins to use, make our definitions. Last, initialize the analog pin A0 (CARTEMP) , so we can read the temperature from the probe in the car interior. Thats everything we need to make this work.


Next we setup things:

There really isnt any magic going on here. All we are doing is setting up the serial ports. The software serial port connected to the GPS, will send its data to the arduinos serial port. You can then debug the data, which is helpful. The rest of the code here is nothing more than setting up the screen in landscape more  ( tft.screenRotation(1)) clearing the screen, outputting a message to the user thats the system is booting up, waiting a second, and telling them its done. In the final version, the delay put in here ( delay (1000)) will be changed to delay(30000) or 30 seconds to allow the GPS time to do a cold boot and acquire the satellites. I may or may not drop this in the future, and just tell the user its is powering up, but thats later, again time is not on my side. This needs to get done, playing with user interfacing is a later project...

The VOID loop:

This is where everything get done. 

ok.. the fun part. In the first part of this the code is telling the arduino to look at Software serial port (ss). Its going to see if there is data there. If there is data available, then decode the data and jump to the void loop " displayScreen".

If there is no data available after 5 seconds, then it jumps to the routine that throws the warning on the screen stating that the GPS is unlocked, and stays there until there is data available

In the loop for the display screen, I have shown the part ( and all the other parts are the same) for parsing out the data ( in this case latitude) and displaying it on the screen. This is repeated in one form or another for longitude, altitude, speed and the number of satellites the receiver sees. All the " if " loops are, is if the code sees a change, for instance " if (gps,location.isUpdated())" then parse out the new value and display it...its rather simple. Mikal Hart does some great explaining on what the library does, and how to use it, its worth looking at the examples and understanding what its does.

Ima bonehead:

As I have mentioned Im under a time constraint. Cute things and added features will come later I just need functionality. When I wanted to display the clock on the screen, I parsed out the time from the NEMA data, and used some examples to update the hour, minutes, and seconds. There were two small problems though. One of the people using this doesnt know what UTC time is ( the standard time sent in the NEMA stream from the GPS satellites.....and we are under Daylights saving Time. If the satellites are sending UTC time, how to account for all of this.....enter my boneheaded bandaided work around.....dont comment on this part of the code...it works, for now until next November when the time changes locally....

This is the dumbest code I have ever written, and the first thing Ill fix later. Basically this code accounts for GMT time, converts the GMT time to DST for the central time zone in the USA, and then make corrections if the time falls after 00:00 local time. In reality it works, its bad code, but I didnt want to sit there and add the code to figure out what day it was, and the month, and then add in to fall back an hour in November, and spring ahead an hour in March.....yes it can be done, this is a bandaid to make it work ...FOR NOW...I get a chuckle everytime I see this part of the code....

Finally the code for the car temperature code. I just wanted to add this, as a cute feature. Its taking an LM35DZ Celsius temperature probe, and converting the temperature to Fahrenheit, and displaying it on the screen. I may move this down to the APRS radios heat sink and monitor the temperature there...its probably the only real " bell or whistle" I added

This about it....nothing fancy. Ill add the entire code in the future for anyone that might want it to adopt for their needs.


Happy coding!

Shell done, now wiring..Part 4

So the project progresses. With the code written, all thats left is the bugs and the wiring, and Im sure there will be bugs, but maybe not. Once the full system is bench tested, basically there is nothing left but the wiring, and making it pretty.

I went ahead and did the final fitting in the car. I have to admit I was able to make a pretty nice fit, which is what I wanted. Though its not original to the car, I didnt want it to look sloppy after all. While Im testing the code, and burning the system, I put the first of a few coats of paint on and started the wiring.

Basically the ugly part of any project, wiring it all together. This is a picture of the start of that process. You can see the APRS radio is now dry fitted in its new home. The wiring here is for the panel switches, the two 5V power supplies, and the mobile phone chargers. My calculations Ill need 2 circuits from the car, a 7A and a 15A. The 7A circuit will power the 5V supplies, and the chargers. The chargers pull 2A each, the power supplies are 2A each for a total of 4A, plus a little head room so no fuses are blown. The radio is a 55W radio and pulls 11A on high power. Ill probably run is on medium power which pulls 7.5A@25W. This still needs the TFT screen hole cut, and the arduino wiring install but that will be soon enough, that mess is still under test.

The GPS receive and the power supply I designed are now finished and work great. I found some commercial enclosures that look nice. It was a bit of a fit, and I almost got it too close, but I ended up using a perfboard, and some headers, putting the receiver next to the power supply, they snugged into the box just fine. The antenna is not shown here, but will be attached to the reliever and mounted in the enclosure as well. Its been tested and it all works. Future revisions the perf board will be a PCB....and the jumpers will be gone as well....

The purple board is the supply. I designed to interface with the receiver, and had Osh Park fabricate for me. They are awesome on turn around time. From design. to submitting , to boards in my hands, 9 days.....coolness. You can check them out at www.oshpark.com.

More later...Happy Coding!

Springtime Project Part 3 - GPS and the arduino Parts and more parts

So the console is coming along nicely. Lots of sanding, and checking to make sure the part I had to build up manually still make for a good fit in the car.While I have been doing that each night after work, I got to the point that I needed to paint, but I have decided to hold off on that, until I get everything in from all the parts houses.

SO, I thought it best I sit down and write some code. Im in a bit of a hurry, so I figured I would see whats out there that people have done, and perhaps get some ideas from then as to which way to go.

First off I got the GPS receiver and antenna in from New York. I came to me in 3 days, a new record for the Postal Service, who still frustrate me on a daily basis ( Im still waiting on parts that should have been here days ago). Its straightforward....The receiver receives the GPS data and output the NEMA data on a serial port...easy. You have to watch though the receiver runs on 3.3V....NOT 5V!

I found the libraries on the internet. The TinyGPS+++ written by Mikal Hart had everything I needed and some good examples to build from.

Using software serial I was able to get NEMA data into the arduino and out put the data to the serial port from the arduino. So within little time, I already had the foundation to get this going. Serial ports are cool in that you can literally split off the ports, or data lines and feed multiple inputs with one output. Im my case Ill have to feed the arduino, and the radio encoder. Again its ok to feed multiple INPUTS with one OUTPUT, not the other way around. I guess I should mention that the inputs your feeding really need to be of decent impedance. Really low impedance devices, can, in some case load down the signal being transmitted over serial and the other device may not decode it correctly. I did some calculations and Ill be ok feeding the arduino and the encoder!.

Next I wanted to add a TFT screen so I could see and make sure the GPS was locked on and outputting data. I also added some cool things for fun, but more on that later. I chose the 3.5 inch TFT breakout from Adafruit. With the SPI interface, though its not lightening fast, I was only displaying a few things on the screen so I was ok on speed.....

This is the TFT screen. I wont be using the touchscreen part right now, but in the future. I wired it up using SPI interfacing, and it worked right out of the box after soldering the header and jumper, and wiring it to the arduino.

This is the initial testing of the TFT display. I was playing around with the placement of things on the screen. The final version is about done and can upload it. I have it so that if the GPS receiver becomes unlocked, then you'll see in the upper right hand corner, the warning and of course its red. Ill have more to show what happens when its working. I'm still waiting on the 3.3V power supply parts from California!!! I hate the postal service!......Note...you cant run this TFT screen on 5V and hook up the GPS receiver to the 3.3V supply of the arduino and expect to run both, there isnt enough current to run the arduino and have it supply the TFT screen and the GPS.....so I wait.

Ill have more on the sketch that run all of this, in the next part...

Happy Coding!