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.
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.
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.
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”.
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.
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.
I now have a functioning WiFi to serial adaptor built from three components that are freely available as ready made modules. All that is required are a few wires to connect them together and to load the software onto the WiFi module using a USB cable and the Arduino IDE. I’ll be putting together a complete description and a list of the components once I put the Arduino sketch on github.
The adaptor uses a NodeMCU WiFi development kit to supply the WiFi access point and to run the sketch that provides the connectivity. This is then connected to the MegaSquirt ECU via an UART to RS232 adaptor module. In order for the complete module to run from the 5V supply from the MegaSquirt serial port, it needs to use a 5v to 3.3v dropper module in the TX line from the RS232 module to the NodeMCU.
There are a number of advantages to using this unit over the RN and WiFly devices in addition to the obvious price advantage (a fraction of the price of those modules)…
The module (via the firmware) provides a web interface to allow it to be configured for MS1 or MS2 (change baud rates).
You can define the WiFi Access point name and also secure it with your own password.
You can continue to use the internet via 3G while connected to the access point.
The open source firmware will allow those who want to to add their own functionality to the link.
Total cost for the complete module is around £12 GBP from Amazon
I’ve fixed all the problems with the architecture of the app and it’s now working as fast as a PC connected via a serial cable when it comes to creating log files, in the region of 16 lines per second on an MS1/Extra. I have 2 more screens to update to iOS7+ compatible and I’ll be looking, finally, at a release. The new architecture has opened up a number of possibilities as well as removing many of the stumbling blocks that were limiting it’s performance.
One of the more recent problems being experienced is a practical one since MicroChip bought out Roving Networks and pulled the rug out from underneath the simplest and cheapest connection option. Obviously one solution to this has been to start looking at BlueTooth interfaces but in tandem to that I’ve also been looking at a much lower cost WiFi option that uses a couple of “off the shelf” modules hooked together. Initial results have been good and it would bring the cost of a WiFi adaptor down to less than £12 ($15USD) but it will need to be flashed with some simple custom code that I’m going to release as an open source project. The software to compile and upload the software to the module is free and you just need a USB cable to flash the module.
This is actually a much better solution than the RN134 as it offers a secure, password protected, connection and a customisable web interface to configure it and, being so much cheaper, will be a good option.
I may be adding banner advertising to the app in an attempt to help it pay for itself. Although the donation model worked initially it’s not covered the costs of developing the app or hosting this web site, let alone the cost of MegaSquirt ECUs to test against. Banner advertising has proved reasonably successful in my other apps as a way of generating a small but steady revenue that might, at least, help offset some of the costs.
I’ve completed the architecture changes I’ve been working on and the first test version of the app is being distributed to testers now. If you haven’t already signed up and are using iOS 8 or later, use the contact form to let me know you would like to become a tester. The new Apple TestFlight system allows for up to 1000 testers and the more people testing it the better !
The architecture changes offer far more flexibility and improved speed of logging by recording the data into a database, including logging sessions. As well as the improved speed it opens up new possibilities, such as a graph view of the data in both realtime and logged data environments. Data from the MS ECU is also stored with log sessions, allowing easier transfer of log data between devices in the future. At some point I will also leverage this mechanism to provide iCloud support for your logging sessions.
Updates to the latest iOS SDKs and methods mean an updated layout that should cope better with different device screen sizes and native support for 64 bit devices will improve performance on those devices.
The one feature that has been lost as part of this restructuring is the ability to transfer log files from the device using iTunes. On the plus side though the email facility allowing log files to be emailed has been updated to support the iOS7 and later action facility. This allows log files to be emailed as before but also allows them to be transferred via AirDrop or any other method that your device is configured for (Facebook, Messages etc…) or opened directly in another app on your device that supports the file type. For Mac users this means you can quickly send log files directly to your Mac over WiFi.
With the new data format it is possible for full log files, with all the MS ECU config data, to be sent between iOS devices and imported into other copies of MobiSquirt at some point in the future.
While the test versions of the app work quite happily on both the iPhone 5 and the iPhone 3G and earlier it seems that the App Store version can’t have that luxury unfortunately. At some point soon I’ll need to make a final decision on how to handle it but my current thinking is that I may create a new version of MobiSquirt on the App store that will support legacy hardware and iOS versions while at the same time allowing the “main” app to take advantage of the latest and greatest iOS developments. Of the current user base of around 800 active users there are 10 users that have devices that don’t support iOS 4.3 and later according to the analytics.
Going down the legacy app route will have the advantage that, when and if I can no longer update the legacy version at least the legacy version will remain on the App Store should an older device need a factory reset or similar and lose the app.
The next App Store release will not support iPhone 5 natively as I want to get the RPM fix out while I pontificate further and see how other developers handle the iPhone 5/iPhone 3G problem.