Hall Sensors'b'Gone

incememed said:
There are three fundamental elements here: UART-communication, arithmetic and displaying on generic LCD. Maybe something for a final project in high school or college introductory embedded course.

I think I'm way past any high school or college time. ;)

Basically I"m going for using an exising android tablet (or phone) as the display device, and the MIT app Inventor to simplify creation of that end of things. The part that seems to be difficult (perhaps impossible) is to get the serial data into the android device in the first place, via any direct serial wiring. Seems that bluetooth is the only way to do that, so I may have to order a serial-to-BT module, and power it off my traction pack via an old celphone charger or USB wallwart (which will often run off 50VDC+ as well as the wall AC voltage).

I'm not a programmer, but I know the general principles, and have done BASIC, assembly, etc., decades ago. So I ought to be able to figure it out with the help of things like the MIT AI. I hope. :lol:

Something just about like what is needed has already been done here on ES to read the Cycle Analyst's serial data stream,
https://endless-sphere.com/forums/viewtopic.php?f=2&t=59893
so I know it's possible, though it may be more advanced than I'm capable of; I can still try. :)




Sure. Didn't see any suitable option in the Word Save as PDF dialogue, though. (I was able to copy/paste from the PDF.)
I don't know wny, but neither the in-browser reader, Adobe PDF reader, or the WPS Office (IIRC) I found (to read the XLS stat sheet locally offline) will let me select text to copy it. :/ I've seen this with other PDF files (but not most of them), and assumed it was because it'd been "flattened" during export/file creation.

If you have a Word version, you can just email me that (or share it via google docs), and I'll stick the changes in there, and then you can review them.




There was a 90% overshoot at one point (Max Iq vs Max Iq ref) in your last post. While this may have little effect on the perceived torque overall, it is not ideal. With that big of an overshoot if demanding close to rated current, the Power down function will activate.
I didn't have any cutout of power that I recall, so it hasn't reached that point yet.

If I can get something written to automaticlaly convert the file of captured realtime streamed data into a human readable table, I could see about when during the trip it happened (assuming each data segment is sent every tenth of a second), and if I can recall the circumstances, it'll help narrow down the reasons for it.

Don't yet know how, but have been poking around the web for searches about scripting and stuff.


BTW, when I said code 9 in the trips yesterday, I meant code 11. :oops:


I suspect MF=0.1 may be on the low side. But let's not rule it out until the low speed WOT stutter has been fenced in. Stutter at WOT from zero/low speed sounds like an R or L issue, rather than kv or MF.

I'm still experimenting with MF values; I'm going to go up by 0.1 at a time until the noise comes back, then go back down until it goes away. Then test ride at that value. But I didn't get up early enough today, and it was already 110F out there by the time I got thru with some essential yard work / watering stuff, and have been inside cooling off since then; it's still 112F out there so it'll be later this evening before I get back to the trike out there. :oops:

If there's an issue in the phase connections or too much resistance in the wires (too small a gauge) that would affect the R. I'lll check into those.

I'll also check into the battery supply connection, since voltage drop there might affect operation under high loads.
 
This is an interesting thread for me, as I have been running sensorless for over 19,000 miles for over 10 years on the same motor, same controller. The motor never fails to start up with more than .10 (guessing) mph of forward travel of the bike, and has never unexpectedly failed me. Its just a plain old 9 Continent with a BMSbattery cheap controller...run with no Halls with this 35 dollar square wave Chinese controller.

https://bmsbattery.com/ebike-kit/805-s-ku63-250w15a-6mosfets-controller-ebike-kit.html

This thread makes it seem very mysterious or even near unattainable for it to work in general?
 
I had to go to the grocery store for some stuff unexpectedly, and just got back, but didn't have time to change any settings during the run, so these results are with the MF=0.1, etc., just like the previous run yesterday.


Temperatures:

I did get to borrow an infrared thermometer (but didn't get to use it till I got home), so I have some motor (and controller external) temperature data as well. When I got home, ambient temperature was 99F (37C), and the controller was 135F (57C) just after I got the trike thru the gate and locked it, and the motor was 117F (47C). (left side motor and generic controller were both at 115F; it was used only for braking during this trip, except for two accelerations to start out at a light with traffic behind me).

After I got the groceries unloaded, a few minutes at most, I remeasured and got 119F (48C) for the controller, and 129F (54C) for the motor (as heat soaked thru the rotor, axle, and covers from the stator and air inside). (left side controller down to 111F (44C), left motor down to 112F (45C)).


I hooked up the serial cable and captured a short bit of realtime stats before shutting down the controller, and got the attached file, which shows around 5320-5340 hex for field 7 (controller heatsink temp), around 21300 decimal, which on the conversion chart of page 29, comes out to between 55-60C (131-140F).
View attachment captured stats 08518 1.txt

After all that I shut down power and switched off the Status LED panel switch, disconnected the serial cable, waited a moment, and reocnnected it, to get hte trip stats, pictured below. During the ride, the lowest temp was 45C (113F), which was higher than ambient when I left the store (would've been around or less than 105F at a guess). Peak temp was 70C (158F).
View attachment 1

RPM reading

I have noticed that Max RPM shows as 600 on more than one stats report. If I'm calculating correctly, that's around 38MPH on the small wheel (Shinko SR214 2.5"x16" moped tire at 35psi https://www.shinkotireusa.com/product/moped-tires/211932 ).

That's almost twice as fast as it's actually ever going.



Stutter/shudder:

There were three times, all at very low speed <5MPH during acceleration from a stop, throttle being pushed quickly forward toward but not yet at WOT, where I got the stutter/shudder, but different than previously. This sounded like a big wooden cabinet being pushed across a floor, when it makes that...shuddering sound...as the corners or feet or whatever stick to the floor and release, repeatedly, at the frequency of the sound. Somewhere down in the low octaves, maybe near A1 on a piano?

It continued until I let off throttle completely; simply backing off on throttle didn't fix it (though it did reduce current and the intensity of the stutter/shudder somewhat).
 
chvidgov.bc.ca said:
This thread makes it seem very mysterious or even near unattainable for it to work in general?
Not really--this controller is a field-oriented sinewave type, where yours is almost certainly a typical trapezoidal generic type.

The FOC types need some info to tune them to their particular motor, so they'll run it well and efficiently. Can take some experimentation to do that tuning.

The sinewave part makes them essentially silent in operation, even under high currents. Apparently some make another noise not from the drive, but from the position sensing; it was loud in this one at first but a settings change has fixed that.

The generics just run the motor however they run it, and don't have any way to tune them for a particular motor to make them run better with it.

The trapezoid part makes them loud and buzzy or grindy sounding, especially at high currents. They'll be louder on some motors than others, but there's no setings to fix that.
 
Stat sheet bug?

Or some cross-setting limitation?

I am creating a number of different notepad files with Realterm Send 1/2 data, so I can just quickly copy/paste these into RT and send them, to experiment with different values on the Multiplication Factor field, and the various Motor Parameter fields (resistance field for now; others later if needed), without having to move around the spreadsheet and whatnot while I'm out in the heat. :)

However, I also thought I'd create a few RTS1/2 sets with a few different values for the Torque Down-ramp setting, to see if I can use the braking type created by this.

If I set that field to anything above 0.011, the RTS (and pickit and docklight) fields all show Not Valid.

According to the field to the right of the TDR field, it should accept values from 0.004 thru 5.00.

It doesn't matter what value I use for the MF field, or if I leave it blank for defaults.

I have not yet set the SFOC with any of the generated RTS data for any of the TDR field values, so dont' yet know what results it creates in reality.
 
Some results for MF values 0.1, 0.2, 0.3, 0.4, 0.5.

Pertaining to the lowspeed stutter on all variants of this test so far: When it happens, throttle must be dropped to off to stop it, or it will simply continue at whatever level of roughness it started at, even if I use the other motor to accelerate, while maintaining some throttle on this motor. The problem happens whether slamming throttle to WOT, or rolling it on slowly, or in between.

Both RPM and current seem to have a bearing on the stutter problem: Most of the time when I am looking at the CA as it happens, I see a battery current of around 25-30A (fluctuates a lot). If the current is higher than that already, or the speed is higher than that listed in each MF variation test, it doesnt appear to happen. Some other notes after these tests, on the ride at MF=0.2.

I tested by riding down my street at various speeds, reached using the other motor, and then using WOT on the SFOC5 to see if the stutter occurred. If it did not, I would let the trike coast down a bit then use WOT again, until I found a speed it would happen at, and repeat this procedure to go up and down in speed to find the top of the speed range it would happen at.

The attached text files above each result include the RTS1/2 data, as well as the post-test poweron stats, and may also have notes I used to remind myself of various things. All of the poweron stats appear to be invalid values, and I think they are all the *same* stats. Most likely all the tests were shorter than four minutes, and so might never have been long enough to cause it to save the stats.

Got too hot (almost 115F) to retry the tests for now to see about getting valid stats, so I took a ride at MF=0.2 and logged that (see attached capture files at end of post. First capture file shows just sitting still for at least several minutes, because I misplaced my glasses (still cant find them) and was looking for them with the system running).


View attachment 4
The lowspeed stutter is least problematic at this setting of those tested. It happens rougher, all thru the speed range it occurs, but has a sharper falloff at the top of the range. The max speed it start at is between 3.6-3.8MPH.

View attachment rts 1 2 for mf 0.2.txt
Stutter is less at top of range it occurs, but still rough at the bottom fo the range. Max speed it starts at is 4.5-4.7MPH. Sometimes I can feel slight "washboard" vibrations up to a few MPH above that speed if I am at WOT, but they are not the same as this stutter (though they may be the same cause)

View attachment 2
Stutter is more like the washboard or ribbed road surface at the top of the range, but still rough at a couple MPH below that. Max speed it start at is abut 6.8MPH. If I lower speed from washboard range to rough range while it is happening, it does not change to a rough feel, it stays at the washboard feel as it decelerates and once it reaches that lower speed (though without input from pedals or leftside motor it will continue decelerating as the right motor is no longer pushing correctly while this problem is happening--that is true of all versions of this test). If it's at the rough feel, then either lowering or increasing speed (using the other motor) doesn't change the feel to rougher or smoother.

It is as if it gets out of sync, and once out of sync a certain amount, it stays that way until current demand (throttle) is stopped and restarted. Don't know if that's what is actually happening, though.

View attachment rts 1 2 for mf 0.4.txt

I didnt' save the powerup stats on these as they were the same as the others, and I forgot to make a note of the speed ranges, but IIRC it was about 7-7.5MPH for the 0.4, and just a bit higher for the 0.5. I didn't spend as much time testing these because the not-operating-motor hiss and vibration are very pronounced in both of these.

At 0.3, the hiss is still audible, and the vibration can be felt even while riding, but not nearly as bad as at the 1.0 setting. Wouldn't want to have to use a controller that did it even at the 0.3 level of it, however.

At 0.2, the hiss is not audible (without putting my ear near the motor), but the vibration can be felt while sitting still. Can't be felt while riding, however.

At 0.1, the hiss is only audible with my hear almost against hte motor casing, and the vibration is so slight that I can only really tell it's there by shuttting off the system and not feeling it anymore. So much better, but would be nice if it werent' there at all.

Also note that the motor has noticeably more "cogging" even at zero throttle with the system powered on, even at MF=0.1. It doesn't wiggle back and forth lke it does at higher MF settings (see video previously posted), but it's still actively putting enough current thru the windings even at zero throttle to cause the coils to self-locate to the magnets and try to hold them there a little. It is stronger if the wheel is handspun in a reverse direction than a forward one.



Testing of various Motor Phase Resistance values, from 50 up to 500:
View attachment 9
View attachment 8
View attachment rts 1 2 for mf 0.1 and mpr 250.txt
View attachment 6
All of these values cause the stutter to be worse than the 70 milliohms it's been set to. 500 is MUCH worse, causing it to occur at the entire range of speeds from 0-20MPH. 250 is the same. 50 and 100 are only a little worse than 70.

I haven't done testing in the narrow range around 70 yet, to see if there's a slightly different value that would be better, with the various MF values. Haven't tested these phase resistances at other MF values, either.



Testing for Torque Down Ramp:
View attachment 5

I only tested the one value, the highest one it give valid RTS1/2 values for. There is no noticeable drag on the trike when dropping from WOT to near zero or zero throttle; coastdown times are the same either way. No negative current shows on the CA, either. (would assume it should, if braking were occuring by the SFOC5).



Test ride at MF=0.2
View attachment 11
View attachment 10


For this ride, was pulling the Mk IV.5 trailer, which has some drag and rolling resistance, and of course the extra weight (dont' remember exactly, but with the present temporary thick plywood deck and the strapped on wheeled dolly, it's prbably around 100lbs).

The stutter was quite a problem several times, as I was at Metrocenter in the parking lot close to the building, where there are several steepish hills to go up going from the south end to the north end, where Sears is having a store-closing sale (nothing there worth the trip; they appear to have raised all the prices first, then put sale tags on them).

On these hills, I had to use the leftside motor to go up, because at the MF=0.2 setting, the stutter trying to start out from a stop either on them or at the bottoms (stop signs in bad places) prevented me from beingg able to accelerate at all with the SFOC5, even in my lowest pedal gear to get started just a bit. Just couldn't get to a fast enough speed to let the SFOC get past the stutter RPM range (assuming that's what's causing it) before having to stop again.

I think at MF=0.1 it would've worked, as the RPM is significantly lower for the top fo the stutter range (on the flats, at least), but I havent tested that theory yet.

Performance otherwise was indistinguishable from MF=0.1 setting, beyond the sitting-still-vibration that can be felt in MF=0.2 that can't be in MF=0.1.
 
If you have a Word version, you can just email me that (or share it via google docs), and I'll stick the changes in there, and then you can review them.
Great, I'll send you a copy.

I'll also check into the battery supply connection, since voltage drop there might affect operation under high loads.
Phase wire gauge is less critical at these currents, but pls do check that battery is solidly connected.

That's almost twice as fast as it's actually ever going.
New update with this and some other things coming over e-mail.

It continued until I let off throttle completely; simply backing off on throttle didn't fix it (though it did reduce current and the intensity of the stutter/shudder somewhat).
Would be great if you could hook up a voltmeter between battery NEG and the LED-panel switch (naked contacts on back are connected to the 12V bus) and watch it on an instant like this.

But first, install update.

If I set that field to anything above 0.011, the RTS (and pickit and docklight) fields all show Not Valid.
Fixed in sheet in public folder.

MF=0.2 sounds like a sweet spot. I will do some testing with this.
 
Side note to above, and separate to call it out better:

I seem unable to reliably get valid powerup stats. Since the 1234 header is always picked up correctly, I'm assuming transmission is ok, but that the values themselves are not valid when sent (or stored?). I did get some stats for yesterday's ride, but today nothing seems to come up valid. Since settings transmission/reception also appears to work fine, I doubt it's a serial/usb comm issue.

The post ride stats, for each segment of the test ride noted above, even though they are definitely longer than four minute segments, are not valid values, and are almost copies of each other. The stats are pasted below, in order from first segment to last. The capture files 1 and 2 in the previous post are for the first two segments of the ride. (The laptop battery died sometime during the last one, and there is no capture file contents for whatever reason. :? )

12 34 7F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 1E F8

12 34 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 1E F8

12 34 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 1E F8


Oh, and the stats I got on first powerup today (leftover from last night when I went in for the night) *are* valid, and make sense for what was last going on:

12 34 00 00 00 00 4A F3 4D 92 00 05 17 D1 18 0A 04 07 03 70 06 38 F9 C4 02 B1 14 4D 16 BF 13 20 00 00 00 00
overnigth saved stats 080618 1.png

incememed said:
Great, I'll send you a copy.
Got it; I'll add updates/corrections where I see they may help, and send it back for review. :)

Phase wire gauge is less critical at these currents, but pls do check that battery is solidly connected.
I checked, and battery connection itself (at pp45s, etc) is solid, contacts are mating correctly AFAICT. No heating of the contacts or shells. Battery current being drawn when there are issues is relatively low, so it's probably not voltage drop on the wires either. (will instrument and test for that, just in case).


New update with this and some other things coming over e-mail..
Got it, will update in a little bit (after I cool off from the last test ride).

Would be great if you could hook up a voltmeter between battery NEG and the LED-panel switch (naked contacts on back are connected to the 12V bus) and watch it on an instant like this.

But first, install update.
Easy enough. Should be able to wire that in and ziptie a meter on the bars temporarily, then test around the block.


I
Fixed in sheet in public folder.
will verify and test after update and retests on update.

MF=0.2 sounds like a sweet spot. I will do some testing with this.
My guess is a little less than 0.2 (to mitigate the rest of the low frequency vibrations when sitting still) is probably closer to ideal; haven't experimented with in-between values yet.
 
Powerup stats:

I didn't get to the firmware update till today; am about to do that. But before I did it I thhought I'd try to get the last powerup stats, and see if I had the same problems as yesterday. Like yesterday, it has apparently valid stats after sitting a long time (hours, in this case), though unlike yesterday it has been powered by battery (left charging overnight, which leaves controllers powered up), with the Status LED panel switch in OFF.

Stats:
12 34 00 00 00 00 55 57 56 96 00 3C 17 AC 17 CE 0E 2D 0D 33 0F 06 04 E9 0F 05 14 91 44 62 13 60 01 DE 0C 3F

stats 080718 overnight.png
Based on the battery voltage instantaneous minimum, controller temperature, and throttle voltage values, it looks like it was from when I was riding before I got home (except it doesn'tt show anny full throttle usage, of which there was plenty for moments here and there during acceleration). But based on the current values, it couldn't have been.

It couldn't be from the time it was charging, either, because the voltage is up t 57.7v (full) and has been for hours, and the minimum would'vve bbeen about 51v. Instead, it shows a total range of only 52.7 to 53v.

So I don't know when it saved these stats. (I'd expect it'd be from when I turned off the Status LED switch since I didn't cut power to the controller...but I did that before plugging in the charger, which means the batttery was sitting at 51v at that time for quite a while).

I haven't yet charted out teh difference in voltage reading between the CA and the SFOC, which reads higher than the CA, but I suppose it could be that issue causing what I see?


If I disconnect the serial, then battery, then reconnect serial, I get
12 34 00 00 00 00 55 57 56 96 00 3C 17 AC 17 CE 0E 2D 0D 33 0F 06 04 E9 0F 05 14 91 44 62 13 60 01 DE
0C 3F
which is the same as just prior, as expected; it hasn't been "on" so it hasn't changed the stats.


I disconnected serial, then connected battery then turned status led switch on, and left it sit for around 15 minutes while I went inside to cool off and do some other stuff, then came back to get the stats, by switching off the Status LED switch, then disconnecting battery, waiting a minute, then connecting serial:

12 34 00 00 00 00 3A 87 46 29 00 09 1A 72 1A 9B 04 18 03 AF 05 47 FB 02 05 16 14 75 15 BE 15 40 00 00 00 00
which all come up invalid (#NUM!).

I would expect there to be valid stats available after the SFOC has been powered on long enough to overwrite the previous stats, even if no actions (throttle, movement, etc) have been performed; the stats should show their actual values, whatever those happen to be.


EDIT: For curiosity, I tried the same stats above in the new stat sheet and they work there. :? Appears to be valid and expected values except the voltage reading too high (should be 57.7v)
 
Flash update was successful:
Code:
Initiating write...
      Searching for bl . (discarded null byte) . . . . . . (discarded null byte) (discarded null byte) . 
      Found dsPIC30F4011 fw ver. 4.0.3
      Waiting for the boot loader to be ready...ok
      Parsing hexfile...
            File timestamp: 8/6/2018 3:57:29 PM
            Opening hexfile...ok
            Validating hexfile...ok
            Hex file successfully parsed
      Writing flash....ok
      Tx 20.1kB / Rx 209 bytes / 16.8s
      Write successfully completed

Created new settings with the new stats sheet from yesterday (attached), using the same values for everything in green section as I previously did, and changing only the blue section for MF to 0.1 from 0.5. Will experiment with various MF values as needed.
0xF0 0x0F 0x03 0x5B 0x16 0xD3 0x00 0xF1 0x03 0xEA 0x1D 0x73 0x02 0x4F 0x01 0x22 0x16 0xF3 0x14 0x1E 0x1B 0x44 0x50 0x1C 0x02 0xA8 0x05 0x90 0x1E 0xAE 0x02 0x5A 0x00 0x03

0x18 0x75 0x17 0xB4 0x17 0x53 0x17 0x23 0x00 0x33 0x79 0x28 0x03 0xCA 0xFE 0xB1 0x3B 0x71 0xCE 0xD8 0x2D 0xA7 0xFB 0x05 0x04 0x9F 0x01 0x7B 0x00 0x06 0x00 0x00 0xF0 0x0F


I verified that the blue field for Torque down ramp allows values like 5 now, without the send data fields displaying Not Valid but have left it blank until testing with the other setttings as before with the new firmware changes things, and what it changes.


EDIT: It did accept 5, but now it only accepts up to 0.05. It doesn't appear to be affected by the MF field; haven't experimented with all fields yet to see which one causes the send data fields to give Not Valid when the TDR field is above 0.05.


I wouldn't expect the poweron stats to be valid after an update, but in case they're useful, this is what I get right after updating and uploading the settings
12 34 7F FF 00 00 7F FF 00 00 00 00 AF BC 00 00 02 3F 02 6D 04 AC FD 9A 01 3D 00 00 00 00 00 00 00 00 00 00
 
The 12v line at the Status LED panel shows 12.79v when controller is off, and 11.82V when it is on, sitting still.

During acceleration, it dips momentarily to 11.79v, then up to 11.85, then back to 11.82 as throttle is tapered off.

During a stutter/shudder, with MF=0.1, it does not change the above behavior within the response time of my DMM. If I could fit it on my handlebars ;) I'd put my old analog Simpson260 up there and watch the needle for correlation with the shudders or the throttle movement, etc. :lol:
 
Stats from the first test ride above:
12 34 00 00 00 7D 3D CF 62 00 01 58 19 81 1A 96 4A 48 51 69 62 68 B5 32 5C 71 14 41 61 8B AC 00 27 21 29 D8
appear to be valid, though the voltage is high, and the estimated battery current is off by quite a lot. Max RPM appears to line up with actual max speed.
080718 1 mf0.1 stats.png

My CA stats:
57.7vstart
56.9vrest
56.9vmin
109.8amax
21.1mph max

8 tenths of a mile riding around the neighborhood.

Acceleration from low speed is improved; I can now start from a point below where the CA starts to show speed (so less than 2MPH or so). (I should addd more magnets to my front wheel and increase the pole count of the sensor in the CA, so it might respond quicker).

Typically now I can give it 1/4-3/4 of a pedal stroke in my middle gear, which is still a very low gear, and with MF=0.1 it will start going forward at nearly full throttle (but not quite). Another stroke and it will go full throttle, or using lower throttle for less than a second, and I can go to full.

LIke this, it is approximately 5.5-6 seconds from 0 to 20MPH, no wind, on the flats. For just the one motor, that's pretty good. Not quite enough, but good. :)

I watched the CA current reading as I accelerated, and battery current is still down in the 30-40A range at low speeds, picking up into the 60s quickly, perhaps 10mph, and from there rockets up into the 90s+ fast enough I can't follow it and the speedo at the same time, then I'm at 20MPH and have to stop accelerating. ;)


The bad news is that now even MF=0.1 has the small amount of audible noise near (but not at) the motor, and has the low vibration thru the trike frame just sitting still. Before the firmware update, that's how MF=0.2 was and MF=0.1 was good enough. Now MF=0.1 is somewhere closer to the old MF=0.2 but not quite a bad.

However, the "cogging" when no throttle in use (offground or not) isn't detectable, which i was with higher MF settings in the previous firmware.


Also, I haven't been able to duplicate it, but the first time I used WOT at startup (wihtout moving at all, to see what happens), I heard a sound like a (pretty big) stick snapping, but there's nothing broken I can find, and there weren't any sticks in teh road or under the trike or in the spokes, etc. So I don't know what the sound was caused by.
 
Offground wheel test at MF=0.1, to see if I got the stutter/shudder anyore there (used to, but doesnt' now)

12 34 00 00 00 A1 47 9C 4D CE 02 85 14 1C 1A 50 59 DD 22 06 5A D5 EC A7 67 F3 14 2C 60 CA AD C0 1C 0E 29 5F

Smooth throttle application thru whole range, regardless of rate it's applied at.

CA stats
56.9vstart
56.9vrest
54.0vmin
18.6amax
2.2 a at full speed no load
Don't have wheelspeed sensor on this wheel yet.
 
MF=0.2 new firmware:

This is much louder and more movement just sitting still than I think I experienced even at MF=1 on the old firmware The hiss is around the same, but the vibration from the low frequency component is worse.

The worst part is, however, that sometimes while just sitting there, without me on it, it actually moves the trike back and forth up to a few millimeters, with no throttle action, and throttle output is at 0.89, with threshold for input set at 1.0v in the SFOC5.

I can't imagine that is desirable operation.

Offground, the wheel jitters around at least as much as it did in the video I posted before (though the audible hiss is not as loud). Keep in mind that MF was at 1.0 (default) in that video, and it's only 0.2 right now.


Just to see what happens I set MF back to default (empty field), and the hiss is at least as loud (seems louder, but would have to do a comparison using the old firmware to test, won't unless you think I should).

The low frequncy vibrations are worse, and the trike actually makes a creaking sound as it jitters back and forth, with the wheel on the ground, and will move back and forth up to a few mm sometimes.


FWIW, I noticed this while I was typing up the previous post after I'd done the new settings for MF=0.2 prior to going for the next test ride. I'm sitting under the trees in the backyard, trike next to me, laptop in front of me, and serial extension on trike is long enough to easily reach the laptop (I just have to remember to unplug it before rolling the trike away ;) ).

If I'm sitting on the trike, I don't conciously *feel* a jitter back and forth, but I can feel the low frequency vibration. Sitting next to the trike, however, I can *see* the trike jitter back and forth.

It's not a constant thing, and only happens sometimes. I suspect it's actually always moving but sometimes the amplitude of the currents in the wheel that cause the vibration are high enough to cause enough movement to be seen, just like with wheel offground it doesnt' always jitter it's rotation at the maximum, just sometimes.

I don't know what would happen to a normal bike on a kickstand with a big motor in it like this--the jitter would be at least a few times worse because the weight would be a few times less than the trike's. If I had something else setup to test I would, just to see....


Anyway, just a heads up that while acceleration and whatnot is much better, this other behavior is worse than original behavior.
 
MF=0.2 test ride
stats look reasonable other than the voltage showing high. Current at CA3 shows 109A max, while this shows 131A max. I'd venture that the old CA2 I used before I got the CA3 would show close to what SFOC sees. Which one is right? Don't know. :/

12 34 00 00 00 00 4D CD 5B B4 01 5F 19 C7 1A 34 3A 17 36 40 3B 4A DC 31 37 BD 13 DA 60 AE 14 20 21 8E 29 4D

080718 1 mf0.2 stats.png

Acceleration at lowest speed is about the same as the MF=0.1, except that when I can cause a stutter its' much rougher than the lower setting.

Acceleration above that is quicker, and it only takes about 5-5.5 seconds to reach 20MPH from zero.


Got too hot (110F but getting more humid, and all the breezes stopped) for further testing; had to come in for a while. (note: actually posted this some hours back, but it failed to submit until now).
 
Documentation questions, probably just nitpicky:

On page 10, section 5.1, it lists 40% as the first LED configuration, but in the stats page it lists that as 50%. I realize it's configurable...but should they match to start with? Or more likely, just say "for example" or similar above the picture in the manual?


Clarification:
This section:
Code:
9	Status	See section 4
E.g., 0b1000000000000110 means status 1, 2 and 15 are active
in the realtime stats section, page 31, doesn't make sense to me.

Couple of things. First, the reference to section 4 (page 8); I'm guessing it means section 5 (page 10 & 11) and the numbers just changed at some point?

Second, maybe I'm being stupid again, but how exactly do we convert that string into the decimal status info?

I have tried every way I can think of to decode it, and I don't see how it gets us a 1, a 2, and a 15.

I thought at first it might be simple single-digit hex to binary to decimal, so that it would look like the Status LED display but in segments, but it doesn't work out like that. A 0 would be 0000, a zero. A b would be 1101, which is 13 decimal. a 1 is 0001, indeed a one decimal, then there are a lot of zeros, then another couple of ones, then a zero.

I tried other conversion methods, but still couldn't figure out any way to get those decimal numbers out of that hex string.



Looks like most of the other stuff I'd seen is already fixed/changed, other than a couple spelling corrections (I fixed them in the version I have here; am still rereading the manual for potential better wording or clarifications).
 
Something about the Stats that is not yet in the manual. They are saved at complete standstills (since writing to EEPROM implies everything else has to wait for some millisecond). Auxiliary LED-code steady 11 turning off signals standstill.

BTW, maybe you want to take the four minute latency down to one or two for the testing you are doing?

(Max Iq reference stat is now fixed in the S&S sheet in the public folder.)

EDIT: It did accept 5, but now it only accepts up to 0.05. It doesn't appear to be affected by the MF field; haven't experimented with all fields yet to see which one causes the send data fields to give Not Valid when the TDR field is above 0.05.
In the file you uploaded just below, 5% seems to work fine. Let me know how to reproduce this.

During a stutter/shudder, with MF=0.1, it does not change the above behavior within the response time of my DMM.
Great, thanks. The A1 semitone wooden cabinet warranted an investigation;)

Anyway, just a heads up that while acceleration and whatnot is much better, this other behavior is worse than original behavior.
Working on this.

MF=0.2 test ride
(Max Iq reference should read 208.) The highest throttle we have seen in any of your Stats is 4.13 V. Here it is 3.78, which corresponds well with the fact that 208 of the 250 A programmed were called for.
On page 10, section 5.1, it lists 40% as the first LED configuration, but in the stats page it lists that as 50%. I realize it's configurable...but should they match to start with? Or more likely, just say "for example" or similar above the picture in the manual?
I have marked this up for change.

Couple of things. First, the reference to section 4 (page 8); I'm guessing it means section 5 (page 10 & 11) and the numbers just changed at some point?

Second, maybe I'm being stupid again, but how exactly do we convert that string into the decimal status info?

I have tried every way I can think of to decode it, and I don't see how it gets us a 1, a 2, and a 15.
Section 5 it is, fixed now.
Someone in the dashboard thread will for sure figure it out and offer you a suitable code snippet.
 
incememed said:
Something about the Stats that is not yet in the manual. They are saved at complete standstills (since writing to EEPROM implies everything else has to wait for some millisecond). Auxiliary LED-code steady 11 turning off signals standstill.
Ah; that makes sense. Does that mean:

--it has to sit for four minutes at a standstill before it writes them,

or

--just have to have battery power connected and status LED panel switch on for at least four minutes, and then whenever a standstill occurs after that point it will write the stats?




BTW, maybe you want to take the four minute latency down to one or two for the testing you are doing?

For this particular testing, perhaps. Since I have the serial cable connection thing worked out so it doesn't take me so long messing with it to get it right :oops: I think it can be set down pretty low. Maybe a minute or two would be fine?

I don't suppose there's a way for me to change the setting here, rather than requiring a firmware update?




(Max Iq reference stat is now fixed in the S&S sheet in the public folder.)
Thanks--I've grabbed the new one.



EDIT: It did accept 5, but now it only accepts up to 0.05. It doesn't appear to be affected by the MF field; haven't experimented with all fields yet to see which one causes the send data fields to give Not Valid when the TDR field is above 0.05.
In the file you uploaded just below, 5% seems to work fine. Let me know how to reproduce this.

I'll be trying different things today after it gets too hot to be outside testing stuff on the trike.


During a stutter/shudder, with MF=0.1, it does not change the above behavior within the response time of my DMM.
Great, thanks. The A1 semitone wooden cabinet warranted an investigation;)
Would it be helpful to get a video / audio recording of the stutter/shudder as it occurs? Or other behaviors?



(Max Iq reference should read 208.) The highest throttle we have seen in any of your Stats is 4.13 V. Here it is 3.78, which corresponds well with the fact that 208 of the 250 A programmed were called for.
I should measure the voltage with a couple of different DMMs at the throttle connector for the SFOC itself while SFOC is connected, and see if it's consistent with that, in case something is different about the actual throttle voltage at that point.

It's not much difference, but the full throttle voltage is higher than that, and I am definitely hitting the stop. ;)

If it's not really reaching the full voltage at the SFOC for some reason, I can change my stats&settings sheet values to reflect the actual range seen at SFOC, so that it is responding to the actual demand I'm trying to place on it.



On page 10, section 5.1, it lists 40% as the first LED configuration, but in the stats page it lists that as 50%. I realize it's configurable...but should they match to start with? Or more likely, just say "for example" or similar above the picture in the manual?
I have marked this up for change.
Thanks. I'm just trying to make sure the easily-confused people out there don't get that way. Since I can be one of them sometimes...it helps me too. :oops:



Second, maybe I'm being stupid again, but how exactly do we convert that string into the decimal status info?

I have tried every way I can think of to decode it, and I don't see how it gets us a 1, a 2, and a 15.
Someone in the dashboard thread will for sure figure it out and offer you a suitable code snippet.
[/quote]
I don't understand.

Sorry I'm such a PITA idiot, :oops: but:

Do you mean that there is some other place the string conversion info exists that I am not seeing? But that someone else in that thread already knows about?

Or do you mean that it is extremely obvious and I'm just missing it?

Either way, a bit of explanation of how to take that particular string of the 9th code, and turn it from the number given of "0b1000000000000110" into the LED status codes of 1, 2 and 15, would be extremely helpful.

I know sometimes I can be extremely dense, but I honestly can't see how the one can be converted into the other in any straightforward way. It doesn't convert into binary or decimal from hex nibbles or bytes into those codes, nor does it convert from binary to decimal into those codes.

I did more googleing, and found that "0b" can be used as a marker to show the beginning of a binary string (instead of being a 1byte hex number; not a convention used way way back when I learned this stuff :oops:). So assuming this is just a switch in terminology from using hex everywhere else in that section to using binary, and is instead a 16-bit binary string, it still doesn't make those codes, regardless of the direction it's read from.

If read with MSB at left,
1000 0000 0000 0110
it's a status 8, a zero (not in the status code list), another zero, and a status 6.

If read with MSB at right
0110 0000 0000 0001
it's a status 6, a zero, another zero, and a status 1.

If read as the inverse of either of those:
0111 1111 1111 1001
it's 7, 15, 15, 9

1001 1111 1111 1110
9, 15, 15, 14

So there arent' any methods I can figure out that give those codes from that string.

Since that is the only example given to work out a code from, there must be something else that has to be done to it to get those codes. (and something to account for the sixteen bits vs the three codes, when all the codes are four bits; but I'd assume that if it's a zero code then that's just no code active)).

So there has to be some other unspecified conversion process necessary, that the manual (or any other documentation I can find) simply doesnt' discuss, or I can't understand. :(

Either that, or (just occured to me as a possibility) the given example string actually can't be converted into the given example status numbers, and they're both just randomly given number sets...which is extremely unhelpful to figure out how to read the realtime info.
 
Stats & Settings sheet issue with Torque Down Ramp value:

I don't know yet what causes the problem, but I took the new stats sheet here:
https://drive.google.com/open?id=1UmMOCWH3_cAB-47qDnAP_0myjk_16IE5
also attached here:
View attachment Settings&Stats SFOC rev 5 pub.xls
which started out with a blank field for TOrque Down Ramp, and simply clicked on that field, typed 5, and pressed Enter. As soon as I did so, all of the Send Data fields for the various programs changed to "Not Valid".

I tried various values for Torque Down Ramp, finding that as in the last reported problem with it, the highest that can be input without causing the Not Valid issue is 0.05.

This is using WPS Office Spreadsheets version 10.2.0.7439 or google sheets directly from the shared file.

I'll post more info as I find it.
 
amberwolf said:
--just have to have battery power connected and status LED panel switch on for at least four minutes, and then whenever a standstill occurs after that point it will write the stats?
That's it.

For this particular testing, perhaps. Since I have the serial cable connection thing worked out so it doesn't take me so long messing with it to get it right :oops: I think it can be set down pretty low. Maybe a minute or two would be fine?
I don't suppose there's a way for me to change the setting here, rather than requiring a firmware update?
Correct, in firmware. I'll make it one minute in the next update.

Would it be helpful to get a video / audio recording of the stutter/shudder as it occurs? Or other behaviors?
The main objective was to ensure there wasn't some unexpected behavior on the 12 V, so that our efforts with code and settings are not in vane.

If it's not really reaching the full voltage at the SFOC for some reason, I can change my stats&settings sheet values to reflect the actual range seen at SFOC, so that it is responding to the actual demand I'm trying to place on it.
Good idea.

but how exactly do we convert that string into the decimal status info?
16 bits in a word, numbered 0-15 going from right to left. There are 15 Status panel LED codes (code zero would be no LEDs at all, so not useful). The algorithm would have to go bit by bit, where a one would mean that LED code is active.
 
Firmware update successful

Code:
Initiating write...
      Searching for bl . . . . . . 
      Found dsPIC30F4011 fw ver. 4.0.3
      Waiting for the boot loader to be ready...ok
      Parsing hexfile...
            File timestamp: 8/8/2018 11:04:16 AM
            Opening hexfile...ok
            Validating hexfile...ok
            Hex file successfully parsed
      Writing flash....ok
      Tx 20.2kB / Rx 207 bytes / 10.3s
      Write successfully completed

Since it says settings dont have to be reloaded; I disconnected serial, powered on trike, and switched on SFOC at the status LED panel switch.

No sound or detectable vibration from the motor. I think the last setting I'd used was MF=0.2, but can't verify that without being able to read back the settings from the SFOC.

No ride test yet, but offground test verifies motor operation. It did have trouble starting up (unloaded, offground) from a stop, even at low throttle, sometimes attempting to start backwards (as much as perhaps a tenth? of a rotation) then stuttering and stopping, sometimes stuttering a bit before going forwards. Out of around a dozen offground attempts, more than half had some measure of issue starting up in smooth forward rotation. I dont' recall that from previous offground tests; I think it was only loaded operation that had those issues.


Stats from it after sitting for the time to type this up (probably 15-20 minutes including paying attention to Yogi and Kirin when they came over to insist....):
12 34 00 00 00 00 3A 3F 48 21 00 00 19 E4 1A 29 03 E4 03 4C 04 F8 FB 0A 04 D9 14 9F 15 CD 14 E0 00 00 00 00
View attachment 1
Odd that it doesn't show the offground test results in that. (says there was no throttle usage, and zero RPM).

Next, I used the newest stats&settings sheet, changed just the trike-specific settings, and left everything else at defaults. (so MF=1.0).

No noise or vibration just sitting there. Offground test startup ok, much better than at the (presumably) MF=0.2 setting it was at for the previous test above; only got one (2nd test) out of a dozen or so startups that attempted to run backwards, and this one did not stutter, but it did run backwards very slowly, "clicking" thru each position, for almost a quarter rotation until it stopped (even though I was still holding throttle at max). Letting go of throttle and restarting worked normally, and no other startups failed to smoothly startup.

During each test, the motor hiss was very loud, at least as loud as it had been with the original firmware. The "random" vibration from the low frequency part was also at least strong as original, too. (both while motor is spinning, and if I keep throttle at the very minimum to prevent it from shutting off (see below) but at either extremely low RPM or not spinning at all.

There appears to be a timer now, so that with no throttle input, it shuts down the position sensing, eliminating the hiss and vibration after 1-2 seconds when stopped. I haven't yet tested to see if it also times out when motor is spinning but with no throttle input (hopefully). This is much better, though still not ideal (but probably the best compromise with the way SFOC senses position).


Stats from second test:
12 34 00 00 00 00 43 11 49 FD 02 5E 19 E7 1A 1F 2A A1 29 BE 2A CC 0A C9 2A F5 14 A5 5F AB 15 20 1C E7 28 AB
post firmware update w settngs update stats 080818 2.png
Looks normal, appears to have captured the offground testing.

Min battery voltage instantaneous seems awfully low for a no-load offgorund test. I'm going to do some metering at connectors and find out if it's drop across wires/etc, then come back and do testing after I resolve that. (it's not nearly as hot today as yesterday, but it's a lot more humid).
 
incememed said:
amberwolf said:
--just have to have battery power connected and status LED panel switch on for at least four minutes, and then whenever a standstill occurs after that point it will write the stats?
That's it.
Thanks--simple enough for me to remember, then. :)



The main objective was to ensure there wasn't some unexpected behavior on the 12 V, so that our efforts with code and settings are not in vane.

Ah, yeah, I guess if there was a hardware problem it's tough to fix in firmware. ;)

If it's not really reaching the full voltage at the SFOC for some reason, I can change my stats&settings sheet values to reflect the actual range seen at SFOC, so that it is responding to the actual demand I'm trying to place on it.
Good idea.
Testing this now, while testing some other voltage stuff under the trike.
but how exactly do we convert that string into the decimal status info?
16 bits in a word, numbered 0-15 going from right to left. There are 15 Status panel LED codes (code zero would be no LEDs at all, so not useful). The algorithm would have to go bit by bit, where a one would mean that LED code is active.

OH! Thanks! Now it makes perfect sense. :oops: I'm sure that was completely obvious to anyone other than me. :oops:
 
Definite Problem report:

While testing voltages and voltage drops on cabling, etc, under the trike, with the trike on it's side (so wheel offground), I happened to grab hold of the wheel to steady myself (something I often do) as I ower myself to the ground there.

It felt very resistant to turning, as if the windings were actually shorted.

The trike is powered on, and the SFOC's Status LED panel switch is on.

There's no noise from the motor, or vibration.

But attempting to turn the wheel by hand is difficult, and gets harder the more I try to turn it. If I turn it far enough, (perhaps a rotation to a rotation and a half or two?) then it activates the controller's position sensing (the hissing and vibration come back). At that point the wheel becomes easier to turn, more like normal (but still not as easy as if the SFOC is switched off or unpowered).

If I attempt to turn the wheel backwards, after the SFOC is reactivated, after a rotation or so it will actually actively spin the wheel itself, taking it out of my hand, and continue spinning it in reverse very slowly, perhaps a couple dozen RPM? with this rotation slowly fallling off (but still being actively caused!), for at least another minute or so, until it ceases rotation and again is "locked" in place.

While reverse powered rotation is occuring, there is no hiss or vibration, just a very slight whine. The hiss/vibration stops the instant it begins self-rotating the wheel.


Durign reverse self rotation, it is at significant torque; I can't stop it by hand, or with a 2x4 levered against the tire as brake.


I can't cause it to self-rotate forwards so far.





Not part of the problem most likely, but the wheel still jitters up to a couple of mm or more, randomly, just sitting there offground powered on and switched on.
 
Voltages at battery input and throttle, SFOC side:

At the battery connector , SFOC PP45 backside, meter leads touching the contacts inside thru the back of the housing read within 0.1v of the CA reading (which is at the shunt less than a foot of wiring from this point), during offground noload testing.

The same is true when I use a wooden 2x4 as a lever against the tire to add a load to slow the wheel a bit and force higher currents, at any throttle position.



Throttle, however, is odd.

The max I get out of it at the SFOC side of the bullet connectors I am using to join the SFOC's connector to the trike system, for the ground and the throttle signal wire, is 3.67v.

The minimum, at no throttle, is 1.28v, when the SFOC is in it's new "standby" mode (no hiss, but still powered and switched on).

If I manually spin the wheel until it comes out of standby and makes the hiss, the throttle drops to 1.11v, though nothing at the throttle end has changed.

If I rotate the wheel manually, just a few degrees at a time, each change causes the throttle voltage to change by a few hundredths of a volt, upward to around 1.14v max, and downward to 1.11v min.

If I trigger rotation via throttle, then let throttle go, then while it is spinning, throttle voltage drops as low as 1.04V, but rises as the wheel slows, back to 1.11v.

When systme is stopped and in standby, very slowly increasing throttle until it reaches 1.44v does nothing. At 1.45v it will begin hissing. If I immediately let go of throttle hissing ceases immediately, and throttle voltage drops to 1.22 or 1.23.

If I hold the throttle right at 1.45v, the hissing cuts in and out as if it is right on the border of coming on.

If I go above 1.45v the wheel begins to make a deeper sound, and the hiss lowers in frequency, but the wheel does not attempt to rotate (other than the "normal" jitter).

If I continue upward in voltage, at 1.47 to 1.48v the wheel begins to rotate.

If I hold that throttle position, the wheel will very slowly decelerate, and the throttle voltage will *rise* to 1.50v or so until it is stopped, and it will continue hissing, and jittering (this is the same jitter as when having no throttle input.


As a test, I disconnected the throttle connector completely, and I still get 0.94v across SFOC's throttle signal and ground pins.

With the throttle still not connected to SFOC, the throttle itself reads 1.33v minimum, and 3.64v maximum. Strange, because it read 0.89 to 4.5v before, with teh same DMM (Extech).

A second (crappy harbor freight) DMM reads within 0.1v of the same readings on all the tests above, which is about as close as it is to anything else.

A third test, a Fluke 77-III, is within 0.03-0.04v of the Extech.

So...I'll change the expected throttle values in the Stats and Settings sheet and reupload the settings, and report back...but gotta eat something first, before I lose other internal organs to my rumbling stomach. ;)
 
I've updated the settings with a throttle range of 1.35v to 3.65v, and tested that, along with going back down to MF=0.1.

Poweron stats were
12 34 00 00 00 00 3B 6C 4F 87 02 7B 19 F0 1A 1D 1A 54 18 0C 19 9F 08 66 1A 66 00 00 66 3C 14 60 14 C1 2C C7



The offground behavior is the same, incluidng the inducable reverse self-rotation, except that the hiss and vibration when not in standby are very quiet.


Manually-inducable reverse self-powered rotation:
ON ground, I did a couple of tests to see if the inducable reverse self-rotation would be a problem, and it could be on a slope, but isn't on the flats.

ON the flats, I can push backwards with my feet (or use the other motor in reverse) to initiate the behavior, and I can feel when it starts becuase it becomes easier to back up, but it isn't powerful enough to keep pulling me and the trike backwards over either the brakes or my feet on the ground or even just my feet locked on the pedals keeping them still (they drive the left rear wheel only).

On my driveway, if I sit on the trike, that weight plus the "locked" wheel behavior while in standby are enough to keep it from rolling backwards.

If I am not on the trike, then sometimes (but not always) it overcomes the locked wheel and begins to roll backwards from gravity, very slightly, and if it rolls far enough then the reverse self-rotation takes over and acclerates the trike backwards down the driveway. Since the steering flops over at this point, the front tire being sideways adds enough drag to slow the trike and stop it. But if I use the steering lock pin to keep the steering straight, then it'll continue all the way off the driveway and into the street. (very slowly...but still it's moving). It will stop once the back wheels roll down and just past the gutter, where the street rises again.

This is not a realworld issue for me because I have "wheelchair brakes" on the rear tires as parking brakes, and I wouldn't leave the system powered on and walk away....but it's still not desirable behavior in a controller.


"Locked wheel" behavior:
Because (without using hte left motor) I need to pedal a bit to reach a speed at which SFOC can begin driving the right wheel motor, the locking of the wheel it does now is a problem. This feels like the same torque regardless of MF setting (havent tried any others) from default of 1 down to 0.1.

It's harder to push against, and hurts more to do. It's like being on a slight uphill slope.

It's also harder to manually push the trike along when I'm standing beside it--getting it started going feels like it's got a wheel in a pothole; once I get it moving enoguh to rotate the wheel far enough, it moves easily enough, but until then it's pretty hard to move.

I can imagine if I had an SFOC on each of the rear wheels it might be impossible for me to move it by pushing beside it under a number of conditions, though not on a regular flat with no load. (it's heavy enough as it is)



Test ride at MF=0.1, new throttle settings:

Acceleration is quicker, likely because the throttle is now able to command full current instead of only partial.

Can't give full throttle until I'm somewhere close to 10MPH, or it'll get the stutter/shudder. However, when it happens I can back off just a little for it to go away, and then I can reapply throttle. I don't have to completely let off throttle like before.


Shutdown during cruise

I have been unable to reliably duplicate it, but there are times at which I can be riding along normally, at speeds from around 15MPH to around 20MPH, cruising not accelerating, and there will be BANG from the SFOC-controlled motor, and the SFOC will shut down. It's a little like the sound I heard the other day, which I thougth at first was a big stick being broken, but this is sharper and louder, and violently brakes that side of the trike for an instant. (not even long enough to cause brake steer)

I'm still trying to find the specific conditions under which it happens.

I do get a code 10 when it happens, so its' the regular shutdown failsafe. Just odn't know why yet.

I also still get a regular code 11 whenever I'm in motion, but not when stopped.

Ride stats
12 34 00 00 00 00 39 C8 53 48 01 47 19 9A 1A 05 61 B6 5C 46 63 FC BE 58 5F 1F 14 52 5F 5E 13 60 29 E7 33 4E


ca stats
119.6amax
-10.2 amin
54.4vmin
56.1vrest
 
Back
Top