Looking for a tough, small Linux computer for my rig

[Matt Hixson]

I've written some software for recording OBD-II data and GPS location from my truck. My prototype system has been Linux running on a Macbook, but I'd like to permanently install a robust Linux machine dedicated to this job. I've been looking at the MintBox Mini 2 because of its lack of fans and it has connections for just about everything I need (wifi, USB). Seems like it would hold up in temperature extremes and dusty conditions.
Anyone out there have experience with one of those boxes in a mobile application or have a better recommendation?

 

[Kirk Kinnell]

How cool is this!!! Ha! I must investigate this more.

 

[systemdelete]

Seems cool but likely overkill depending on how efficient your code is. I helped setup a rasberry Pi as an ADS-B receiver in a friend's airplane plane and it doesn't seem like a very different use case.

Yep, found a similar setup available in the market using the pi platform.(might be a simpler/cheaper base that would work)
https://www.autopi.io/hardware-dongle

 

[Matt Hixson]

Yep, found a similar setup available in the market using the pi platform.(might be a simpler/cheaper base that would work)
https://www.autopi.io/hardware-dongle

Interesting platform. I've looked at a few Raspberry Pi systems, but haven't really found anything I like for my application. In this case I don't really want a box sticking out from my OBD-II port, although I could probably relocate it using an extension cable.
The other issue is that the roof of my Hummer is one giant piece of steel. This means I pretty much need an external GPS antenna to get reliable signal in dense tree cover and steep valleys. I'm making use of my old school Garmin GPS III Plus and a serial->USB cable for pulling the GPS data in using gpsd. I found a good Python library for reading OBD-II data. I'm stuffing the GPS location and OBD-II data into a Postgres database. I'll setup some sort of sync between the mobile Postgres db and one on a more powerful server I have at home for querying and building some visualization tools. My ultimate goal is to have something almost like Strava, but for OBD-II data.

 

[Lumbjack_MC]

I use a Bluetooth OBD reader and an android tablet running an app called torque. Not exactly what you want, but close and super easy.

 

[mylilpwny]

I've written some software for recording OBD-II data and GPS location from my truck. My prototype system has been Linux running on a Macbook, but I'd like to permanently install a robust Linux machine dedicated to this job. I've been looking at the MintBox Mini 2 because of its lack of fans and it has connections for just about everything I need (wifi, USB). Seems like it would hold up in temperature extremes and dusty conditions.
Anyone out there have experience with one of those boxes in a mobile application or have a better recommendation?

I had a friend who used to use one to data log on his off-road truck. He said it worked pretty good for his purpose. 1 thing he did mention was to mount with some form of isolation. He used a rubber mount he made, said that even though he used the truck heavily off road that even in a overland style off road or even just daily on the street the vibration killed his first one. He also said that he is trying to come up with a better way since he has gone through a couple due to abuse but believed that in your application it should be ok.

 

[Matt Hixson]

I had a friend who used to use one to data log on his off-road truck. He said it worked pretty good for his purpose. 1 thing he did mention was to mount with some form of isolation. He used a rubber mount he made, said that even though he used the truck heavily off road that even in a overland style off road or even just daily on the street the vibration killed his first one. He also said that he is trying to come up with a better way since he has gone through a couple due to abuse but believed that in your application it should be ok.

Do you know if his was using a regular hard drive or an SSD? I'd love to see pictures or build threads of his system if he has it online. Thanks!

 

[brien]

I can vouch for the RPi route. I've done something similar in my rig, although I read the more detailed and comprehensive CAN bus data directly from the vehicle's electronics network. It would be very easy to apply a very similar solution for capturing just the OBD-II data

My RPi is direct wired right into the main wiring harness (i power it off of the vehicle 12v from the harness as well) and it stores away nice and neat in my glove box:
It also has a full case around it now as well, the bare RPi above was just the first initial test


I wrote a software library called CANd (candy) for Elixir that makes working with the CAN bus fairly easy. It's up on github here: https://github.com/brienw/cand

If you are interested in more of the nitty gritty details of how i did this, I gave a talk about the project at a technical conference earlier this year.

I have configuration set up so that when i pull into my carport at home, the RPi connects itself automatically to my wifi and makes itself available to the network. This makes it really easy to access and an added bonus is that i'm able to push updates to the device "over the air" whenever i'm parked at home.

A note about hardwiring: I needed to hardware to get access to the low level CAN bus packets, for OBD-II you won't need to go this deep. You can have an RPi stashed away somewhere and just connected to a BT OBD-II reader that is plugged into the port. There are also cables that will plug into the OBD-II port and then have a USB connection on the other end, in case you don't have Bluetooth capability on your RPi (or whatever other mini-pc you go with)

All of my work was around RPi, but at the end of the day, it's just another linux box, so all of the above applies to any type of computer you want plugged in.

As always, hit me up if you wanna explore this route and would like some advice/help/feedback.

 

[mylilpwny]

Do you know if his was using a regular hard drive or an SSD? I'd love to see pictures or build threads of his system if he has it online. Thanks!

He is using an SSD. In a situation like this I wouldn't use anything else. As for mounting I don't believe he has a write up anywhere but if I hear differently I will let you know. I know it is just mounted to the cage with ruber between it and mount to help isolate vibration

 

[Matt Hixson]

As always, hit me up if you wanna explore this route and would like some advice/help/feedback.

Very cool project, Brien. I'll give your project talk a view later. What made you want to dig into the CAN bus? Did the OBD-II interface not give you access to something you wanted?

 

[brien]

Very cool project, Brien. I'll give your project talk a view later. What made you want to dig into the CAN bus? Did the OBD-II interface not give you access to something you wanted?

Yeah, for me it was primarily about the much more expansive and detailed data and control that was available via the CAN bus. Direct wired into the CAN bus, I can also write my own packets back into the network as well. With this extra access I can do things like:

1) have an event driven system: I have full visibility into basically every single thing that happens in the car. AC kicks in, gas peddle is pressed 30% of the way down, window is rolling down, fuel gets to 20%, horn just honked, button 3 on the steering wheel was pressed, transmission goes into reverse, GPS coordinates are near X,Y, any ECM data, etc. The sky is the limit, as basically everything that happens in the vehicle broadcasts a status or command on this network.

2) push packets back into the system: I can overwrite parts of the dashboard displays. I can trigger things to happen - lock/unlock doors, honk horn, etc. I can also enable/disable things like ABS and such (not sure why I would ever want to, but i COULD, since i'm connected into the low level network)

3) intercept/replay messages: by detecting messages, then sending my own messages immediately following, i can effectively "intercept" events and make my own events happen instead. if button 3 on my steering wheel is supposed to show me the outside temperature of the vehicle via my dashboard display, but I want it to momentarily show me the internal temperature of my fridge first, i could do that - assuming my RPi has access to the temperature data of my fridge.

It's really a huge rabbit hole of functionality, all depends on how deep into the rabbit hole you want to fall. I'm a tinkerer and maker, and i really like just exploring the technical limitations of just about everything I own, so for me a big part of this was just to see how far i could dive into hacking the vehicle - mostly just for the heck of it.

 

[Matt Hixson]

Yeah, for me it was primarily about the much more expansive and detailed data and control that was available via the CAN bus.

Very cool. I like working with event driven systems, but for right now the request/response mode of OBD-II should be all I need. I'm going to have a configuration where I have something like the code and frequency that I want to know about it. One thing I've been interested in lately is how my turbo is functioning. This can fluctuate quite a bit depending on throttle position and engine load so I'd like to record that data every couple of seconds. Engine coolant temp is also interesting, but I probably don't need to record it any more often than once per minute.
I see that people have gotten Postgres running on the Pi 3 Model B+. In your opinion would the Raspberry Pi have any trouble running gpsd, Postgres, Python scripts, and be able to handle database writes on the order of greater than 1/second? If so, that's a very attractive option at 1/10th the cost of the MintBox.

 

[brien]

I see that people have gotten Postgres running on the Pi 3 Model B+. In your opinion would the Raspberry Pi have any trouble running gpsd, Postgres, Python scripts, and be able to handle database writes on the order of greater than 1/second? If so, that's a very attractive option at 1/10th the cost of the MintBox.

From some of the benchmarks i've seen, i suspect it would be just fine running all of that and doing inserts at greater than 1/sec. I know i've seen projects with RPi Zeros that are serving and processing real time video just fine, which is pretty darn CPU intensive. IMO, for ~$30 it's worth picking a model 3 B+ up to at least play around with. I'd be surprised if it didn't easily handle what you want it to do. To give a bit more context, in my CAN bus project, my little RPi 3 B+ is able to process hundreds if not thousands of messages per second, granted i'm not inserting all of those into a database

 

[Matt Hixson]

I know i've seen projects with RPi Zeros that are serving and processing real time video just fine, which is pretty darn CPU intensive.

hah! In that case I'm going to try a $5.00 RPi Zero and see if I even need anything more than that.

 

[Matt Hixson]

Yeah, for me it was primarily about the much more expansive and detailed data and control that was available via the CAN bus.

Hi Brien, I've finally gotten a Raspberry Pi and have started building my truckputer. I have the Pi 4 and it is plenty fast enough for everything I want to do.

I have been using a ScanGuage II to show me live data from my truck. It didn't come with the ability to read a few parameters from my truck such as Transmission Fluid Temp. I was able to add commands to my ScanGuage using these instructions:

Transmission Fluid Temperature (Degrees F):
TXD: 6C10F1221940(01)
RXF: 046205190640
RXD: 3008
MTH: 00090005FFD8
NAM: TFT

Do you know of any Linux libraries that would know how to take that information and turn it into an OBD-II request? I've been using python-OBD, but I don't see how to take the above info and stick it into a custom Command object.

Any help would be greatly appreciated.

 

[M Rose]

Wow, cool concept. How hard would it be to make a system like this to work for OBD I?

 

[Matt Hixson]

Wow, cool concept. How hard would it be to make a system like this to work for OBD I?

I'm not sure. Cars built in 1996 and newer have been required to implement OBD-II, which was just before open source started taking off. My guess is that there are probably fewer OBD-I libraries available for building something like this.

 

[M Rose]

The other problem is pre 95 there wasnt an industry standard let alone manufacturer standard, hence interchangeable cards for different year and model cars under one brand. Exampe the OTC Monitor 2000 used 4 different cards just for 1988-1994 FordFull Sized Passenger cars. This didnt include light trucks, mid sized cars like the Taurus, or small sedans like Mustang or Escort. Infact iirc mustang had its own card.

So I guess the hunt is on for a scan tool for my Bronco. 2 years a go I had a tool that would do the job, but it got sold with the rest of the shop tools.

 

[Matt Hixson]

Hi Brien, I've finally gotten a Raspberry Pi and have started building my truckputer. I have the Pi 4 and it is plenty fast enough for everything I want to do.

I have been using a ScanGuage II to show me live data from my truck. It didn't come with the ability to read a few parameters from my truck such as Transmission Fluid Temp. I was able to add commands to my ScanGuage using these instructions:

Transmission Fluid Temperature (Degrees F):
TXD: 6C10F1221940(01)
RXF: 046205190640
RXD: 3008
MTH: 00090005FFD8
NAM: TFT

Do you know of any Linux libraries that would know how to take that information and turn it into an OBD-II request? I've been using python-OBD, but I don't see how to take the above info and stick it into a custom Command object.

Any help would be greatly appreciated.

Just reviewing this thread and found that I have an answer to my own question. I found a Windows program called SG2 to OBDDash in the Windows store that knows how to read ScanGauge X-Gauge commands and shows you the formula that is used to turn the response into something useful on the ScanGauge display.

 

[egilbe]

We use these things in areas of the shop floor that can be high temps, or corrosive to monitor equipment parameters.

Fanless Industrial Intel Whiskey Lake NUC Computer

Fanless quad core Intel i5-8265U Whiskey Lake NUC computer with dual LAN in an ultra-compact form factor. With terminal block power, DIO and Wi-Fi/Bluetooth.

www.onlogic.com