Kingsong KS16-A Tinnitus and more...

[Jason McNeil]

1 minute ago, esaj said:

Jeffrey Scott Will did:

Dooh, thanks Esaj!

[US69]

2 hours ago, johrhoj said:

 

I also had to add 5 kg to my weight; used to say 105, now i accept it is really 110. You made me laugh by saying that: ... some of the riders are "also" 90kg. You sure you are not a little in denial still?  

But seriously, I also heard that Kingsong wheels had overheating problems. So, the first few times that i thought I had asked a lot of my wheel (long ride, ending in sprint hill up, in the sun, ambient 20 degree C), I checked the temperature through my app. No problems with heat.

I must add that I am a moderate/conscionable/responsible driver, never go to the extreme. Also I have not the same wheel (I have the KS18 1200W) but I feel I never have to check for overheating anymore. 

i sad that with "also" because i have in mind the asian riders are normally a lot more light weight and smaller as european or american....

I heard that with the "heat" Problems only at from about 5 to 6 People....Really...Thailand gulf isle in may is a heat hell...i did NOT exscpect it to work at all!!!

But the KS 16 proved me wrong...and Boy that was not like in the netherlands...inclines and declines whereever you go on "The Rock" and bumpy streets ...it's more like offroad all day! And i am not so moderate/responsible as made a fast Crash at about 32 kmh there....stupidity braggart done...fooled :-)

 

But heat wise at least my KS16 was a bummer....not ONE Problem in this heat hell....

 

[HEC]

1 hour ago, Jason McNeil said:

Has anyone had any success upgrading to v1.20? For me, when trying to install it, it's not able to download...

Hi @Jason McNeil sorry a bit of OT but if it has been you I was chatting about KS16 purchase earlier today you can get hold of me here

[Jason McNeil]

v1.20 has bricked my Wheel!  It's serial number v009, so maybe it's something in this early Wheel build. 
Situation is that the Wheel is powered-on but NOT responding to the power button, the lights are on, but the Wheel is locked (e.g. has a lot of resistance when attempting to turn it).

At the download stage, it stalled a couple times, and until finally successful; then during Upgrade, the status bar shows one or two pixels & repeats.

Only recourse is to open up the Wheel and disconnect power, otherwise it will drain the battery pack.

 

 

[HEC]

1 hour ago, Jason McNeil said:

... disconnect power ...

Hi @Jason McNeil maybe that will reset the board to some more cooperative state?

[esaj]

6 minutes ago, Jason McNeil said:

v1.20 has bricked my Wheel!  It's serial number v009, so maybe it's something in this early Wheel build. 
Situation is that the Wheel is powered-on but NOT responding to the power button, the lights are on, but the Wheel is locked (e.g. has a lot of resistance when attempting to turn it).

At the download stage, it stalled a couple times, and until finally successful; then during Upgrade, the status bar shows one or two pixels & repeats.

Only recourse is to open up the Wheel and disconnect power, otherwise it will drain the battery pack.

Goddamnit... Is the wheel still "blocked" without batteries connected (ie. did it fry your bridges)? I wonder whether KS tested upgrading from older versions than those released in last month(s) or something, as your app says current version is 1.07, and I've seen people here stating they have 1.13, 1.15, 1.18 etc. Either way, this shouldn't ever, ever happen...

The debacles with Ninebot and now this has seriously made me wonder whether upgradeable firmware is worth it.

[dside]

14 minutes ago, Jason McNeil said:

v1.20 has bricked my Wheel!  

That's really bad news

Makes me wonder if they ever changed their firmware testing protocols like they promised.

I guess i'm stuck with v1.15. No problems with that though.

[HEC]

13 minutes ago, esaj said:

 I wonder whether KS tested upgrading from older versions than those released in last month(s) or something, as your app says current version is 1.07, and I've seen people here stating they have 1.13, 1.15, 1.18 etc.

Was thinking exactly the same. Hopefully @Jason McNeil will manage to revive it. Are there any JTAG or other programming points or pins present?

[Hunka Hunka Burning Love]

I hope they have some routine to verify the checksum of the firmware downloaded and transferred to the wheel as it seems that almost every other hardware manufacturer recommends not flashing firmware wirelessly as it can be risky.  They should have some jumpers that will set the control board into automatic firmware reload mode where a recovery can be done easily from a micro SDcard slot on the board or through an USB port.  Or if BT is still functional, have a fallback check to allow a user to restore a previous firmware version of their choice.  A simple query in the app "Was the firmware flash successful?  Yes/No" then go into fallback mode if needed...

[esaj]

4 minutes ago, HunkaHunkaBurningLove said:

I hope they have some routine to verify the checksum of the firmware downloaded and transferred to the wheel as it seems that almost every other hardware manufacturer recommends not flashing firmware wirelessly as it can be risky.  They should have some jumpers that will set the control board into automatic firmware reload mode where a recovery can be done easily from a micro SDcard slot on the board or through an USB port.  Or if BT is still functional, have a fallback check to allow a user to restore a previous firmware version of their choice.  A simple query in the app "Was the firmware flash successful?  Yes/No" then go into fallback mode if needed...

At least their json-file describing the binary locations & versions doesn't contain any checksums. While many people believe otherwise, TCP can and will mangle packets from time to time in a way that WILL pass the lightweigth crc32-checksum built into TCP itself (although rare, but I have witnessed this first hand at work, both with HTTP & raw binary data transmitted over plain TCP). So the binary could first get corrupt even during download over the internet, and then again when it's being transferred to the wheel. Checksumming it would be very important before permanently writing it into the MCU flash / EEPROM / whatever it is.

I don't know how much RAM those STM32's or whatever they use have, so it could be an issue if they can't cram the entire firmware-binary into the memory at once for calculating checksum before burning it... But at the very least, the app itself should check it got an error free copy of the firmware before starting to send it to the wheel.

[Jason McNeil]

Power disconnected. When reconnecting there's no life from the board (no lights, welcome message). After 20 secs & replugging it in, the connector sparks, which you don't normally get on a functioning Wheel, unless you drain the capacitor by turning it on without the battery connected. Indicative that the board processor is doing something loopy...

23 hours ago, esaj said:

Goddamnit... Is the wheel still "blocked" without batteries connected (ie. did it fry your bridges)?

Spins freely now without power connect, code must lock Wheel before upgrading.

EDIT: Ignore the below advice, others are reporting v1.20 is a solid upgrade
<strike>YOU MIGHT WANT TO HOLD OFF ON THIS UPGRADE FOR NOW </strike> .

[Hunka Hunka Burning Love]

Yikes these firmware problems can be a disaster if the programming isn't implemented correctly or tested thoroughly.  Going back to the idea of becoming a distributor and selling a bunch of these KS16's - imagine if a large base of your clients flashed to the latest firmware and now want warranty coverage due to dead wheels... not something I would want to deal with.  How long do they beta test these new firmware releases before sending them out into the wild? 

I wonder if it would be wise to only release newer versions to small ranges of serial numbers over a period of a couple of weeks at a time to see how things go.  Have a group of local Shenzhen beta testers trial the firmware over a few weeks.  Maybe have the app send success/failure info back to their server... That way they could maybe limit the damage if any...  Or just have a built-in external media slot on the shell casing (USB/SDcard) for music play and firmware flashing rather than wireless flashing?

Regarding firmware flashing (and I'm no expert here by any means), I'd imagine for computers some do overwrite the original BIOS while loading, but for these wireless flashes, I would be surprised if they transferred from the app directly overwriting the master code as a simple wireless BT disconnect or power failure could brick everything.  I would hope they transfer it over BT to some NVRAM holding area after which it's checksum is verified before copying it over to the working location?  That way even with a power cut to the wheel, on next boot perhaps firmware corruption detection could reload it from the holding area?

[esaj]

I cooked up this in about an hour, so by no means "production level" design, but it shouldn't be that hard to implement a couple of fairly simple & straightforward checks into the app & bootloader in the MCU:

A simple state machine of downloading the firmware binary over the internet to the mobile / tablet / whatever. Some additional checks should be used to prevent endless loops, like retry counts; if for some reason for example after 5 tries the firmware binary still doesn't match the checksum from the JSON-file, abort and ask the user to retry later etc.

As for the actual firmware upload:

Simple sequence diagram of the steps of actual transmitting of the fimrware data to the wheel:

• First ask the device to prepare itself for the update
  • The device may respond with an error (like the wheel is moving; you don't want to update the firmware while riding ), after which the user should be (possibly) asked to do something, like STOP MOVING THE GODDAMN THING AROUND , or charge the battery first to prevent shutdown in middle of update or whatever
  • If everything's ok, the wheel should prepare itself for the update (stop the motor, disable power button etc) and then inform the app that it's ready to receive the data
• Assuming the device has reported that it's ready for the update, start chopping up the firmware data (THIS IS ONLY NECESSARY IF THE MCU CANNOT HOLD THE ENTIRE FIRMWARE BINARY IN MEMORY AT ONCE):
  • Take next N bytes from current offset (0 at the very first packet), assuming there are N bytes still available, calculate the checksum for those N bytes, create the message (an example of the messages are described below in this post) and send it to the wheel
    • The wheel receives the message, extracts the N bytes of the firmware data, calculates the checksum for those and then compares it to the checksum in the packet
      • If the checksum matches, the wheel writes the N bytes of firmware into Flash / EEPROM, and asks for next packet (if this wasn't the last packet)
      • If the checksum DOES NOT match, the wheel discards the data and asks the app to resend last packet (or optionally, data from offset X)
  • The above steps are repeated until the last bytes of the firmware have been sent
• After succesful firmware update, the wheel informs the app that it's complete and restarts itself

Very simple "pseudo" protocol for the messages:

 

App -> Device -message

|    1st byte    |  2nd & 3rd byte  |  N bytes  |        Last <X> bytes       |
-------------------------------------------------------------------------------
| Message id and |  Data length     |  Firmware |  Some checksum of firmware  |
| control bits   |                  |    data   |  data, byte amount depends  |
|                |                  |           |  on checksum type           |

Message id bits:

|    0-4     |        5        |      6 & 7      |
| Message id | last packet bit |  Unused for now |

First 5 bits store the message identifier (could use more or less, depending on how many different messages are needed):
0 = Prepare for update, expect either error or ready-message
1 = Firmware data packet, expect acknowledge or resend-request

5th bit (last packet bit) is set when the packet contains the last bytes of the firmware data

Here I've used the first 5 bits of the first byte in message to represent the message id as 5-bit integer. 5th bit has only meaning with firmware data, if it's 1, it means that the packet contains the last bytes of the firmware and after those are received & checked and written, the entire firmware binary has been transferred to the wheel. Any number of bits could be used for the message id, and the control bits could be "whatever is needed", carry bits could be used to have dynamic sizes for control bits etc. etc... Actual data size is 2 bytes (16 bits), so this could send a maximum of 65535 bytes of firmware data per packet. The actual data follows the data length, and after that, there's a constant amount of bytes that contain the checksum for the firmware data -portion.

It's really not hard to design & implement this type of basic binary-protocol stuff, if you put your mind to it (albeit it might be easy for me to say, as I've done projects involving binary protocols for living since 2009 or something ).

 

Device -> App -message
|    1st byte    |  2nd & 3rd byte  |     N bytes      |
--------------------------------------------------------
| Message id and |  Data length     |  Message related |
| control bits   |                  |       data       |

Message id bits:

|    0-4     |      5-7       |
| Message id | Unused for now |

First 5 bits store the message identifier (could use more or less, depending on how many different messages are needed):
0 = Ready for firmware data, data length = 0 (no message related data)
1 = Cannot start firmware update, data lenght = 1, message related data will contain error code (8 bits):
Error code 0: Motor is turning
Error code 1: Battery very low, danger of unit turning off during update
Error code n: other errors

2: Send next packet, data length = 0 or n, optionally message related data could contain the offset into the binary file
3: Request resend, data length = 0 or n, optionally message related data could contain the offset into the binary file
4: Firmware update complete, preparing to restart, data length = 0

The data packet structure which the wheel responds with. Again, any number of bits could be used for the message identifier and control bits etc. If you compare this to the sequence diagram above, it should be fairly straightforward to see how it works in general.

The idea is simply VERIFY all the data always before writing. Transmitting data over the air can be finicky at times, and you don't want a mangled up version of the firmware to enter the device, as even a single bit error can lead to a disaster. The above probably doesn't take into account a lot of things, but its purpose is simply to show that doing such verification isn't very hard.

The above design assumes that the MCU cannot hold the entire firmware binary in memory at once, and thus has to write it in pieces. The downside is that should the power be cut during the upload, you end up with a "partially written" firmware. If it could hold the entire binary in memory at once, only one message would be needed to send the entire binary + checksum, and the wheel could check that the data & checksum match, and then do the entire write at once (or ask the app to resend the file).

I've taken a peek at the binary-files the KS json-file points to, but likely they're just part of the puzzle (they cannot be directly disassembled). I suspect that like in Arduinos, there's a firmware bootloader written into the chip that's not included in the firmware binaries and not overwritten during the update-process, ie. the real entry point is outside those files. In that case, I'd expect that the firmware (if written "cleverly enough") could detect that the uploadable part of the firmware is corrupt (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).

[Hunka Hunka Burning Love]

They should put you on their payroll!    I bet though that they likely have some sort of checksum verification in place, or it would be a circus considering the number of people flashing wirelessly out there.  I wonder if the new firmware flash might not wipe out all the old code or reset some registers or something.  In any case it's a random guessing game we're playing.  What they should do is have like 5-10 test units from different production times.  Flash each one to different earlier firmware versions then flash directly to the latest firmware to see how jumping from v1.0whatever to v.latest works out.  Don't let the consumer be the guinea pigs and learn that oh no, if you have version 1.07, don't upgrade to version 1.20!

Also they should try interrupting the firmware upload to the wheel at random spots to see what happens.  Call the phone while it's uploading.  Interrupt the WiFi/BT and reconnect it.  Turn the phone off while it's sending the file.  Run a bunch of different apps (eg. screen recording app) while it's flashing.  There's got to be some more thorough testing to avoid killing off a wheel.

[esaj]

Took a quick peek at the newest KS-app; they're using CRC16-checksuming for the data & YModem (if you visited BBS's in the 90's, you should find that familiar ):

https://en.wikipedia.org/wiki/YMODEM

So it seems they have at least some checksuming happening (when writing the data to the wheel).

If you're interested, the actual update-logics are in com.kingsong.unicycle.SettingActivity. The HTTP-stuff downloading the file (without checksuming at least at first glance)  is in com.kingsong.unicycle.HardwareUpdateService.

[Chriull]

4 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).

That's a small step for a programmer, one giant leap for customers! (And all the bricked innocent motherboards...)

btw: i updated my ks16 from 1.13 to 1.20 - everything went fine (just the ks16 needed two restarts to show the new version...). I don't have any idea why i did this - maybe as a tribute to all the brave daring people who volunteered with updating their ninebot so others like me could savely upgrade...

This evening i already made a small test ride (~12km, in total 34m incline). Wanted to drive carefully  but with all the byciclists overtaking me it happened that i rode most of the time around my 30 km/h tiltback and hat nice accelerations from the traffic lights... ?

Also slow slalom driving through the pedestrian zone worked nice, too.

I could not see/feel any big difference to before - it was just safe stable and fun like before! I did not notice the slight "wobbles" while driving slalom - maybe one of the new firmware versions got rid of this, but it was just a short ride...

Lets see...

[Jeffrey Scott Will]

Hey guys, I started a KS16 firmware thread in the KS forum for easy reference to those who are looking to see which releases are safe to download. V 1.20 has been good for me so far, but mine is not an early serial # like Jason's. Disappointing to see KS following Ninebot's footsteps with bad firmware releases. 

 

[Jason McNeil]

Sorry for my reticence, trying to do a bit of project catch-up... 

 

Quick update: getting a replacement control-board from KS, but I think @Chriull is spot on (as usual). My Wheel was of the 16A variety, which for some reason, is completely incompatible with the 16B firmware... As of v1.20, KS removed the 16A update choice, probably because these are such a small handful of units out there. 

[Chriull]

34 minutes ago, Jason McNeil said:

Sorry for my reticence, trying to do a bit of project catch-up... 

 

Quick update: getting a replacement control-board from KS, but I think @Chriull is spot on (as usual). My Wheel was of the 16A variety, which for some reason, is completely incompatible with the 16B firmware... As of v1.20, KS removed the 16A update choice, probably because these are such a small handful of units out there. 

Also for the KS16B they removed the choice, but looking at http://apkdomain.duapp.com/kingsong/versions.json they have still different firmwares for the 16A, 16B and now a new 16C. So it seems they have automated the identification of the model and choice of firmware for it... So it could either be, that the 16A binars is broken, the automatismn failed or you had some unrecognized transmission error...

which firmware exactly was installed can be checked with the app under basic settings/version.

Would be nice if you now get a 16C motherboard (if it is interchangeable with the 16A/B modell) and/or get some info about the new features!

[esaj]

31 minutes ago, Chriull said:

Also for the KS16B they removed the choice, but looking at http://apkdomain.duapp.com/kingsong/versions.json they have still different firmwares for the 16A, 16B and now a new 16C. So it seems they have automated the identification of the model and choice of firmware for it...

It would seem that the app identifies the device type based on the Bluetooth-device name (or some other BT-data) of the wheel, and then compares that against the types listed in the JSON-file.

EDIT: Here's the relevant part parsing the type from device name:

                    (this.mDeviceNameString = new String(array, 2, n3)).trim();
                    if (this.mDeviceNameString.substring(0, 2).equals("KS")) {
                        this.isInvalidDevice = false;
                    }
                    else {
                        this.isInvalidDevice = true;
                    }
                    MainActivity.mUnicycleType = "";
                    final String[] split = this.mDeviceNameString.split("-");
                    for (int i = 0; i < split.length - 1; ++i) {
                        if (i != 0) {
                            MainActivity.mUnicycleType += "-";
                        }
                        MainActivity.mUnicycleType += split;
                    }

[fearedbliss]

On 4/8/2016 at 7:10 PM, Cloud said:

Wouldnt change a thing for me - i only ride above 50 C  

LOL

[Sawyer]

I was also in the situation that I thought I bricked the wheel months ago. I paniced how to shut off the non responding wheel! The rescue was: while it appeard dead in mostly all respects, the bluetooth connection and firmware-upload function (and only that) in the app still worked!  I was able to complete an upload and all went back to normal again.

[steve454]

On 4/8/2016 at 3:50 PM, Gunthor said:

My new Kingsong arrived today and I hate the noise (when reading this kindly remember that I am a Ninebot One owner...)!!!

1. Especially when riding around 15 Km/h there is a high pitched noise that is ringing in the ears. Always when getting close to people I wanted to hide like "I am not the one aggravating and molesting you with this tinnitus like sound emissions on purpose". I am afraid that the sound is created by the engine because the faster I ride the louder the nuisance. 
2. The new app crashes quite often.
3. Firmware update is inconsistent: I updated from version 1.13 to 1.16. After the update the display still shows current firmware version 1.13!!! OK - I switched Kingsong off and on again, restarted the app and then it displayed current firmware version 1.15 new firmware 1.16!!! I didn't monitor the update so I thought something went wrong and I missed an error message. So I repeated the steps and wanted to upgrade from 1.15 to 1.16. However, no error showed up and the current version is still 1.15. I think that there probably was a buggy 1.16 version that got replaced with the previous 1.15 version and I can most likely consider myself lucky to not have gotten the 1.16 version...
   The app does not offer a downgrade option - but this was to be anticipated.
4. The auxiliary button is for switching on and off Bluetooth - this is what the manual claims this button should do! First I thought this is a good thing because I rarely monitor my unicycle using the app while riding. However, when I switch off Bluetooth and turn on the EUC via the Power on button Bluetooth is switched on as well. So the use of the auxiliary button is reduced to switching the lights on and off and offering an alternative to switch on and off Bluetooth when the EUC is not moving. I would have preferred the opposite: Switching off Bluetooth when riding.
5. The fan of the control board The engine sounds like the ball bearings are already broken. Here is a sound sample:  Fan_of_the_control_board.mp3
   Update: Jason McNeil was correct on this one: The fan turns on at 50°C! The "broken ball bearings" sound is coming from the engine and are torque “bursts” causing minute flexings within the wheel resulting as audible “ticking” noise!!!
6. The pedals are very stiff. You feel like a jerk when struggling to get the pedals aligned to the case at the entrance of a shop with people watching you. Same thing when you take off: I liked to start riding with one foot on one of the pedals while nonchalantly pulling out the other pedal with the other foot. With Kingsong this is not possible. Starts and stops are clumsy.
7. Today I only rode about 6 Km and must say that the Kingsong didn't always react as I expected. It seems to be balanced differently compared to the Ninebot One - but I think this is something I will get used to (see also point 4 of the good things).
8. The manual is a good laugh: It says "Do not ride in [...] wet conditions" and later on "Don't store the unicycle in dry condition". Some sentences need to be read twice in order to be understood. But Pidgin-English is a minor flaw...
9. The app displays a loudspeaker icon on the first screen that appears when starting the app. However I can neither turn off the beeps nor adjust the sound level. The Kingsong only beeps when clicking on it.
10. Update: The side LEDs can't be turned off and you cannot choose any other pattern - there is only one default.
11. Update: The odometer is working incorrectly. When I got the Kingsong, the odometer of the app displayed 96 Km. Then I made three trips: 6 Km, then 34 Km and then 52 Km. So guess what the total odometer displays now... 188 Km? No! It shows 116 Km!!! Now if 20 Km on the odometer equal real 92 Km then others have driven my "new" Kingsong EUC for (92 x 96 / 20 = ) 442 Km before it was sent to me!!! Now I wonder if I got a refurbished test EUC?!? 
    The day following the odometer was working correctly and showed 166 Km at the end of the day. The day after the odometer displayed only 81 Km!!!  Now this needs to be remedied quickly, because owners of this wheel need to correctly state the Km driven when reselling the wheel (also updating to firmware 1.16 does not do the trick)
12. Update: The "Play" mode is not as rock solid as the 9b1. While riding the wheel the pedals gently wobble back and forth a little. This not disturbing but doesn't create the confidence the 9b1 can offer.

I invite users who already experienced the Kingsong KS-16A to share their first impressions as well. My highest concern is the ringing noise while riding. This is driving me nuts...

Oh - I nearly forgot: The good thing about this wheel is

1. You can drive circles single legged in both directions without hearing any scraping sounds. My Ninebot One needed a washer - the Kingsong seems to be well built.
2. Update: The position of the pedals is very good: With 9b1 the blood circulation within my feet was an issue after 1 1/2 to 2 hours ride. With the Kingsong I can drive 3 hours in one go without this issue.
3. Update: When riding with business shoes the rubber surface of the pedals offer fantastic grip - also when it's raining! On the 9b1 this always felt slippy.
4. Update: The engine power is great and driving with 22-25 Km/h is really wonderful.
5. Update: With two battery packs the KS16 is balanced more evenly compared to the 9b1. So 9b1 riders that got used to work against the inferior 9b1 balance (only 1 battery pack on one side) finally (need to) learn how to ride properly when switching to Kingsong. This is irritating at the start but pays off when riding with higher speeds.
6. Update: The tyre can easily be inflated because the valve is accessible (no obstruction).
7. Update: Easier cleaning beneath the handle (can be pulled up) and  at the wheel and rim.
8. Update: This is an obvious one and the reason I bought the wheel. With 800 Watt you have a lot more power in reserve. I got used to driving the 9b1 at its limit so there is nearly no reserve in risky situations resulting in tense and dangerous driving behavior! With the KS16 you have enough power between you feet and riding it is pure joy (if there wouldn't be this high pitched whining noise...).
9. Update: The integrated retractable trolley bar comes in handy when visiting mid-sized shops: Within huge building supplies stores I still love to use the EUC in order to get to the far away shelves quicker. I never carry the EUC into tiny shops like bakeries and leave it outside leaning it against the wall. However mid-sized shops always have been a problem because using the EUC there feels awkward (because of the small aisles and many people) and carrying it is a burden. So the option having a trolley bar to push the EUC around is a solution I like very much. Also I got stopped once by our factory security officer asking me not to use the EUC after passing the turnstile and being on the factory ground. The building I work in is far away from the turnstile so here again the retractable trolley bar is a wonderful solution. Nevertheless I'd like to mention that the trolley bar is not high enough when traveling on another EUC and transferring the KS16 by simply holding the extended handle in one of your hands (I had a strenuous 18 Km ride).

 

I agree that the Kingsong apparently has a better battery, however the NB1 is good, I feel safe on it.  However 

[Gunthor]

Yesterday the weather forced a heavy duty waterproof check on my KS16:

Rain clouds approached when I was still approximately 18 Km away from home within an integral nature reserve. The next shelter was about 10 Km away. Of course it started raining before reaching the shelter. Sorry - did I say "raining"? It poured down buckets of water: After only ~20 seconds I was soaked (no raincoat)! It was a funny feeling when the water was running down my body (I wore long legged jeans and a long sleeved T-Shirt) flooding my shoes. It was like standing under a full tilt huge raindance shower - the rain was even running down my balls - water was everywhere. 

After reaching shelter I took off my T-shirt and squeezed out a liter of water - so it seemed... and waited 20 minutes until thunder and lightning had moved on. Then it was only raining moderately and I continued my journey home. On my way I had to cross two puddles - at least this was what I thought they were and I anticipated the depth of those puddles to maybe 10 cm so I drove into them...

...but holy smoke my feet signaled pretty soon that my entire shoes had submerged into the "puddle" even before reaching the middle of it (The "puddle" was ~ 11 meter long and covered the entire width of the bicycle road and even more!). Only then I dismounted, switched the KS16 off and lifted it out of the water (I''m pretty sure the loudspeaker openings got submerged temporarily). I waded through this "puddle" and the water nearly reached my knees (so the depth was ~ 40cm)! Then I put down the KS16, switched it on again and was able to continue my journey. I had to cross one more of those "puddles" but this I did carrying the KS16 from the very start - because the previous experience had made me smart. 

I don't recommend imitating this experience but thought I share it - so you know the KS16 should continue to function when getting contact with water. Unfortunately the pedals are missing a drainage so all the water under the rubber material will only flow out slowly when parking wheel and pedals upright. 

[August Y]

7 hours ago, Gunthor said:

Yesterday the weather forced a heavy duty waterproof check on my KS16:

Rain clouds approached when I was still approximately 18 Km away from home within an integral nature reserve. The next shelter was about 10 Km away. Of course it started raining before reaching the shelter. Sorry - did I say "raining"? It poured down buckets of water: After only ~20 seconds I was soaked (no raincoat)! It was a funny feeling when the water was running down my body (I wore long legged jeans and a long sleeved T-Shirt) flooding my shoes. It was like standing under a full tilt huge raindance shower - the rain was even running down my balls - water was everywhere. 

After reaching shelter I took off my T-shirt and squeezed out a liter of water - so it seemed... and waited 20 minutes until thunder and lightning had moved on. Then it was only raining moderately and I continued my journey home. On my way I had to cross two puddles - at least this was what I thought they were and I anticipated the depth of those puddles to maybe 10 cm so I drove into them...

...but holy smoke my feet signaled pretty soon that my entire shoes had submerged into the "puddle" even before reaching the middle of it (The "puddle" was ~ 11 meter long and covered the entire width of the bicycle road and even more!). Only then I dismounted, switched the KS16 off and lifted it out of the water (I''m pretty sure the loudspeaker openings got submerged temporarily). I waded through this "puddle" and the water nearly reached my knees (so the depth was ~ 40cm)! Then I put down the KS16, switched it on again and was able to continue my journey. I had to cross one more of those "puddles" but this I did carrying the KS16 from the very start - because the previous experience had made me smart. 

I don't recommend imitating this experience but thought I share it - so you know the KS16 should continue to function when getting contact with water. Unfortunately the pedals are missing a drainage so all the water under the rubber material will only flow out slowly when parking wheel and pedals upright. 

Is it still working today :D?