Speeduino Parsing and progress

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.

Parsing Complete ?

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.

Parsing ini files

Typical section of an MS .ini file
Typical section of an MS .ini file

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. 

V1.2 Live on the app store

I’m pleased to say that the app has passed the review process and is now available on the App Store again.

I’m now working on the next version which will include a revamp of a number of views for iPad users as the current iPad implementation isn’t ideal. It will also include support for MS2. I’m also looking at a possible issue with the latest version of MS2/Extra, depending on the severity of the issue and how big a job it is to fix it, I may ship an interim fix version.

Feedback from users will help drive this project forward, if the app works for you and your firmware, let me know so I know it works with that firmware OK. If it doesn’t work with your firmware, again, let me know and I’ll try and implement a fix. 

v1.2 Submitted to the App Store

I have submitted the current TestFlight version (v1.2 build 347) to the App Store for review.

The App will be reviewed by Apple to ensure it meets the necessary standards and policies and, if accepted, will be made available on the App Store shortly afterwards.

The iPad screens are functional but need some work on them but, for the moment, I’d rather get a working version back on the App Store and fix the iPad screens in a later release. The app does support iPad multi-window mode though and, currently looks nicer that way !

WiFi Hardware update

As a side project I’ve been playing around with the possibilities for a cheap WiFi adaptor to support the app, as an alternative to Bluetooth. This has been bubbling away for a while now but today I finally got to spend some more time on it and have a simple working prototype that allows the WiFi module to be configured via a web interface, including password protection, baud rates, WiFi access point name. You can also get it to connect to another WiFi network.

I’ve tested this against MS1 and MS1/Extra and all seems well so I’ve updated/created the user manual pages with details on how to build this adapter. I’ve also had it running with MS2/Extra now without any issues.

The manual pages can be found here…

Test build 345 available

I’ve shipped test build 345 onto TestFlight this evening.

This build supports MS1, MS1/Extra and MS2/Extra having been tested against my own ECUs.

MS2 testing has revealed a weakness of the Bluetooth interface, compared to WiFi and I’m still investigating ways around it. For the moment though I’ve put a workaround into the app to compensate. It does mean though that it’s unlikely that the same Bluetooth device that you use for iOS can be used for TunerStudio or similar.

There is a limitation in some of the modules that prevents the module transmitting a block of data that’s more than 500 bytes long at 115,200 baud. For MS2 and MS2/Extra this is an issue as the data pages that the app loads at startup are 1024 bytes each. This certainly applies to the HC-08 modules and I will test the HM-10 module, hopefully, in the next couple of evenings to see if that has the same limitation.

User manual updates

In preparation for initial testing of the new app, the user manual section of the web site has been updated with details of the new functionality.

In addition, I’ve added a guide to building a Bluetooth connector and using it which, hopefully, will allow more meaningful testing. For anyone not confident to build their own, I have had preliminary talks with a company that may be able to supply a completed solution “plug and play”.

Connecting via Bluetooth

Bluetooth connection now working

This is a short video/screen recording of a very early Bluetooth enabled version of the app. Still a way to go before it’s ready for testing but as it stands it’s a promising basis for the new app.
The ECU is connected to a simulator so the realtime data may look a bit odd as I swing the inputs around to test the response.
The sampling throughput is running at a steady 11 samples per second which is a bit down on the WiFi adaptor but more than adequate for most uses.
Now I know that the Bluetooth adapter works and is reliable I’ll put together a “how to” guide, showing what is needed to build the interface.
A test version of the app will be released to testers, probably within a week or so. I have some UI glitches to fix now the basic connectivity is working.

Bluetooth, a new chapter ?

As a spin off from another project that I’ve been working on which uses a Bluetooth module to transfer data between an MCU and an iPhone, I’ve been mulling over the amount of work required to both update the MobiSquirt app to the current architecture (to get it back on the app store) and, at the same time add in support for Bluetooth. It can then be added back onto the app store.

To gauge interest and support for the project I’ll be looking for beta testers in the next month or so. If you have already expressed an interest in testing the app I will send you a TestFlight invitation and you will then be notified as soon as a new build is available for testing.

The cost for the Bluetooth components is around £15 from Amazon, cheaper if you get them from AliExpress or similar. I now have this link working in another project and, hopefully, transferring the code across shouldn’t be too painful.

I’ll post a further update when I have a better idea of the work involved and time scales. It won’t happen overnight and is likely to take months rather than days as I fit it in between my other time commitments but after a break from the project I’m now feeling more enthused about it.