• Content count

  • Joined

  • Last visited

  • Days Won


Chriull last won the day on December 3 2016

Chriull had the most liked content!

Community Reputation

1,227 Excellent


About Chriull

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,293 profile views
  1. Should be fine - anyhow with a charger from china you should controll the max output voltage with a voltmeter before using it! Normally there are three small trim potentiometers inside for max voltage, max current and "idle" current adjustment and they can be "off"...
  2. It's not trivial - but well explored and settled "basic knowledge" for people working in this field. Could easily be that the greatly increased motor power is the cause - the rest of the system stayed more or less the same. So the compensation by the motor happens now to quick which leads to overshoots and oscillations which just requires a small adaption of the previous controller design (which they presumably never did... ;( )
  3. A first step should be a mathematical model of the whole system (motor, physics, control loop) to design a stable controller. That's a well understood topic easy to accomplish by experts. A PID controller is nothing magic and can be perfectly designed... An oscilation as a response to a step function input to a controller is not at all necessary - just a one time investment into one who knows what he does. The test-rigs are a great second step to proof and fine-tune the model empirically. The test-rigs would also be great to test/show max continous load situations and so show weak links in the system to the designers... No more burned cables, fried mosfets, etc... There are thermal probs with the actual wheels - they cannot provide their 1200W continously. Not to speak from the peak values (3600w?) With this test data firmware limits could be implemented to get the wheels really safe - something like 3600W for max 10sec, 1200W for 5 min, 800W for 10 min, etc with a time constant to simulate the recovery of the system ... Quite an easy task with solid simulations and test data at hand. pfff... That would be quite another huge design fault - they should get the signal transmission from the sensors to the mb safe - again nothing magic. Maybe @electric_vehicle_loveror some others from "our firmware members" can help them out to implement a sensorless control (or some mixed mode model to use the sensors just for "calibration"/startup or whatever...), if the interference with the motor cables are not be handled...
  4. @JumpMasterseems to be no longer active around here - his last post was from 31.10.2016 Also i think somewhere that he stopped devleopment of wheellog.
  5. Had exactly the same - was somehow like driving on super soft mode ...;) ... And then the fuse blew up on an incline - fortunately it was my brother testing (at low speeds)
  6. @zlymexposted measurements from his MSuper3s+ showing an about ~50A average going up a big hill. As it seems Mosfets are under controll - with overheating warnings/tiltbacks once it gets too much. Cable losses (6-3 mOhm with 50A are around 7,5-15W) seem to be enough to get them overheated over time - or maybe it was alway somewhere a not so good connection/"offended" cable (bendings or whatsoever... anyhow just too high resistance) that generated the heat to get the cables/insulation down? If now the cables get thicker, connectors better and they are under controll - what's the next part to fail?! One weak link eliminated - next one dies? Are the mosfets back again - or will the PCB traces go up in smoke? Or we get something new? The motor has an internal coil resistance of something about 0,1 Ohm - so with this 50A it dissipates 250W. Should be cooled enough by all the metal inside - i assume this should work out?! Then we have the batteries - now they use in these wheels 20s6p? If they have comparable cells like the LG MJ1 (37mOhm) that would result in an internal resistance of 0,123 Ohm - dissipating ~300W! They are in a plastic sleeve - no cooling? The BMS should have temperature surveillance -> hard shutoff once they overheat? Edit: As found out in the average battery current is much lower than the motor current in many cases, so in such a case there should/could be just ~15A battery current leading to just 30W battery losses!
  7. In a real bldc motor used in the EUC there are 3 phases. They are internaly connected as a star, so the motor voltage is always applied over two phases in series. For the commutation sequence the voltage is applied in a fixed sequence (for example A-B, A-C, B-C, then again A-B, ...) so at any time there is voltage applied over two phases and the current flowing through them. To make it more complicated this voltages to the phases could be sinusodial or trapezoidal - but then again one could take the effective voltage...;) If voltage is applied to i.e. A-B then I A = - I B, in the internals of the motor one coil of phase A sits aside of a coil of phase B, so A attracts the permanent magnet and B pushes the same magnet... For my calculations the resistance of this two phases and just look at one (effective) voltage and current, which should be for our purposes a good enough approximation. Battery voltage does not really matter for the torque, since it is pwmed (stepped down) to the right motor voltage to get the correct current (proportional to torque) by I motor = (U motor - U back emf)/Rcoil... (as long as the battery voltage is greater than Umotor) Since the load and speed determines the needed power and P=U*I thats prooven! Yes, considering the 10A are the motor current and not the battery current! In this example battery current will stay the same (constant power demand). Motor coil resistance is also very importand, since with the currents it adds a voltage drop on top of U back emf and by this makes a higher battery voltage needed to reach a certain speed. The Inductance (togheter with the motor interia) mainly averages the pwmed motor voltage - so i looked only at "static" situations where it has no "influence" beside this. Once accelerations/load changes happens so that the motor current changes they presumably play a big role and are not to be neglected again - they'll also contribute then to a negative or positive voltage on top of the ohmic coil resistance voltage drop and back EMF. (They are working against the change, so higher voltages are needed to get the current for the required torque flowing to balance the wheel...) Capacitance ... pffff ... I assume the big capacitors on the mainboard are needed to support the peaks the battery cannot deliver with their internal resistance and stray inductivities?
  8. Since this are all "direct" formulas now without iteration needed, one should be able to plot everything. At a given (constant) motor output power average battery current and average battery voltage should be constant - Just the ohmic resistance from the motor should be a loss and not motor output power - so some small changes would be needed in the sheet. Also the internal resistance of the battteries should be considered as loss and so only the "real" battery output power equaled to the motor power without ohmic coil losses - seems like a next iteration for the formulas has to come...
  9. yes - everything is on the same axis, so volt,ampere and km/h depending on the curve. Horizontal is the speed in km/h
  10. Strange - @DaveThomasPilotseems to had no prob? the pictures where at and till now seemed to work wo prob?
  11. With 90A and a coil resistance of ~0,1 Ohm that would make a motor loss of 810W only from this part - not taking into account friction/"magnetic"/etc losses... Edit: and a bit more is burned within the battery packs?! Msuper3s+ also has a 20s6p configuration? Would make ~0,12 Ohm? (1) Even with the average ~50A you reached going uphill that's around 250W and 300W (1) burned in the motor and in the batteries - still a small but nice cooking plate... --- I finshed my formula set (so everything can be calculated in excel without iteration): (1) I renamed the one U battery max to U back emf max to avoid misunderstandings - this value is used to calculate the actual U back emf U battery max ist by default set to number of cells in series * Voltage per cell, but can be changed as wanted. (Pay attention - it can be set too low, so the duty cycle becomes >1 ) - i did not thouroghly check it, but it seems quite ok... The used formulas: and a first graph: (again) (1) Thats for a fixed Power of 800W, resulting in a Average Battery voltage of 74,68V and average Battery current of 10,71A. The max battery voltage equals to I motor shown in the graph. The graph is made over Speed (0-55 km/h). Max U Back Emf was set to 70V (at 55 km/h) Edit (1): ups - 6 cells in parallel don't have 1/6 of the resistance of one cell... ... i'll change that... Edit2: or it is - pfff - i have to make a break.... Edit3: Ok - it is 1/6 - don't know what happened yesterday...
  12. Just another way to see the cable prob: AWG 16 has an resistance of 13,6 Ohm per km, so 13,6 mOhm per m so something about 5,5mOhm for the cabling from the PCB to the motor (~40cm?) AWG 14 has 8,55 mOhm per Meter, so ~3,4mOhm AWG 8 has ~0,85 - so the first below 1mOhm Considering that the Mosfets have ~5mOhm Rdson and get a heatsink... Cables can withstand a higher temperature than a mosfet, but that just "buys" some time...
  13. The sheet uses the kv ( motor constant for U back_emf = kv * rotations) by calculating U back_emf = Ubattery max / v max no load speed * v. And by this changing U battery max in the sheet changes the whole motor characteristic (kv) ;( I changed here the sheet by inserting a seperate U battery max (cell B 10), so that U back emf (kv) gets calculated from this, and the U battery max in call b 13 can be changed as one whishes: ps.: don't forget to use excels "iteration" on cell c 21 (should get 0) by changing cell b22 after each change... pps.: I'm not really sure if you intented your topic to go in this direction - if you feel that i captured this thread to somewhere else, i can split it to somewhere new... Edit: i just got now that you changed U battery average - that's a calculated value and not to be changed. Ubattery max in cell b13 is the one to adopt. I should start to user different fill colors or so to mark input cells... Done
  14. Imho it was 8 kHz - but i have no screenshots of my "measurements" on my harddrive. Would have to search in the old posts.... pffff... nice parameters... On the english wiki are the formulas for the self-inductance of two parallel wires. Maybe you should use the formula for two parallel wires (high frequency), since high currents behaviour is sometimes quite similar to high frequency situations. Or there is also the inductance of a wire parallel to a conducting wall, if this better meets your requirements?
  15. I assume thats both the same content? The motor defines by its Back EMF (which is a motor constant times speed) and the Coil resistance the Voltage wich has to be applied (Umotor). By the duty cycle d this is "down scaled" from the Battery Voltage. The motor current is defined by Imotor = (Umotor - Uback emf) / Rcoil). So with every Battery Voltage (1) above Umotor this state of the motor (accomplishing a certain output power while rotating with a certain speed with Umotor and Imotor) can be accomplished by different duty_cycles. Edit: (1) Minimal Battery Voltage under maximum load while the "circuit is closed - mosfet conducts"