Hall Sensors'b'Gone

(EDITED first section after opening box; will attach pics later)

About midday, the dogs let me know the controller arrived, but I'm home sick today cuz I can't seem to stay away from the bathroom very long. :/ Hadn't even gotten to opening the package until a little more than an hour or so ago; took some pics then had to lay down again.



incememed said:
FYI, a throttle side connector is in the box.
Thanks--I'd assume that's the connector to the controller-box end? (I'll find out when I open the package :) )

So I'd use the one I have on one end of that cable, and the one you're supplying on the SFOC5 end. I'm using the one I'm using simply because I may need to swap the throttle signal from one controller to the other, either because of a problem or simply for comparison.




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.

Somehow I missed that...I'll go back thru the manual and read it again.


I have not developed anything around this data, the user or third party must provide receiving side hardware and software.
That's easy enough,as far as straight logging goes. :)

Anything like a dashboard...is probably beyond my abilities. But there is a project here on ES that takes teh Cycle Analyst's data stream and converts it to a tablet or phone display for a dashboard, so it might be possible to use a modified version of that to do it.



FWIW, it's likely that those people running a Cycle Analyst with the Cycle Analogger could use the Analogger to log this controller's data stream too, and perhaps adapt it to log both streams (though I'm not sure how that would be handled; I don't have one to try anyhow).

I'm sure I can figure a way to log both streams of data (CA and SFOC5) on a laptop. If the data is timestamped as it comes in (have to find a program that will do that, I guess) then there should be a way to directly compare moments in time between the two data sets.
 

Attachments

  • dsc07641.jpg
    dsc07641.jpg
    29 KB · Views: 2,139
  • dsc07645.jpg
    dsc07645.jpg
    26.9 KB · Views: 2,139
  • dsc07646.jpg
    dsc07646.jpg
    40 KB · Views: 2,139
  • dsc07648.jpg
    dsc07648.jpg
    33.1 KB · Views: 2,139
  • dsc07649.jpg
    dsc07649.jpg
    31.4 KB · Views: 2,139
  • dsc07651.jpg
    dsc07651.jpg
    31.7 KB · Views: 2,139
  • dsc07652.jpg
    dsc07652.jpg
    33.8 KB · Views: 2,139
  • dsc07653.jpg
    dsc07653.jpg
    31.4 KB · Views: 2,139
Couldn't sleep, so now that it's (just) under 100F outside (after midnight), I wired up the connector ends that came with it to the connector ends that mate with what I put on the trike, based on the pinouts in the manual.

Throttle only connects signal and ground; the 5v from SFOC5 is not used; my throttle still gets it's 5v from the Grinfineon it would normally be powered from. (this may be the source of a problem noted later; have to troubleshoot).

I cut an old VGA extension cable and used that to extend the "dashboard" LED/switch PCB so it will be able to reach up to the handlebars and mount there.
dsc07660.jpgdsc07661.jpgdsc07662.jpg
The motor temperature sensor is not connected yet, as the manual shows a second 3-pin connector for it, but there isnt' one on the controller itself. It does have a multiwire cable coming out of it, but there isn't a connector on it, so I'll need to determine the wiring of that cable; most likely it'll be easy enough if I open up the controller to see which color goes where. (assuming the fourth cable is actually for the temperature sensor; all the other cables are used--throttle (verified), data/programming port, and LED/switch dashboard panel. )


Didn't mount anything physically to the trike yet, but setup the trike with the righthand wheel offground, and did a basic power-on test.

As noted, I'll have to troubleshoot these issues and find out what I've setup or wired incorrectly.

On power-up, it sequentially lights the 1, 2, 4, and 8 LEDS. Then it blinks the center two, then the outside two also light (so all four are lit), then the two outside LEDS go out, leaving only the center two lit. I was being distracted by a couple of very scared St. Bernards due to someone setting off mortar-style fireworks at that moment, so I lost count of the number of times it did this. When it stopped it left the center two LEDs lit steady. It did repeat this at least once while I was testing, probably more than once, as I was not always looking at the display.

If I'm reading the codes correctly, the two center steady LEDs would be that the temperature sensor is not connected (makes sense), and the all four on would be either "internal error" if it's presumed this is a blinking code, or battery voltage gauge 4/4 (voltage less than 40% full) if it's a steady code.

I haven't calculated what the voltage is on the battery vs the settings I'd put into the spreadsheet, but that might be correct since I gave myself a bit of wiggle room on the LVC.


During this, the motor made some hissy-sounding tones; presumably the controller doing some checks.

After it remained steady, the motor continued to make a steady hissy-sounding noise. It's pretty quiet, but I suspect it's not supposed to keep making that sound all the time.

At no time during this did the motor move at all (the wheel is off-ground, just in case it did so).

Since there did not appear to be any actual error condition (except perhaps for the hissy sound from the coils of teh motor), I tried out a very gentle throttle test, and it did begin to spin up the wheel, though rotation is backwards (have to swap a pair of phase wires to fix that).

As I gently and slowly gave it more throttle, it reached a point where it sounded like a slam or a very loud fast grinding, just for an instant, and continued to spin. I backed off throttle at that point, and did not push it further.

At that point I was hot enough I decided to let the dogs guide me inside (cuz they were still scared from the fireworks boom), and write this up.

Sorry I still havent' posted the pics from the previous post, gotta fix teh card reader cable (I think Kirin tangled up in the cable and pulled it's connection apart...her and wires.... :roll: )
 
Sounds like we are right on track.

Low key hissy sound is normal, controller acting to maintain zero current.

LED code steady six is motor temp sensor disconnected. Steady 15 is batt volt gauge 4/4. They alternate with one sec latency.

Blinking LED code would not alternate, would blink much faster, would turn off the power stage, and would require a restart.

If you would like to connect the motor temp sensor included in the box, the color coding is in the manual.

High rpm noise we'll have to work on. I noticed this just the other day while testing a motor type I had never run before. Code is now improved. This is the first update I would like to push once you are up and running. There are some other improvements in there as well.

(It may also be some motor parameter that is actually way off from what we estimated. One 130 kv motor I recently bought turned out to be the 180-variant, despite the label. The 80 kv motor I recently tested showed a 93 kv when measured with the scope.)

Since in the general case there may initially be motor parameters that are not perfect, the controller upon detection of very high current is setup to gently power down to zero current while showing steady code 10, in this way letting the user know tuning is not perfect. The intention is that whatever the user does, controller HW and road safety are never in jeopardy.

When you get the chance, take it for a spin to verify that we have basic functionality and mobility.
 
Thanks!

The first loaded test will probably be tonight after work at the earliest, or tomorrow or Saturday more likely, as I want to:

--securely mount the controller and wiring, including the status/LED/switch panel (and see if I have a little clear box I can put it in to prevent water in the switch and/or potential shorting of stuff on the back of it to the handlebars). If I don't, a tic-tac candy container should work and I can grab one of those while out and about for other stuff.

--ensure if I break something on the trike itself, I have time to fix it before I have to use it for work

--setup a "live feed" logging laptop of the controller's output. (I'll add the CA's logging later, unless it turns out to be easy to do two at once).

--read the log data from the initial power-on, if any.
 
MOUNTING:

Haven't got the live feed / logging going yet, but did mount up the controller and LED status board (inside a mini tic-tac box) and tie the wiring down. Everything still behaved as before, so I didn't break anything. (yet) :)

Then I swapped phase wires to get the motor running forward.

STATUS LED CODES:

I fully charged the traction battery, and now the LED status only reads a steady six, except every 20 seconds or so it goes to a 13 for less than a second, then back to the six.

13 is undefined (and I think 11 would be it's inverse in case I'm reading these backwards, but it's also undefined). With the switch on the lower left, and the LEDs across the top, I think they are 8 4 2 1, correct?


LOADED TESTING:

I'll get the trip log tomorrow, too tired to follow the steps to do it right now.


First, I did a low-throttle on-ground power test in the yard. There was no feeling of response at all; upping the throttle eventually got (at about half throttle) the motor to begin "rocking" but didn't spin forward on it's own at all.

I used the generic sensorless controller on the left wheel to get started, while still holding throttle at mid on the right wheel's SFOC controller, and at 4-5MPH I began to feel the right side pull; then I ran out of yard and had to stop.

Next was a test up and down the street at the front of my house, as that's the longest straight run right here. This late at night (about 1am at the time) there's no one on the street so is safe enough to do testing where I have to look at the displays on the handlebars a lot and mentally note stuff. :)

I had to startup each time using the generic sensorless on the left wheel, and sometimes a partial pedal stroke. Even if I then let off the throttle on the left wheel completely, and no pedalling, and even full throttle on the right wheel (SFOC5) then unless I was already somewhere around 4-5MPH I couldn't feel any acceleration/pull from the right wheel.

Once at that point, I could feel gentle smooth acceleration, like it was barely pulling me along. I saw around 28A on the CA at this point, fluctuating up and down, but I was paying more attention to the speed and feel so don't recall the full set of readings.

There were a few random "jerks" indicating most likley that the motor parameters are not fully tuned (connections are fine).

As noted above, the hissing noise is audible/feelable even at this stage.


While very quiet, even silent (ignoring the hiss), it doesn't have anything like the acceleration power I'd hoped it would. Might need to up the amps settings, if motor parameters don't fix it.


NOTES

NOISE:
The "hissing" is really loud. Like a large tire with a very bad leak.

Loud enough to hear while riding (even just coasting), over the wind and road noise, up to something like 12-13MPH. After that point I have to strain to hear it, but I can still pick it out in quieter moments.

Worse, I can *feel* it thru the frame and suspended-mesh seat, over the road vibrations, as a low random-frequency-feeling vibration. As speeds increase so does amplitude of road vibrations, so at some point around 10-12MPH it becomes difficult to tell which is which.

It doesn't change amplitude under any circumstances so far, though it does change frequency (upward?) during the 13 LED code.


The actual motor operation, while being driven by the controller, is silent as far as I can tell--I can't hear it over the hiss or the road/wind noise, at any rate.

I suspect different motors might sound different, and be quieter or louder depending on their design and size.

I can imagine many people being quite disturbed by the noise and hence not using this controller. If the point of having this controller on a bike was silence, I wouldn't want to ride it on bike paths or other quiet places without sufficient traffic/etc to drown out the hiss.

(the noise of a typical/generic non-sinewave controller is much louder, but it also only occurs while actively powering the motor to move the wheel. Since SFOC5's hiss is continuous anytime it is on, it's actually much more annoying.

EXTRA DRAG?
Along with the noise, the controller "holds" the wheel in position a bit more than lightly, whenever no throttle is applied, and appears to slightly attempt to fight manually turning the wheel. At a guess, this probably means wasted power, and extra heat generation inside the motor, and extra drag on the wheel when not actively powering the motor with the controller.

When it's off ground, I can see the wheel jittering back and forth just a teensy tiny bit sometimes.



STARTUP FROM STOP

I knew it wouldn't be able to take off snappily from a stop like a sensored controller, but I did expect it to do quite a lot better than it does right now (a crappy generic 15FET beats it all up). There may be settings to change to fix this (motor parameters, etc), which I'll explore tomorrow.

The generic controller stutters and occasionally "grinds" for a second at startup, but in most cases it is at least capable of really quickly getting the trike going from a stop. In some cases it won't move and I have to just very slightly push the trike forward either flatfooted fred-flintstone style, or pedalling just a partial rotation. Neither one of those is good, because it hurts my knees/ankle to do it either way, but as it's only a second or less I can usually handle it. (normally the sensored Grinfineon on the right, used along with teh sensorless generic on the left, gets the trike started with no help from me).

Even with just the generic sensorless, it doesnt' take long to reach 20MPH, and acceleration from a stop is very quick (as long as it starts forward smoothly or I help it).

However, at least with the settings it presently has, the SFOC5 is not able to get the trike started quickly. The worst part is that it accelerates slowly, feeling like it is either a linear acceleration curve or that it is only building speed faster as speed increases. The opposite of the way the other controllers do it, and the opposite of the way I need the trike to accelerate in traffic.



TEMPERATURE SENSOR:

The temperature sensor wiring requires +5v on one side, but all the (hub) motor sensors I know of (including on mine) that come built in are wired with ground on one side, so you might want to redesign that part of your circuit so the sensor wires can be plugged into existing motor temperature sensors (if they're compatible types, but it's a common sensor type). Or have it switchable, if there's a design option that lets you do that.

Before I can use the temperature sensor with the present design, I will have to open up the motor and rewire the sensor to put it's ground leg on the hall 5V line. That part isn't difficult, but having to take the wheel off the trike to do it is.

(otherwise I'd have to cut the hall cable entirely off the Grinfineon-to-motor connection to disconnect the ground wire from anything, so I could use it as the 5v line from the SFOC5. I really don't want to do that, since that would leave me unable to just move the phase and throttle wires back over to the Grinfineon in just a moment, should I have to do that roadside for any reason. I could put a connector in there, but I don't have any waterproof ones that have enough wires, which is why I soldered them in the first place).

More later; finally getting tired enough to doze off soon, I think.
 
Finally got the USB connection to the SFOC5 setup; had some trouble because the regular prolific driver has been sabotaged by prolific to not work with anything except their newer genuine chips, and had to find a driver that will work with the clone chip in the cable that came with the SFOC5. This page was useful, if anyone else needs to do this:

http://www.totalcardiagnostics.com/support/Knowledgebase/Article/View/92/20/prolific-usb-to-serial-fix-official-solution-to-code-10-error

using this driver

http://www.totalcardiagnostics.com/files/PL2303_64bit_Installer.exe

Download and save the "PL2303_64bit_ Installer.exe" by clicking here.
Unplug all USB-To-Serial adapters from your computer - and double-click on "PL2303_64bit_Installer.exe"
When it prompts you, plug in one (1) of your USB-To-Serial adapters and click "Continue".
Reboot your computer. That's it


SESSION LOG / STATS:
Now that's out of the way, I followed the procedure in the SFOC5 manual, using Realterm 2.0.0.70 setup as manual specifies, and got this string:

12 34 7F FF 00 00 7F FF 00 00 00 00 B7 28 00 00 01 F7 01 61 02 D7 FD FA
02 26 00 00 00 00 00 00 00 01

When pasted into the Settings/etc.xls file in the stats section as the manual specifies, I get what look like invalid readings:

Many values (anythngg I don't list below) show either #N/A or #NUM! or are blank.

Min motor temp says 85C, probably due to no sensor connected
Max RPM is zero
Min Battery Voltage is 407.82
Max Battery Voltage is zero
Max IA is 10
Max Ib is 7
Max I is 14
Max ID is -10


Are all of those from incorrect motor parameter settings?



I have reread the manual a few times, and don't see a way to read the settings back out, to verify that they are actually set to what they should be. Is there a way I have missed? If not, that might be something to add in the future.




I'm presently confirming what motor values I can, as well as throttle voltages, etc.

Note taht at present throtttle goes directly to the SFOC5 and does not pass thru the CA, so the CA is only monitoring battery voltae and current on the whole system, and speed of the front wheel.
 
Very nice report, we have a lot to work with. This post will focus on the noise, much of the rest would be easier analyzed having the Stats.

Some background. Through the FOC algorithm, d- and q-currents are the DC representation of the sinusoidal phase currents. Being DC, they lend themselves to PI-regulation, something sinusoidal quantities readily do not, which is the whole purpose of the algorithm. When the phase currents are perfectly sinusoidal, the dq-currents are perfectly horizontal. The more distorted the phase current, the more jitter appears in the dq-currents. The proportional gain of the PI-loops (Kp) acts directly on the error, i.e. the instant difference between the dq-current references (perfectly horizontal) and their actual values.

The lower the speed and/or current, the more distorted the phase currents. This is because the bemf is low compared to other quantities and the phase current sensor signal-to-noise ratio is low, being that their measurement range is >600 A while the signal is a couple of tens of amps. The Kp amplifies this jitter and that is what is heard from the motor. As phase current shapes improve and become more sinusoidal, the hissiness fades.

The algorithm to determine the PI gains (Kp and Ki) in the Settings&Stats sheet is setup to render the most aggressive response possible to changes in the references quantity, while erring on the side of being robust. The aggressiveness is measured by the swiftness of response to a step increase in the reference. Thus Kp is maximized, and unfortunately so is its noise producing quality at low currents.

The aggressiveness (and thus the noise) can be tamed by the Multiplication factor in the Advanced parameters.

This is the simulated response from amberwolf's motor with the current settings, i.e. Multiplication factor 1.0. The step response is a fraction of a millisecond, roughly corresponding to one period in a 20 kHz system.
View attachment 6

This is the same motor with Kp and Ki two orders of magnitude smaller (Multiplication factor 0.01). It now takes some 5 millisec for the same response.
ambwolfPIfact0_01.png

The gains can be diminished to a certain degree with little or no perceived difference to the person behind the wheel. At some point, however, the response becomes weak enough to risk instability.

Here are some 150 A step response tests using a C80100-80 motor and a free-spinning bike wheel as load. The difference is between 1.0, 0.5, 0.1, 0.05 and 0.01 Multiplication factors, respectively. (The end of each series is marked by all three quantities being set =0.)
factor1.png
factor0_5.png
View attachment 3
View attachment 2
View attachment 4
 
Sme thoughts on user-friendliness for the future:

PROGRAMMING PROCEDURE

If there is any way to modify the controller firmware so it does not require physical disconnection of the serial end of the USB-serial in order to do various things but instead could leave it always connected, and either have a "button" on the status LED panel or something automatic, it would be highly preferable.

For now I will probably just open the controller and replace the short cable to the programming connector with a significantly longer one, at least a couple of feet, so I can run it up around the frame under the deck to the seat/cargo box or somewhere else easily reached. Probably later tonight.

Before I do that I'll see if simply putting a switch into the TX wire of the serial end of things will do it; if so I can just have a switch on the USB-serial device to enable/disable programming mode, and le me use the same device to just log data to a file in realtime, too.



In my use case, for instance, the controller is under the deck of the trike, just inboard of the front edge of the right rear wheel. Without tilting the trike up on it's other side, it's difficult to reach the controller to plug/unplug, which has to be done for each change made to settings, log display, etc.
 
incememed said:
Very nice report, we have a lot to work with. This post will focus on the noise, much of the rest would be easier analyzed having the Stats.
The technical data (not quoted here) is helpful in understanding the reason the noise happens.

However...I don't understand why at zero throttle input, it's still putting any phase current thru the motor at all. It's wasteful of power (though it must be very small, as the CA does not indicate anything above it's 0.0A (which is zeroed out for the existing controllers, so any load from the SFOC5 shows up above that.

It also, as noted, adds extra drag on the motor wheel the SFOC5 is running. Not a lot, but it's there, and I can feel it when trying to pedal, with SFOC5 switched on vs off. (the trike is very heavy and I'm not very strong).


IIUC, some of teh noise may be a consequence of incorrect motor parameters, affecting how the controller interprets the feedback it is getting?
 
TORQUE RAMP
How safe is it to play around with the Torque UP Ramp values, and would that get a quicker ramp up of speed? Is preset to default.

Acceleration is quite low at this time, and definitely needs to be much quicker.

I'm still experimenting with motor parameters (kV, uH, mOhm), to eliminate the cutouts/thunks at faster unloaded RPMs.

I should put a speedo sensor on the driven wheel, and a switch at the CA, so I can see what speed the wheel is at off-ground when various things occur. :!:


IIRC correctly, higher Torque DOWN Ramp value will essentially cause braking of the wheel when throttle values/demands drop below the actual present torque generation? Is presently preset to default.


DRIVELINE MOMENT OF INERTIA
Since my driveline is a hubmotor direct to the wheel/ground, should this setting be different than it is right now? Is still preset to default.
 
No idea what is different but I got valid stats on this most recent power up.

12 34 00 00 00 00 3C 51 41 05 00 9B 19 95 1A 33 1B 23 1C 23 37 46 28 D6
2B 67 04 3D 60 0A FE C0 02 90 1A 03


SESSION LOG / STATS:
Any values I don't list below show either #N/A or #NUM! or are blank.

Min heatsink temp is 45
Max heatsink temp is 45
Max RPM is 160 (off ground test)
Min Battery Voltage is 56.96
Max Battery Voltage is 58.34
Max IA is 137
Max Ib is 142
Max I is 279
Max ID is 206





I am now trying some different motor and throttle settings; this is the realterm send 1 data
0xF0 0x0F 0x05 0x57 0x13 0xF6 0x00 0xEA 0x03 0x6C 0x26 0x1C 0x13 0xB4 0x0A 0x8B 0x16 0xA2 0x14 0x1E 0x1B 0x44 0x5F 0x6A 0x02 0xA8 0x05 0x90 0x1E 0xAE 0x04 0x47 0x46 0x4B
 
A thought:

Since I haven't yet started that new thread in the testing section for this controller, would it be a good idea to have a moderator split off all of these posts out of your thread into a separate one for the purpose of these tests, rather than cluttering up your thread with them?

Or better to leave it all in one place, and then I just reference pertinent stuff already in this thread when I do make that new thread?




DOCUMENTATION

After re-reading documentation and thread, various parts over and over, looking for details I might've missed...I just finally connected the note in the manual that says that realterm only sends 32 bytes at a time, with the spreadsheet having realterm send 1, and realterm send 2 data fields. :oops:

I only sent the first field, so I'll have to retry with both fields, one after the other.

I think the manual may need some wording changes, or additions, to make a few things more explicit. I'll make some posts in a bit (maybe next few days if not tonight) containing a new version of the bits I've had a little trouble with, in case it helps others later. :)



LOAD TESTING

The test probably isn't valid since as noted above I didn't apparently finish telling the controller everything, but results anyway, and log later (after dinner and cooling myself off; it's hot and muggy out there, at 96F and somewhere around 35-40% humidity, even at 1030pm).

Whichever new settings did make it into the controller (from the send1 field) don't appear to have changed most of the behaviors, however the "stuttering" is worse, so I'll try changing the motor parameters in the other direction, one at a time, until it either gets worse or better, see if I can find a middle ground.

What I changed was
motor resistance up to 110.0 from 72.0
motor inductance down to 200 from 230
based on various posts about the MXUS 450x series.

Phase current limit (AACpeak) up to 300 from 150

I'm not sure why, but the original RPM Limit (RPM) of 690 was no longer accepted, and forced me to change it down to 680.


Battery peak DC cell voltage down to 4.13 from 4.15 (to give the more correct total of 57.8 when full).

Throttle fully engaged output voltage up to 4.3 from 3.8 (since its' directly connected and not via the CA).

The xlsx files are attached for reference.
 

Attachments

  • original shipped settings 072518 Settings&Stats SFOC rev 5 pub.xls.xlsx
    167.6 KB · Views: 69
  • experimental settings 072718 05 Settings&Stats SFOC rev 5 pub.xls.xlsx
    167.4 KB · Views: 62
Started a post here
https://endless-sphere.com/forums/viewtopic.php?f=2&t=92101&p=1398794#p1398794
in the MXUS thread collecting all the motor parameter data I can find.


Also, ignore previous posting about using the MXUS built in temperature sensor--apparently it's a KTY83/110 PTC, so not the type the SFOC5 is meant to read.

I'll have to open up the motor to install the supplied NTC 10k instead, if I want to monitor motor temps. Not sure how long it will be before I do that.
 
Apologies for the steady 13 code, a debug aide that was mistakenly left behind.

There were a few random "jerks" indicating most likley that the motor parameters are not fully tuned (connections are fine).
Throttle on/off? Rolling/standstill? High rpm? Always in the same situation, always the same type of "jerk"?

it doesn't have anything like the acceleration power I'd hoped it would. Might need to up the amps settings, if motor parameters don't fix it.
Right wheel will outperform left wheel eventually, anything else and I will change hobbies;) Remember, however, that unlike most controllers, torque is never more than what the user signals via the throttle. 25% throttle voltage means no more than 25% of max phase current setting will flow through the phases. It's like the gas pedal of a car, it only pulls you back in the seat if you floor it.

It doesn't change amplitude under any circumstances so far, though it does change frequency (upward?) during the 13 LED code.
Correct, there is some minor interference going on on the 5V bus. Although not a problem, it's an anomaly and will be addressed in any future HW revision. Well observed.

The worst part is that it accelerates slowly, feeling like it is either a linear acceleration curve or that it is only building speed faster as speed increases.
There is no manipulation, linearization, etc., between the throttle voltage and the torque demand. (There are only upper settings limits, rating limits and thermally or speed induced limits).

motor sensors I know of (including on mine) that come built in are wired with ground on one side
Noted. They actually share the same physical GND connection with the halls sensors?

and don't see a way to read the settings back out, to verify that they are actually set to what they should be.
While programming, once all settings have been successfully received (start of transmission and end of transmission special number sequences have both been acknowledged by the controller), the corresponding LED-code displays and the settings are echoed back by the controller to the serial interface program.

If there is any way to modify the controller firmware so it does not require physical disconnection of the serial end of the USB-serial
Done. It now resumes start-up after successfully having received the new settings. Steady code 13 now signals this for three secs before moving on.

For now I will probably just open the controller and replace the short cable to the programming connector
I recommend you keep everything closed for now and make an extension cord instead.

However...I don't understand why at zero throttle input, it's still putting any phase current thru the motor at all.
Very small currents are constantly generated by the position estimation algorithm. KTM, Kubergs and perhaps more have the same whisper.

IIUC, some of teh noise may be a consequence of incorrect motor parameters, affecting how the controller interprets the feedback it is getting?
Perhaps to some degree, but probably not significantly. You are the better judge of this, being so close to your motor.

How safe is it to play around with the Torque UP Ramp values, and would that get a quicker ramp up of speed? Is preset to default.
Default is max, corresponding to a few millisec to ramp up to full current, way beyond how quickly a human can twist the throttle. Refer to step response tests above.

I'm still experimenting with motor parameters (kV, uH, mOhm), to eliminate the cutouts/thunks at faster unloaded RPMs.
That's great. By all means, try some Multiplicantion factor as well, such as 0.7.
Let me know when you are ready to receive the firmware update. In the update, I have bypassed the cross coupling compensation algorithm, something I need to work on some more before releasing again.

I should put a speedo sensor on the driven wheel, and a switch at the CA, so I can see what speed the wheel is at off-ground when various things occur.
Good idea.

IIRC correctly, higher Torque DOWN Ramp value will essentially cause braking of the wheel when throttle values/demands drop below the actual present torque generation? Is presently preset to default.
That's correct.

Since my driveline is a hubmotor direct to the wheel/ground, should this setting be different than it is right now? Is still preset to default.
This is only used for speed limiting, i.e. if you put a say 300 rpm limit instead of the 690 your fully charged battery voltage would get you. Even in this case, this setting only alters how fast the controller hones in on your actual speed, a matter of seconds of difference depending on setting. Not important.

Min heatsink temp is 45
It's hot where you live! (Or you cycled the power on the controller right after some riding.)

I pasted your string, it seems you lost the last few values somehow, maybe they ended up in the cell below? This is what I get (using the filled in sheet you posted earlier)
ambwolfStats.jpg

It seems at 160 rpm (or 3680 e-rpm) you get the no-load thump? It's likely kv value or the cross coupling compensation issue mentioned above.

There is a 279 A spike on phase C, likely from the above issue.

I_D should be close to zero in a healthy setup.

I_Q should be close to whatever was demanded, in your case 150. Some 10-20% overshoot is expected once the setup is healthy.

The throttle has a resting voltage of 0.17 V, correct?

The instantaneous battery voltage indicates a value very close to zero (actually negative, hence the weird conversion), something I have never seen before. It is usually corresponding to some cell voltage in the low 3 volts range. We'll have to watch this and try to figure out what is going on.

You pulled an estimated 21 A from the battery, but I wouldn't assign that value too much of significance at this point, given the spikes in I_Q.

In the update, there is also a readout for the maximum torque demanded, not just the maximum throttle voltage.

Or better to leave it all in one place
Your/the moderator's call. I'm fine with having this conversation in this thread.

I think the manual may need some wording changes, or additions, to make a few things more explicit. I'll make some posts in a bit
Noted, and thanks.

Whichever new settings did make it into the controller (from the send1 field) don't appear to have changed most of the behaviors
Correct, nothing is programmed until all settings are received successfully, as announced by the LED-panel.

and forced me to change it down to 680.
This setting depends on the battery peak voltage.

Let's see what your new settings can teach us.
 
I'll read and reply to your reply in a moment, but first just posting the results of a real test ride. I like the controller...but it does need some improvement in responsiveness; maybe settings changes will do that. :)

REAL TEST RIDE:

Much of the below is a "feel", a bit rambly, comparison to the only other controllers I've had on these contraptions of mine: cheap generic BLDC 6, 12, and 15FET "ebike" controllers. Some sensored, some sensorless, but with mostly "adequate" performance, even with their noisy trapezoidal control and lack of features/etc. So I'm used to immediate full power if I ask for it (even if that is so hard on the controller it blows up :lol: ).

I'll have the ride stats/log after I get home, as the parking lot surfaces are all way too hot (even in the shade) to kneel down and reach under the trike to plug/unplug the programming cable serial end. I definitely need to put that switch in the TX line. :oops:

So I may sound harsh in some ways, with certain expectations set by that sort of thing. But I'm extremely impressed in other ways. :)

Anyway, it may not be the feedback you're after, but it covers some important things for hubmotor city-traffic use, for my purposes at least.


Took a 10-mile round trip to pick a few thing up and check thrift stores for useful items, and give the SFOC5 a workout in traffic and cruising on longer stretches without stops. Using the file attached in the previous post for the test ride, using the "known" phase resistance and inductance.

Using only the SFOC5 for everything except right turns (use the left motor to push into the turn) and any other tests noted below.

Once it finally gets goingg, it's good. Silent except for the hissing and the constant random vibration from that (since it has a lot of low frequency component that feels like an ICE car engine running a little rough, even just sitting still, but which doesn't change even while accelerating or at speed.


Acceleration is very poor, though quite smooth above 4-5MPH. It's actually difficult to tell that it *is* accelerating, because of that smoothness. :lol:

But it *feels* like it has a very long ramp to respond to throttle commands. Throttle is still directly connected to it, so the CA is not interfering. I fully max out throttle (4.29v output) from a stop (I'm not gentle with acceleration most of the time, I'm trying to get to 20MPH in as little time as possible, especially when I'm at the head of the line at a stop light when it turns green, with a bunch of impatient drivers behind me.

At zero to low speeds of up to 4-5 mph, it doesn't push the trike at all, doing either nothing but hissing at the 0-2ish mph range, or above that just pulsing the power to the wheel every...half second or so?...and sort of pushing at the trike a bit, as if someone walked past and put their hand on it as they went by. I can feel it but it is not significant thrust.

Above taht speed it begins slowly accelerating smoothly, and other than the constant hiss and vibration it's so quiet it's almost scary. :)

On one longer stretch of back street that has a long straight line of sight, no cars, no pedestrians, etc., and reasonably smooth surface, I tested acceleration time, with just this motor, vs with both motors (left side 4t, generic 15fet "80A"), with repeated runs both ways on the street, using full throttle until the moment I reach 20MPH.

By itself it takes just over 19 seconds to reach 20MPH. IIRC, that's actually worse than the old 9c 2807 motor with the generic 12FET (sensorless? cant' recall) 30A controller, though the trike was a bit lighter at the time, it had a lower-capacity lower-current capability old battery pack on it.

With both motors, it's around 4 and a half seconds, which is close enough to what I get (just under 4 seconds) with the Grinfineon 12FET 40A sensored in place of the SFOC5.


A rather disturbing thing was when I went up the driveway slope into one of the parking lots I have to pass thru on the way up here, which is rather steep and long compared to most. I am guesstimating it's around a 10-12 degree slope for about 20-ish feet, immediatly following a right turn into the lot from the street.

Aproaching at 17MPH, then letting it coast down to 10 or so just before the turn, then tickling the left motor's throttle to push into the driveway, then using the SFOC5 and right motor to push full throttle up the slope--it slowed down to less than 5MPH before I reached the top of the slope, and *just* began to get the "bumping" of the right wheel by the SFOC5 as it levelled out and started smoothly accelerating again.

I couldn't watch the CA's display at those moments (watching traffic behind and around me) but I saw 28A on there as my eyes passed it around the middle of the slope. I'd expect a lot more for full throttle on a slope with a few hundred pounds of trike and me. ;)

FWIW, peak battery current on teh CA for the trip so far is 84A, sagging voltage down to 52V. (rounded up/down; dont' recall the decimal ATM, will have that later). That includes current demand from the leftside controller, which could pull that current by itself.


Another issue may just be me getting used to a current throttle vs a "speed" throttle and that's that holding speed during cruising is difficult. Of course, I'm used to just holding the throttle in one position and maintaining something within half a MPH of my speed, on our relatively flat roads, when winds are constant or nonexistent (which is most of the time; today there wasnt' really any wind to speak of during that ride, not even a breeze when I started out).

With the SFOC5, the speed varies as much as 4-5MPH total, going up as much as 22MPH and down as low as 17.something MPH. Some of that is because of it's slow response as I change throttle position to compensate for the drift in speed, some of it is just me learning; don't know how much of each or any other factors yet.

More later.
 
I've broken up the reply since it was pretty long... :)

incememed said:
Apologies for the steady 13 code, a debug aide that was mistakenly left behind.
No worries--it's a "beta test", I expect a lot of stuff to need fixing or changing. :lol:

I've done a lot of beta testing over the years, of hardware and (mostly) software, and so far this is one of the most-finished things I've tested. :) Just needs a bit of tuning for this application, and me learning how to use it and program it, and it'll be really good.



Throttle on/off? Rolling/standstill? High rpm? Always in the same situation, always the same type of "jerk"?

Sorry, didn't give enough detail there. :oops:
--Throttle at full for onground tests
--throttle at very low ranges for offground tests (otherwise it goes quickly to full speed and jerks like this up to a couple times a second)
--at low throttle offground, it only jerks once rpm get above what would make walking speed, and not more than every several seconds if that.
--at low throttle offground above what might be 10-15mph (guessing without speedo on that wheel, jerks come more often the faster it goes.
--always the same type, as if the wheel were being braked for just an instant
--much more while unloaded offground (probably higher RPM, not sure so that's why I want to put a speedo on that wheel too)
--Is perfectly smooth rolling up from standstill offground
--rolling up from the around 2mph where it will begin powering the wheel it has a light pulsing push, but it' not a jerk--it's what appear to be normal operation.



Right wheel will outperform left wheel eventually, anything else and I will change hobbies;) Remember, however, that unlike most controllers, torque is never more than what the user signals via the throttle. 25% throttle voltage means no more than 25% of max phase current setting will flow through the phases. It's like the gas pedal of a car, it only pulls you back in the seat if you floor it.
Throttle immediately pushed to and held at full for onground acceleration tests. (I like hard accleration, and need it in traffic).

Is direct connection; not thru the CA, to ensure no interference by CA until I know the SFOC5 is doing what I want it to. :)

Throttle voltage range is 0.89v at zero throttle, up to 4.29v at full throttle.

SFOC5 had the same throttle response when it was set to 3.8v as full throttle, 1.0v zero throttle (what the CA was set to output to match the other controller's actual input range), as it does now when set to 4.29v as full throttle, 1.0v zero throttle.




Correct, there is some minor interference going on on the 5V bus. Although not a problem, it's an anomaly and will be addressed in any future HW revision. Well observed.
Makes sense. Is the interference anything I can do something about here? (adding small bypass caps, etc)


The worst part is that it accelerates slowly, feeling like it is either a linear acceleration curve or that it is only building speed faster as speed increases.
There is no manipulation, linearization, etc., between the throttle voltage and the torque demand. (There are only upper settings limits, rating limits and thermally or speed induced limits).[/quote]
Ok. Then there's some other issue/setting I'll have to figure out.


motor sensors I know of (including on mine) that come built in are wired with ground on one side
Noted. They actually share the same physical GND connection with the halls sensors?
Yeah. All of the ones I've seen posted about on the forum so far at least, including the bigger QS motors, use the hall ground as a way to save a wire in the bundle coming out of the motor.

For any DIYer it's no big deal to pull the motor cover and disconnect ground from the thermal sensor, and connect that sensor side to hall power instead, if they need the halls for any reason (like a speed sensor; some things like the Cycle Analyst can use a motor hall as a wheel speed sensor, which saves some work and has less "stuff" on the bike).

If they don't need the halls, then since they wont' be connected to anything, it doesn't matter that the thermal sensor uses ground, because it isn't ground if it isn't connected to anything. ;) Just wire that side to the "sensor in" pin of SFOC5, and the "thermal sensor" wire on the motor to the "5v" pin of the SFOC5. (which is what I would do if I didn't have the halls still running to the Grinfineon as backup/comparison controller).



and don't see a way to read the settings back out, to verify that they are actually set to what they should be.
While programming, once all settings have been successfully received (start of transmission and end of transmission special number sequences have both been acknowledged by the controller), the corresponding LED-code displays and the settings are echoed back by the controller to the serial interface program.

Yeah, I saw that in the manual, and I get that code (blinking 2 IIRC) when I send both sets. :oops:



Done. It now resumes start-up after successfully having received the new settings. Steady code 13 now signals this for three secs before moving on.

Cool! That should simplify things signficantly, especially for testing / logging applications, or those using a serial-dashboard (once one is developed by someone...I've been doing some pondering on that but no complete thoughts yet).

I recommend you keep everything closed for now and make an extension cord instead.
Ok. I think I can just put a switch in the TX line near the USB adapter on the serial side instead of an extension--that will still be reachable easily, and should keep it out of programming mode.
 
However...I don't understand why at zero throttle input, it's still putting any phase current thru the motor at all.
Very small currents are constantly generated by the position estimation algorithm. KTM, Kubergs and perhaps more have the same whisper.
Ok. I guess I haven't had any experience with this type of thing before.

As I describe in my real test ride results post, it's actually a significant vibration from the low frequency components of the whisper, as if I had a small "quiet" ICE car-type engine running all the time. Even regular road vibrations don't completely overwhelm it, on the smoothest roads, though most roads are rough enough to do so. (keep in mind I am on a suspended mesh seat, so a lot of vibration is not passed thru to my butt; anything that does get thru is somewhat significant).

It's pretty annoying--I'm sure I can get used to it eventually, but it's quite unexpected to have this level of noise/vibration when just sitting there, especially for a controller that is so silent actually accelerating and driving the motor. :)

I don't know how other people would react to it, but just for testing I'll see if I can get some friends/coworkers to sit on it with the SFOC5 switched on and off and see what they say, without telling them what I'm looking for first.



I wish I had a better way of describing or showing this. Hmm. I have an old STM32 Circle devkit that has a G-force / vibration program; maybe I can put that on there and post the results from it with the SFOC5 on and off.




That's great. By all means, try some Multiplicantion factor as well, such as 0.7.
Let me know when you are ready to receive the firmware update. In the update, I have bypassed the cross coupling compensation algorithm, something I need to work on some more before releasing again.
I'll try the Mult.factor (blue box) settingg at 0.7 (vs the 1.0 I think is the default) once I get home.

I'm ready to try any firmware updates whenever you are. :) I'd assume ;) that I can always downgrade back to a diffeent version if necessary?
 
It's hot where you live!
Yes, it definitely is hot. In-the-shade temperatures yesterday were about 110-112F in my backyard. I have an old aquarium sitting upside down on top of one of the shed roofs, which I put bottles of water/teabags in to make suntea, and it's usually close to 160F air temperature in there while the sun is shining on it, during this season.


I pasted your string, it seems you lost the last few values somehow, maybe they ended up in the cell below? This is what I get (using the filled in sheet you posted earlier)
Nothing should be in anything but the green cell; I just clicked on the cell, did Ctrl-A to select all, Del to delete existing stats, then Ctrl-V to paste the new stats in, and Enter to let the spreadsheet do it's thing.

The values are copied from realterm by selecting every character displayed on the black screen with the mouse, then Ctrl-C to copy them. I pasted them into a Notepad to verify I had them all before putting htem in the spreadsheet, too--that's evverythingg being sent to Realterm by the controller unless realterm is truncating it.

All realterm settings are defaults except those called out in the manual to change.



It seems at 160 rpm (or 3680 e-rpm) you get the no-load thump?
Could be, I'd have to calculate out what the RPM converts to in MPH for this wheel.




I_Q should be close to whatever was demanded, in your case 150. Some 10-20% overshoot is expected once the setup is healthy.
I'm guessing the SFOC5 current metering must be much faster than the CA, because the CA never measures any currents nearly as high as those shown for battery current in the SFOC5. I do suspect the CA is measuring on the low side by as much as 15-25%, even though it's correcly set to the actual shunt value, as it reads that much lower than the older CA I had been using before (or else, the other CA was always wrong, instead).

The throttle has a resting voltage of 0.17 V, correct?
0.89v, actually. (SFOC5 should be programmed to start responding above 1.0V, though)

Perhaps there is ground-side noise because of the connection between battery ground and logic ground inside the Grinfineon and the leftside generic controller that're still wired to the system?




The instantaneous battery voltage indicates a value very close to zero (actually negative, hence the weird conversion), something I have never seen before. It is usually corresponding to some cell voltage in the low 3 volts range. We'll have to watch this and try to figure out what is going on.
The battery itself is definitely not running that low, and I know the cells themselves have little sag under load (actually recently checked that and balance under load, charging, etc. while I had the battery out of the compartment to do some rearranging in there).

If that isn't a data glitch, then perhaps there's something wrong with the battery power connection to the SFOC5. I'll take a look at that, putting a voltmeter into the back of the PP45 connectors on the SFOC side, and watch it under acceleration load down my street, and if necessary change the PP45s to an SB50 to plug into the larger heavier-gauged charging port instead of the smaller one.


You pulled an estimated 21 A from the battery, but I wouldn't assign that value too much of significance at this point, given the spikes in I_Q.
Ok. Does that mean an average of 21A, or a peak of 21A, battery current? Average might be reasonable, but peak I would expect to be a lot higher.


In the update, there is also a readout for the maximum torque demanded, not just the maximum throttle voltage.
That should be useful. :) Wish I had a torque sensor I could put on the motor to tell me what the actual torque output was. :)





Or better to leave it all in one place
Your/the moderator's call. I'm fine with having this conversation in this thread.
Then we'll just leave it all here. :) Then I'll copy or link relevant stuff to the other one once I get it started.
 
I went ahead and tried to get the stats from the controller before I headed home, but I forgot to change the realterm settings, like activating the port, lowering the baud rate, etc., before connecting to the controller. I also forgot to turn the status/led panel switch off the first time I turned it on when connecting the serial/usb, so I had to power cycle it again. Then I ended up having to power cycle it again a few times before I finally got the realterm settings right *and* the order of connection and power on correct.

So I didnt' get any useful log data from it. The only data came up like the first ones--just a bunch of invalid or impossible values, and becuase it had to be power cycled multiple times, the data I wanted was long gone anyway.


12 34 7F FF 00 00 7F FF 00 00 00 00 B7 18 00 00 02 01 01 F7 02 76 02
43 FE 6C 00 00 00 00 00 00 00 00

which gives:
min motor temp = 85
max = n/a
min heatsink temp = blank
max = n/a
max rpm = 0
min battery = 407.68
max battery = 0
max ia = 10
max ib = 10
max ic = 12
max id thru max ibatt all equal #num!


It might seem a simple procedure, but since mistakes can happen, which loses the log data, I recommend there be an option to set a flag so that it changes logging modes. In this new mode, one must send a character string in realterm or whatever terminal program is used, in order to clear the previous log data, and this mode would not allow overwriting the log data until that is done. Probably more work than it's worth.

It wouldn't matter if I was logging realtime, I guess; have to get that setup, then not have to worry about getting that stored log. Then no changes to procedure would be warranted.




I did get the log data from the trip below, however, once i got back to the house:

12 34 00 00 01 30 41 3F 53 F6 7F FF 18 26 19 1C 46 A3 48 71 46 75 22 99
4B 6B 04 4A 5F 52 13 80 19 E2

which gives:
min motor temp = n/a
max =-45
min heatsink temp = 45
max = 65
max rpm = 32770
min battery = 53.77
max battery = 55.91
max ia = 357
max ib = 366
max ic = 356
max id = 175
max iq thru max ibatt all equal #num!



Better...but worse

Changed some settings, including the mult factor. Some of these I might ahve already changed for the trip today but without being able to read the settings back I can't be sure. (I created a few versions of the settings spreadsheet for today, but I don't remember for certain which was the one I actually uploaded the data for, as I kept looking at various settings, thinking about them, after that, before i left the house.)


Motor resistance is a bit lower, at 70 (previously 72)
inductance back to 230 (from 200)
battery current to 160 (from 300)
phase current to 360 (from 300)
throttle fully engaged output 4.3 (actually 4.29 but it rounds up automatically)
Multiplication factor 0.7 (from 1.00)


A test trip out and about for a few more miles got a pretty different behavior set than anything previous, and I suspect it's more the multiplication factor than the other stuff, but I'll have to try the old settings with just the MF changed, and see what happens. Then we'll know what to narrow in on. :)


Now the motor has much stronger pull, from a lower speed, BUT:

The "pulsing" I got before, from low speeds, that didn't really push the trike much but could be felt, if I applied throttle (even max throttle) appear to be magnified enormously (though it could be something different).

What happens is that if I apply a tiny bit of throttle it gets rapid pulses of power that attempt to move the wheel (from a stop or under a couple mph), but they don't successfully push the trike forward. Just a hair more throttle than that causes the wheel to "grind" and shudder with alternating pulses of acceleration and braking. if I apply yet more throttle, it becomes audible and shakes the trike, but doesn't propel it forward.

If I'm above maybe 5MPH, it happens similarly, except that if i keep the throttle low enough it'll acclerate extremely slowly, and once I get towards around 10MPH I can keep the throttle low enough to accelerate with very minimal shudder, but if I get above some amount of throttle (higher for higher speeds), the wheel grinds and shudders and actively brakes the trike on that side so hard it pulls to the right very suddenly.

Once I'm over about 16-17MPH its' easy to control the throttle to keep it below that transition point, and continue quickly accelerating up to 20MPh and hold it there fairly stably.


But if I blip the throttle experimentally up, it'll grind and shudder and brake.

The best description I can give of the motor behavior is as if it were suddenly being jogged back and forth between two positions rapidly and under high torque. Like a timing problem can cause. When at speed, it feels like it's still forced forward against this, but the drag is high so it brakes the wheel a lot. On a regular lighter bike I expect it'd lockup the wheel and skid, but since the trike is so heavy especially right over that wheel (battery is right in front of it), that it keeps traction going.



The good news is accleration is much better but it's also very touchy at low speeds trying to acclerate, and max throttle cannot be used at all (it probably could above 20mph but that's the limit here), unlike with previous settings, where max throttle could be used without causing that kind of problem, at any speed 0-20mph (although it might not have any effect, or not much, at low speeds).


No problems with the short steep slope, either--it maintained speed just fine on that, responding to the throttle change quickly enough, though it took some practice to keep from reaching the shudder/braking point.


Because of having to use extremely low throttle at low speed, accleration time with just this controller/motor is still extremely long, even longer than it was before. Once I get to a speed I can easily control throttle within the range below the shuddering, I can get pretty quick smooth acceleration (though not as hard/quick as I want yet). That range expands the faster I'm going, if it helps to troubleshoot.


I've attached the xls file for the present setup.
 
Oh, and this is the pic of the status LED board in the tic-tac box, presently just ziptied to the handlebars next to the CA. I am looking thru my stuff with LEDs for some brighter ones that still use the same current, cuz these aren't daylight readable even under my trike's canopy, so I can't see if there are any status codes unless I pull over, stop, and get close to teh LEDs adn shade them even more with my hands. :/
 

Attachments

  • dsc07662.jpg
    dsc07662.jpg
    33.2 KB · Views: 2,194
  • dsc07661.jpg
    dsc07661.jpg
    27.7 KB · Views: 2,194
Also, ignore previous posting about using the MXUS built in temperature sensor--apparently it's a KTY83/110 PTC, so not the type the SFOC5 is meant to read.
It can read this sensor, it did it before on the Qulbix or the Fighter. Let me ponder how to best roll it out.

Anyway, it may not be the feedback you're after,

Best ever, what we need to know to advance.

Throttle voltage range is 0.89v at zero throttle

Fixed the stats recording in the firmware update, min throttle should read about this much now.

Is the interference anything I can do something about here?
You probably could, but let's leave it, at least for now.

unless realterm is truncating it.
There we have it. When not in full screen, it seems RealTerm truncates and this follows along to the spreadsheet. So either full screen or "mend" it in Notepad. I'll make a note in the manual.

Perhaps there is ground-side noise because of the connection between battery ground and logic ground inside the Grinfineon and the leftside generic controller that're still wired to the system?
As I understand, logic GND (throttle) is not wired in with your battery. Even if it were, that is how SFOCs were wired for years before version 5.

Ok. Does that mean an average of 21A, or a peak of 21A, battery current?
That is the highest estimated value for the entire session.

So I didnt' get any useful log data from it.
My bad, the save stats function is called way more frequently than once every four minutes, another debug bug left in there. So, normally the log, which is on EEPROM, would not be overwritten just for cycling the power on briefly.

AmbStats.JPG
That RPM value is a validation of your previous inertia concern! Geared RC-motors are a far cry from the hub motor. I replaced the formula with a fixed filter time constant. I wasn't expecting this, since we saw normal rpms from the previous Stats, and since no steady code 2 was reported (Speed limiting active).

I put an updated Settings&Stats in the public folder, use this for now (ambw Jul 29). We'll hold off the firmware update to weed the impact of this out first.
https://drive.google.com/drive/folders/1SrqjgC2lSxXCAzWI8V--YkTYgAr2jAxa?usp=sharing

Simple, robust and universal. Sometimes I forget.
 
incememed said:
Also, ignore previous posting about using the MXUS built in temperature sensor--apparently it's a KTY83/110 PTC, so not the type the SFOC5 is meant to read.
It can read this sensor, it did it before on the Qulbix or the Fighter. Let me ponder how to best roll it out.
Oh, ok. :)

Once the SFOC5 knows how to read this sensor, then I figured out I can do more or less what I did with the throttle, and just put a connector for the ground wire on the motor-to-grinfineon hall/thermal sensor ground rather than disassembbling that side of the trike to open the motor and swap the wries, at least for now.


I saw a section in the spreadsheet that looks like the values SFOC5 expects at various temperatures from a particular sensor. Is that just a reference, or is it data it actually sends to the SFOC5 in the realterm data?





There we have it. When not in full screen, it seems RealTerm truncates and this follows along to the spreadsheet. So either full screen or "mend" it in Notepad. I'll make a note in the manual.
I took a look at it, and figured it out, based on your reply above. Looks like realterm puts a CR-LF in the data on screen; as long as I "mend" it in notepad by taking that out, it does work. I should've noticed that before. :oops:






My bad, the save stats function is called way more frequently than once every four minutes, another debug bug left in there. So, normally the log, which is on EEPROM, would not be overwritten just for cycling the power on briefly.
I guess that will fix that issue.

For my own ease of use I put a switch in the serial TX line from the USB-serial adapter. It's a bit clunky-looking but it should make things easier. Havent tested it yet, about to head out to work so may not get to till tonight but it cuts the green TX line in the USB's serial-end cable, puts the SFOC end of that at the common of a doulbe pole switch. One pole has the TX wire to the USB, and the other pole has a 3.3kohm resistor to the USB-to-SFOC 5V line to hold it high when not in programing mode.




That RPM value is a validation of your previous inertia concern! Geared RC-motors are a far cry from the hub motor. I replaced the formula with a fixed filter time constant. I wasn't expecting this, since we saw normal rpms from the previous Stats, and since no steady code 2 was reported (Speed limiting active).
I did wonder if maybe it was a heavvily-loaded-at-low-rpm-hub vs high-speed-geared/etc motor issue. :) We'll see how it does with the new sheet below.


I put an updated Settings&Stats in the public folder, use this for now (ambw Jul 29). We'll hold off the firmware update to weed the impact of this out first.
https://drive.google.com/drive/folders/1SrqjgC2lSxXCAzWI8V--YkTYgAr2jAxa?usp=sharing
I'll try that out first then. It looks like it has all the settings for the trike already in there, so I'll test this version without changing any settings, see what it does, then start altering one setting at a time to refine whatever behavior I get.



[quote ]Simple, robust and universal. Sometimes I forget.
[/quote]
It's hard to get all three of those in the same thing. :)

And then you get users asking for new features or extensions of old ones...whcih lead to new problems, and sometimes to new feature requests, and so on.... :lol:
 
Getting acquainted with the C80100-80 from Alien Power System, posting the SFOC5 stats here for reference.
Capture.JPG
This is from a 20 km ride, mostly backroads and trails.

Some observations:
- All three phases have similar peak current values, which would indicate a balanced three phase current.
- The value of Iq (torque), in turn, coincides with these peak phase current values, which indicates very little oscillation in Iq (a DC quantity derived from the phase currents using the (estimated) position of the rotor).
- Max Iq is some 10% higher than Iq reference (torque demand from the throttle), suggesting an overshoot of 10%. The amount of overshoot is an indication of how well the PI-loops are tuned in combination with how well the estimator is tracking rotor position. Overshoot tends to go up when any of these are off. (PI-loop gains have not been adjusted other than using the default values suggested by Settings&Stats.)
- The reference for Id is zero, and max Id should typically not rival that of the phase currents or Iq. At acceleration and deceleration, Id will naturally deviate from zero.
- Estimated peak power from the battery is around 8 kW.
 
I experimented with the Multiplication factor as low as 0.5 and as high as 0.85, using the new XLS sheet, with no particularly notable change in the behavior at lower speeds (above some amount of current (throttle position) it will stutter/shudder/jam the wheel as previously described, and it still can't accelerate normally from below around 5MPH without help from the other motor).

The faster I'm going the more throttle it takes to cause it. At a guess, once above some amount of current for that speed, there is something swamping out the signals the controller uses to determine timing, so the controller sends phase signals that are significantly advanced or retarded vs actual motor position, which causes enough drag on the rotor to brake it enough for the next set of signals to cause it to push hard in the right direction again, but then the next set of signals is out of phase, and the cycle repeats until I back off the current (throttle) a fair bit. (have to back off more than you'd expect because the braking effect of this takes at least a couple MPH off the speed).


Today I'm going to set the MF back to 0.7, then lower the phase currents by a third down to 240 from 360, see what that changes.


These are the logged stats from different attempts. The first one is from 0.7, the second from 0.85, the third from 0.5. Then I rode around the yard, which is pretty much all below 5MPH, too short a distance to get up to speed with all the trees and the dogs trying to help. Mostly had to try to get up to speed with the other motor and then start trying to get SFOC to drive the right motor in a forward and smooth way. Only had about 40 minutes to mess with any of it before I had to leave for work.

I left the 0.5 setting for the work trip, and it's usable when in the upper 5-7mph of my 20MPH speed range; below that it's harder to deal with as the usable throttle range is on the short side. Couldn't get the log for the work trip as I had no time at work to deal with the connection/reading process, or before I left for home at the end of the night. Messed up the process once I got home so lost that log.

I tried some other values between those, but messed up getting the logs due to similar user-confusion as the first trip. Even these logs don't appear to be fully usable.

See the next posts for some more feedback on the methods used to gather logs and to program.


12 34 7F FF 00 00 7F FF 00 00 00 00 B9 03 00 00 01 E1 01 9F 02 BE 01 EB 00 31 00 00 00 00 00 00 00 00

View attachment 2

12 34 7F FF 00 00 7F FF 00 00 00 00 B7 3F 00 00 01 B7 01 48 02 AF FE 39 02 2F 00 00 00 00 00 00 00 01
072918 MF 0.85 stats.png


12 34 00 00 00 11 3C 4A 44 B7 00 77 1A 3D 1A 6C 36 BA 28 30 2A FC 0F 13 37 00 04 3D 5E 46 16 80 0F 97

072918 MF 0.5 stats.png
 
BTW, here's some of the Cycle Analyst trip stats. The first one is for my second test trip the other day, after having first changed the MF to 0.7 after the first real test ride:
https://endless-sphere.com/forums/viewtopic.php?f=2&t=30680&p=1399363#p1398903
and shows the CA doesn't read the same battery current as the SFOC. I don't know which one is correct, but one of them has to be wrong. ;)

Also, it shows the SFOC appears to be passing some current back to the battery (possibly durring the "stuttering/shuddering" events when throttle is above whatever threshold causes that), as the CA shows regen current. The leftside generic controller always uses some power to do it's braking, and doesn't have any regenerated current that I've ever seen.

I have to experiment with causing that event while watching the CA's current-monitoring page, to see when this occurs. If it doesn't happen there, I'll see if it happens during coastdown/throttle off, and if not there if it happens during braking on the left wheel despite previous behavior to the contrary.

First trip at MF=0.7

57.7v start
53.7v rest
53.5v min

10.67Ah
(0.3179Ah regen, 10.978Ah fwd)
2.9% regen
-11.0A min
102.9A max

598.7Wh
51.6Wh/mile

11.283 miles
22.6MPH max ***
14.2MPH avg
47m 32s triptime

0.026ohms rbatt

***(when experimenting with throttle to see where the "stutter/shudder" happens, hit that speed *real* quick after reachign 20MPH, so acceleration even at somewhere around mid-throttle+ is really good once I get to a fast enough speed...but that is at a speed above where I am allowed to use it)


These stats are for my work commute yesterday, so at the MF=0.5.

57.7v start
55.8v rest
53.4v min

4.54Ah
(0.0254Ah regen, 4.5642Ah fwd)
0.5% regen
-18.2A min
82.8A max

255.72Wh
55.1Wh/mile

4.623 miles
20.9MPH max ***
13.7MPH avg
20m 14s triptime

0.030ohms rbatt
 
Back
Top