I’m having so much fun with this! The main thing of note is that I’ve ditched echarts for custom implementations of guages, line charts, heatmaps, and 3D surfaces. This has cut about 70% of the bundle size. -rw-rw-r-- 1 dgs dgs 2889 Feb 1 08:24 favicon.cddaee99.svg -rw-rw-r-- 1 dgs dgs 27699 Feb 1 08:24 index.html -rw-rw-r-- 1 dgs dgs 409 Feb 1 08:24 manifest.webmanifest -rw-rw-r-- 1 dgs dgs 32941 Feb 1 08:24 public.
I am a sloperator. I use LLMs where I think appropriate. The trigger for this post is that I’d always been mildly irked that whilst the pages of the blog had tags, they weren’t clickable and were thus a little useless. So I fired up Gemini in the editor and gave it this instruction Each page has categories tags. I want these to be clickable in the browser that leads to a page listing all the posts with that tag And off it chuntered
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.
Introducing VETuner 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.
I thought I’d have a play with Copilot to see what it could do as I maintain this blog using VSCode as it is significantly better than both emacs & vi1. I thought a nice simple task would be to add OpenGraph tags the the head of each most. It was more painful than I thought. TL;DR It finally got it right, but it didn’t notice it wasn’t reading the output of it’s own test tools and it happily made assumptions without testing them.
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?
My plane currently weighs 235g (minus a few grammes of control surface connections), but it has a weight problem. I used FreeCAD to design and print a simple balance frame. (I should have put a nice chamfer on the joints) I then removed the battery (27g 600mAh 2S LiPo) and put some scales under the tail. They read 25g. In order to get the plane to balance, I’d need to place the battery somewhere about 300mm in front of the centre of gravity.
It’s A Plane When I was a teenager, I used to belong to the Chester Model Flying Club (which now appears to be defunct :( ) and I flew electric powered gliders of about 2M wingspan. Typically a balsa framework, with a 540 motor and a 6 cell NiCad battery. Power (& skill) were marginal, weight was high, but I had fun. I’ve always hankered getting back into it, partly becuase my route to and from work can go via the Nomansland Common where there are facilities to fly planes.
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.