EX Custom iOS/Android App

[Cerna007]

didnt know the 1.7.0 is out right now... i have the 1.6.0 and no updates available

But I already do
It's possible that the ability to connect was patched out in version 1.7.0, so be careful with the bike update for now if you want to continue using the app.
I have only this screen… (bluetooth connection hardening?)

 

[brongle]

But I already do
It's possible that the ability to connect was patched out in version 1.7.0, so be careful with the bike update for now if you want to continue using the app.
I have only this screen… (bluetooth connection hardening?)

Ah well most certainly its them enabling the new BLE stuff I saw before. When I have time I'll look into the 2.8.x app versions and see what it takes to replicate/support in Svag.

 

[Cerna007]

Ah well most certainly its them enabling the new BLE stuff I saw before. When I have time I'll look into the 2.8.x app versions and see what it takes to replicate/support in Svag.

Thank you very much for your efforts on behalf of everyone, I think.
Great Job!!!

 

[brongle]

Actually some interesting changes in the latest app versions:

• Added a ton more error and warning messaging for faults in the BMS, inverter, etc. Unclear if this is visible in the UI yet, but seems like they are trying to give users access to more information that was previously not shown.
• Added a mechanism for firmware updates over Wi-Fi, I imagine this may be a mitigation strategy with the new BLE security stuff to avoid the possibility of bricking bikes.
• Some indications for a new BLE data-transport format based on TLVs, don't really think this is used much yet.

For the authentication changes (probably just interesting to the handful of people building their own stuff off the BLE interface):

• Enable notifications on 0x1001
• Read 32-byte nonce from 0x1001
• Compute auth payload using functions from 'libnativecrypto.so': buildAuthPayloadV2(vin, normalizedSoldDate, variant=2, nonce)
• Write auth payload to 0x1001

This leaves two main complications moving forward, dealing with 'libnativecrypto.so' calls and passing a proper 'normalizedSoldDate' (in the form 19700101). There are various anti-tamper methods in the JNI module and in the end it was easier for me to just reverse engineer and port the functions to Rust (can provide the source if you message me, otherwise gets a bit weird with licensing). For the second, I believe this should be easy enough for users to guess/find and input before connecting for the first time.

I have a version of Svag which may support these changes, however it'll have to wait until my bike gets the firmware update for full testing.

 

[Beagle]

Actually some interesting changes in the latest app versions:

• Added a ton more error and warning messaging for faults in the BMS, inverter, etc. Unclear if this is visible in the UI yet, but seems like they are trying to give users access to more information that was previously not shown.
• Added a mechanism for firmware updates over Wi-Fi, I imagine this may be a mitigation strategy with the new BLE security stuff to avoid the possibility of bricking bikes.
• Some indications for a new BLE data-transport format based on TLVs, don't really think this is used much yet.

For the authentication changes (probably just interesting to the handful of people building their own stuff off the BLE interface):

• Enable notifications on 0x1001
• Read 32-byte nonce from 0x1001
• Compute auth payload using functions from 'libnativecrypto.so': buildAuthPayloadV2(vin, normalizedSoldDate, variant=2, nonce)
• Write auth payload to 0x1001

This leaves two main complications moving forward, dealing with 'libnativecrypto.so' calls and passing a proper 'normalizedSoldDate' (in the form 19700101). There are various anti-tamper methods in the JNI module and in the end it was easier for me to just reverse engineer and port the functions to Rust (can provide the source if you message me, otherwise gets a bit weird with licensing). For the second, I believe this should be easy enough for users to guess/find and input before connecting for the first time.

I have a version of Svag which may support these changes, however it'll have to wait until my bike gets the firmware update for full testing.

I have no idea what you just said but thanks anyway

 

[Karinshi]

"but seems like they are trying to give users access to more information that was previously not shown"

like what? it could be good to at least see battery temperature, so i can stop riding brefore it overheats... surrons and talarias have it... even voltage information aswell

 

[sgr1080]

@brongle -- how to convert .stf files to .csv or some other format that can be easily plotted/analyzed with PYTHON tools?

 

[brongle]

"but seems like they are trying to give users access to more information that was previously not shown"

like what? it could be good to at least see battery temperature, so i can stop riding brefore it overheats... surrons and talarias have it... even voltage information aswell

Stuff you would expect, BMS, inverter, etc. I've seen a few photos of the new warnings screen in the app and it looks like they want it to be a modernized version of a typical diagnostics/OBD fault-code log.

@brongle -- how to convert .stf files to .csv or some other format that can be easily plotted/analyzed with PYTHON tools?

You can use the viewer app (Svag) to re-export it as JSON, right now CSV is not supported but I can probably add that in the future. If you want to just read the STF files that information is here: GitHub - b1naryth1ef/svag-telemetry-format: A simple protobuf-based telemetry format for the Svag app and Stark Varg motorcycles.

 

[brongle]

I figured I'd circle around on the "missing cell groups" issue as its been cropping up a lot more on Facebook. I was hoping someone might have more industry knowledge or experience with lithium packs and be able to confirm my current theory. However based on everything I've seen so far I am under the growing impression that Stark is actively trying to hide potentially serious issues in the original MX 6.5kwh packs.

I've been trying to figure out how to help users reporting this problem as I don't want to mislead people or have Svag causing unnecessary concern. Right now this is what I know:

• This issue has only been seen on the older 6.5kwh pack.
• Bikes keep working, charging, etc. No noticable impact if you didn't have the BMS telemetry data.
• The pack will no longer charge to full voltage, at 100% reported SOC it will be at say 414v for one missing cell, or lower for more.
• The pack voltage seems to match what is reported in Svag, based on @Yieloficial measuring via multimeter (we obviously can't confirm the cell-group readings).
• In almost all cases (except for Erwin's) Stark is denying any issues, saying ride telemetry looks fine, and not replacing packs.

So now the uneducated theory I've been crafting up. My best guess is that the old MX packs have a systematic issue which causes balance leads to fail over time. This is a well known failure mode for EV packs, and I believe Alta also had similar problems. However I think that Stark is (maybe unintentionally?) using a cheap-chinese BMS trick to prevent these failures from disabling the pack. Basically they are lowering the max charge voltage to give "buffer room" that should avoid over-charging the cell groups which now cannot be monitored. This would also mean the 0% voltage is a bit higher than on "healthy" packs to avoid under-voltage.

I would be extremely inclined to think this is just an issue with Svag except for the multimeter reading and various data-points which seem to suggest the pack is actually at a lower voltage.

Curious to hear others thoughts or a better explanation for whats going on. I reached out to Stark on Monday for an official comment and have yet to hear a response. I'll probably work on some dedicated FAQ page for this once I can actually have some confidence in the problem.

 

[Erwin P]

As i sidenote i must add that i've had far greater succes with customer support than seems to be the standard.

I think that's due to me having experience communicating technical issues. As a Proces Operator in a large high-end production enviroment you learn to describe problems in other ways than are ''natural'' to many people. Also adding or leaving out ''cerntain details'' to get things done with the maintenance department was a skill i had to develop.
Starks tech support are very knowledgeable people. I suspect they come from a line of work where they had technical proffecionals on the other side of the line. Having to deal with ''common'' people might be quite the challenge for them.