KS16s firmware feedback v1.00

[Fitz0uille]

Hi everyone, 

Do you have any feed back in KS16S 1.00 Firmware. I guess @Jack Frost could have a good echange with Tina based on this thread 

Here is a "few" of mine :

o    Smooth ride but not constant.

§  When you take short turn your pedals up (Sometime in an impressive way) but when you take a long one they still dive in (A very little but you can feel it)

o    Alert don't adapt.

§  Settings : Alert 3 : 30 ; TB 31

§  Battery : <30% TB down to 28 but alert still at 30

§  I guess it's the same when you climb

o    Hello Kingsong

§  So great, he isn't loud 

o    Odometer

§  Seems correct now (No communication on this important feature, it's wired)

§  Didn't check for speed, check only on total KM

o    Curent mileage

§  don't reset rigth after your turn off your wheel (A manual reset could be better :))

o    Bluetooth button

§  Don't work proprely

§  Turn on : bluetooth ON

§  Turn off : Still ON

§  Now, my "Kingsong music is ALAWYS ON (Except if i turn of my wheel)

 

[abinder3]

Oh yea; Tina is no longer at King Song.

[HermanTheGerman]

4 hours ago, abinder3 said:

Oh yea; Tina is no longer at King Song.

A bad sign, if somebody so cooperative and communicative leaves or must leave.

I'll watch KS16S reports closely for some months before I change my current wheel, and will also watch the development of the company during this time.

[Lukasz]

AFAIK there were some not-exactly-business-related reasons for Tina to stop working, so rather not a "bad sign" hopefully.

However communication, or in fact understanding of problems explanations and responsiveness on the KS side is a quite big issue.

 

[US69]

i would also say:

interpretation of Tina leaving has nothing of "a bad sign"..... its china...get a better job? bye bye...

 

KS16S: from the direction KS is doing changes...i think they are going all for safety and reliability and not going the crazy speed competition!

Super good Mosfets...thicker wires...second capacitor...better cooling abilities...in a very well designed and quality workmanship way!

If just the KS16S would also have some more capacity (like 16s6p instead 4p for example)......it definitely would be my next wheel!

[Lukasz]

I look forward to check myself... I have pre-ordered KS16S, they have to arrive by boat so 6-8 weeks from now...  I hope that by that time we will be able to count on the updated firmware, and maybe (hopefully) better connecting android application. For me KS16S seems to be perfectly balanced for my type of use (mostly city rides), and my current KS16 with 680Wh battery offer more than enough range - I rarely make more than 30-40 km per day so on the daily basis I charge it to 90% using charge doctor, and usually end the trip with more than 30% left, so 840Wh would be also enough, with 1200W motor offering additional acceleration and the safety margin. I have made a few 50 km trips, but this is in most cases not that much fan any more when you reach such distances - starting to get bored / tired. 

@KingSong69 - would You like 16s6p for more current, or still extended range?  What kind of trip lengths You aim for? 

 

[US69]

8 hours ago, Lukasz said:

I look forward to check myself... I have pre-ordered KS16S, they have to arrive by boat so 6-8 weeks from now...  I hope that by that time we will be able to count on the updated firmware, and maybe (hopefully) better connecting android application. For me KS16S seems to be perfectly balanced for my type of use (mostly city rides), and my current KS16 with 680Wh battery offer more than enough range - I rarely make more than 30-40 km per day so on the daily basis I charge it to 90% using charge doctor, and usually end the trip with more than 30% left, so 840Wh would be also enough, with 1200W motor offering additional acceleration and the safety margin. I have made a few 50 km trips, but this is in most cases not that much fan any more when you reach such distances - starting to get bored / tired. 

@KingSong69 - would You like 16s6p for more current, or still extended range?  What kind of trip lengths You aim for? 

 

A bit of both...For more security, less voltdrop, less Batterie stress...but mostly for more range and that i dont Need to Charge every evening!

I did not Charge my wheels above 85-90%(100% about all 10-20 charges for balancing) and i never go under 30-40%...if not needed for the last mile.

I have a 1360wh(8p) wheel and a 1160wh(6p) wheel .....and yes that's enough, but with less i would not be very happy :-)

 

Aaah...and btw:

With my 1200W or 1500W wheels i am very near to need/use 20wh for 1km....so lets say using 50%batterie (85%->35%) of a 1160wh wheel= 580wh= 29km....

[Lukasz]

I fully understand Your approach...  but more battery cells means more weight, so less portability.   For two days of ride from one charge.. hmm,  this will have to wait for the next generation of batteries in order not to have range anxiety in the second day ...  Elon Musk in on our side here...  I am not sure if Tesla is going to release 2170 cells soon to the open public, but maybe Panasonic will make 2070 cells available soon, so - maybe in 1-2 years..  Capacity is increasing 8-10% per year - maybe use of graphen will allow to jump...  

Anyway - we live in the interesting times..

[Christoph Zens]

Back on topic, firmware issues found in current KS16-S firmware (1.0), I think I got one:

• Reporting of braking current (negative values) does not work. The wheel seems to report 70A (some kind of maximum value apparently), instead of a useful negative value. Don't know if KingSong is able to do this correctly on other wheels, but my NB1 correctly reports negative current during braking.

Since both the KS app and WheelLog consistently show 70A during any kind of deceleration, I assume it's a problem in the wheel firmware rather than the two apps. Maybe @esaj or someone else already riding the KS16-S can confirm this bug? I was a little worried when I first saw these numbers, but quickly found out it must be garbage. It doesn't change with soft or hard braking either...

On a slightly different note, my wheel came with a 40A spare fuse, even though these wheels are supposed to have 2x30A fuses. Strange.

[esaj]

1 hour ago, Christoph Zens said:

Back on topic, firmware issues found in current KS16-S firmware (1.0), I think I got one:

• Reporting of braking current (negative values) does not work. The wheel seems to report 70A (some kind of maximum value apparently), instead of a useful negative value. Don't know if KingSong is able to do this correctly on other wheels, but my NB1 correctly reports negative current during braking.

Since both the KS app and WheelLog consistently show 70A during any kind of deceleration, I assume it's a problem in the wheel firmware rather than the two apps. Maybe @esaj or someone else already riding the KS16-S can confirm this bug? I was a little worried when I first saw these numbers, but quickly found out it must be garbage. It doesn't change with soft or hard braking either...

On a slightly different note, my wheel came with a 40A spare fuse, even though these wheels are supposed to have 2x30A fuses. Strange.

This may not be the case (although it could be). A quick decompilation of the app shows that the value is being read as 16-bit integer, no Math.abs() or such:

this.current = (byteArrayInt2(paramArrayOfByte[10], paramArrayOfByte[11]) / 100.0F);

BUT, the devil is in the details:

  private int byteArrayInt2(byte paramByte1, byte paramByte2)
  {
    return (paramByte1 & 0xFF) + (paramByte2 & 0xFF) * 256;
  }

Seems harmless, right? And Java uses signed values, so it would seem the value is sent as positive... Except, in this case, the binary operators come into play. ANDing with 0xFF actually promotes the paramByteX to an int, then strips off everything except the lowest 8 bits. Since it's a full 32-bit int, the sign-bit is in the MSB, which is always 0 in this case, meaning that any sign in the original value is lost. Whether this is actually meant to be, I don't know, it could still be that the board always sends the value as positive. Maybe this will be clearer to understand what I mean:

    private static int byteArrayInt2(byte paramByte1, byte paramByte2)
    {
        return (paramByte1 & 0xFF) + (paramByte2 & 0xFF) * 256;
    }
    
    public static void main(String[] args)
    {
        int val = byteArrayInt2((byte)1, (byte)0);
        System.out.println("0x0001 = " + val);
        
        val = byteArrayInt2((byte)0, (byte)-1);
        System.out.println("0xFF00 = " + val);
        
        val = byteArrayInt2((byte)127, (byte)127);
        System.out.println("0x7F7F = " + val);

        val = byteArrayInt2((byte)-1, (byte)127);
        System.out.println("0x7FFF = " + val);
        
        val = byteArrayInt2((byte)-128, (byte)-128);
        System.out.println("0x8080 = " + val);        
    }

OUTPUT:

0x0001 = 1
0xFF00 = 65280
0x7F7F = 32639
0x7FFF = 32767
0x8080 = 32896

The point is, with the way byteArrayInt2 is written, it will never return negative values, even if the original data was meant as such (signed value, MSB as sign bit). Whether the value is capped elsewhere in the app (the actual current is the value divided by 100.0f, so if there's a sign-bit, and it's capped at 70A, it will always show the maximum value if the sign-bit is set, or whenever the final value is more than 7000), I didn't check. It might still also actually be that the mainboard doesn't send signed values, and instead sends 7000 (divided by 100.0f, that makes it 70). I'd need to take a data capture from actual braking situation to see the original data.

Wheellog has probably just copied the value calculation straight from the King Song app, so it behaves the same.

[Christoph Zens]

23 minutes ago, esaj said:

  private int byteArrayInt2(byte paramByte1, byte paramByte2)
  {
    return (paramByte1 & 0xFF) + (paramByte2 & 0xFF) * 256;
  }

Yes, this is never going to yield any negative value. So, it may be the app after all...

This would mean that braking current is not reported correctly on any KingSong wheel and no one cares about it? Hard to believe, since this bug ruins every single wheel log (of battery current) by adding 70A spikes all over the place. Check it out for yourself, it's unusable the way it is right now.

Once your health is restored, could you try the other wheel you recently got and see if the bug exists there as well? Thanks!

In any case, I entered a feedback message on the KingSong website. Let's see if someone actually cares to respond.

[Chriull]

2 hours ago, Christoph Zens said:

• ...Reporting of braking current (negative values) does not work. The wheel seems to report 70A (some kind of maximum value apparently), instead of a useful negative value. Don't know if KingSong is able to do this correctly on other wheels, but my NB1 correctly reports negative current during braking.

Since both the KS app and WheelLog consistently show 70A during any kind of deceleration, I assume it's a problem in the wheel firmware rather than the two apps.

...

 

1 hour ago, esaj said:

...The point is, with the way byteArrayInt2 is written, it will never return negative values, even if the original data was meant as such (signed value, MSB as sign bit). Whether the value is capped elsewhere in the app (the actual current is the value divided by 100.0f, so if there's a sign-bit, and it's capped at 70A, it will always show the maximum value if the sign-bit is set, or whenever the final value is more than 7000), I didn't check. It might still also actually be that the mainboard doesn't send signed values, and instead sends 7000 (divided by 100.0f, that makes it 70). I'd need to take a data capture from actual braking situation to see the original data.

Wheellog has probably just copied the value calculation straight from the King Song app, so it behaves the same.

Seems like they changed the way current data is sent from KS16S/B/C to KS16S firmware - with GyroMetrics (iphone) from @Paco Gorina and my KS16C i got the following for rocking the wheel gently back and forth:

Values for speed and current where just positive sane numbers - so the way wheellog and the KS App processes the data should not make any difference.

As Gyrometrics originated for Ninebot with negative values it could be that with this iphone app the values are treated correctly and show now negative Values?!

[Rehab1]

1 hour ago, Christoph Zens said:

Once your health is restored, could you try the other wheel you recently got and see if the bug exists there as well? Thanks!

@esaj are you Ok?

[esaj]

5 minutes ago, Rehab1 said:

@esaj are you Ok?

Yeah, it's just a flu and mild fever, but I'm taking it easy and not riding until it has passed. Just blowing my nose every 10 minutes   Took the day off today.

[Rehab1]

12 minutes ago, esaj said:

Yeah, it's just a flu and mild fever, but I'm taking it easy and not riding until it has passed. Just blowing my nose every 10 minutes   Took the day off today.

Relief! I had envisioned an accident on one of your new wheels and you broke something!

[Christoph Zens]

6 hours ago, Chriull said:

 

Seems like they changed the way current data is sent from KS16S/B/C to KS16S firmware - with GyroMetrics (iphone) from @Paco Gorina and my KS16C i got the following for rocking the wheel gently back and forth:

Values for speed and current where just positive sane numbers - so the way wheellog and the KS App processes the data should not make any difference.

As Gyrometrics originated for Ninebot with negative values it could be that with this iphone app the values are treated correctly and show now negative Values?!

OK, so they usually just ignored current direction and only reported the absolute value. That explains the way they constructed an integer value from two bytes of the byte array. But if they changed the S firmware to be able to also report negative current, like the NB, they'll need to fix the app to actually support it.

Here is what I get on the KS16-S driving figure 8 in the garage:

[Chriull]

3 hours ago, Christoph Zens said:

OK, so they usually just ignored current direction and only reported the absolute value. That explains the way they constructed an integer value from two bytes of the byte array. But if they changed the S firmware to be able to also report negative current, like the NB, they'll need to fix the app to actually support it.

Here is what I get on the KS16-S driving figure 8 in the garage:

Great that ks now has a current direction -   Looks exxactly liike a signed value handled as unsigned as @esaj supposed before. Does it show the same behaviour wirh negative speed?

have to test if this also changed with fw 1.25 for the normal ks16