Warning: This will be heavily biased towards my specific setup. If you have had issues with boosterless brakes, this might work well for you though.

My brakes finally feel ok. I just finished a drift event 2 days ago and forgot that I even had issues with my brakes until half way through the day. They do take more effort than factory but not much. I feel like the firmness of the pedal is what spec E30 guys want in their cars.

The solution to my issue is still not completely clear. There was a spec E30 forum post I read where a driver hooked up pressure sensors to his brakes and depending on different inputs, the rear brakes would either work or not. He tracked it down to the rear proportioning valve. I debating on just deleting it but instead I replaced it with a factory unit for 12x the cost. At the same time, I swapped to a different (but used) factory cylinder, and deleted the ABS unit. The brake fluid from the old setup was pretty dark so I opted to replace the front brake lines as they were the most worn.

With all of those changes, my brakes felt great. In retrospect, I don’t think I know exactly what did it. My last master cylinder could have been internally fried from the heat from the headers. As a precaution, my new(er) master has a heat shield that attaches to the master cylinder mount. It should be attached to the engine but space doesn’t allow for it. Regardless, I could still grab the master after pulling off track from a run.

The other options are either the ABS delete or the rear proportioning valve. I kind of doubt the ABS unit because I couldn’t find it failing for anyone else. The online spec E30 forum post makes me think it was the rear proportioning valve more than anything.

I highly doubt swapping out the lines and bleeding the brakes did anything but you never know. In the end, this manual braking setup with the moved pivot point will work with the factory master. I went down the rabbit hole instead of simply investigating the rest of a system I didn’t know.

It seems like every time I make a post on this project, I do completely different things than I set out to do in the post. I wound up cleaning up some code (but not much). I realized that the gauge animation code ate up a significant amount of time between PID polls so I managed to get a 4 PID from 600ms down to about 150. After that, I did some GUI improvements. The Subaru ECU still proves to be temperamental but things consistently work.

Originally, I wanted the log parser in a web application format but I don’t have time to learn everything I want to. So I started up a windows application. The application is still very fragile but it does load up logs and let you see data points as well as mix and match logged elements. It gives things like time stamps as well as parsing the GPS information.

I copied over the KML google earth code that I wrote and then wound up rewriting almost completely. I managed to get it to take in the GPS data but colorize the line based on any other logged data. The image below shows the line plot with speed information overlayed. Red is where the vehicle was stopped and green was my top speed for that log.

From here, I’d really like to output this data to something that can be imported by a video editor and overlayed on some in car footage. I also might go back to trying to get external input logging reliably. Or I might clean up code some more. I’m not entirely sure.

A lot has happened in 2 weeks. I found out that the I2C bus is easily susceptible to noise like in an automotive environment so the UART connection made a bit more sense. Even though it can only take in 1 input, I’m only going to connect 1 arduino. Which works out great because now I don’t have to split out the I2C connector.

Here’s what the current setup looks like. You push the button, the arduino uno reads it, sends it to the arduino mega, and the mega displays it on screen. With that, I’ve officially reached the end of the “proof of concept” stage. Now I know and have setup every major milestone in the system. The rest is code and finalizing IO.

Before that, I worked a bit on the gui. I went for that old NES look. The touch screen now displays 3 different setting screens. So far they don’t do much of anything, but you can swap between them. I’ve also been toying with some DTC reading/scanning/clearing code but that’s really far on the list of priorities.

The down side I realized is that the more PIDs you poll from the OBD2 port, the slower everything goes. Just reading the RPMs was a 60ms lead time. Reading in the final list of what I want (rpm/iat/clt/throttle %) bumps that time up to 600ms (over half a second). This is likely due to the kwp2000 “fast” protocol not being able to give me the data fast enough. But I think the LS2 uses the CAN protocol so this might be a non issue. I should test on the E30 soon.

From here, there’s still too much to list that needs to be done. For instance, I’d like to be able to read in a config file from the SD card. The main goal is to start cleaning things up. My code is pretty disjointed and messy. I’d mainly like to polish the GUI. Maybe look more into reading PIDs faster.

For my own archive, here’s the current list of external IO for the uno to eventually log:
Accelerometer for the uno (another MEMS to keep things consistent?)
Clutch switch
Brake switch
Ebrake switch
Steering wheel input? (I have no idea how I would do this)

OK I lied. The urge to work on the expansion of inputs won over and I’ve done a bunch of research into that. The I2C connector the OBD2 plug uses is an expandable bus while the UART plug is only able to take in a single input. As a result, I made the decision to use another arduino (uno) on the I2C bus using the existing plug on the LCD TFT screen. This gives me another set of digital and analog inputs that can be farther away from the main unit (without tons of wires all over). This will also make a great way to mount a second accelerometer to calculate slip angles later.

Anyway, some sexy mods I did was to figure out how to make a basic dial gauge. I’m going to use it for RPMs since the tachometer doesn’t work on the LS E30. It’s also very noteworthy that the lag time between the car’s tach in the IG video and the arduino is minimal. This beats out most bluetooth solutions I’ve used in the past. This makes me very happy.
https://www.instagram.com/p/BOnSAN_jQDT/

I’m still ordering parts here and there for the new arduino setup. But in the man time, I should be able to start to build out the UI. I’d like to get it broken into a few different useful screens. One will likely be checking and clearing DTCs and one will likely be just a main gauge readout. I figure I’ll have a third for reading out tons of other stuff but I haven’t fully filled out that thought process yet.

I finally managed to get the OBD2 protocol working. It was mildly embarrassing but at least it works now. The screen shot below looks like a jumbled mess but that’s ok. To help figure out sizes and place things appropriately on screen, I’ve added a grid background. At this point, every major component outside of the external input, has reached “proof of concept” stage. Now it’s time to start polishing.

I think my next step is to clean up the UI and get it to display things I want. I’ll do an attempt at the G meter animation but it’s not the most important thing right now. If it does get done, it’ll be to test the refresh rate and speed of the animation.

Otherwise, I’d really like to get a sexy background up so it doesn’t look like the mess that it currently is.

Well at least I’ve made some form of progress. I originally wanted to make the log files queue all data then export gut the gps polling and other parts of the system don’t update in unison so it was simpler to leave the logs the way they came from Freematics.

I did whip up this quick windows application to parse the log files into separate bits. Ideally, I want to create a web application that will do all of this regardless of your operating system. For now, I just needed something to take the log files spat out and turn them into the KML format to load into google maps/earth.

The KML file format is a bit foreign to me but I did manage to get it to load. Eventually, I’d like to make the line color change according to accel/decel so you can more accurately view your data.

The data is even good enough to see what lane I’m in. Which is good considering the GPS unit I have is the cheap/slow/inaccurate model. I think the altitude is also a bit off or google maps doesn’t have their altitude right on the map.

On top of this, I have managed to get buttons to work on the touch screen. I’m not entirely sure what I’m going to use them for, but I have them. In the mean time, I’ve become obsessed with figuring out why the unit won’t connect to my daily driver 2–7 Subaru. It’s technically some form of CAN bus. But regardless, the unit should connect. Older Subarus are “ISO 9141-2” and mine falls into a weird split where google isn’t helpful. Either the car is “KWP2000 FAST” or “CAN 11bit 500K”. None of these settings seem to work.

Without it, I can’t test full data logging without driving around the race car. Winter is not the best time to drive it around.

I’m not entirely sure what my next steps are. I might bang my head against this OBD Protocol issue until I figure it out. If I do, I’ll either work on the UI of the device itself or start working on parsing data logs to find useful information. I did have this idea for a G force readout animation. The arduino might not be able to render that much though.

It’s only been a year and two months since my last update. I did get a lot of interest in this project so I figure I’d update.

Before I put this away last time, I managed to get all major features working except accepting external IO. There still is some left over pins and ports so creating an analog to digital conversion that links into the arduino’s bus shouldn’t be too hard. But I do expect it to be the most involved part of this.

I forget what the special secret was from the last post so here’s the outline of what I want to get done:

1. Log all data to external SD card
2. Load background image from SD card for “theming”
3. Display useful data on screen
4. Math for drift data/scoring
5. Accept external I/O sensors like steering angle
6. External software/website for parsing log files
7. Touch screen has toggle buttons for various cool things

Interestingly, most of the concepts have already been proven. I wound up hacking up a lot of the canned touch screen and SD card code but I got the background images to load using this UTFT RGB565 converter. The “raw” file format used by the UTFT lcd screen is proprietary so this converter is a necessary evil. It’s a bit of an annoying step but it works.

The green text on the middle left of the image is the current coordinates of the press. It isn’t a button per se but it will allow me to accept touch input then do something as a result.

Finally, here is an excel print out of 3 minutes of log time for the accelerometer chip. It’s integrated into the OBD2 port under the dash so that could prove problematic. For some reason, there seems to be some offsets. Z axis appears to be forward/backward movement and Y axis seems to be side to side movement.

Unfortunately, my daily driver subaru won’t connect to the I2C OBD2 adapter and read PIDs but it will do everything else. So in the mean time, I hope to get the logging format hammered out and some more polish work on the code as a whole.

For my next update, I’ll likely focus on the GPS unit and see how I can export that to google maps.