It’s been a long time since I last spent any time on this project – too many projects, too little time as ever !

Recently my trusty MS1-Extra that has been running my LS1 powered Land Rover since 2007 has needed a bit of attention as I simplified the vehicle’s wiring somewhat.

It’s given me an incentive to look at a few ideas that I’ve had for an upgrade. I have an MS2-Extra ECU that was configured for the LS1 but never ran properly due to, what turned out to be, a firmware issue which meant the lambda reading was incorrect.

I’ve also been more and more interested in Speeduino as I use Arduino for so many of my other projects these days and wouldn’t mind trying that out on the LS1.

With the last version of MobiSquirt I knew I’d painted myself into a corner by hard coding a lot of the ini file contents. It worked great for firmware versions I needed to use but I struggled to support other versions.

Mobile development has changed massively in that time and, for my day job, I still write native apps but I also write complex apps in React-Native and, for a long time now I’ve been thinking that that would be a much better and easier language to dynamically interpret .ini files.

So, MobiSquirt v2.0 is currently in development and the intention is that it will be released as an open source project. It will also be released on both iOS and Android platforms. So far, progress has been good and I have a working version of the app that runs against the old demo data that the original app used.

The repo is on my GitHub account and, prior to going fully open source I’m open to offers from contributors. The project is a react-native expo project written in Typescript.

I’ve continued to make slow but steady progress on the parsing of the assortment of .ini files. Most of this work has been on restructuring the resulting database entries to speed access.

I’ve also successfully parsed the Speeduino .ini file which, for some reason, uses a number of different line formats. This means that, once the app fully supports the parsed data structures, it can also be used for Speeduino as well as MegaSquirt/MicroSquirt versions.

I’m currently completing the communications classes in the app which take the parsed database files and use them to determine the type of ECU that is connected and reads in all the static data from the ECU. Once this step is complete I will be looking for people to test this functionality against their ECUs to confirm success (or not) for each firmware version.

In case it’s of any interest, the parsed ini files are being stored in a MongoDB database for the app to use and I will be looking to mirror the data to Atlas. This means that the app will sync against that master database and will also mean that the same data can be made available to other app/web developers.

A bit of a milestone was reached today, the parsing code, for the first time, managed to successfully parse every available .ini file. Parsing versions from the original B&G MS1 to the latest MS3 Pro. In total there are nearly 50 different versions of the firmware out there and each of them has introduced it’s own challenges in producing a universal parser !

This is a major step forward as the app now has available to it all the data and information required to communicate and create logs from any MS main stream release.

The next task is to build the communication structures and code that can use that data to identify and load the correct configuration. Once that is complete I will then be able to build the interpretation methods for the incoming data for both logging and display.

Following on from the v1.2 release, which addressed some of the data storage architecture in the app, I’ve been taking some time to review other aspects of the app.

The storage architecture is working really well, giving much improved performance as well as giving some enhanced ways of using and displaying the data within the app in the future.

Where the app is still struggling is when it comes to addressing the many and varied firmware and hardware versions. The original app was first written at a time when MS2 was cutting edge and MS2-extra was still in beta. As a result it seemed pretty straight forward to do away with the need for the app to ask the user which firmware was being used, possibly supplying a .ini file to use.

These days, however, the number of firmware and hardware versions is staggering and it seems that it is increasingly difficult to reliably decode the data from the different revisions even within the same firmware version.

So, my current focus is on producing a “universal” parsing engine within the app. Where currently the app has a number of hard coded parsers, one for each firmware version, this new one will effectively use the .ini file for it’s decisions allowing new firmware versions and revisions to more easily be supported. To avoid having the app processing the .ini file itself these will be pre-processed and the relevant data shipped with the app although these pre-processed files will also be updated from a web service, allowing new firmware versions to be supported without an app update.

The effect on performance in the app is yet to be gauged but should performance be reduced due to the “universal” parser I may end up retaining the hard coded parsers and only using the universal one for firmwares not supported in hard coding.