Small progress on the car. The cracks are all welded up, gussetted and painted. The bonnet frame and the radiator is in.
I started work on rewiring the fan, the start of the recent shenanigans and I came to remember how much I dislike un-insulated crimp connectors. I’m struggling to get a reliable crimp on the large diameter wire I’m using. I suspect I may have to resort to soldering.
(long post ahead)
For a while now, my car gets grumpy when it gets hot. In stationary traffic it gets hot, the fan kicks in and it becomes a bit of a struggle to keep it running at idle as the engine goes lean. I assumed it was to do with the engine ingesting hot air coming out of the radiator as under bonnet temperatures get quite high when the fan is running1
I’ve found a new gadget that I’m genuinely excited about. The Pill from Shelly is a tiny little USB powered thing that you can plug sensors into and advertise the values over BLE
I have a Stupid Car
and I’ve always had trouble with temperatures under the bonnet.
Over the years I’ve tried to interface to DS18B20 sensors in various ways. It started with Raspberry Pi(s) which required a lot of effort not to kill with car voltages and shutdown.
VETuner now has a proper home at vetuner.co.uk .
If you’ve been following along while I poked at parsers, dashboards, serial comms and all the other fun bits, this is the bit where it turns from “odd side project” into “real thing with an actual domain”. It may even result in “actual users” and “actual users who give me money”!
This was driven by me getting fed up with Android development for MSDroid. MSDroid is great, it’s just Google changing the requirements underneath it, taking phones from general purpose computing devices into ad impression generators. Ironically, it’s Google that makes the only browser with the Serial/USB APIs I need to talk to the ECUs, so I’m not completely done with them.
What you see there is the first time I have successfully connected a web browser running on Android to a Speeduino ECU via a direct USB connection.
The read rate is poor as it was a very old Motorola that is normally my Squeezebox controller , but it was to hand and had a USB-C socket on it. I have got over 60Hz on a desktop browser.
My Stupid Car has just got a new limited slip diff, but this isn’t about that.
One of the benefits with developing VETuner, is that I can fix all the things that irritate me in TunerStudio . Top of the list is the difference dialog. If you load a new tune file that doesn’t agree with what the ECU has then you are presented with a multi-page dialog that looks something like this
I want to connect the code running in the browser, to the ECU. The browser code sends requests that the ECU processes in a synchronous manner and sends back the data.
sequenceDiagram
participant Browser
participant ECU
Browser->>+ECU: Request
ECU->>-Browser: Response
If I use Chrome on a desktop, I can use the WebSerial API and do effectively that. Running at 115200 baud I can get about a 60Hz rate poll rate, which is pretty decent.
Ever since I put a Megasquirt MS1 into the Stupid Car, back in 2009, I’ve been fiddling with software to work with it and similar ECUs. It started with MSLogger, and Android app that only logged and didn’t provide any capability to adjust the ECU. Then I joined the effort working on MSDroid which was much more capable.
Fast forward many years and MSDroid is effectively dead. I still fiddle with the code, but I can’t publish any updates to Google Play as it is tied into an obsolete payments library and that side of it belongs to the project owner.
The Stupid Car failed it’s MOT on knackered bushes in the shocks and the Panhard rod. I knew this day was coming as they looked pretty ropy last year when I took this photo
This is not something I’d ever done before, so new stuff to learn and maybe an excuse for new tools! First port of call was the Spax website to see if they had suitable bushes. TL;DR was “We don’t support old shocks, want to buy some new ones?” That would be the Answer Of Last Resort. So off I went and did a lot of searching.
After my last post I drank some more wine, read the comments it generated and got down to some jolly good proper thinking. I realised that I was distracting myself with standard deviation and such like, and a more empirical approach may work.
The rough pseudo code is
for each log entry that isn't filtered out by temp/RPM etc
Find the AFR in the future by doing a bilinear interpolation on a delay table
Find the actual VE by doing a bilinear interpolation on this record
Find the target AFR by doing a bilinear interpolation on this record
Work out how far out of whack the actual AFR is
For each of the 4 cells involved in the current reading, add a weighted adjustment record depending on where the bilinear interpolation lands
for each cell that has more adjustment records than the minimum number of hits required
Calculate a weighted average adjustment to apply to the cell
create a new VE table by applying the adjustments to the base table
And it seems to work. Circa a couple of hundred lines of the finest Javascript to run in your browser.