[dougingraham]

I have a Soliton 1 and I am glad I decided to get one rather than roll my own. Thank you Evnetics for a fantastic line of controllers!

The controller as is will exceed most peoples conversion needs. But there are a few things I would like to see added to the unit.

1) An over rev output. The controller already watches the RPM if you hook up a sensor. What I would like to see in addition to the rev limiter function that is already in the software is a user selectable RPM which will set an output bit so as to alert the driver with some sort of audible signal. This would come in handy in the event you flub a shift and go down instead of up or simply start down a hill and not realize you are exceeding the rev limit of the motor.

2) User selectable profiles. This is almost supported now with the reverse signal input. I would like to see this extended so that two input bits could be used to select one of four profiles. Examples of this would be Daughter, Valet, Normal, and Sport (or Race). There would be different settings for RPM, Motor voltage and current. These could be selected on the fly. The only real problem is we are already short of inputs.

3) Directly settable throttle endpoints. The system provided works well and it good for most people but I want to be able to put in numbers, either the percentage or actual voltages.

4) Configurable throttle response curves. This is almost supported with the half throttle percentage thing. And that is probably good enough for most things. However I did electronic speed controls for the RC hobby from the early 90's and one of things I researched was throttle curves. You want a different curve for RC boats, RC planes, and RC cars. You can make the throttle feel a lot better by matching curves. And in the case of full size cars where we use mechanical linkages between the throttle pedal and the sensor mechanism there can be non-linearities that could be compensated for in software.

The ones above are mostly possible with just software. The ones that follow will need additional hardware.

5) Cruise control. The idle control loop could be used to hold speed on the highway. Unfortunatly there are just not enough inputs to do a cruise control safely. In addition to a brake input you want an on/off input and a set/accel input, and a decel input. For safety you would also want to disable on clutch pedal, and neutral setting of the transmission and inertia switch trip or airbag deployment. There aren't nearly enough inputs to support this so it can't be added with just software.

6) I would like to see the controller side of the battery current hall sensor made available. You would hook the charger to this point which is outside the built in contactors and then the Soliton could act as a fuel gauge. I know it has been mentioned that the hall sensor is not accurate enough but that could be corrected at the same time as this additional connection is implemented.

7) Finally I am thinking it would be useful to provide a connection to the controller side of the precharge circuit. This could be used as the charger connection or as a connection to a DC-DC converter. This point has the advantage of allowing the other devices to make use of the input filter caps in the Soliton so they would not need as much of their own if any. Other devices in the car can take advantage of the contactors and precharge circuit in the Soliton.


I have other ideas but they get progressively more radical and less likely to be implemented.

Thanks again Evnetics for a great controller!

[Tesseract]

Thanks for the thanks. We do appreciate it. We also appreciate well-reasoned feature requests; indeed, many of the cool functions in the Soliton controllers were the result of such requests (including, but not limited to, the gauge drivers, idle, throttle limit, cooling pump output, etc.).

However, there is but one severely overworked microcontroller inside the Soliton controllers, and after 4 years of adding features we are just about out of flash memory. I think the latest tally of free space is something like 700 bytes left. Not even 1k. The only way we can get more space - without designing new hardware - is to hand optimize existing functions to take up less space, a process that is more art than science, and incredibly time consuming. Thus, a feature at this point must either be really compelling, or take up a miniscule amount of memory to be considered.

Originally Posted by dougingraham

...
1) An over rev output...

That is already implemented in a way - the error light blinks slowly if the motor RPM exceeds the set limit (it also blinks slowly if the controller is too hot, or the tachometer signal goes missing... ) - but adding that as another programmable output function shouldn't take up too much memory (I have to be careful about promising such things, though, as I am not the software dude; that's Qer's responsibility).

Originally Posted by dougingraham

2) User selectable profiles....

There is definitely not enough flash memory for this. It's also a bit complex for the people that just want to hook the controller up and go. You can achieve some of this functionality - albeit crudely - with the throttle limit input function.

Originally Posted by dougingraham

3) Directly settable throttle endpoints.....

You're not the first person to ask for this, but I challenge you to really articulate why you think you want it. Next, try to think about the possible negative consequences of allowing the direct entry of throttle calibration values.

Originally Posted by dougingraham

4) Configurable throttle response curves....

Good idea, if a little messy without resorting to another web page, and both the function itself plus the web page would require too much flash memory.

Originally Posted by dougingraham

5) Cruise control....

Yep. Excellent idea that needs additional hardware to accomplish. My only comment is that there is nothing stopping anyone else from building the hardware to do all this, you know...

Originally Posted by dougingraham

6) I would like to see the controller side of the battery current hall sensor made available....

The Hall effect current sensor is in the motor loop, not the battery loop, and these sensors are typically only accurate to +/-2%, anyway, so both reasons argue against this. Besides, it would require a modification to the hardware and some loss of backwards compatibility.

However, I've been thinking of something similar for the charger - putting the current monitoring *shunt* (not Hall effect sensor) outside of the box so it can pick up current going into and out of the pack. This is really the device that ought to have this kind of functionality built into it, not the motor controller.

Originally Posted by dougingraham

7) Finally I am thinking it would be useful to provide a connection to the controller side of the precharge circuit....

Oh boy... Letting the outside world have access to the controller side of the precharge circuit... What Could Possibly Go Wrong?®

[Qer]

I'll fill up with additional answers to T's reply. Generally I do like your thinking though...

Originally Posted by dougingraham

1) An over rev output. The controller already watches the RPM if you hook up a sensor. What I would like to see in addition to the rev limiter function that is already in the software is a user selectable RPM which will set an output bit so as to alert the driver with some sort of audible signal.

Hm. Actually not too hard to implement as long as noone comes with the additional request that it should warn for over-rev AND <insert some more tresholds> on the same output. Then it'll get a bit messy...

Originally Posted by dougingraham

2) User selectable profiles. This is almost supported now with the reverse signal input.

As T said there's the external current limit signals. More complicated than that will be, err, challenging to implement due to the cramped space. Maybe if I had thought of it from the beginning. Anyone happens to own a time machine?

Originally Posted by dougingraham

3) Directly settable throttle endpoints. The system provided works well and it good for most people but I want to be able to put in numbers, either the percentage or actual voltages.

Originally Posted by dougingraham

4) Configurable throttle response curves. This is almost supported with the half throttle percentage thing. And that is probably good enough for most things. However I did electronic speed controls for the RC hobby from the early 90's and one of things I researched was throttle curves. You want a different curve for RC boats, RC planes, and RC cars.

Not convinced this will actually improve anything. Keep talkin'...

Originally Posted by dougingraham

5) Cruise control. The idle control loop could be used to hold speed on the highway. Unfortunatly there are just not enough inputs to do a cruise control safely.

That's not half of it. The RPM input is special for a reason, implementing a cruise control would need a second RPM input with a similar hardware circuitry. That would demand a new CPU and somewhere there it's a completely new product...

Originally Posted by dougingraham

6) I would like to see the controller side of the battery current hall sensor made available.

Originally Posted by dougingraham

7) Finally I am thinking it would be useful to provide a connection to the controller side of the precharge circuit.

Not touching those. Definitely T's domain!

Originally Posted by dougingraham

I have other ideas but they get progressively more radical and less likely to be implemented.

uhoh

Originally Posted by Tesseract

However, there is but one severely overworked microcontroller inside the Soliton controllers, and after 4 years of adding features we are just about out of flash memory. I think the latest tally of free space is something like 700 bytes left. Not even 1k.

It's not THAT bad actually, not since I started to store the web pages as compressed data in the controller, before that we actually had negative free space for a while. Now we actually have more than 2kByte free space! LOTS of place for new features...

But T's argument still stands and there's the additional problem with the slowly increasing CPU load. I've had to trim the code a few times to keep the CPU load at a level I feel is safe. And then there's the RAM. Somewhere back in the days when the first Soliton prototypes started to see daylight we sprung for the biggest CPU in the CPU-family we'd chosen to have lots of space to grow. Well... At least it was a good thought.

I'm very reluctant to add new features unless I've been convinced it's a really good feature that will be widely appreciated. I think your first point definitely has merits and will ponder if I can at least partly implement your second point by reworking the current limit to be a bit more flexible limitation feature (maybe also limiting motor voltage?) but no promises there!

The rest of your ideas/requests would be worth considering for a potential future new product/rework, but I don't think it'll be implemented in the current Soliton series due to the cramped resources and hardware limitations...

[piotrsko]

REGEN

more for braking than energy recovery.
apparently according to Tess, I'm already doing it, kind-of; but some control would be cooler. Still have that $500 BURNING A HOLE for this.

[drgrieve]

Cruise control should be done outside of the controller. If you car doesn't have cruise control then there are after market devices available. In the end for the Soliton it's just a throttle input and the other safety features part of the cruise control module.

For things like user profiles does the web interface support a underlying API or do request s have to follow a certain workflow? If you can just POST new data then an external device (android phone etc) could be used as the interface for additional features like this.

This would leave the Solition for basic setup and the fancy stuff can be offloaded.

[EVfun]

Originally Posted by dougingraham

3) Directly settable throttle endpoints. The system provided works well and it good for most people but I want to be able to put in numbers, either the percentage or actual voltages.

4) Configurable throttle response curves. This is almost supported with the half throttle percentage thing. And that is probably good enough for most things. However I did electronic speed controls for the RC hobby from the early 90's and one of things I researched was throttle curves. You want a different curve for RC boats, RC planes, and RC cars. You can make the throttle feel a lot better by matching curves. And in the case of full size cars where we use mechanical linkages between the throttle pedal and the sensor mechanism there can be non-linearities that could be compensated for in software.

This reminds me of the old DCP way of handling throttle. The max point was set (I wouldn't recommend going back to that controllers analog method of setting it) but the 0 throttle point was defined as the throttle position measured when the controller was started. The car would never launch on start up because by definition the throttle was zero at start up.

If you held the throttle wide open at startup the car would not move because 0 throttle took priority over the full throttle setting. The downside is that if you held the throttle at about 90 of open when starting the controller you would have a huge dead area in the pedal travel and a very aggressive throttle near the end.

7) Finally I am thinking it would be useful to provide a connection to the controller side of the precharge circuit. This could be used as the charger connection or as a connection to a DC-DC converter. This point has the advantage of allowing the other devices to make use of the input filter caps in the Soliton so they would not need as much of their own if any. Other devices in the car can take advantage of the contactors and precharge circuit in the Soliton.

That scares the crap out of me. However, it could be useful to provide an output that was toggled on during the precharge time. It would be an output to indicate the controller was in precharge that could be used with simple additional circuitry to operate a timed precharge on startup for a DC to DC Converter (for those who want to switch them on and off with the car.)

[skooler]

Hi All,

Its probably not supported by the hardware/uses to much processing but I think that a really useful feature would be a tach output that could mimick the signal generated by the crank/eccentric shaft position sensor on an ICE. On my RX8 this would be a lifesaver - fooling the ECU into thinking the ICE is still there.

Probably too many possible variations etc.

Perhaps there's a market for an EVNetics unit to fool ECU inputs?

Cheers

Mike

[piotrsko]

Originally Posted by skooler

Hi All,

Its probably not supported by the hardware/uses to much processing but I think that a really useful feature would be a tach output that could mimick the signal generated by the crank/eccentric shaft position sensor on an ICE. On my RX8 this would be a lifesaver - fooling the ECU into thinking the ICE is still there.

Probably too many possible variations etc.

Perhaps there's a market for an EVNetics unit to fool ECU inputs?

Cheers

Mike

my Sol does this quite nicely already which is how it runs the factory installed electric cruise control, speedo and tach. a 555 timer running in asynch mode for the O2 sensor, and a couple of light bulbs and fixed resistors here and there for monitored outputs so the ecu thinks it is in open loop.

[skooler]

Originally Posted by piotrsko

my Sol does this quite nicely already which is how it runs the factory installed electric cruise control, speedo and tach. a 555 timer running in asynch mode for the O2 sensor, and a couple of light bulbs and fixed resistors here and there for monitored outputs so the ecu thinks it is in open loop.

What tach output are you using on the Soliton? I have a feeling that it will be much simpler than what my RX8's ECU requires!

Some food for thought...

http://foxed.ca/rx7manual/2003mazdar...018880W02.html

Terminal connected: 2U (+)-Negative battery terminal
• Oscilloscope setting: 2 V/DIV (Y): 5 ms/DIV (X), DC range
• Measurement condition: Idling after warm-up (no load)

[dougingraham]

Originally Posted by Tesseract

However, I've been thinking of something similar for the charger - putting the current monitoring *shunt* (not Hall effect sensor) outside of the box so it can pick up current going into and out of the pack. This is really the device that ought to have this kind of functionality built into it, not the motor controller.

I didn't know you were doing a charger. And of course there are two obvious places to put the gas gauge. In the motor controller or in the charger. The charger is slightly preferred because it can reset to full automatically because it knows when you topped up the battery.

I know what you mean when you talk about Hall effect current sensors. It is exceedingly difficult to make them accurate. You need a precision regulated supply and a thermal oven to get them to be well behaved. And then you need to calibrate a mapping function so as to get an accurate reading. Otherwise they are plus and minus a couple of percent. They certainly are easy to use though. Which explains why there are some bad devices out there. Of course there are lots of applications where a couple of percent error doesn't hurt anything.