Jump to content

Chriull

Moderators
  • Content Count

    3,101
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Chriull

  1. If you bought your wheel from 1radwerkstatt i'd say chris is the one to give you a "real" statement!
  2. I cited the content of the link of the by now hidden sales topic: But as written this is for shipment within the US...
  3. Cable diameter, length and max current determine a maximum voltage sag and temperature rise for a given enviroment. So there are different "rules" for cables used in households (how many cables in one ?installation bay?/?tube?) or cars, etc... Could fit for charging cables used in EUCs. Or not... If one looks at the battery discharge cables/motor wires beside my gut feeling would say they are ok. The charge wires don't go directly to the battery anymore but by the mainboard! So all traces/components that are between the charge cable plug and the battery charge input have to withstand the charge current. The KS16X is measuring the charge current - wasn't there a firmware that started beeping at currents above some 5A? Also the components in the input protection circuitry of the battery BMS have to withstand the charge current. So there is more as to just look up some AWG cable calculator :(. Most presumably it could work out - but there could be valid reasons why KS had this firmware warning at charge currents above ?5?A!
  4. And please give us a description of the new BMS and the app! Once you had enough riding...
  5. Yes. That was reported here. They just shiw what the wheel reports. Don't know if euc world corrects this wrong values, has an option for correction or such a feature is planned. Afaik euc world processes gps epeed, too. With that one should have a correct speed?! I understand it as "inflated by 18%" and would therefor calculate it as 40 km/h / 1.18 ~ 34 km/h. But as far as i remember it was the ks18(x)l with 18% to high numbers. Ks16X afair "only" shows 9% too much. So 40 km/h / 1.09 ~37 km/h If i remembered right the ks16x with 40 km/h should still be a bit faster... 50/1.09=46 km/h Seba posted speed/voltage charts for the KS16X here:
  6. Imo some points adding up: KS has some good current current limiting for low speeds. High needed phase currents at start up are transformed to low battery currents. With a "good" motor control algorithm this seems to work out. My KS16S graphs show ~10A at about 0 speed. @Seba s graph show just some sparse point in this range. Afair he saves/transmits "only" 1 sample per second vs 5 samples per second per "original" wheellog. And at ~0 km/h driving least time is spend. Most time at this speed is standing and waiting without current needed. So high burden starts at this low speed need more data collection to really show up in the graphs? @Seba s binning/clustering shows somehow "real" frequencies of how often samples occured by leaving seldom areas sparsely populated. While in my graph some spots are cluttered up but are compared to other areas in reality very sparse? Maybe in a year this graphs look very different whith much more data collected?!
  7. Thanks! The datapoints above tiltback speed are missing in these graphs? There were (not too many) in your speed over voltage diagramm! Or they few points are just invisible by the ? This would be the "interesting" parts of riders reaching the limit (beside some lift cut off speed test)
  8. Each battery has its own BMS inside. If anything got destroyed at the BMS one can maybe see it by "molten" spots of the plastic wrap? Be careful with your batteries! As the BMS could be malfunctioning by now. There is a big capacitor at the mainboard. Sparks when plugging the batteries in again are "normal" when the capacitor is charged again. Blowing the fuses by this is a bit uncommon but could happen? Maybe KS could help you if you contact them directly and/or via your reseller! Maybe @Micheal Shen from KS can help too establishing a contact/prevent further damage/solve the problem? It's hard for us/me to do a remote diagnoses, especially for ?new?/not (well) known problems.
  9. As you noticed short circuiting the charging pins is not the best idea - they should be/are somehow protected against wrong polarity (?and short circuit?) but as you have seen something was overloaded... Imho it's not your (EUC main) board that got destroyed but the battery BMS board (the input protection part)? Your prior problem (wheel stayed in charging mode) is strange and quite new? Maybe the firmware (wrongly) measures a too high battery voltage and by this thinks it has to be still in charge mode? Or they use now some new BMS with communication to the mainboard? Did you measure the charger output voltage? Do you know which battery voltage was reported by the app while the wheel was stuck in "charging mode"? Please keep us informed about this problem and the solution, you'll hopefully find out soon!
  10. @Seba @Aneta - here a battery current over speed scatter graph from KS16S wheellog logs: Points above tiltback speed (35 km/h) are drawn in red. ("Guessed") limit lines are drawn for low and full battery voltage (3.3V*16=52.8V and 4.2V*16=67.2V). Here the try to "normalize" the graph. All the speed and current values were multiplied with 67.2V/(U_batt_reported+I_batt_reported * R_i_batt): As one sees the red dots do not "start straight at" at 35 km/h anymore but are scattered by the "normalization". And some points are beyond the limit line. Seems to be my "guesses" for R_i_batt and/or jitter/not timely exact reported values... The same with calculated motor currents (a first try - imo they are to low - have to adopt calculations/factors...): And motor current normalized: PS.: pythons matplotlib gets already noticable slow with >3 Mio datapoints @Seba - I hope you have something more "intelligent" not putting every datapoint to the scatter plot... I'd assume you have much more datapoints than this... Seems something like a "clustering of points within one area" would more appropriate here...
  11. I'd understand throttle as input to the controller, the PWM duty cycle as output. Should, but does not have to be the same as one sees with the current limiting. And the not 100% duty cycle achieved for 100% throttle. But yes - more or less. For Imotor it's right. For battery it's a bit more "complicated" - it is not the whole battery voltage dropping at Rbatt! Your formula for Ibatt is for short circuiting the battery. For the battery one has to consider the internal Battery Voltage (before Rbatt, the no load battery voltage) Ubatt_0. Then with some battery current Ibatt flowing the terminal voltage of the Battery Ubatt = Ubatt_0 - Ibatt * Rbatt Same with the motor - it has an internal Voltage Uemf and a terminal voltage of Umotor=Uemf + Imotor * Rwindings Now the controller with his duty cycle D "connects" both terminal voltages: Ubatt * D = Umotor. Without losses in the controller Pin = Pout and so Ibatt*Ubatt = Imotor*Umotor or Ibatt = D * Imotor. So again for D=1 Ibatt = Imotor. Almost For D=1 (as with no controller inbetween) Ibatt = (Ubatt_0 - Uemf) / (Rbatt + Rwinding) = I_motor or Ibatt=(Ubatt-Uemf)/Rwindings=Imotor PS.: That's all in detail worked out in with LTSpice Simulations, circuit diagrams and formulas... (and some trial and errors...:) )
  12. Yes of course. If I look at such a diagram for my ride i want to see how near or far i was to the limit - to learn about how much my "safety margin" was. This is not possible with just seeing the limit for the full battery - this needs some "transformation" to get battery voltage "fixed". But maybe there are also other interesting aspects to be seen i am not aware of? Isn't that called throttle % in the motor simulator? With 100% duty cycle no PWMing happens - the full batter power goes to the motor. So in my simple equivalent circuit diagram there is just the battery, their internal resistance the coil resistance and the motor. So the battery output voltage is the same as the motor terminal voltage and maximum motor current can be produced for this speed. In this case battery current is motor current. Another "special" case in the simulator is the first part of the diagram as there is current limiting active - so there is never a duty cycle of 100% reached for the limit. For the rest of the diagram the motor current is already quite similar with the motor current for throttle=100%. Could be that the controllers have some maximum duty cycle and never reach real 100%? Ps.: Just tried a custom controller with enormous current limits - there also at low speeds motor current is almost battery current!
  13. After checking the charger, as @The Fat Unicyclist wrote you could try charging both packs seperately. Could be that only one pack is bad and the other one is fine! And document everything - maybe you can open a dispute on aliexpress for having a faulty battery? Ps: to NOT connect the batteries together again once they have different voltages!
  14. Me too - but i do not really see by now how to too this in detail. For current, power could work wo problem? At least for wheels reporting battery current one gets the battety power easily. Motor output power needs some calculations... Why? That's a nice addition, too - imo especially for range considerations. Current over speed diagrams just show where within the "limit" one is driving. No matter of weight, incline,... All this burden factors "just" determine the reported current value. "Unfortionately" the upper boundary (max current == torque over speed limit) shifts proportionally with battery voltage (the no load battery voltage - without the burden induced voltage sag). So in a big data scatter graph the limit lines are a range/area, too. One will just see the outermost limit for full batteries. Faceplants happend with low/empty batteries are just somewhere inside of the blob. I tried, to overcome this, to "normalize" every point by dividing current and speed by their according no load battery voltage and multiply again with a fixed voltage (for example 84V). So one "projects" all possible limit lines to one line again, but all other points "below" are "indeterministicly skewed". So it is not possible anymore to draw for example lines to show tiltback speed - they are by this transformed to an area... +1. The limit (currentwise) will be exactly the same for a light or heavy rider. There is no influence of weight. Just the resulting accelerations/burdens will differ - but they are not known/in the diagram anyways. Yes - having both would be great. But at the limit battery current and phase current are identical! It's just the further one is from the limit, the more the currents will differ. So the high phase currents at low speeds (inclines!) will be "lost" if one plots battery current. Ks16s was quite exact speedwise? Just distance was about 20% off? Or did this change too with newer firmwares? Could rhis come from the deviation from the different wheel diameters - so that they are calculated from real 16 and 18 inch but both wheels used tires differ from that? Pfff... But +18% for the KS18 would mean they should have been 21 inch wheels;) -18% could mean they calculate as for an 16 inch but the tire diameter is 19. That could be realistic?
  15. @Seba -Nice data! No need for excel sheets and guessing anymore! There are 2 KS18XL?! Two different mainboar/firmware versions? The KS16X has a bunch of entries downto 58V! That would be 2.9V cell voltage! And a "hole" around 62V?! Some "aretfact" or firmware reporting error? The other wheels have just some "dips at speed" downto lower voltages - riders desperately trying to get home and getting low voltage tiltbacks?
  16. Seems i found the discrepancy - also the KS16C already reported battery current. With this corrected in the formulas one gets to something like this: Here acceleration taken by Delta v / Delta t correlates much better to the calculated one by the motor current Works also nice for GW (MSX) which report the motor current. Here the calculated acceleration from the motor current is (mostly) higher as the one calculated from speed change in difference to the KS16C log. Maybe the rider was much lighter as the KS16C, the KS16C reports too low current/the GW too much, i guessed some constants wrong, still have some wrong assumptions in my to ?simple? model, .... But the GW seems quite right - as for this graph the acceleration is calculated from the motor torque current fully disregarding all the non electric losses/burdens (magnetic, friction/air drag/...) edit: calculating the msx as 18 inch wheel will reduce the accel a bit (~11%)... corrected
  17. With 14*63=882W - KS (are supposed to) show battery current. So with some reduction for losses still enough for slow climbing. 5 km/h at 22° should need about 500W.
  18. Great! Thanks! Your numbers give a perfect line - 50 km/h limit at 100% downto 30 km/h limit at 30% So the table changes to kv ((km/h)/V) lift cut off speed 10% charge (km/h) lift cut off speed 30% charge (km/h) lift cut off speed full battery (km/h) Max Tiltback/3rd Alarm Speed (km/h) factor at 10% charge factor at 30% charge factor full battery KS16X v1.07 0,78 50,97 54,26 65,77 50 1,32 KS16X v1.07 0,78 50,97 54,26 65,77 30 1,81 Looks better and much more comforting now!
  19. So the KS16X has no fixed tiltback speed of 50 km/h from 100% downto 30% charge?! It has some reductions already inbetween, as it seems. Your voltages seem to be about a bit above 50% ((84+63)/2=73,5) and tiltback is already a bit lower than the 50 km/h. Does someone know the actual speed reductions from the KS16X? Then i could update my above posted sheets - and they would not look as dangerous anymore.... .... sorry i did not really follow all discussions about this ...
  20. That fits quite well together! Although it's hard to get the charge percentage/voltages together - i'm not really sure if 0% is now 3V, 3.15V or something in this range by now for the KS16X... Afair it was 3.15V? So it's understandable why KS introduced the speed reduction for lower battery charges - the margin is just too low. (if my numbers are right and there is no typo hiding in my sheet... ) This forum would be a great place to start with such a summary - i've thought of doing so since i posted my "anatomy of an overlean" topic. But it's a bit hard for me to write easy understandable "prose/lyrics" with simple concise graphs instead of tables, formulas and graphs with some conclusions that are "hard" to follow... ;( Will be a great future! But imho GW with the 3rd alarm is almost there - just the beeping is imo easy to be overheard at higher speeds. The margin as seen in the graph above for the MSX 84V is really nice (from the dark-red 3rd alarm to the black "torque" limit and from the light-red 3rd alarm to the corresponding grey "torque" limit). If they now would make the 3rd alarm motor current dependend it would be about perfect. And customizable, and optionaly as tiltback, ...
  21. kv is just in this list as helper for the calculations - it's just the motor constant showing the speed/rotations per Volt. The "result" of this table is the factors between (battery voltage depending) lift cut-off speed and maximum riding speed (Tiltback for KS, 3rd speed alarm for GW). This factor shows about a safety margin. So if one looks at the KS16X row the factor at 30% charge is 1,09. Telling us that by tiltback 50 km/h would be still allowed, but with this battery voltage the lift cut-off speed is only 9% higher at 54,26 km/h! That's about no safety margin and one should never reach this 50 km/h tiltback at 30% charge - one will just faceplant before. The KS16S had at 30% still ~24% reserve, the MSX has evertime ~40% reserve. And this reserve "is only true" in a no load situation - that's why i added the MSX current(torque) over speed diagramm with the 3rd alarm shown and the current(torque) over speed limit.
  22. Since i had an wheellog log of a MSX-84V ride (ending with an overlean) i added the 3rd level alarm to the charts. In the current over speed diagram are the two limit lines in black and grey for the max current (torque) over speed for the highest on lowest battery voltage in the log and the dark red and red line for the 3rd level alarm at these voltages. Ps.: the time axis labels are a bit unfortionate - they mean "day hour:minute"...
  23. Cell Voltage (V) Empty 10% 30% Full GW/KS16B/S 3,30 3,39 3,57 4,20 KS16X 3,15 3,26 3,47 4,20 KS18XL 3,00 3,12 3,36 4,20 Battery Voltage 16s (V) KS16B/S 52,80 54,24 57,12 67,20 Battery Voltage 20s (V) GW 66,00 67,80 71,40 84,00 Battery Voltage 20s (V) KS16X 63,00 65,10 69,30 84,00 Battery Voltage 20s (V) KS18XL 60,00 62,40 67,20 84,00 kv ((km/h)/V) lift cut off speed 10% charge (km/h) lift cut off speed 30% charge (km/h) lift cut off speed full battery (km/h) Max Tiltback/3rd Alarm Speed (km/h) factor at 10% charge factor at 30% charge factor full battery KS16B 0,68 37,15 39,12 46,03 30 1,30 1,53 KS16S 0,76 41,09 43,27 50,91 35 1,24 1,45 KS16X 0,78 50,97 54,26 65,77 50 1,09 1,32 KS18XL 0,82 51,09 55,02 68,78 50 1,10 1,38 MSX 0,92 62,04 65,33 76,86 55 1,40 MSX 0,92 62,04 65,33 76,86 45,67 1,43 MSX 0,92 62,04 65,33 76,86 43 1,44 OK - Put your numbers into the sheet. Afair KS16X had 3,15V(63V low pack voltage) as low cell voltage, the KS18XL 3.0V(60V low pack voltage)? I also made a column for 30% charge - were the KS wheels start speed throttling, so any safety margin factor with the higher speed limits would be senseless for empty batteries. For the MSX 84V (GW) i entered the values for the 3rd Level Speed Alarm - as one sees, here one has a constant safety margin factor over battery level! kv i changed from V/(km/h) to (km/h)/V as imho the normal units are rpm/V for kv? If my numbers are right, the KS16X/18XL lift cut-off speeds come dangerously near to max tilt-back speed at 30% charge! Ps.: this factor = Lift cut off speed at this battery voltage / max tiltback-3rd alarm speed Edit: First Changes to the table: Added 10% charge, as this is the charge for the 43 km/h 3rd alarm for the MSX 84V
  24. Could it be that he measured at low battery voltage? Then the value would be quite normal: kv (v/km/h) v empty battery (km/h) v full battery (km/h) Max Tiltback Speed (km/h) factor empty battery factor full battery KS16B 1,46 36,16 46,03 30 1,21 1,53 KS16S 1,32 40,00 50,91 35 1,14 1,45 ?KS16X? 1,10 60,00 76,36 50 1,20 1,53 Just the KS16S would be with a little lower than the others. If one calculates the KS16X with the same lower factor as the KS16S: kv (v/km/h) v empty battery (km/h) v full battery (km/h) Max Tiltback Speed (km/h) factor empty battery factor full battery KS16B 1,46 36,16 46,03 30 1,21 1,53 KS16S 1,32 40,00 50,91 35 1,14 1,45 ?KS16X? 1,16 57,14 72,73 50 1,14 1,45 Just if he got the 38 mph ~ 60 km/h with full batteries there is something wrong/very strange. PS.: At ~30% charge the tilt back speed gets lowered by firmware - so in reality the "factor empty battery" is never reached... Idid this sheet with 3.3V for the empty cell and 4.2 for the full cell - but for the KS16X low battery is somewhere about ?3.15V? instead of 3.3V as with the KS16B/S... That's how GW has their 3rd alarm implemented. It's linear with battery voltage/charge. So for the 84V Monster for example at 100%==84V at 55 km/h and at 10% charge down at 43 km/h. As lift cut off speed is linear with battery voltage/charge that is exactly this implemented. Riding weight is just one parameter for a burden, as also wind, inclination, etc is. But one could choose the factor between alarm and battery voltage so everyone can get his personal safety margin. To really regard the burden one could additionally lower this alarm speed by the reported current (with again some factor) - this would then reproduce more or less the max torque over speed limit of the wheel!
  25. +1. For the abovementioned LG MG50 21700 i found in some forum discharge graphs that showed that a firmware should be changed to stop riding from the by now 3.3V to ~3V or almost half very very much of the great capacity is lost at a bit higher discharge rates. But again - no LG cells are used, no "tustworthy" discharge graphs are given and no real max/average battery burdens are known... So some only real test result would be by now a rider as @Marty Backe doing his mountain ride and stating a (much) different or about the same capacity usage!
×
×
  • Create New...