So the new Center Console project version 2 is going nicely. As usual Im under a bit of a time constraint, because Id like to have this project done and installed before the Labor Day weekend, when I plan to leave town for a few days!

Im getting the pictures arranged but Id like to start with the firmware. Its taken a bit to develop mostly because I never succumb to the old addage that " good is fine, better is worse". I started out simple wanting to chenge out the old LCD screens for new TFT LCD touchscreens. I wanted to reduce the switches on the console, and what better way to incorporate that than using touchscreens. They are a little tricky in that you need to make them trigger when you touch them, but how you touch them makes a big difference. For instance if you have big fingertips, sorta like I do, making the buttons on the screen really close together to maximize the space, wont work. You will end up with two buttons pressed instead of one, not good. But, if you narrow up the trigger area too much, you end up needing to use a toothpick to make stuff happen...its all about compromise.

The first arduino sketch Ill start with is the one for the GPS screen. In the old console I just had a LCD screen reading out lat, longitude, altitude and the satellites in view. In the new screen, I do all of that PLUS I added speed, direction, and a graphical representation of altitude including color coding the graph based on altitude...........

So the sketch..........

The first part of the sketch is like all the others. This GPS sketch is an adaptation of the GPS example written by the fine folks at Sparkfun for their GPS module. I had tried others but this one was the easiest and was easily adapted to what I wanted to do.

You will see all the libraries you need. Likewise I used the Adafruit fontconverter program using my Linux box and uploaded several new fonts. I like these fonts because they are easily read even at a 7,8 or 9pt font size.

You will also see I like to mess with colors. Most of these arent used but I usually import all the RGR565 colors I have used in the past to see how things look

  This next section is nothing more than setting up the TFT screen, clearing the screen when starting or rebooting, and then a little splash screen just for fun

           This next section does nothing more than set up the individual windows in which the real time(ish) data will be displayed. I say real time(ish) because when displaying stuff on a TFT screen you must destroy the previous data displayed and rewrite the new data. With everything Im displaying, this all takes about a second using the Arduino Mega....so all updates are roughly every second. There is alos a built in delay in the sketch to allow new NEMA sentences to be fully read and displayed

Finally the rest of the setup showing where I set the MPH units for the speed window, the Altitude graph box area and two counters, which Ill explain later.

The simple void loop. It calls the main GPS data printing loop and also adds the 1sec delay to ingest all the NEMA data

This is where the fun begins. The GPSInfo loop. At the begining of the loop you will see that counter that I initially set to 0 in the setup up. This counter will increment by 1 with each pass of the loop. The rest of this section is showing the typical

set up for displaying the data. You remember in the SETUP we created the data display window. We ingest the data, then before displaying it, we destroy the old data with the tft.fillRect( ) statement. This paints a black square over the old data the same size as the box we set up in the setup. This way we retain the original set params and clear the window. The rest of the commands are setting the font, font color, location and finally printing the new data. This is done exactly the same for all the windows.

Altitude graphing:

This is the Altitude graphing section. I actually have two altitude sections. One is a simple window that dispays the current altitude. This section take it a step further and shows a histrogram of the altitude over about a 35 min period in which we have traveled.

The altCOUNTER is the counter we increment by 1 with each pass. Therefore with the counter reaches 16 ( it starts out at 1, with the first pass) this sets us up for making a altitude graph entry ever 15 secs.

Then I do a little math. All of the variables are floats. I know it takes a little  arduino horsepower to do floats, and yes I could have declared them earlier, but I did this over a couple of days, and in sections so it

ended up like this. All you programming gurus out there please dont slam me with a bunch of comments, I acknowledge its not pretty, but functional. yyfeet is the actual reading from the GPS in feet like 456.78ft of altitude. next to reduce this so I can fit it on the screen of the TFT, I divide this by 100. The reason for this is my graph will show a traversed path from 0 to 10000ft of elevation. I would suspect I probably wont drive to Pikes Peak, or anywhere above 10000ft, if I do the graph will just brickwall at this elevation. So now we have a altitude of 456.78ft, reduced to 4.4567.

The window to display the graph is a window thats 100pixels tall ( 10000ft) and 400 pixels wide. Originally I had the graph display a 10 minute traveled path, the final result is much longer. if you take the 400pixels and divide it by the 15 sec measurements, you get a little over 9 mins which was my original thoughy.

The coordinates of the window are 30,319. just a little left and nearly at the bottom of the tft screen which is 320pixels in height The ycord = 319-yy is to make the y coordinate land at the bottom

The xcord, is the x coordinate. Since we want to display the altitude over a time frame, its necessary to plot the x coordinate, and one the next measurement move this to the right by some fixed distance and plot the new data. This way you end up with a series of rectangles, drawn based on the altitude (yy). Since we are using the tft drawRect( ) command, you need an x coordinate, a y coordinate, a height, a width, and a color) so then we just substitute in all our variables and we tell the arduino to draw a rectangle based on the altitude.... or.....

   tft.fillRect( xcord,ycord,2.5,yy,BLACK)   this tells the arduino to draw a rectangle at the current (x,y) coordiantes, with a width of 2.5pixels, at a height of (yy) which is our calculated height in the color BLACK.

Now in order to get the arduino to draw the new altitude rectangle to the right of the last one so we have a history being drawn on the screen..... we have to add in another counter. This counter (xcordCOUNTER) counts the rectangles drawn and when it gets to 144, then it will wipe the graph clean and start over with a new one. xcordCOUNTER reaching 144 is enough to show a traveled history of 36 mins ( 144counts * 15secs = 2160 / 60 = 36mins) You can change this to whatever you want.

All if the "if" statements preceding are to change the color of the graph based on the altitude. From 0-5280ft the graph is black, from 5280ft to 6000 ft its CYAN, and so on......


Direction Traveling:

The only other thing I did was change the way that the arduino take NEMA data and displays your direction traveled. Originally I just printed out the heading in degrees, but of course I had to change it. I like the result...it adds several lines of code but it works. Basically I take the GPS Course data, and tell the arduino to look at it and based on the IF statements display whether we are going North, South, Ease or West. I then decided if I did that might as well add in the NE, NW, SE and SW directions too. The arduino looks at the course reading, and picks the direction corresponding to that heading. I simply broke the entire 360 compass into 45 degree sections.








Finally here is what the screen looks like. The graph at the bottom unfortunately is nearly flat because its sitting in my room....but it works

In the meantime.........happy coding!

Center Console Version 2!

So its been a while since I posted, but that doesnt mean that I havent been working on things. Since the last I posted, I have added a APRS digipeater, and Igateway, to funnel APRS from the RF world to the Internet. I have also built an additional echolink /allstar node for the local radio club which Ill outline in another post. Also I have put up more antennas, and changed my workspace some. All of this was prep work for my new center console project for the car.

As you may have read I did an earlier version of this back in 2014, which turned out nice. It worked great but to one flaw. It was small, and it wasnt as sturdy as I thought. My kids, getting in and out of the car, accidentally kicked the old console and eventually it developed cracks, and started to show signs of falling apart. I wasnt that mad, because I have always decided I would build a new and improved version of this concept. I proud to announce, that all the firmware is written, the testing is done, and I am ready to put the pieces in place. In the next few days or so. Ill document the construction, wiring and results of several weeks of planning, and designing the new console.

Stay tuned............
In the meantime as always...........happy coding!

Prototype online, new discoveries

So the finishing touches and the tweaks begin on the Naked Node. I went ahead this weekend and finished up the last little construction and configured the BeagleBone computer, as well as the echolink configuration as well.

The node works, proving that that circuits work. I was able to drive more than 3 miles away and get into the node from the car. I have discovered though that there is still an RF problem. When the radio keys, after receiving a signal, and then you try and talk into the node from a handheld, it seems that the micro-controller has a bit of a lag recovering from one mode to the other. Not sure if this is because of the code, RF getting into it, or a design problem. Sometime I have to key the radio a couple of time before the node responds. I noticed that the heartbeat LED on the micro-controller, stops for a second or two and then restarts back blinking. This is telling me the firmware is stopped running and then restarts. Im looking into both the code, and perhaps toning down the radios power output even more.

In the video, two fellow hams are talking. You'll notice that I slapped on the 20x4 LCD. I did this so I could go ahead and run some tests, before adding the touchscreen. Its all part of the design process, working out what bugs you might not have anticipated. The tow hams are located in Arizona, and Long Beach, CA. I didn't catch the calls.

So work continues, as I finish up this node, and make preps for a improved node in the future, as well as lessons learned for the continued repeater build coming later this summer.

In the meantime.........

Happy Coding ( and building)

Final touches on the Display

So works continues on the Naked Node Project. I have been concentrating on the display. I wanted to add some additional features, and have a couple more to add, but Im enjoying the challenge.

I added two additional buttons at the bottom of the screen to turn the radio and the computer off and on via the touchscreen. I have to admit calibrating the touchscreen is a bit of a chore, especially since this screen isnt the greatest in the world. I ended up chopping up the parts of the sketch for the screen into multiple voids, so that the main loop would run faster. The original way I had it caused you to push the buttons multiple times before the request registered on the MCU. Chopping up everything made this a lot faster. There are a few occasions that I have to push the button twice, but that ok for this project.

As promised I will show the S- Meter animation. Its not the greatest video but you get the idea

S Meter Animation

I also as mentioned added two additional buttons. Each button is now capable of turn the radio or the computer off and on using a single key. When the equipment is ON, the button changes to a filled color, when its off, then its just a void button. I had a lot of fun getting one button to do both desired functions, but it works.

   

                            When the equipment is off, this is how the voided out button looks

Buttons have turned on the equipment

Though the photos dont really do justice, the radio button is actually green, and the computer button is a light shade of purple. The lighting messes with the hue of the photo.

This is about it for this update. Work continues on the project. Ill post the code once its all cleaned up for those that might wanna see whats going on.

In the meantime..........

Happy Coding!

Little Suprise....the Cherry on top

So work on the node continues. I decided to kinda take the node to the next level. I realize that its a bit over the top but I like my projects that way.

I finished level 3, the radio level, and decided to add a 4th level. Most will say that its unnecessary, but in reality I wanted to do this because its the precursor to the front panel of the repeater. So what is it?  Well I added a display. The first version was an I2C 20x4 LCD. I had one laying around so I decided to use it. Being that its I2C it was easy to interface, and a snap to write the code.......

Then of course I changed my mind. In reality I changed it for a good reason. I had an older 3.2 inch TFT screen available. I decided that I would try that. It wasnt bad to interface, and though a little more difficult to program I think the result looks clean and nice. Im not a huge fan of a lot of clutter, so I kind of modeled after the ICOM IC-5100 their first generation D-Star radio. I finally added a splash of color as you will see and I animated the S Meter as well. Here are the shots, one with the radio in transmit and the other receiving a signal

My inspiration was the IC-5100 by Icom.

Im a big fan of graphics. I just think the IC-5100 display is clean, easy to read, easy on the eyes and really looks professional. It was what I used to model my display after.....Thanks ICOM!

I havent added everything I want to the screen. It is a touchscreen and Im working on the bottom row of buttons, which will eventually power the system off and on, and maybe kill the radio while leaving the computer attached to the network. I liked the font I found which gives the screen a clean look and not just ordinary. A font conversion utility from an engineer at Adafruit turned me on to converting and uploading my own custom fonts, which I have to say once you learn how, it makes ordinary TFT screens really stand out.

When I am fully finished Ill add a video of the screen in animation so you can see the S Meter in action. Once Im done editing as well Ill post the code for the screen.

In the meantime, work continues on the Naked Node. My hope is to have the Node finished in the next few days, depending on available free time..........

In the meantime

Happy Coding!

Naked Node work continues with Part 3

With the Control layer done and wired up, its time to start on the next layer. This next later is one of the easier ones, the computer layer.

The Computer layer is pretty basic. Its consists of a BeagleBoneBlack credit card computer running a version of Allstar link, the image written by WA3DSP. You can also see the soundcard FOB that will be modified and fed to the control layer.

The SMAKN module is  the battery eliminator for the node radio. Commercial bought, this module takes 12VDC and converts it to the 3.7VDC needed by the radio. Its just simpler to buy this commerical converter than it is to make one, wait on the boards, and populate them. Its cost a whopping 5 bucks off amazon.com.

The only other thing to show here is the underside of this layer

The underside I have added to save space, a relay module. Again this was also bought commercial for another project that I decided not to do, so I used it here. The MCU will connect to this module and command it to do what I want. Its just easier to used this than try and make one myself. In this case both the battery eliminator and the relay module saved alot of time. We can see I started wiring up the battery eliminator to the relay. One will turn on and off the radio, the other relay will turn on and off both layers 1 and 2. This way I can kill the radio, yet say connected to the Allstar network if I wish, and then turn on the radio when I want the link active.

Thats really it for Layer 2. Nothing really complicated here. In the next post we will move on to the radio layer, layer 3, and the final layer which is a surprise for now

In the meantime as always

Happy Coding!

Naked Node Part 2

So the work on the Naked Node continues. Seems I have found myself with some build time, so I decided to take full advantage. The Node is built in layers, each layer, for me, is a different function. Some may look at it and say this can be built a lot less complicated, and a lot smaller, but for me thats not the point. My point in all of this is to make a fully function node, broken into modules, that if something were to go wrong, troubleshooting can be simplified down to a module, and the module or even a layer, could be switched out, and Im back in business. Likewise, if I want to play and add features, I can use the basic building blocks to do so, even reconstructing a layer on the bench, adding what I want and then swapping in the new layer for the old....

So the bottom layer is the brains. As I discussed before, the larger board is actually on old repeater control board, all be it a flawed design, I could re-purpose it for this project by modifying the board. In your design, and when I get around to it, I have already designed a replacement for this board thats a lot smaller, and does the job. In my case, with the bad boards I had, I could go ahead and start on this and visit it later to replace the re-purposed board. You could even design something to do the same job. The cool thing with this is you can be the designer. The basic building blocks of this are simple to use, easily available, and not hard to modify, so have at it.......

Ill point out too that each layers base is built on 3/8 thick plexi-glass. I both love this medium and hate it. I love it in that its readily available, and with just a Dremel tool, I can cut and shape it, with not too much mess. The finished product looks clean, and cool. Its light weight as well. The cons are of course you cant solder to it, grounding things takes a little thought process since you cant use the layer as a ground, and drilling.........oh the drilling. I have broken several nearly completed layers using a brand new drill bit and a variable speed drill. I finally found out if you put painters tape on the area to be drilled, especially if its close to the edge, mark the holes and carefully at slow speed drill until your are almost through, reverse the drill and carefully push the bit the rest of the way through, actually melting the remaining material out of the way, you end up with perfect holes. I broke 5 of these layers before I found the combination that worked....I think perhaps in later designs I might switch to aluminium stock....this is a prototype after all

The bottom layer consists of the modified controller board, a MCU, a repeater module, a buffer board and a FOB interface board, all of which were originally designed for the repeater. Since I had extras, I just populated the boards, and left off what I didnt need.

Figure 1

Figure 2

The boards are visible here. You can see that the controller board is huge, in my case 4inchs x 4inches. This is total over kill, but remember, these are useless for the repeater, so why not use them here. You can see as well that there is a lot of unused ports. The port next to the Arduino ProMini328 interface board, is what would normally be the MCU display board running a touchscreen on the controller unit in the repeater. Likewise, there are two smaller header ports, one for a Control radio link transceiver, and one for a remote base. Of course both arent used here.

The MCU interface board is nothing more than allowing me to take a smaller Arduino ProMini, and turn it vertically making use of the vertical space instead of having to make a bigger board. Its also removable, and able to be programmed in place with a laptop if I want to upgrade the firmware. I have also broken out the SDA and SCL pins so that in the repeater, a I2C LCD screen could be attached for troubleshooting problems. Ill explain more of that when I write up the repeater build, for now its just there. The arduino works just like any other arduino, I just mounted it vertically is all so I can squeeze 2 of these MCUs on one smaller 4x4inch board.......saves on PCB costs.

The USBFOB board is located in the lower right hand corner of Figure 2. You can see the baby blue BAT43 diodes that stand out.

The USBFOB board is a simple design. Many that have ALLStarLink repeaters, nodes and other equipment have used the StarTech USB sound card to interface a computer with the Allstar network. These works great allowing for radio carrier detection, PTT, and audio interfacing. I designed a little board to allow nearly all of my connections to the USB soundcard, to be made external so that I could minimize the amount of soldering to the CM108 chip in the FOB. I can do SMD soldering, but this way I  simply remove a LED, and make just 2 solder connections to the CM108 chip and Im done. I dont have to solder transistors, diodes and all that in the FOB. Conversion of the USB Sound card can be found on the web, Ill cover my mods later, for now here is the schematic of the board I made, and this is plugged directly into the repeater control board....or better in this case my node controller card. Note to I add notes to my schematics, its just for me, that way if I have to fix something, I dont have the ask myself...ummm " why is that transistor there again"..........just saves time.

Finally beside the radio module ( which I have covered in a previous blog) this is the buffer board. Now this board isnt totally necessary. I like to use a buffer when I am sending signals from one unit to the MCU. This cant be done several ways, some use ICs, some use pullups and pull downs, I like to channelize things. Its a little more work, but it gives me a clean 4.3V HIGH signal and a clean LOW signal to take in from a module, and send it to a MCU. I also like to plcae a diode on the output path. You can see several of these in Figure 1. This provides isolation as well between the buffer and the MCU. I like to keep the MCUs isolated, and with transistor output, everything is clean and loading between stages kept to nearly zero. Its an old habit from decades past. I relaize you can put IC buffers in there like a 74HC07, or similiar, but when you have 300 2N3904s and 3906s hanging around, you tend to use them when you can....The buffer board is noninverting, two stage board, what goes in is what comes you at a pure 5Vdc, the .7Vdc drop is the isolation diodes I mentioned earlier.

The last thing to mention is I did go with a commercial LDO voltage regulator, seen on the left in Figure 2), they are fully adjustable from 1.5 to 37Vdc. I love the LM2596 chip! Its also handy to have the 7 segment readouts, no meter needed. You simply feed these with 12Vdc, adjust down to 5V, done!

I havent covered programming ht MCU, Ill write more in a later blog about the firmeware. For now this covers the bottom layer! More later

Happy Coding!