DIY Electric Car Forums banner

1 - 3 of 3 Posts

1,760 Posts
Discussion Starter #1
Yes, it's finally finished and it's a pretty major upgrade that contains several bug fixes, safety fixes and a huge amount of new features. From the readme (included in the zip-file that's, btw, attached to this post):

Bug fixes:

  • Fixed bug that didn't shut down the controller if 12 Volt dropped too low (below 10V). This is a redundant safety mechanism to protect the IGBTs from being under-driven. Note that the controller first inhibits motor output (~4ms) then shuts down if the under-voltage condition persists (~80ms).
  • Fixed bug with temperature derating so it starts at 1000A rather than the max motor current setting. If, for example, motor current current is set to 500A then derating shouldn't kick in until 75°C since the IGBTs can still handle 500A at that temperature.
  • Fixed so the setting for motor overtemp can actually be changed.
  • Fixed a buffer error in the web server that truncated the drop down menus, making some of the options impossible to select.

  • Error codes are now stored in the on-board non-volatile memory and will be presented in English in the web interface upon the next page refresh. The errors persist until cleared with a click button. Both error and the running time since last startup are stored to make it easier to hunt down the area in the logfile (if collected!).
  • The warning lamp flashes during initial startup if any error codes have been stored (rather than briefly light solid which is done to simply indicate the lamp is working).
  • Improved RPM-measurement and overspeed protection. A digital filter implemented in software better discriminates between valid tach pulses and noise.
  • Performance/Quiet mode setting. In Performance mode the controller always operates at 8kHz for best efficiency while in Quiet mode it uses 14k to reduce the chance of the motor "singing", especially at low currents when dithering (randomized pulse skipping) is in effect. Quiet mode also reduces the magnitude of ripple reflected back to the battery pack so is beneficial with lower pack voltages (<96V). The controller will automatically drop back down to 8kHz at high motor currents or if it goes into thermal derating. The higher frequency will automatically resume when current or temperature drops enough.
  • Motor kW-limit. It's possible to limit not only the maximum current and voltage delivered to the motor, but also the maximum power. A motor that, e.g., can withstand 1000A or 200V won't necessary survive both at the same time! Being able to limit power as well will increase the survival odds for the motor (but it is still up to the end user to wield the power of the Soliton1 responsibly!)
  • Idle. A proper PID loop has been added to regulate motor RPM despite changing loads, mainly for "idling" the motor. This is an industry- first feature that makes conversions with automatic transmissions (not to mention keeping A/C going in heavy traffic!) practical!
  • Start input. Allows pushbutton starting of idle, rather than applying throttle. Mandatory safety requirement for EU regulation ECE-R100.
  • Run indicator. Blinks when precharge is over the controller is ready to accept throttle input and/or start idling. Changes to a steady light when the start button is pressed.
  • Factory defaults. Erases all user settings so the controller goes back to, you guessed it, Factory defaults.
  • The brake signal input can now handle both normal (high when brakes are applied) or inverted (low when brakes are applied) polarity.
  • State of Charge meter output. Gives a rough indication of battery capacity remaining by looking at where the pack voltage is at between two user-set limits. A battery current above which point the SoC percent is held can be set as well. This method is of limited effectiveness with Lithium chemistries and is no substitute for an Ah-counting SoC gauge.
  • Tachometer output. Can be set to generate pulse trains compatible with standard 4, 6 and 8cyl. tachometers, regardless of how many pulses per revolution are used for the actual motor tachometer.
  • Single cell low-voltage input. Allows a BMS with an alarm output or NC loop to tell the controller to dial down motor current when a single cell has dropped below a safe level. This works just like the existing pack level minimum voltage protection.
Added safety:

  • Low voltage protection. If pack voltage drops 10 Volts below the minimum pack voltage setting then the controller considers this an error. Normally pack voltage will never go more than a few Volts below the treshold since the controller automatically dials down motor current to protect the pack.
  • Motor current is limited to 900A if pack voltage is above 310V.
  • If there's an "Precharge timeout, no voltage" or "Precharge timeout, too low voltage" error stored in the controller, there's an extra 10 second delay added at startup before the ordinary precharge sequence is initialized. This is to limit power dissipation in the precharge resistor that can cause it to become unsoldered should someone, e.g., program too high a minimum pack voltage and keeps cycling power to the controller wondering why it won't start. The delay will disappear when the stored errors are cleared.
These changes are relative to version 1.0 but many controllers have been delivered with beta versions so some of these changes might already seem familiar to you. My hope is that we from now on only will deliver (and release) stable releases of the software, which also will make my life a bit easier when people report bugs...

Oh, and a screen dump of the error printouts in the web interface:

So now I'll start on version 1.2 which will mainly be adaptions for the Junior, but I'll probably sneak in a new feature or two for the Soliton 1's as well. :rolleyes:

Later on (possibly for 1.2 but probably for a later release) I'll also change the logger format (the UDP-data the controller transmits over the network) so if you've done some kind of logging application or similar for the Soliton, please let me know so we can discuss these changes. I'd welcome input from others to make the logging format as versatile as possible so that all future EVnetics controllers can use the same protocol to avoid compatibility problems and make it possible for, for example, gauges and displays to work with different models.

I'll start a new thread for that later so we don't clog this thread with those discussions, but not tonight. I've had a one man release party + that it's getting awfully late in Sweden...


PS. Dimitri, the 1.1 you have isn't the latest version, so please upgrade your 1.1 to this 1.1... :D


1 - 3 of 3 Posts