New VARG Software Update.

I just got 1.6.0 today, went to go for a ride and noticed the status-led having a little disco party and rapidly cycling through the colors of the rainbow. Cool effect but in the moment I assumed something was messed up (especially given the control inputs do nothing) and played around with the front hub connectors for a minute until I noticed the status LED was back to normal. Is that the normal indication a firmware update is happening? Either way seems like pretty bad UX not to mention the annoyance of random auto-updates.

Rode fine, didn't notice anything different except it reset my neutral safety timer which was pretty annoying given I didn't have the phone on me to change it back, and depending on traffic I find myself triggering it every other light.
 
I just got 1.6.0 today, went to go for a ride and noticed the status-led having a little disco party and rapidly cycling through the colors of the rainbow. Cool effect but in the moment I assumed something was messed up (especially given the control inputs do nothing) and played around with the front hub connectors for a minute until I noticed the status LED was back to normal. Is that the normal indication a firmware update is happening? Either way seems like pretty bad UX not to mention the annoyance of random auto-updates.

Rode fine, didn't notice anything different except it reset my neutral safety timer which was pretty annoying given I didn't have the phone on me to change it back, and depending on traffic I find myself triggering it every other light.
On the MX 1.0 that is, the cycling is normal when the firmware upgrade is happening. Usually it returns to standby mode when done a slow flashing red.

I don't know why they can't save the defaults properly. Seems kind of half-ass to change settings like that. In all the firmware I have worked on over the past 30 years the first steps are save a backup copy and save the user config. Do the update, check update for validity, recopy in the user settings. QA should have made goddam sure it worked and that no inadvertent changes would impact users.
 
After another full shutdown and restart, I just managed to update to 1.6.0.

Just by chance I tried a few things and discovered that the EX "kill switch" on the right hand grip now has a different function. Previously, it basically did the same as the on/off switch on the left grip. I used it in the past to put the bike in Neutral and to do regular shut-offs.

After my update, the kill switch now acts as a full shutdown switch. It now kills the bike completely and places it into a full shutdown with the red light not flashing at all. Previously, the red light still flashed when using the kill switch.

I can also use it as a shutdown switch after the bike is turned off with the on/off switch (red light flashing). Even in this sleep mode, the kill switch now quickly places it into full shutdown (same as holding in the +/- button feature until full shutdown, but much quicker).

Does it do the same with anyone else's EX? If so, it's a new feature.
 
After another full shutdown and restart, I just managed to update to 1.6.0.

Just by chance I tried a few things and discovered that the EX "kill switch" on the right hand grip now has a different function. Previously, it basically did the same as the on/off switch on the left grip. I used it in the past to put the bike in Neutral and to do regular shut-offs.

After my update, the kill switch now acts as a full shutdown switch. It now kills the bike completely and places it into a full shutdown with the red light not flashing at all. Previously, the red light still flashed when using the kill switch.

I can also use it as a shutdown switch after the bike is turned off with the on/off switch (red light flashing). Even in this sleep mode, the kill switch now quickly places it into full shutdown (same as holding in the +/- button feature until full shutdown, but much quicker).

Does it do the same with anyone else's EX? If so, it's a new feature.
Yes, apparently the kill switch now completely shuts the bike down. The power button on the left now only turns it on and puts the bike in standby mode. I think I like it better this way.

Edit: I just went back and read your post. I guess I repeated exactly what you said. As I get older, I have more of those moments. lol
 
I just got 1.6.0 today, went to go for a ride and noticed the status-led having a little disco party and rapidly cycling through the colors of the rainbow. Cool effect but in the moment I assumed something was messed up (especially given the control inputs do nothing) and played around with the front hub connectors for a minute until I noticed the status LED was back to normal. Is that the normal indication a firmware update is happening? Either way seems like pretty bad UX not to mention the annoyance of random auto-updates.

Rode fine, didn't notice anything different except it reset my neutral safety timer which was pretty annoying given I didn't have the phone on me to change it back, and depending on traffic I find myself triggering it every other light.
I got the magenta flashing light first. Then up+down press and disco lights for a few minutes.
After that I tapped the "check for update" in the App and it offered if I want to update the app now.
No auto updates of either.
Can't ride or test for the next few days, though.
Screenshot_20251125-080716.png
 
My bike wanted to update today as well - flashing yellow light! Since I had been pretty happy with my 1.5.0/2.7.1 combination my desire to change that was pretty low and so I decided to see what would happen if I ignored the update request. After turning it off (standby) and back on for 3 times with some breaks in-between the flashing yellow light would change into a flashing purple without having done anything else. By then the firmware had updated to 1.6.0 automatically! Repeating the on/off cycle with the flashing purple light there was no further change though and only after manually initiating the update process the rainbow colored flashing would appear. So it looks like the update process is a bit more complex than expected with firmware updates being automatic and the rainbow flashing actually indicating something else?

As said before I had been very happy with the 1.5.0 firmware before and since the app update to 2.7.1 everything seemed to run smooth without hiccups. Fortunately 1.6.0 seemingly hasn't changed any of that and the update from 1.5.0 to 1.6.0 actually didn't change any of my settings like timers or power modes for the first time ever. Could it be that I'm on the way of being a very happy customer :lurker:

Michael
 
My bike wanted to update today as well - flashing yellow light! Since I had been pretty happy with my 1.5.0/2.7.1 combination my desire to change that was pretty low and so I decided to see what would happen if I ignored the update request. After turning it off (standby) and back on for 3 times with some breaks in-between the flashing yellow light would change into a flashing purple without having done anything else. By then the firmware had updated to 1.6.0 automatically! Repeating the on/off cycle with the flashing purple light there was no further change though and only after manually initiating the update process the rainbow colored flashing would appear. So it looks like the update process is a bit more complex than expected with firmware updates being automatic and the rainbow flashing actually indicating something else?

As said before I had been very happy with the 1.5.0 firmware before and since the app update to 2.7.1 everything seemed to run smooth without hiccups. Fortunately 1.6.0 seemingly hasn't changed any of that and the update from 1.5.0 to 1.6.0 actually didn't change any of my settings like timers or power modes for the first time ever. Could it be that I'm on the way of being a very happy customer :lurker:

Michael
The download of the new version is different than loading the new image into the processor that is typically why the leds vary in color. The rainbow is likely the actual loading of the program into processor memory. It is typically done like this to make sure there is a copy of the old and new programs in the storage in case something goes wrong and if rainbow fails checksum or something it should fall back to the old version. Even custom ASICs generally work like that when the firmware is updated.

I wish Stark would document this stuff and be more transparent with what they are doing with the software/firmware. It is not like this stuff is state secrets or something. I don't even think they provide release notes which is general practice across the software industry.
 
The rainbow is likely the actual loading of the program into processor memory.
Basically I'd agree with you, but on this one it was showing 1.6.0 on the Arkenstone before the rainbow flashing - IMO the purple flashing prior to the manual update procedure was pointing to other components updates and the initial yellow flashing (without the rainbow flashing process) to the firmware update. It is hard to imagine that Stark would risk a firmware update without making sure the user can't intervene, but it seems they can force a firmware update now so they must have figured something out. It could be something like two firmwares being present and just a pointer set at powerup on which one to use - with this you could prepare the update in the background and activate it any time.

Michael
 
I don't know if it's relevant, but after the disco lights and shutdown I got the magenta light for the second time. Bike and app were already updated at that moment.
Then the magenta light went off on its own.

This is all tolerable in the garage on a rainy day, but I would not want to deal with any of it at the start of a ride.

Charging power slider in the app can still be set to 6.6kW, by the way. (n)
 
Basically I'd agree with you, but on this one it was showing 1.6.0 on the Arkenstone before the rainbow flashing - IMO the purple flashing prior to the manual update procedure was pointing to other components updates and the initial yellow flashing (without the rainbow flashing process) to the firmware update. It is hard to imagine that Stark would risk a firmware update without making sure the user can't intervene, but it seems they can force a firmware update now so they must have figured something out. It could be something like two firmwares being present and just a pointer set at powerup on which one to use - with this you could prepare the update in the background and activate it any time.

Michael
Not sure but Arkenstone may read the store rather than what is loaded in processor memory and it may read the latest version in the store. Like you say I think the store almost certainly has both copies and points to the one to use. The process generally varies by implementation a firmware update to your TV is probably has less human impact than a firmware update to a heart monitor --but it is rare in my experience that the user is not informed of a pending functional update, especially if there is potential human impact. Users have reported settings changes after updates so with the Stark a user could be impacted by a live forced change.

They may update other components but that can be risky too and complicate things as failures in other components may jeopardize the firmware update and complicate an undo if there are dependencies. I agree in most implementations it is good to prevent user interruption but the design has to be able to recover from this. The classic Windows don't interrupt message has been ignored by users for years --get pissed off pull the plug... Usually doesn't brick it.

I have heard Stark can force a firmware update but at least in the work I have done in embedded systems this is typically relatively rare. It is difficult to predict in the field what the user is doing or going to do at any given moment. An update to the actual running firmware could be very dangerous and probably would break something. I hope they are only updating the store and require user intervention or at the very least a powercycle to force update to runnable code.

I think I have heard of setting changes in live operation which I have been hoping is just a misalignment of what is in storage and what is in memory. In many applications I have worked on especially with remote control devices like phones there can be a disconnect and inaccuracies between what is actually running and what is read back by the device --Stark themselves has had this same problem in troubleshooting some bikes in the field.
 
Back
Top