GPS/BaroTemp/Roll/Pitch

[Barclay]

I made a thing.

Dash display with GPS info, altitude, temperature, barometer, roll, pitch, as well as a variety of min/max recordings.

http://www.redgeek.net/2018/08/02/roaddash/ for details and buildout.

 

[old_man]

Nice project. I've been working on something similar but with engine monitoring for Renix era Cherokees. It is RPI based and written in LabVIEW.

 

[Barclay]

Yeah, the next rev will be RPi based, which makes it easier to do the bluetooth/wifi/anti-aliased fonts/etc thing. The only downside to it is that it becomes stateful, meaning you need to cleanly shut it down (or hook it up to a persistent power supply). The nice thing about this rev is that you can power cycle w/o issue (the roll/pitch calibration is still retained in EEPROM), and it boots almost instantly.

 

[geekyadam]

Nice work.
I feel like if you were to code an Android app, you could charge $1 and make some good money on this. I'd love to setup something similar (I love geeky Diy projects for my truck), but it would be much easier to grab an old Android phone and mount it somewhere on the dash.

Sent from my Pixel 2 using OB Talk mobile app

 

[Barclay]

I actually have an android app 90% written (ugh, java) that does all of this (as well as being able to share tracks to maps, email, etc), but there's the caveats I listed in the post:
- keeping an android phone semi-permanently mounted on your dash, with a lipo battery, is bad news for warm climates.
- no temp/barometer data unless you have data.
- every time you remove the phone and re-attach it, you have to re-calibrate the roll/pitch, since it will probably be slightly off.

-B

 

[geekyadam]

I actually have an android app 90% written (ugh, java) that does all of this (as well as being able to share tracks to maps, email, etc), but there's the caveats I listed in the post:
- keeping an android phone semi-permanently mounted on your dash, with a lipo battery, is bad news for warm climates.
- no temp/barometer data unless you have data.
- every time you remove the phone and re-attach it, you have to re-calibrate the roll/pitch, since it will probably be slightly off.

-B

Oh fair points, apologies I didn't have time to read over your whole build post, just glanced at the pics! Sounds like you're keeping all those possibilities in mind. I definitely understand your concern of the powering issues with phones and RPi. I've always been the geeky guy growing up, but have yet to take time to play with Arduino or similar boards, only spent time with RPi variations. I love the RPi and therefore have thought about a few ways to implement into my rig (some ideas admittedly just to show off my geeky side...), however I always come back to the powering issue; should it only be powered when the vehicle is on? If so I would need to take boot up/down into consideration. That's not the end of the world, but just doesn't seem very fluid and cohesive to me. I'd love to learn more about dedicated board projects that work much better IMO with intermittent power. For RPis, the easy alternative is an always-on solution, which isn't out the question, especially if you're running dual batteries or a solar setup to replenish the RPi's minimal power usage from your battery. For someone like me who doesn't have experience [yet] with dedicated boards for this type of project, I'll probably end up doing one or three always-on RPi projects and setup a screensaver and/or sleep timeout or something for the screen to turn off.

 

[geekyadam]

I just finished reading over the whole post, and I'm browsing through your code now. Man, this is A LOT of work. I haven't touched C++ in like, 15 years I think, but this all looks great (if that amateur opinion is worth anything to you haha). Awesome job on this man!

I really like how almost every value also shows the minimum/maximum value for that driving session, and clearly/easily displayed next to the current value. I was wondering if those min/max values persist when the unit is restarted? In other words, if you drive trails for 5 hours and then turn off your rig so the unit loses power, do you lose those min/max values? Furthermore, with how you have it wired up, would the unit continue collecting data while the vehicle is off? Although it looks like only data that could benefit from that would be temp. Meh.

If you're looking for feedback, here's a few other recommendations for future iterations:
- Distance traveled
- Change pitch and roll to be graphical display (i.e. roll could be a line across bottom of display with arrow pointing at current value, or maybe a graphic that literally rotates based on current value). Just to make it easier to understand the current value at-a-glance rather than putting the number value into terms of instantly helpful representation.
- To combat against heat issues, raising up to top of windshield area could help reduce that considerably. It would be cool to mount above rear-view mirror like this: https://store.blendmount.com/mobile/blendmount-kit-for-scangaugeiiscangauged-p101.aspx

 

[Barclay]

I have an always-on USB port, but for auto-shutdown on an RPi that can withstand high temps, check out: http://juice4halt.com/. It's super-capacitor based, so it can withstand high temps, and is supposed to have enough juice to auto-power off, complete with scripts. I haven't played with it yet though.

Currently, the min/max values don't persist across reboot (but given that I have an always-on port, that's not a big deal). It'd be relatively easy to add those to EEPROM storage. It just means more EEPROM write cycles (every time you hit a new max, not a big deal unless you reset the min/max frequently), and every EEPROM has a limit to the number of write cycles it will support.

Currently, it does collect data when the car is off, which is intentional. That way it keeps collecting barometric pressure over a 3h window, in order to determine the barometric trend and give a weather prediction -- and I know how cold it got overnight. :) However, the screen automatically turns off if the car is stationary, and (when I get around to the GPS logging feature) it won't log GPS when the car is stopped either. I'll also probably scale the GPS logging frequency to the speed of the car: the slower you're crawling, the less frequent the log points need to be.

Distance traveled is a good idea. The UI might start getting cluttered with buttons, so on the next rev, I may do a separate window for handling settings.

I had played around with a graphical representation, but I found it not as useful for some reason. Right now, I actually have the text change color from white to yellow to orange to read at different thresholds, and I find I clue into that pretty quickly. I could make that an option, though. Unfortunately I can't mount above my rear-view, because that's where my spod switches are. :)

Thanks for the detailed feedback!