!!! Firmware or hardware problems with KS18L, wheels locking up while trolleying

[ricqvo]

10 minutes ago, esaj said:

What nte suggested about the unboxing procedure doesn't sound like a bad idea to me:

 

Trolley for 30+ minutes sounds like hell for me

[esaj]

2 minutes ago, ricqvo said:

Trolley for 30+ minutes sounds like hell for me

It's your call. So far it seems the issue isn't very common to occur (although we have no idea how many 18L's have been shipped, less than ten reports known to date), so it might be rare.

[ricqvo]

1 minute ago, esaj said:

It's your call. So far it seems the issue isn't very common to occur (although we have no idea how many 18L's have been shipped, less than ten reports known to date), so it might be rare.

I hope it is rare... And I wont be the "lucky" rare hunter one.

[Shad0z]

On ‎7‎/‎7‎/‎2018 at 10:24 AM, US69 said:

@esaj

The frying boards on the 18L where related to a problem with the LED lightring...a firmware problem, not app specified!

In seldom situation a Lightring pattern might bring the board into a loop...get stuck, overheating and frying because of this! So yes, even if the Leds where not working...this IS the problem...KS was able to reproduce the fault at their factory!

3 days after this issue was reported KS brought out FW 1.07 which fixed the issue!!!

Then they didnt take it down again....it was just that the server not working for ONE Night!

So everyone shoulf be able to update to 1.07 now again (KS18L)! 

The IOS version of app, which still shows the 18L as illegal equipment, is in the works and will be relaesed next week, if all is running fine.

 

I was in constant contact with @tinawong and some asian resellers, so this info should be uptodate and reliable!

Sure, this firmware glitch should have never happen...but in my personal view KS has done a good job with 3 days react time to solve the issue! My 2 cents

wow the ks18L had been a bumpy release :/ 

[syrupnew]

On-the-sidewalk disassembly of a locked 18L by Russian guys:

 

Edited July 21, 2018 by syrupnew

[Beowolve]

It doesn't look to be a rare case, considering that not every insitent will be reported. This sounds very concerning to me.

If I would own one of this expensive wheels I would consider a small mod to it.

How about adding a killswitch, so you guys don't need to disassemble the unit. I am thinking about using 2 high current mini relays (50A+ / 110v+) that can cut the power of both battery packs from outside. The relays wouldn't need any power to make it work if you use a "opener" or switch type, that means the relay switches to open state if you apply power to the primary side.

You could just drill a small hole (maybe hidden below the sidepads) for the primary side cable accessible from outside with a simple small plug attached.
If  that problem happens again, all you need is a 12V battery (most relays use that voltage) with the correct plug attached. Connect the battery and your wheel is safe.

[Lutalo]

On 7/20/2018 at 6:11 PM, esaj said:

I can not shrug and say, "well, it seems like a minor issue touching a minority of shipped wheels, let's just forget about it, most people shouldn't ever encounter it, and at least mostly it seems they can get away just with disconnecting and reconnecting the batteries". It's about neutrality, at least some form of objectiveness (no person is truly totally objective ever,

I would like to offer the perspective of someone still awaiting the arrival of an 18L shipment. I am very grateful to those like @esaj who have reported incidents to objectively raise awareness about potential problems with a wheel. Reporting issues on the forum has spread relevant information about some challenges buyers might face.

On the other hand, I think that @US69 is correct to call for some sort of sanity in the manner that problems are reported. Following organized incident procedures enables the manufacturer to efficiently collect the data necessary to reproduce the fault. Since reproducing the fault is the best way to find a permanent solution, it is in everyone's best interest.

I think the fact that KS has been responsive to the reported problems is the best indicator of how they would respond to problems of all levels of severity; they have certainly been responsive to every issue that I have had including skype phone conversations with @Flora Yuan. Furthermore, @Jason McNeil has never failed to return a phone call; this is a feat I imagine is not easy, especially when buyers are eagerly awaiting new wheel shipments. So, for me history sets the best precedent and is the best predictor of future behavior.

As one who has purchased an 18L I want to know the problems, how they are addressed, and efficient solutions; not a cacophony of uninformed opinions that ultimately only add to confusion no matter how well-intentioned. For that to happen requires a bit of a commitment and obvious support from the forum users; IMHO.

 

Edited July 22, 2018 by Lutalo

[ricqvo]

6 hours ago, Lutalo said:

I would like to offer the perspective of someone still awaiting the arrival of an 18L shipment. I am very grateful to those like @esaj who have reported incidents to objectively raise awareness about potential problems with a wheel. Reporting issues on the forum has spread relevant information about some challenges buyers might face.

On the other hand, I think that @US69 is correct to call for some sort of sanity in the manner that problems are reported. Following organized incident procedures enables the manufacturer to efficiently collect the data necessary to reproduce the fault. Since reproducing the fault is the best way to find a permanent solution, it is in everyone's best interest.

I think the fact that KS has been responsive to the reported problems is the best indicator of how they would respond to problems of all levels of severity; they have certainly been responsive to every issue that I have had including skype phone conversations with @Flora Yuan. Furthermore, @Jason McNeil has never failed to return a phone call; this is a feat I imagine is not easy, especially when buyers are eagerly awaiting new wheel shipments. So, for me history sets the best precedent and is the best predictor of future behavior.

As one who has purchased an 18L I want to know the problems, how they are addressed, and efficient solutions; not a cacophony of uninformed opinions that ultimately only add to confusion no matter how well-intentioned. For that to happen requires a bit of a commitment and obvious support from the forum users; IMHO.

 

I am waiting for my 18L next week to come.... I read everything I see about 18L on the forum.... I think it is great to share issues... Now, when my wheel will come, I will be ready for problems like blocking while trolleying...

[esaj]

On 7/21/2018 at 11:37 AM, Beowolve said:

It doesn't look to be a rare case, considering that not every insitent will be reported. This sounds very concerning to me.

If I would own one of this expensive wheels I would consider a small mod to it.

How about adding a killswitch, so you guys don't need to disassemble the unit. I am thinking about using 2 high current mini relays (50A+ / 110v+) that can cut the power of both battery packs from outside. The relays wouldn't need any power to make it work if you use a "opener" or switch type, that means the relay switches to open state if you apply power to the primary side.

You could just drill a small hole (maybe hidden below the sidepads) for the primary side cable accessible from outside with a simple small plug attached.
If  that problem happens again, all you need is a 12V battery (most relays use that voltage) with the correct plug attached. Connect the battery and your wheel is safe.

Could work, but I'd be worried that the contacts of the relay could momentarily break open during a bump or such, but maybe there are relays which have very high force keeping the contacts together when they're closed... Another slight issue is having to carry a battery with you so you can actually open the relay if need be. But yeah, still easier than starting to dismantle the wheel to be able to disconnect the battery connectors.

Another earlier idea that I first dismissed was the "kill switch", because no normal switch could withstand currents in tens or 100+ amps, but upon further thought, that might actually be a good idea if it can be integrated with the BMSs. Probably they won't have such option out-of-the-box, but just looking at this:

This is just some general BMS-chip example, could be different for different BMSs, but I'd believe similar schemes for cutting power are used in most.

There are N-type mosfets for protection near the PACK- (could be multiple in parallel for the high current packs), it should be enough just to get them shutdown. N-channel (enhancement-type to be exact) turns off if the gate voltage drops to low enough value,  in comparison to source (marked V_GS in the datasheets), the thresholds are usually 2..4V, fully open somewhere around 7...10V for non-logic level fets, logic level mosfets use lower voltages, as they're meant to be controlled from 5V or 3.3V low voltage digital circuits.

There are resistors marked R_GS going from the gates to sources of the mosfets. These are there to keep the gates referenced to sources and to discharge the gates when the outputs from CHG and/or DSG go low (or high impedance, or floating, no idea of the operation without datasheet), so that the gate voltage drops to same level as source (V_GS = 0V).

Bypassing the R_GS's with the switch (do also note that in the picture I used as an example, the R_GS's go to different sides, as the mosfets are arranged in opposite directions, probably for reverse polarity protection, so you'd need a switch with 2-pole/2-throw 2P2T configuration), the gates would be directly connected to sources, dropping the voltage difference between them to 0V. But of course it's a bit risky to start opening up your packs and soldering wires there..    Also, no idea how much current the CHG & DSG -pins are capable of providing, when the R_GS's aren't "there" anymore (bypassed by the switch), they might have to output a lot more current continuously as they're trying to keep the fets open, which might heat the chip or even damage the IO's, depending on the values of R_DSG & R_CHG.

And, let's also mention that I don't suggest anyone really trying this unless they know what they're doing... it's just the general idea how one could possibly implement a "kill switch" in batteries.

Edited July 22, 2018 by esaj

[ygsoft]

I disabled the sensor in the application on the smartphone. In addition, I detached the wires from the sensor inside the mono-wheel. Within a week, I used the wheel in this form. I also wheeled the wheel by the handle for a distance of 200-300 meters. During this time, the problem of jamming on my wheel was not repeated.
On my wheel, the lock once occurred when the sensor was turned on. After switching off the sensor, this has not happened yet. I think that there is reason to think that the problem really can be related to the lift sensor. Although it is still possible that this is just a coincidence and there is no connection.

[Stan Onymous]

8 minutes ago, ygsoft said:

I disabled the sensor in the application on the smartphone. In addition, I detached the wires from the sensor inside the mono-wheel. Within a week, I used the wheel in this form. I also wheeled the wheel by the handle for a distance of 200-300 meters. During this time, the problem of jamming on my wheel was not repeated.
On my wheel, the lock once occurred when the sensor was turned on. After switching off the sensor, this has not happened yet. I think that there is reason to think that the problem really can be related to the lift sensor. Although it is still possible that this is just a coincidence and there is no connection.

Great example causation and correlation without identifying either. Perfect analysis of the situation! Kudos for the info and tactic to disable the fault. 

[US69]

On 7/21/2018 at 10:37 AM, Beowolve said:

doesn't look to be a rare case, considering that not every insitent will be reported. 

I have a little bit other view here.

When you have a new wheel which locks up when trolleying, starting to overheat, and if you do nothing against it , it will/might even fry your board,  you will for sure report this incident....as you want warranty for it, or?

From what i know, nearly every case has been reported here, or over other social Media channels AND over the reseller. all this cases have been than reported by me, and or the owner AND the reseller to KS company.

When Tina from Kingsong and i compared our reports....there was only one or two that i/we couldnt connect to the resellers report, or lets say to the country they come from. Also the complete Singapur/Thailand wheels (in complete ober 30) have been without any incidents and/or happenings....No LED ring fries before 1.07...no wheel locks with 1.07.

That gets me to the personal opinion that it is still a „rare“ case ....as said worldwide we are at about 7-8 to this „trolley and lock“ cases.

Again, thats no downplaying of the isssue.....that are exact this 7-8 to much!

There are signs that its in fact related to the sensor, so to put it off i general is a good idea, which i promoted to all my known sellers, friends, here in the forum and so on..   

I hope in the new week a solution will be found.....

Edited July 22, 2018 by US69

[LILLO]

On ‎7‎/‎17‎/‎2018 at 2:02 AM, eddiemoy said:

It is personal communication from vendor to one person in our group that had the issue.  Think there was one other person in our group that had the issue.

thanks!!!

[TomOnWheels]

On 7/20/2018 at 10:48 PM, esaj said:

This is why I was wondering how they even measure it... for a "normal" operating system scheduler, it's far more trivial to calculate the free "time slots"/processes waiting for CPU time, but what do you do with a real-time system? All I could think of was that they've set a hard limit (1ms, 100µs or whatever, "real-time hard agent" or whatever the correct technical term is, with a strict time limit, vs. a "soft agent" which has some target time, but no actual "penalty" for missing it) for a single main loop, and compare how much time is left "free" at the end of it. If the processing would fall back a lot while driving the motor, that would be a bad thing (it could start missing phase changes for the motor or dropping dead-time insertions to too low, causing a bridge shoot-through), but I'd hope they'd dealt with this "intelligently" (ie. all the critical functions are interrupt timer based and the rest can fall behind / be skipped if need be). Not that I've ever really worked with any time-critical embedded systems, my background's in "traditional" software running on top of OS's.

Well, the main issue is that we don't know how KS firmware is build... In RTS all is predictable. So it seems quite ok to say that your cpu is 80% busy because then there is simply 20% of space to add some extra tasks and anyway it will remain stable. Of course KS will never tell you how their firmware works... Even if there are interruptions involved they also must be quantifiable and predictable on CPU time... All that are only what I suppose... I was just saying that 80% in a RTS is something quite normal... I've seen some systems doing 98% permanently...

[TomOnWheels]

12 hours ago, esaj said:

Could work, but I'd be worried that the contacts of the relay could momentarily break open during a bump or such, but maybe there are relays which have very high force keeping the contacts together when they're closed... Another slight issue is having to carry a battery with you so you can actually open the relay if need be. But yeah, still easier than starting to dismantle the wheel to be able to disconnect the battery connectors.

Another earlier idea that I first dismissed was the "kill switch", because no normal switch could withstand currents in tens or 100+ amps, but upon further thought, that might actually be a good idea if it can be integrated with the BMSs. Probably they won't have such option out-of-the-box, but just looking at this:

This is just some general BMS-chip example, could be different for different BMSs, but I'd believe similar schemes for cutting power are used in most.

There are N-type mosfets for protection near the PACK- (could be multiple in parallel for the high current packs), it should be enough just to get them shutdown. N-channel (enhancement-type to be exact) turns off if the gate voltage drops to low enough value,  in comparison to source (marked V_GS in the datasheets), the thresholds are usually 2..4V, fully open somewhere around 7...10V for non-logic level fets, logic level mosfets use lower voltages, as they're meant to be controlled from 5V or 3.3V low voltage digital circuits.

There are resistors marked R_GS going from the gates to sources of the mosfets. These are there to keep the gates referenced to sources and to discharge the gates when the outputs from CHG and/or DSG go low (or high impedance, or floating, no idea of the operation without datasheet), so that the gate voltage drops to same level as source (V_GS = 0V).

Bypassing the R_GS's with the switch (do also note that in the picture I used as an example, the R_GS's go to different sides, as the mosfets are arranged in opposite directions, probably for reverse polarity protection, so you'd need a switch with 2-pole/2-throw 2P2T configuration), the gates would be directly connected to sources, dropping the voltage difference between them to 0V. But of course it's a bit risky to start opening up your packs and soldering wires there..    Also, no idea how much current the CHG & DSG -pins are capable of providing, when the R_GS's aren't "there" anymore (bypassed by the switch), they might have to output a lot more current continuously as they're trying to keep the fets open, which might heat the chip or even damage the IO's, depending on the values of R_DSG & R_CHG.

And, let's also mention that I don't suggest anyone really trying this unless they know what they're doing... it's just the general idea how one could possibly implement a "kill switch" in batteries.

Seriously, I really like your posts ! They are really interesting from technical point of view ! It's a pleasure to see that actually they are some people around who at last have the knowledge to understand what they are talking about...

[Possejdawg]

Better solution is putting a small switch at vdd to disable to bms. The anti series diodes and mosfets will naturally block the flow of current in the example shown. 

What is mentioned above about bypassing the mosfets would defeat the charge and discharge capability of the bms. I.e. no regenerative braking...

[Circuitmage]

On 7/22/2018 at 10:45 AM, US69 said:

I hope in the new week a solution will be found.....

Also (riding everyday), my lock up happened 1 week after I started riding...more like 6 days. And it happened with only around 70km. So, waiting should also be a good indicator of frequency.

I am concerned about the apparent lock-up of the wheel while charging and lifting. This really seems like a related issue and I have not seen much forum response on my post.

[US69]

1 hour ago, Circuitmage said:

am concerned about the apparent lock-up of the wheel while charging and lifting. This really seems like a related issue and I have not seen much forum response on my post.

charging and lifting? report where? sorry indont see anything...give me a tip, please...

[esaj]

15 hours ago, Possejdawg said:

Better solution is putting a small switch at vdd to disable to bms. The anti series diodes and mosfets will naturally block the flow of current in the example shown. 

That could work too, although it may require cutting a trace to add the switch in-between.

 

Quote

What is mentioned above about bypassing the mosfets would defeat the charge and discharge capability of the bms. I.e. no regenerative braking...

Not sure what you mean by that... the idea was to bypass the resistors between mosfet gate and source to force the mosfet off and to "shut down" the battery if needed, of course there's no regenerative braking then either.

When it comes actually bypassing the protections, in older wheels, where overcurrent or overdischarge protections were causing faceplants by cutting power, we actually "shunted the packs", ie. used heavy gauge wire to bypass the protection mosfets altogether. The topic's 3 years old but still pinned in the Mods-forum (all the original picture's are gone though):

 

 

 

Edited July 23, 2018 by esaj

[Circuitmage]

@US69 

 

 

[Circuitmage]

FYI, I just had lock up #2 while trollying. I have informed the seller. Disabling lift does not appear to fix.

 

[Lutalo]

1 hour ago, Circuitmage said:

FYI, I just had lock up #2 while trollying. I have informed the seller. Disabling lift does not appear to fix.

 

Sorry to hear that you are having so much difficulty with your wheel. I know that it must be frustrating. Interested to know what will be the ultimate fix for your wheel.

[TomOnWheels]

Just as an update on my story with KS18L, it has been now almost 4 weeks, 200km, and around 500m of trolley mode, without failure. As a reminder, my wheel had a firmware freeze issue, that endup with replacement of controller card. Since then I've also fixed the trolley tubes that are having issue with locking properly went in lower position, and the lock mechanism being to weak to support the weight of the wheel when holding it. At the same time, I've also made some adjustments  to both trolley sensors and calibrate them using the app. Since then no issues, all good, nothing to report. The trolley is still the most stupid and weak part of this fabulous wheel. It's important to pay attention to lock properly both sides of the trolley before holding up the wheel - because otherwise all the efforts are only on one side of the trolley and this for sure will brake the already fragile mechanism. 

[ricqvo]

3 hours ago, Circuitmage said:

FYI, I just had lock up #2 while trollying. I have informed the seller. Disabling lift does not appear to fix.

 

What?!? Poor you...

I ordered my 18L and now I am waiting for it I dont want to have issues with it.... Btw can we now where did you ordered from? Some bigger seller? Or some china seller?

[Circuitmage]

@TomOnWheels Nice update. I agree with the handle issue. Hope to have mine fixed as well.

@ricqvo The seller has already volunteered that information on this forum on another thread with the KS rep, and he has very good customer service, so I don't mind mentioning eWheel's @Jason McNeil . I hope to (eventually) have my issues ironed out.

As I relayed to the seller, having to take this wheel apart every week (now 2 weeks in a row) is not something I want to continue doing, so I will have to revert to my 16S until this is working. Luckily it is not a failure that appears to happen while riding. But I will also ride it home slowly today before giving it a long rest.

And, now that I have taken this apart 2 times, I find 1 or 2 screws are starting to wear down and I broke the white plastic housing on the left side of one of the speakers trying to pry the sticky foam off so I could reach the power plug.  . I think I should not be taking this apart any more. Hopefully it's just a bad controller board.