When I did some dyno testing with two AMP Clamps on on battery current and one on Phase current it saw they were really close. I just thought it was because my dyno is spinning up to fast and not loading my wheel down enough. I will try again when I get my big dyno done. I am also thinking the Amp Clamp may not respond fast enough to see the peak phase currents.
Hall Sensors'b'Gone
- Thread starter incememed
- Start date
I see, the average based on one phase cycle give almost I/5 of I_phase = I_battery! BTW I got code and components for bldc sensorless from atmel (AVR444), I will publish some results here. Thank you so much,incememed said:Well, thank you for the kind words. I will look to them for encouragement next time I blow yet another component
I can't give any useful input on how to capture phase currents, I don't use direct phase current measurement. I did however simulate the phase currents of the first few commutations during startup a while ago (PSpice), this way you get a visual on what patterns to expect. Violet is battery current, green, red and aqua are A, B, C phase currents.
(20kHz, DC 20%)
to be continued
incememed
10 W
Arlo1 said:
Verifying the buck converter current multiplication property in this way might not yield very accurate results, and it also needs some adaptation of the measurement.
Imagine for a moment that the simulation mentioned above is actually a valid model of what really goes on in the motor/controller. Let's say we were to clamp the meter to the aqua colored phase, for example. Looking at the curve, we see that the assumption of Iphase = Ibatt / duty cycle seems to be true in period 1 and 2. But in period 3 it's no longer true! Battery current remains the same, but phase current is zero. We see this happen again in period 6. So the reading on the meter would not confirm what we're trying to measure, the value on the meter will be much lower.
The assumption of the buck converter analogy remains true also in period 3 and 6, but the actual circuit of this buck converter does not include the aqua colored phase. So, in order to measure correctly, we would have to rapidly switch the meter to another phase during these periods, which is of course not possible. Another possibility is to realize that the current value is zero during 2 out of 6 periods, ie 1/3 of the time. So to compensate, we could multiply the meter value by 3/2.
Having introduced the inaccuracy of 1) an AC-meter and 2) the compensation multiplication, it becomes important to monitor the duty cycle. If the duty cycle is high, some 60-80%, considering the inaccuracies, it might not be possible to distinguish the battery and phase current. Make sure duty cycle is low during the test. Verify the duty cycle by putting a voltage probe on any of the phases. Look at the PWM-action on the scope and calculate duty cycle = on-time / PWM period.
Looking forward to seeing the results, hopefully you will validate the model.
Gordo
100 kW
Ampclamps are calibrated for DC or 50/60Hz AC. How could they be good to measure PWM currents?
incememed
10 W
Hi,
Thought I'd make an update of recent controller activities. I've been working with a control method called FOC (Field Oriented Control) or vector control. This is the type of AC-motor control used in industry and in cars such as the Prius etc.
It's main feature is that it feeds the motor with sinusoidal voltages, instead of the step voltages used in trapezoidal control. This is supposed to make the motor go smoother and quieter. From what I've read, it's a tie with the trapezoidal method in terms of torque production.
The basic idea is to let the controller work with a DC model of the motor, instead of dealing directly with the three-phase sinusoidal reality. A DC-value is easy to control with conventional PI-control.
What I like the most, though, is that I now have phase current sensors. This is a blessing, I can only regret I didn't use this earlier. A MOSFET has yet to fail, which is NOT what I'm used to when developing these controllers.
Some vids from initial testing.
http://youtu.be/p4GXnPsJM4A
http://youtu.be/IwNU9RmiERc
http://youtu.be/FSaUIxaZzzQ
http://youtu.be/s23fTaYHYpI
Startup is still - as with any sensorless method - an issue I haven't bothered much about. A slight push is all it takes to take off, this soon becomes a reflex. Overall, I like this control method, it's every bit as robust as the six-step control I had before. What I don't like is the rpm-capability. There is so much math involved that maximum rpm is affected. I've had it above 6000rpm with the C80100 unloaded, but 4-5000rpm is what it comfortably does. Got to re-gear.
/Mattias
Thought I'd make an update of recent controller activities. I've been working with a control method called FOC (Field Oriented Control) or vector control. This is the type of AC-motor control used in industry and in cars such as the Prius etc.
It's main feature is that it feeds the motor with sinusoidal voltages, instead of the step voltages used in trapezoidal control. This is supposed to make the motor go smoother and quieter. From what I've read, it's a tie with the trapezoidal method in terms of torque production.
The basic idea is to let the controller work with a DC model of the motor, instead of dealing directly with the three-phase sinusoidal reality. A DC-value is easy to control with conventional PI-control.
What I like the most, though, is that I now have phase current sensors. This is a blessing, I can only regret I didn't use this earlier. A MOSFET has yet to fail, which is NOT what I'm used to when developing these controllers.
Some vids from initial testing.
http://youtu.be/p4GXnPsJM4A
http://youtu.be/IwNU9RmiERc
http://youtu.be/FSaUIxaZzzQ
http://youtu.be/s23fTaYHYpI
Startup is still - as with any sensorless method - an issue I haven't bothered much about. A slight push is all it takes to take off, this soon becomes a reflex. Overall, I like this control method, it's every bit as robust as the six-step control I had before. What I don't like is the rpm-capability. There is so much math involved that maximum rpm is affected. I've had it above 6000rpm with the C80100 unloaded, but 4-5000rpm is what it comfortably does. Got to re-gear.
/Mattias
incememed
10 W
Looking for someone to test this prototype
Ok, so this controller is finally(!) in a state where it could be of use to others. I have a prototype that I'm now looking to send to someone to test it, abuse it at will and give feedback.
This development was originally spurred by bicycle experiments many years ago with the C80100-motor, trying to drive it first by using the ESC, and then by retro-fitting hall sensors and running a conventional BLDC controller, none of which worked satisfactorily. The idea was always to have a robust, fail-safe, lightweight, compact, weather-proof, fit-and-forget controller that would be prevented from letting up smoke no matter the abuse.
One of the first steps was to eliminate the hall sensors. From there on it's been all about making robust, both electrically and in the control. It's getting there, and now I would like to have some users testing it in their respective environment.
The prototype in question is rated 84 V and 360 A sinusoidal phase current. It has a 140x90 mm footprint and weighs about 800 gr. There will be a similar 126 V prototype available soon.
What is needed of you to make it go is
- Knowledge of your motor kv, resistance, inductance and number of magnet pole pairs
- A PC to load the configuration and subsequent firmware updates that may result from your feedback
The controller is supposed to be able to control any surface mounted permanent magnet motor. So far it has been successfully tested with the Stealth Fighter, the Qulbix (QS motor) and many different "Turnigys" including the C80100. I'm currently working with another forum member to add Revolt to this list. He has also provided valuable commentary on the documentation and pioneered the programming procedure.
If you think it would be fun to experiment with this prototype, PM me or reply to this thread. Preferably you are in Scandinavia/Europe but not a requirement. A requirement is however that you have been posting on ES for at least a few years.
You are not liable for any damage made to the controller. You may use the connectors provided with the controller or use connectors of your preference. You agree to return the controller at your own expense after 1-2 months of use for analysis, regardless of whether it's working or not, at my discretion. Should you still want to use it after that, in appreciation of your effort, it'll be yours for about half the price of a compatible controller on the market.
Documentation of the controller is here:
https://drive.google.com/drive/folders/1SrqjgC2lSxXCAzWI8V--YkTYgAr2jAxa?usp=sharing
Ok, so this controller is finally(!) in a state where it could be of use to others. I have a prototype that I'm now looking to send to someone to test it, abuse it at will and give feedback.
This development was originally spurred by bicycle experiments many years ago with the C80100-motor, trying to drive it first by using the ESC, and then by retro-fitting hall sensors and running a conventional BLDC controller, none of which worked satisfactorily. The idea was always to have a robust, fail-safe, lightweight, compact, weather-proof, fit-and-forget controller that would be prevented from letting up smoke no matter the abuse.
One of the first steps was to eliminate the hall sensors. From there on it's been all about making robust, both electrically and in the control. It's getting there, and now I would like to have some users testing it in their respective environment.
The prototype in question is rated 84 V and 360 A sinusoidal phase current. It has a 140x90 mm footprint and weighs about 800 gr. There will be a similar 126 V prototype available soon.
What is needed of you to make it go is
- Knowledge of your motor kv, resistance, inductance and number of magnet pole pairs
- A PC to load the configuration and subsequent firmware updates that may result from your feedback
The controller is supposed to be able to control any surface mounted permanent magnet motor. So far it has been successfully tested with the Stealth Fighter, the Qulbix (QS motor) and many different "Turnigys" including the C80100. I'm currently working with another forum member to add Revolt to this list. He has also provided valuable commentary on the documentation and pioneered the programming procedure.
If you think it would be fun to experiment with this prototype, PM me or reply to this thread. Preferably you are in Scandinavia/Europe but not a requirement. A requirement is however that you have been posting on ES for at least a few years.
You are not liable for any damage made to the controller. You may use the connectors provided with the controller or use connectors of your preference. You agree to return the controller at your own expense after 1-2 months of use for analysis, regardless of whether it's working or not, at my discretion. Should you still want to use it after that, in appreciation of your effort, it'll be yours for about half the price of a compatible controller on the market.
Documentation of the controller is here:
https://drive.google.com/drive/folders/1SrqjgC2lSxXCAzWI8V--YkTYgAr2jAxa?usp=sharing
Sounds like fun...not sure I have a good way to measure the inductance or resistance of my MXUS 4503 or 4504 motors (though this is probably documented here on ES or elsewhere).
The SB Cruiser trike those motors are on is big and heavy and needs to frequently accelerate quickly from a complete stop (0-20MPH in <4 seconds) on my short work commutes and other trips.
It has an EIG NMC 14s2p battery capable of supplying peaks of 400A, though it doesn't usually have to supply even a quarter of that, less than about 20A during cruise. IIRC it's 8G / 10G wiring from battery to controller, with a 63A breaker (that hasn't popped in usage so far, but is bypassable).
Uses a CAv3.1 for monitoring (and eventually control of some things).
Presently still using a couple of generic type of controllers to run the hubmotors; still building Lebowskis to replace them with.
Am in Phoenix, AZ, USA, though. However, that would let you test it in relatively high temperature environmental conditions.
The SB Cruiser trike those motors are on is big and heavy and needs to frequently accelerate quickly from a complete stop (0-20MPH in <4 seconds) on my short work commutes and other trips.
It has an EIG NMC 14s2p battery capable of supplying peaks of 400A, though it doesn't usually have to supply even a quarter of that, less than about 20A during cruise. IIRC it's 8G / 10G wiring from battery to controller, with a 63A breaker (that hasn't popped in usage so far, but is bypassable).
Uses a CAv3.1 for monitoring (and eventually control of some things).
Presently still using a couple of generic type of controllers to run the hubmotors; still building Lebowskis to replace them with.
Am in Phoenix, AZ, USA, though. However, that would let you test it in relatively high temperature environmental conditions.
incememed
10 W
We don't get much of Arizona heat around here, I think it would be an excellent venue.
I did find some info on the forum, including an inductance value for a MXUS 3T which I believe would apply to the 4503?
kv / R (mohm) / L (uH) / pp
4503 11.9 / 72 / 230 / 23
4504 8.9 / 112 / 307 (extrapolated) / 23
While accuracy in motor parameters may have some measurable impact, there is a fairly wide range where human perception will tell no difference in how it drives. So, having ballpark values, the tuning can be dialed in quite well.
The controller needs to be told the resting level and full throttle level of the CA throttle signal, if other than 0 V / 5 V, respectively. This is in the settings sheet.
Also, from the CA, you need to connect both GND and Throttle signal to the controller throttle connector. This is because the logic (5 V) circuit of the controller is galvanically separated from the main voltage, meaning that battery negative and logic GND have no connection in the controller. So in order for the throttle signal from the CA to have any meaning to the controller, its logic GND must be connected to CA GND (effectively reconnecting battery neg to controller logic GND).
If you prefer, the settings can be preprogrammed before shipping. All you need to do is to fill out the green fields of the first sheet of Settings&Stats.xls in the Documentation folder.
I did find some info on the forum, including an inductance value for a MXUS 3T which I believe would apply to the 4503?
kv / R (mohm) / L (uH) / pp
4503 11.9 / 72 / 230 / 23
4504 8.9 / 112 / 307 (extrapolated) / 23
While accuracy in motor parameters may have some measurable impact, there is a fairly wide range where human perception will tell no difference in how it drives. So, having ballpark values, the tuning can be dialed in quite well.
The controller needs to be told the resting level and full throttle level of the CA throttle signal, if other than 0 V / 5 V, respectively. This is in the settings sheet.
Also, from the CA, you need to connect both GND and Throttle signal to the controller throttle connector. This is because the logic (5 V) circuit of the controller is galvanically separated from the main voltage, meaning that battery negative and logic GND have no connection in the controller. So in order for the throttle signal from the CA to have any meaning to the controller, its logic GND must be connected to CA GND (effectively reconnecting battery neg to controller logic GND).
If you prefer, the settings can be preprogrammed before shipping. All you need to do is to fill out the green fields of the first sheet of Settings&Stats.xls in the Documentation folder.
We'll also have the chance for rain, with the higher humidity and weather patterns for the next little while.incememed said:
AFAIK the MXUS 3T (3000w) is the 4503, and the 4T is the 4504, and those value ranges sound right, from what a quick search finds, like here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=91144&p=1390038#p1390038
and here
https://endless-sphere.com/forums/viewtopic.php?f=2&t=92101
I have various multimeters, including an old Fluke 77 III (but no current measurement with it as the fuses blew long ago, and are expensive), and another Fluke I forget the model of, and a little mini-oscilloscope. If there's a way to get the readings we need using those, I can try.
(even if it's just readings of other things to do calculations with).I have to verify which one is on the right side, but that's the one I'll test with (at least at first), I think it's the 3T (4503). I depend on the braking from the left side more than that on the right, so until I "know" this controller's braking behavior I'd rather trust the one I know well.
(it's hard enough to cause some brake steer to the left).T
That's easy enough. At present the CA doesn't drive the system, just monitors it, so it's directly controlled by the throttle (one for each controller/motor, in the rear wheels, so I can also help steer with them in sharper turns, and run them independently if something goes wrong with one).
So the voltage on the throttle will be typical hall throttle values; I'll have to measure them to see exactly what it is.
That's a good way to do things anyway; I already have a logic ground for the controls/etc wiring to the controllers (which are under the trike's deck near the wheels for short phase wires).
I can't clearly see which connector type you're using for the control wires or programming. Whatever it is, I might have a matching one here.
For programming/etc., I have a few USB-serial units (one old Belkin, one newer Belkin, both with DB9 serial end, one from Lyen with just pins on the serial end, and one from Grin Tech with the 3.5mm phono plug on the serial end).
Speaking of phase wires--are those PP75s? If so, I think I have three I can install on my motor wires. (or use a couple of SB50s, as those will mate with PP75s and use the same contacts) (at present all my wires are directly soldered, to prevent any possible connector issues, but it's probably a good idea to use connectors for the testing, so if somethign goes wrong on a commute I can just plug the other one back in).
My power wires are also soldered, but I have an SB50 I use for charging that I can plug this into instead of splicing in new power connections. I'd just use an adapter from PP45 to SB50 I already have.
Ok. I'll find an XLS editor and do that, to save a bit of time on the first setup and tests.
I suppose you probably don't want me to open it up and post a thread about all the internals and review it's operation (like i usually do with new controllers, etc).
incememed
10 W
Sounds good for getting a side-by-side comparison. Should you wish to match them, the throttle up and down ramps are settable in the Advanced parameters.amberwolf said:I have to verify which one is on the right side, but that's the one I'll test with (at least at first), I think it's the 3T (4503). I depend on the braking from the left side more than that on the right, so until I "know" this controller's braking behavior I'd rather trust the one I know well.
If not necessary for reason of the CA, it is suggested to keep battery neg and logic GND separated. This improves the working environment for the u-controller and current sensors, and protects from anything nefarious that may be going on in the power stage.
Anything producing 3.3-5 V signal levels should be fine. A serial converter cable with the proper connector will be included in the shipment. (All terminations are in the manual p. 21, for reference).
That's correct.
The prototype is yours to poke in anyway you wish. On this particular one, however, the signal cable holes were made too small, so the cables are really tight in their grommet, making it risky to try to remove the supply/signal side housing flange from the PCB, as the force needed may result in a sudden jerk that may snap the signal wires where they interface the PCB. So keep this flange close to the PCB and exit the PCB on the signal/supply side (p. 3 in manual). The phase side flange folds to be dragged along with the phase wires through the housing, no need to remove the contacts.I suppose you probably don't want me to open it up and post a thread about all the internals and review it's operation (like i usually do with new controllers, etc).
One consequence of this is that on re-assembly, for the three bolts that join the heatsink to the housing from the outside, fitting the nut closest to supply/signal flange is mildly tedious, since it should be done from the phase wire side.
That looks pretty compact for the rating. Nice job.
What did you end up using for hardware?
What did you end up using for hardware?
Well, they're not totally separate on the trike; the generic controllers still have common ground internally between battery side and logic side, so with the leftside controller still attached to the system, it'll still have common ground on everything tha'ts connected to it.incememed said:
I can separate the rightside throttle's wiring entirely from the leftside system, so they don't share a ground (presently they do, due to number of conductors I had available in the cable from front to rear, by running a separate 3-conductor cable from righthand throttle down to the SFOC5.
Since SFOC5 doesn't have inputs for them, it doesn't matter that the I'd still have a common ground via the ebrake lever, and the reversing switch. Those are common controls for everything on the bike, so I can't separate them. :/
( It would be nice if SFOC5 did have a reversing feature, to change rotation direction on the fly.
Some form of electric braking would also be nice; I personally prefer braking that actively powers the wheel to a stop, even though that uses up power rather than regenerating any, becuase it will actively stop the trike much more quickly. )
Ah--thanks.
FWIW, I know one of the motors has an NTC 10K thermistor, which appears to be the type SFOC5 is meant to read. But I don't remember which one it is--most likely it is the 4T on the leftside, so probably wont' get to test with motor thermal monitoring/rollback at least at first. (unless I move the sensor, or add one to the 3T on the rightside).
At least until the testing is over and you need it back.
Then once it's here, I'll start a thread for the testing, linked to here. I haven't seen anything on the forum about SFOC5 so far except this thread, so it should add some info here for you about it (not exactly an ad, but call it public review data that might promote SFOC5, depending on results.
) I notice the manual describes session logging; if that'll be useful I'll try to get and post the logs along with other trip information gathered by the CAv3.1 and myself.
I can easily build the LED status monitor (dashboard) to put up on the bars for realtime usage; is there a cable length limitation for it? (it'll probably have to be 8-10 feet long to get up there).
So more or less like the generic controllers, though those disasemble that way becuase there are lots of wires all on the one end, so it's just easier to do it that way.
Pretty sure I know what you mean, but I'll see for sure once it's here.
I've attached an edited version of the settings file with what should be the right settings for SFOC5 on my system, including battery/etc.
Since I don't know what the phase amps are coming from my existing generic 12FET, I've just set the phase amps limit to what I found in the main MXUS thread, of 150A. Since the throttle controls the amount of amps directly, I can limit this easily by hand to what works without breaking things. (if I can't manage to do it by hand I can use the CA to do it for me if I have to, but that ties the logic and battery grounds together again, so reprogramming SFOC5 here would be a better solution).
Oh, just as an aside, you note a few times in this thread that sensorless isn't smooth/strong/etc at startup, and may require an external kickstart (pedalling/pushoff/etc).
I just thought I'd point you to Lebowski's new controller version-in-progress where he's fixed that, in case you'd like to change that (maybe you can glean something from it, or even work with him to implement it in yours, if he's willing (I have no idea)).
Current thread
https://endless-sphere.com/forums/viewtopic.php?f=30&t=94865&hilit=sensorless+standstill
Earlier thread
https://endless-sphere.com/forums/viewtopic.php?f=30&t=54918&hilit=sensorless+standstill
I just thought I'd point you to Lebowski's new controller version-in-progress where he's fixed that, in case you'd like to change that (maybe you can glean something from it, or even work with him to implement it in yours, if he's willing (I have no idea)).
Current thread
https://endless-sphere.com/forums/viewtopic.php?f=30&t=94865&hilit=sensorless+standstill
Earlier thread
https://endless-sphere.com/forums/viewtopic.php?f=30&t=54918&hilit=sensorless+standstill
incememed
10 W
fechter said:
Thanks. Housing and board space are definitely approaching full utilization.
The 84 V is 18x IRFP4468 and the 126 V variant is 18x IRFP4568.
incememed
10 W
I have put reversing on the list of things to look into, just after regen braking. Looking to confirm core functionality and universal applicability, as well as ease of setting up before adding more features.amberwolf said:
A make-shift one will be included in the shipment, to get you up and running. No limitation in cable length for you to do your own.
Looks fine, I'll set it up. Let me know where to ship it.
incememed
10 W
Thanks. I am indeed following this thread, would be great to see it work out.amberwolf said:
incememed
10 W
That would be very useful. We may add or subtract some signals along the way if need be.amberwolf said:
incememed said:
Sounds good--if there's a way to update firmware at my end I could test those "live" if you get that far while it's here. (though I guess that isn't really possible without the inputs to do it wired out--unless there's open pins I could connect controls to for it on the board inside).
BTW--rather than *just* regen braking, you might look into active powered braking, which can stop *much* more quickly under heavy loads, especially in situations where battery charging current can't be made high enough to put enough drag on the motor to make decent braking force. (but where discharge current can be as high as necessary, up to the limit of the controller) It will *use* power rather than recovering it, but the extra braking power is worth it--especially if there is proportional control over that.
The generic controller I have on the left wheel that has that feature, and it's a tremendous help with the trike, especially loaded down or pulling the trailer full of stuff.
Then I can just lengthen / add the cable I need to make it reach.
I guess a destination would help.
Pm'd.
incememed
10 W
Firmware updates will be possible. If we ever get to pinouts and reversal, however, it means we had a good month.amberwolf said:
Absolutely, the way regen would be implemented in vector control is negative torque demand (instead of just zero, as throttle off would normally render), which would be revoked as the vehicle approaches zero rpm. The torque magnitude would be a setting, the negative demand would kick in when the conditions Throttle off and Above a certain rpm are both true.
As of now, by increasing the Torque down-ramp setting, power can certainly be regenerated while slowing down the vehicle, at the expense of coasting.
incememed said:
Guess we'll see how things go.
It would be better if this was engaged via a separate input, rather than only an automatic feature.
For those that don't want to use a brake switch to engage it, they just short that input to it's active level.
For those that need braking to only occur at specific moments, but also don't want or need to keep throttle active all the time, they wire the input up to their brake lever switch.
Personally, I'd prefer a proportional control over the braking that is controlled via the actual brake lever (analog hall sensor, cable-actuated pot or throttle, etc).
I don't have that at present, and with much more braking power than I have now, I might have problems with stress on the axles from the sudden torque application (I've broken them under other stress conditions). But I actually need more braking power; it takes too long to brake under just electric braking at this time--I just don't want to have to always apply it suddenly and fully.
I'm sure others would like that, too.
Something to consider for future revisions.
That kind of braking I don't think I would want, but I'll test it out after operating it "normally" first. At least it would be more controllable than I have right now.
(As noted above, I'd rather have braking controlled solely by a braking input, once it's an option.)
incememed
10 W
Snapshot from step response test made prior to shipping to AZ. It shows the controller trying to follow a sudden increase in the torque demand, corresponding to a very rapid twist of the throttle from its minimum to maximum position.
The setup is a C80100-180 motor with bike wheel load (bike hanging in bike stand).
The test slowly accelerates the motor to 2000 rpm, and then instantly ramps the torque producing current (Iq) reference to the maximum allowed 360 A (approx at the 2 msec mark in the graph). The motor accelerates to >7000 rpm in the time frame shown in the graph.
The motor experts I have had the privilege to talk to all ascertain that sensored control will outperform sensorless, which makes sense, at least when assuming very accurate sensors. In vector control, though, all setups sensored and sensorless (for rotor position) are still relying on the current sensors, which will introduce at least some error in the d and q current vectors.
One conclusion that can be drawn from he graph is that in a worst case scenario - currents high enough to introduce saturation, violent acceleration and instant throttle movement from zero to rated current - the error is around 10%.
The setup is a C80100-180 motor with bike wheel load (bike hanging in bike stand).
The test slowly accelerates the motor to 2000 rpm, and then instantly ramps the torque producing current (Iq) reference to the maximum allowed 360 A (approx at the 2 msec mark in the graph). The motor accelerates to >7000 rpm in the time frame shown in the graph.
The motor experts I have had the privilege to talk to all ascertain that sensored control will outperform sensorless, which makes sense, at least when assuming very accurate sensors. In vector control, though, all setups sensored and sensorless (for rotor position) are still relying on the current sensors, which will introduce at least some error in the d and q current vectors.
One conclusion that can be drawn from he graph is that in a worst case scenario - currents high enough to introduce saturation, violent acceleration and instant throttle movement from zero to rated current - the error is around 10%.
The SB Cruiser trike is now ready for whenever the controller arrives.
I've put PP75s in the phase wires of the existing Grinfineon (leaving the hall wires directly soldered to the motor).
I put a connector into the ground and throttle signal, too. I didnt'have much in teh way of even remotely water-resistant connectors (since its' the rainy season, such as we get), and the only one I had three of (one for the Grinfineon end, one for the throttle end, and one for the SFOC5 end) was the "turnigy" bullets off some old dead LiPo packs. I'll put the last one onto the SFOC5's open throttle wires once it arrives.
Since the SFOC5 already has PP45s on the power connector, then at first I'll just use the existing spare PP45 charging port to power it (it's right by the space the controller will be mounted to under teh cargo deck). If that turns out to be problematic due to the relatively small wires on that charging port, I'll change the PP45s on the SFOC to an SB50 and mate that to the regular SB50 charging port that has pairs of much thicker wires.
I dug out some old computer extensions (VGA, serial, keyboard, etc) to use for the "dashboard" LEDs from teh handlebars to the controller.
BTW, I wasn't sure based on the manual if it's possible to stream the log data live out to a PC. If it is, I can carry the laptop in either the seatbox or the cargo area, and log stuff directly to it.
I'd like to also log the CA3.1 data to teh laptop, which would make a comparison for some things. It's shunt reads both controllers, but I have separate throttles and use them in specific situations so I know generally which data should be for which controller (or both).
I should be able to use two separate USB-serial devices on different USB ports, and two separate instances of terminal/logging programs, on one of the laptops. I have some pretty old ones, Win98, maybe WinXP, with actual serial ports, if I have to use those with just plain serial cables. I also have a win10 laptop but it's my main computer so don't really wanna carry that around much.
I also have an old android tablet, with an external USB port but I have no idea if I can read USB-serial stuff with that.
I've put PP75s in the phase wires of the existing Grinfineon (leaving the hall wires directly soldered to the motor).
I put a connector into the ground and throttle signal, too. I didnt'have much in teh way of even remotely water-resistant connectors (since its' the rainy season, such as we get), and the only one I had three of (one for the Grinfineon end, one for the throttle end, and one for the SFOC5 end) was the "turnigy" bullets off some old dead LiPo packs. I'll put the last one onto the SFOC5's open throttle wires once it arrives.
Since the SFOC5 already has PP45s on the power connector, then at first I'll just use the existing spare PP45 charging port to power it (it's right by the space the controller will be mounted to under teh cargo deck). If that turns out to be problematic due to the relatively small wires on that charging port, I'll change the PP45s on the SFOC to an SB50 and mate that to the regular SB50 charging port that has pairs of much thicker wires.
I dug out some old computer extensions (VGA, serial, keyboard, etc) to use for the "dashboard" LEDs from teh handlebars to the controller.
BTW, I wasn't sure based on the manual if it's possible to stream the log data live out to a PC. If it is, I can carry the laptop in either the seatbox or the cargo area, and log stuff directly to it.
I'd like to also log the CA3.1 data to teh laptop, which would make a comparison for some things. It's shunt reads both controllers, but I have separate throttles and use them in specific situations so I know generally which data should be for which controller (or both).
I should be able to use two separate USB-serial devices on different USB ports, and two separate instances of terminal/logging programs, on one of the laptops. I have some pretty old ones, Win98, maybe WinXP, with actual serial ports, if I have to use those with just plain serial cables. I also have a win10 laptop but it's my main computer so don't really wanna carry that around much.
I also have an old android tablet, with an external USB port but I have no idea if I can read USB-serial stuff with that.
incememed
10 W
Sounds great. FYI, a throttle side connector is in the box.
The max/min values of some key variables are available to paste and visualize into the Stats sheet. They currently reflect what I like to look at post-session, such as heatsink temperature, torque demand and torque delivered (degree of overshoot), and more. Your input may change or augment this set of variables.
The Status LED-panel and post ride Stats are a functional minimum to understand what is going on in the controller. In addition to this, a host of variables (speed, torque, battery current, etc) are transmitted to the Communication port in real time. These can be used for data logging or a more featured dashboard. The format of the real time variables and the communication protocol are specified in the manual. I have not developed anything around this data, the user or third party must provide receiving side hardware and software.
The max/min values of some key variables are available to paste and visualize into the Stats sheet. They currently reflect what I like to look at post-session, such as heatsink temperature, torque demand and torque delivered (degree of overshoot), and more. Your input may change or augment this set of variables.
The Status LED-panel and post ride Stats are a functional minimum to understand what is going on in the controller. In addition to this, a host of variables (speed, torque, battery current, etc) are transmitted to the Communication port in real time. These can be used for data logging or a more featured dashboard. The format of the real time variables and the communication protocol are specified in the manual. I have not developed anything around this data, the user or third party must provide receiving side hardware and software.
incememed said:
That sounds like it might actually be a good thing.
The most common problem I've run into is oscillation in the current limiting which results in surging/overshoot. Normal approach is to use some kind of PID control loop but getting those dialed in can be a pain. If the loop response speed is fast enough it tends to be less of a problem.
