I looked into it, it seems that Garmin Virb uses a file format called FIT. So basically all we have to do is convert the iLogger log to a FIT format and it should load into the overlay. I did not decide yet where the conversion processing is going to happen, so I’m still planning on that.
I spent some time thoroughly testing the units and working on some improvements/fixes. The results are satisfactory so far, and everything is starting to come together as development is maturing.
I would like to take a moment and sincerely thank everyone who took a step and supported this project thus far, and know that I’m working hard to push the development of this project to a stage that meets or exceeds your expectations.
Without further ado, here is a summary of what I have been working on:
iLoggers are alive! (It was such a relief to know that hardware production went well, without any unpleasant surprises).
Wifi is working as expected - data rate is reasonably fast, I’m working on further improving up-link data rate to the API on larger files. Coexisting with BLE without any issues -
BLE - no issues detected, connected to my phone right away. The communication protocol is pretty stable.
SD card (All functions are operational), Writing, appending, renaming, deleting, listing successfully. Tested at default speed of 5Hz, but can be set to log at a rate up to 20Hz ( 20 samples per second) for when you need an extremely fine-grained log. iLogger can push to 40Hz but I think that’s very excessive to enable it.
OTA - Automatic version detection and over the air updates working as expected.
Stress tested for 10+ hours, currently undergoing a 24h+
Implemented a full SD card encryption system - Both locally (on the SD card) and during BLE/WIFI transfer.
This took me a while to get up and running, I had to make sure that the app and online API backend both understand and properly decrypt the gibberish data coming from the iLogger.
Improved ride attributes system to better store notes, cloud URLs, FW versions…
Updated delete and create functions to be compatible with the new attributes data.
Added settings page on the app, and finished OTA routine. (When you tap “check for updates” the app pings the iLogger, checks if it’s connected to WIFI, and initiate the OTA routine on the iLogger. iLogger connects to the cloud API, checks for new FW version, and start the OTA update, all while reporting progress through BLE. So the whole update is done by the iLogger itself through wifi, the app only reads reported progress.
Added maps for recorded rides on the app.
Discovered and fixed a few bugs related to fetching and listing ride files.
So only a few minor testing is left for me to perform before shipping out the first beta batch: CAN communication and wrapping up the app for deployment
CAN bus testing is almost done. You can see a debug log of received CAN messages on my phone. CAN status rate is running at 5Hz here, debug is only showing at a rate of 1Hz.
@annihil8ted I’m currently at the very last testing stage. Even tho those are beta testing units, I want to make sure that the initial software release is as polished as possible and stable. One thing I know for sure is, despite all of this, we are still going to encounter many bugs and improvement suggestions, that’s just the nature of any beta initial release, all of which I will be fixing through software updates on a weekly basis.
The good news is, subsequent batches are going to be shipped much faster than this one because the critical testing was already done.
As shipping goes, I can safely say that I should be able to start shipping them out starting on Monday
@mishrasubhransu Thanks I have a Master’s degree in Computer & Software engineering, a couple of research publications at IEEE Computing and Communication conference, and the creator of countless software releases over the past 8 years or so. I picked interest in renewable energy during the last two years and I’m a huge supporter of everything electric.
@kevingraehl The first beta batch is sold out, but I already have many orders in for the second round, which is going to be limited to 40.
I’m starting production for the second batch as soon the beta units are shipped out. I don’t expect the hardware to be changing a lot, so I think it’s safe to say that I will be producing larger and larger hardware quantities as time goes by.
Second batch production is estimated to start around July 15 or earlier.
Im kind of skeptical of this. I know you say that the hardware is flushed out, but isnt the whole point of the beta to find things you may have missed/qc issues/stuff that breaks when test monkeys beat on it with hammers?
Either way im excited to get mine in hand, and I have a build waiting for it so I can provide feedback ASAP. Are you going to ship the beta units with all the necessary cables (CAN x2, UART, GPS, etc.)?
I know what you mean, but what I meant is that, hardware wise, there aren’t many moving parts that can go wrong. It is a pretty simple yet solid design. The whole testing is going to be mainly focused on the software (iLogger firmware, phone app, and online API), that’s were we have many, many variables needs to be tweaked and updated as more and more people give feedback.
Edit: yes, it’s going to have 2x CAN cables, 1x UART cable, 1x GPS connector, 1x antenna.
Here is a quick update regarding first batch shipping and the tasks I have been working on pre-deployment.
First of all, thank you for waiting, I really mean it. I know I’m behind schedule but there have been many tasks I had to perform and finish before sending out the modules.
I’m currently packing everything up, adding heat shrink tubing, and printing shipping labels.
Everyone will receive an email with shipping details and tracking number, as well as your unique iLogger pin number.
Speaking of which, here is what I have worked on:
Implemented a security pin : On first time use you should enter your iLogger’s unique pin to be able to bond through BLE. This is required on first time use only, or when you manually “Forget” the device from your paired devices list. This prevents unauthorized access to your device.
Finished CAN support and it is now 100% operational.
Added UTC offset settings to adjust timezone
Implemented a failsafe rescue mode. In the unlikely event something goes wrong, iLogger can enter a rescue mode and automatically recover to a stable firmware version. This was a very important feature I had to make sure it was working correctly.
Implemented a recursive delete function, this allows you to delete a whole directory including its content.
For performance and usability reasons, long rides are automatically chunked into multiple logs. Ride1, Ride1-1, Ride1-2, etc…