The KS16 Firmware Thread

[Jeffrey Scott Will]

This topic has been discussed in various threads, but since the firmware upgrades will be an ongoing process, I figured it deserved a place we can all reference when new versions come out.

As I mentioned elsewhere, I impulsively upgraded to V 1.20 against recommendations from my seller that I wait until the stability in confirmed. I commuted with it today which includes plenty of stresses with prolonged hill climbs and descents, high(ish) speeds(22-23kph) and idling. It's only been one day, but so far so good. Not a beep or any indication of struggle. Felt just like V 1.15 which is what I was upgrading from.

So my personal verdict so far: 

V 1.20  Thumbs up

Perhaps the brave souls who try new releases can all chime in so others can decide for themselves if they would like to upgrade. Personally, if this is your only wheel, I'd wait a few weeks until enough reports come in before jumping the gun like I did.

[Jeffrey Scott Will]

After more research into another KS16 thread, I'm going to link @Jason McNeil's experience. AKA: don't upgrade yet!

 

Edited June 2, 2016 by Jeffrey Scott Will

[SlowMo]

So one thumbs-up and one thumbs-down. Need more votes to say it's safe.

[Reivax]

One French reseller in paris is trying the 1.20 release with no issue but advised his customers to not upgrade for now if they have no trouble with their wheels.

Wisely consider that "If it ain't broke, don't fix it"

[Chriull]

Then also a cautious thumbs up for V1.20 - posted my first experience with the new firmware here: http://forum.electricunicycle.org/topic/3719-kingsong-ks16-a-tinnitus-and-more/?do=findComment&comment=44369

The endomondo stats: http://imgur.com/ex0HPx0 (the 40 and 50 km/h peaks are GPS glitches...)

4 hours ago, Jeffrey Scott Will said:

After more research into another KS16 thread, I'm going to link @Jason McNeil's experience. AKA: don't upgrade yet!

 

By now, there are three firmwares/modells for/of KS16 available: 16A,B and C according to http://apkdomain.duapp.com/kingsong/versions.json - So this reports should consider which firmware version/KS16 model one has! Could be that @Jason McNeil's KS16 is a KS16A and (only?) this binary has problems?

Mine is a KS16B (delivered with firmware 1.13) - after this update the App shows me under "Basic Information" as Version "KS-16B-V1.20"

... to play devils advocate theoretically also the automatic firmware selection of the Kingsong App for updating could have been faulty at @Jason McNeil's trial ... (mixes up wrong firmware for a model...)

[edwin_rm]

Jason's wheel firmware seems awfully old! I'd asume 1.07 must be from a prototype version KS16 perhaps? The first consumer wheels he sold came with v1.15 out of the factory. Mine is currently at 1.18 and working flawlessly, even after a few crashes due to not paying attention to obstacles. Well built wheel. 

[esaj]

In that same thread where Jason told of his problems with the firmware, I posted a bit about error-checking to prevent transmission errors. As people here are not telecommunications engineers (hell, I'm not either, just software engineer, but I've mucked around enough with stuff like binary protocols and TCP to know some things), I thought things need more clarification:

 

Transmission between app and device

First of all, the transmission of the firmware binary between the app (in your phone / tablet / whatever) and the device (the wheel) uses a simple file transfer protocol (called "YModem") developed in the 80's for modem use. It does have error checking, which is A GOOD THING, although I wasn't exactly jumping with joy to see that it's CRC16 (which, by modern standards, is very weak error checking). Here's a bit more technical mumbojumbo about it:

Something that should be noted here, and that most people overlook completely, is the fact, that the TCP checksum is actually a very poor checksum.

The TCP checksum is a 16-bit ones-complement sum of the data. This sum will catch any burst error of 15 bits or less, and all 16-bit burst errors except for those which replace one 1’s complement zero with another (i.e., 16 adjacent 1 bits replaced by 16 zero bits, or vice-versa). Over uniformly distributed data, it is expected to detect other types of errors at a rate proportional to 1 in 2^16. The checksum also has a major limitation: the sum of a set of 16-bit values is the same, regardless of the order in which the values appear.

Source: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf

So if you randomly flip any number bits anywhere in the data part of the packet, the chances are 1 to 65536 that this error is not detected, even if you don't touch the checksum at all, as the new data, even though totally corrupt, has in fact the same checksum as the old one. If you just swap two 16 bit values in the data part, regardless which ones and regardless how often, the chances are even 100% that this error is not detected, since the order in which the 16 bit values appear in the data part of the packet is totally irrelevant to the value of the calculated checksum.

What I'm trying to say here is that you don't have to worry too much about the rather unlikely case that data and checksum both get corrupted and this error is not detected because the corrupted checksum matches the corrupted data, the truth is that every day millions of TCP packets on the Internet have only the data corrupted and this error is not detected because the uncorrupted checksum still matches the corrupted data.

If you need to transfer data and you want to be sure the data didn't get corrupted, the TCP checksum alone is certainly not enough for this task. I would even dare to say that a CRC checksum is not enough for this task, since a CRC32 may not detect an error where more than 32 bits in a row are affected (these errors can "cancel out" each other). The minimum checksum you'd need for ensuring flawless data transfer is the MD5 value of the data. Of course anything better than that (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool, and so on) will work even better, yet MD5 is sufficient. MD5 may not be secure enough for cryptographic security any longer (since it has been broken multiple times in the past), but as a data checksum MD5 is still absolutely sufficient.

Original source: http://stackoverflow.com/a/15649930/594183

Actually, that talks about TCP, but since that also uses CRC16, it's relevant here. And I'll get to TCP in a bit.

The "the chances are 1 to 65536 that error is not detected" is a bit of an simplification, actually it depends also on things like the packet size and error probability of the network/transmission route. But it's a good rule of thumb (n-bit error checking can fail in about 1 out of 2ⁿ errors). Mucking about with the decompiled source of the KS app, it seems that the app sends the firmware to the wheel in 16 byte (not 16 bit, there's a difference!) chunks, with some overhead around it per packet . For example the 16C.bin is 43008 bytes long. If sent in 16-byte chunks, the amount of packets needed to transmit the firmware to the device is

43008 / 16 = 2688

Nice, it even rounds up evenly (actually, that makes me think whether they padded the file to match 16-byte boundaries, and if their protocol implementation cannot handle "unevenly" sized files, but that's besides the point ). Even if you had a bad connection between the app and the device, and each first send of a packet would contain one error (which is exaggerating) using that rule of thumb of "1 in 65536 errors goes undetected", it would mean that among users who got such bad connections between the app and the device, on average every 65536 / 2688 = 24.38... th (round it to every 25th update, 2 digits) update would fail due to malformed data passing the error checking undetected.

In reality of course, the number is much, much lower, as not every packet is going to contain an error in the first try and need resending (or slip through in about every 65536th time on average). Like I said before, it's a GOOD thing that they at least have some error checking in the protocol for such critical place. Personally, I would have preferred something more robust, like MD5 which is a 128-bit checksum, the chances of error going undetected is about:

1 to 2¹²⁸ = 1 to 340282366920938463463374607431768211456, that's 39 digits

It's fairly simple to implement (there are lots of examples and ready-made libraries floating around the net), but does add overhead to the transmission. That shouldn't mean much when the firmware binaries are tens of kilobytes, I'd rather wait some seconds / a minute longer knowing that the probability of undetected error is so low that I don't need to worry about it.

Using the above (again, exaggerated) example, where each packet contains an error on first send (and always succeeds on retry), on average the failed update due to transmission error occurs every

340282366920938463463374607431768211456 / 2688 = 126593142455706273609886386693366150.xxx (that's 36 digits)

updates. That's next to impossible, consider that winning the Finnish lottery is about 1 to 15 million (1 to 15000000, 8 digits). For Americans, propability of winning the Powerball jackpot is about 1 to 175223510 (9 digits). Actually, it's more probable to be hit by a lightning than winning the lottery (at least in Finland, the rate was something like 1 in 4 million).

So, in conclusion about the app <-> device transmission, it's good that there is some error checking, but with a little bit more effort, it could be made next to impossible for the update to fail due to transmission error.

 

Transmission between server and app

The app reads the available firmware-data from  http://apkdomain.duapp.com/kingsong/versions.json  . The json-file that URL points to contains the version numbers, types & links and descriptions for different firmware binaries. Formatted, it looks like this:

{
  "devices": [
    {
      "type": "KS-14B",
      "versionName": "1.00",
      "versionCode": "120",
      "app_url": "http://apkdomain.duapp.com/kingsong/14B.bin",
      "des_ch": "Ìáʾ:\nÉý¼¶Ö®Ç°Çë½øÈëµ½»ù±¾Ã?Ã…Ã?¢ÀïÃæ¼Çס¹Ì¼þ°æ±¾Ã?Ã?ºÅ,ÔÚÉý¼¶¹ý³ÌÖÃ?ÇëÎðÃ?˳öÉý¼¶½çÃæ,Éý¼¶Ã?ê³ÉºóÇëÖØÆô»úÆ÷\nÀúÊ·°æ±¾:\nV1.20 ½â¾öÉý¼¶ËÀ»úÎÊÌâ¡¢¼ÓÈëµÃ?ѹÃ?ÞËÙ¹¦ÄÜ\nV1.18 Ã?Þ¸´×ÜÀï³Ì¶ªÊ§ÎÊÌâ",
      "des_en": "Note:\nBefore upgrading, pls do check the basic info and bear the firmware version into mind, pls don¡¯t exit upgrading interface while upgrading. Restart the unicycle after upgrading.\nPrevious version:\nV1.20: Fix unicycle block while upgrading, add low-votage speed limitation feature\nV1.18: Optimize total mileage calculation"
    },
    {
      "type": "KS-14BA",
      "versionName": "1.00",
      "versionCode": "120",
      "app_url": "http://apkdomain.duapp.com/kingsong/14BA.bin",
      "des_ch": "Ìáʾ:\nÉý¼¶Ö®Ç°Çë½øÈëµ½»ù±¾Ã?Ã…Ã?¢ÀïÃæ¼Çס¹Ì¼þ°æ±¾Ã?Ã?ºÅ,ÔÚÉý¼¶¹ý³ÌÖÃ?ÇëÎðÃ?˳öÉý¼¶½çÃæ,Éý¼¶Ã?ê³ÉºóÇëÖØÆô»úÆ÷\nÀúÊ·°æ±¾:\nV1.20 ½â¾öÉý¼¶ËÀ»úÎÊÌâ¡¢¼ÓÈëµÃ?ѹÃ?ÞËÙ¹¦ÄÜ\nV1.18 Ã?Þ¸´×ÜÀï³Ì¶ªÊ§ÎÊÌâ",
      "des_en": "Note:\nBefore upgrading, pls do check the basic info and bear the firmware version into mind, pls don¡¯t exit upgrading interface while upgrading. Restart the unicycle after upgrading.\nPrevious version:\nV1.20: Fix unicycle block while upgrading, add low-votage speed limitation feature\nV1.18: Optimize total mileage calculation"
    },
--- SNIP ---
}

As you can see, there are no checksums for the files. This is a real world conversation I've had (actually more than once, but just one example):

   Me: If we're going to transfer files to the game-clients over the network at runtime, we better implement some data verification
   CTO: But the data is transferred over TCP, TCP has error correction, so it cannot become corrupt

If I had a dime (or an euro) each time I've heard that, I'd have... several dimes. It is true that TCP has that checksum/error correction, it detects most errors and corrects them by asking the previous node in the network to resend the data if the checksum verification fails (also it does other handy things like assuring the right order of packets etc, but that's besides the point). HTTP, which is used to transfer the firmware binary to the phone/tablet, also works on top of TCP (Transmission Control Protocol) and TCP works on top of IP (Internet Protocol). HTTP has no error correction in itself, but both TCP and IP implement their own, CRC16 for TCP packets, IPv4 only has checksum for it's own header, but not for data, but:

An IP packet has no data checksum or any other footer after the data section. Typically the link layer encapsulates IP packets in frames with a CRC footer that detects most errors, and typically the end-to-end TCP layer checksum detects most other errors.

The keyword again being most other errors. Like shown above, the 16-bit checksum isn't exactly fool proof.

So, we ended up implementing a simple data verification for the file transfer (note that this is not over HTTP, but "raw" TCP binary stream, still the basic principle is the same) and added a mechanism for the client to report verification errors to see how often it happens. Our logs contain a LOT of these (I've censored most of the message, as it contains client-related data etc. that's not related):

Client reported error: HandleFileChunksResponse - context='<CENSORED>', category='<CENSORED>', id='<CENSORED>', file chunk md5 mismatch, re-downloading chunk at offset 262144
 

If I had to hazard a guess, I'd say that happens about 1 in 1000 to 1 in 10000 file transfers (in our case, that's a raw assumption based on the amount of the error reports the clients send vs. amount of active players), typically with the largest file (around 400kB, 10 times bigger than KS's firmware binary), because the larger the file, the more probable it becomes that there are transfer errors. But, as we implemented that error checking, the client code can check that it got the pieces (chunks) of the file without corruption, and even if there was corruption, it will just download that chunk again (and usually it succeeds on the second try without a hitch). Without this, we'd have corrupt data on the game-client, and angry customers because their games would (likely) crash with that malformed data.

An abstract of a paper from the year 2000 ( http://dl.acm.org/citation.cfm?id=347561&dl=GUIDE&coll=GUIDE ) states that:

Traces of Internet packets from the past two years show that between 1 packet in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where link-level CRCs should catch all but 1 in 4 billion errors. For certain situations, the rate of checksum failures can be even higher: in one hour-long test we observed a checksum failure of 1 packet in 400. We investigate why so many errors are observed, when link-level CRCs should catch nearly all of them. We have collected nearly 500,000 packets which failed the TCP or UDP or IP checksum. This dataset shows the Internet has a wide variety of error sources which can not be detected by link-level checks. We describe analysis tools that have identified nearly 100 different error patterns. Categorizing packet errors, we can infer likely causes which explain roughly half the observed errors. The causes span the entire spectrum of a network stack, from memory errors to bugs in TCP. After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets. From our analysis of the cause of errors, we propose simple changes to several protocols which will decrease the rate of undetected error. Even so, the highly non-random distribution of errors strongly suggests some applications should employ application-level checksums or equivalents.

Ok, so 1 in 16 million to 1 in 10 billion doesn't sound that often. How come we're seeing the data malformed in, say, every 10000 file transfers then? There are multiple reasons, here's a few I can think of right of the bat: 

• The amount of internet traffic has grown exponentially since the year 2000 (in 16 years)
• TCP-packet MTU (Maximum Transfer Unit) is 1500 bytes at highest, and typically much lower, meaning that 1 file is not the same as 1 packet (assuming a 1000 byte average transfer unit, transferring the 16C.bin at 43008 bytes would need around 43 packets)
• In 2000, wireless over-the-air transmission (like WLAN/Wifi, 3G/4G/whatever mobile data, Bluetooth) was very rare or non-existant for some technologies
  • Over-the-air transmission is MUCH more prone to interference, and thus has much higher error probability than landlines
  • Our games are made for mobile devices, so almost always there's wireless transmission involved
• As the amount of wireless communication has also grown exponentially, and continues to grow, the amount of interference also grows
  • Most wireless technology works over a fairly narrow frequency band around 2.4GHz, because it's unregulated, so basically they start to compete against each other and interfere each other, causing larger amounts of errors and resends needed (and errors sometimes slipping through)
• Things like solar storms/flares and cosmic rays can affect the satellite (and maybe even landline) communications (I'm not making this shit up! )

There's a reason why you usually see an MD5-checksum (well, nowadays probably something like SHA256 or whatever) for a file, when downloading something like a Linux-image from a website. The MD5 is there so that you can check that the file is not corrupt after downloading, and avoid the hassle of trying install an OS from a corrupt image.

Another real world example: Have you ever encountered a situation where you open a web-page and it shows all mangled up, but after refreshing the page, everything's ok again? There's a possibility you got hit by an undetected error in the HTML or CSS files in the first go. It happens. I've had corrupt Linux-images in the past, and encountered mangled up data and web-pages, that were fine after refresh/resend.

So, while it is (relatively) rare to encounter a transmission error (especially with such a small file as the firmware binaries), the effort to fix this shouldn't be that huge for KS:

• Calculate an MD5 (or whatever, I'd see MD5 as "good enough") checksum from the known to be good binary files
• Add a field for the checksum in the json-file and write the checksum for each file there
• Modify the app to calculate the checksum from the firmware binary file after the download over HTTP completes
  • If the checksum doesn't match, re-download the file

And that's pretty much it. It will also be backwards compatible with current apps, they just won't do any checksum-checking, but they shouldn't mind of that "extra" checksum-field in the JSON-data.

In conclusion, this isn't exactly the most critical problem in the world (I can imagine the developers programming the firmware update to have lots and lots of other problems to tackle ), but on the other hand, it removes one possible single point of failure in the process and doesn't require much effort.

Edited June 2, 2016 by esaj

[Chriull]

1 hour ago, esaj said:

...

So, while it is (relatively) rare to encounter a transmission error (especially with such a small file as the firmware binaries), the effort to fix this shouldn't be that huge for KS:

• Calculate an MD5 (or whatever, I'd see MD5 as "good enough") checksum from the known to be good binary files
• Add a field for the checksum in the json-file and write the checksum for each file there
• Modify the app to calculate the checksum from the firmware binary file after the download over HTTP completes
  • If the checksum doesn't match, re-download the file

...

16 hours ago, esaj said:

... (ie. update has failed, like store a value in EEPROM when the update starts, and erase / change it after it's complete; if during boot time the value is still found / shows that there's a update in progress, the update has failed, and bootloader should enter a "fault"-state, where it won't do anything except accept a new firmware).

Imho both measures together (saving the (new) md5 checksum in the EEPROM and check the contents of the EEProm with the given md5 checksum at every startup) should be a good measure to also be save from all other possible failures (eeprom data faults by aging and whatsoever...) with a quite simple method...

 

Edit: Somehow the formatting with the quoting got quite messed up ;(

PS.: This discussion started by occasion with the new KS firmware update with some evidence of these shortcomings, but imho would be fair to be written in the general section not only exclusively mentioning KS - i am afraid that many wheels with upgradable firmware could have the same/quite similar "problems"...

And additionaly many different suggestions for the manufacturers to improve the firmware could be collected there, like 

- Battery testing: It could be possible to measure the internal resistance of the battery pack at startup/while riding, so that "bad/aged" cells could be found _before_ the BMS shuts down while riding... Should happen with every EUC after some years (or even earlier if the packs where not held at the right voltages/temperatures...) that one/some bad/aged cells will get the BMS to just shut off because of undervoltage...

- System simulation: The firmware could model the whole system (wheel + rider) to predict (some) overleans/overpower/shutdowns and gives an alarm early enough (reaction time) for the rider...

- many other already mentioned/discussed firmware topics around here...

Edited June 2, 2016 by Chriull

[Chriull]

1 hour ago, esaj said:

...

An abstract of a paper from the year 2000 ( http://dl.acm.org/citation.cfm?id=347561&dl=GUIDE&coll=GUIDE ) states that:

... After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets.

 ...

TCP-packet MTU (Maximum Transfer Unit) is 1500 bytes at highest, and typically much lower, meaning that 1 file is not the same as 1 packet (assuming a 1000 byte average transfer unit, transferring the 16C.bin at 43008 bytes would need around 43 packets)

...

I did not read the paper, but it could be that "the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets." regards each hop a packet makes. So to http://apkdomain.duapp.com/kingsong/versions.json from my place each packet makes (now tested with a tracetroute) 17 hops... And then there is the 18th hop once the data is transfered to the wheel.

So the chances for an undetected error would raise in this case by 43 packets (for the whole file) times 18 hops. So this would lead to a worst case of an undetected error every 21 thousand transfers (16 Million/43/18)... (with some packet retransmissions even more often...). This "amount" should happen and be "noticable" in a real world usage...

[Chriull]

7 hours ago, Chriull said:

Then also a cautious thumbs up for V1.20 - posted my first experience with the new firmware here: http://forum.electricunicycle.org/topic/3719-kingsong-ks16-a-tinnitus-and-more/?do=findComment&comment=44369

...

Just added another 16km's of unspectacular V1.20 driving - so ~34km of no probs with V1.20 till now...

[Ecko]

I have updated from 1.18 to 1.20....no problems so far but the total milage resetted to zero.... Aaaahhhh

[ThomasK]

3 hours ago, Ecko said:

I have updated from 1.18 to 1.20....no problems so far but the total milage resetted to zero.... Aaaahhhh

same with me except that I updated from 1.13 to 1.20

[Gunthor]

@Ecko and @ThomasK: T h a n k   Y o u   for letting us know 

If the total mileage gets a reset then this a a clear "Thumbs down" for me. I will not update.  

[dside]

I took the plunge too and updated my 1.15 to 1.20. Works just fine. I rode 20+ km with the new firmware today. 

[HEC]

Apologies for a bit of OT but didn"t want to make a new thread just for that ... but where do you download the KS16 app from or what is it called exactly? Can't see it on the web or in Play store. Thank you!

 

[ThomasK]

3 minutes ago, HEC said:

Apologies for a bit of OT but didn"t want to make a new thread just for that ... but where do you download the KS16 app from or what is it called exactly? Can't see it on the web or in Play store. Thank you!

 

Updating the firmware is done through the app itself: firmware upgrade under settings

[HEC]

3 minutes ago, ThomasK said:

Updating the firmware is done through the app itself: firmware upgrade under settings

Thank you, I'm aware of that. My question is though where do I get the app from in a first place

[ThomasK]

7 minutes ago, HEC said:

Thank you, I'm aware of that. My question is though where do I get the app from in a first place

Download from the KingSong site is not working for ages.... You should get it from your supplier.

There is a version at http://kingsong-france.com/download/app-ks16a/

You can download a version translated into German at http://www.electro-sport.de/epages/78292882.sf/de_DE/?ObjectPath=/Shops/78292882/Products/%22Kingsong%20KS16%22

pls go to " App für Android gibt es hier". Choose the file which is corresponding to the size of your battery pack.

 

[edwin_rm]

Or download here for English KS16 Android app.

Edited June 3, 2016 by edwin_rm

[Stuart]

How long does it take to download the new firmware in the app as I can see the new version, pressed download and can see that the download button is highlighted and the black bar under it appears but that's it. Seems as though it is stuck??

[dside]

35 minutes ago, Stuart said:

How long does it take to download the new firmware in the app as I can see the new version, pressed download and can see that the download button is highlighted and the black bar under it appears but that's it. Seems as though it is stuck??

Sounds like it's stuck. It took maybe couple of seconds to download in my case. 

Edited June 4, 2016 by dside

[Stuart]

Any guru's on here that know how to make it unstuck?

[Frankman]

Me too same problem. But it can depend on the smartphone

I press the download button on the app, but nothing happens (HomTom chinese smartphone).

I try with my wife's smartphone (Samsung smartphone) and it works. However I did not make the upgrade yet. I prefer waiting untill a solid and tested firmware is released.

Edited June 4, 2016 by Frankman

[DS]

I updated from 1.15 to 1.20 and did 50 km riding in different conditions afterwards.

When I pressed the button "download", it took several seconds for download on the phone (Samsung galaxy 3 and fast internet). Just in case, before that, I removed the SIM card - did not want eventual phone call interruption.

Second step was longer one, when the firmware transfers to the KS16. After a minute transfer, I decided to leave the phone on the table.....and the process stopped and I thought "Now I'm f...ed" . Waited a couple of minutes, nothing happens and then pressed "download" again. This time (no movements from my side) the process finished successfully and when I restarted the EUC, the app showed ver.1.20.

The new firmware seems resolved my problem with the false "overpowered" reports, at least up to now have not happened.

But I observed twice that when reaching max speed the wheel mismatched the messages and instead of "Decrease your speed" says "Hello Kingsong" followed by Bluetooth connection interruption which was the case with ver.1.15 too.

The new app is still very unstable, looks like got improve a bit, but this may not have in common with the new firmware.

Edited June 4, 2016 by DS

[Frankman]

The app for iOS that I installed on my iPAD seems to work better than the Android version.

Edited June 5, 2016 by Frankman