Go Swissdrive thru-axle Hub Motor with EBiCS Firmware

[kartoffelbrei]

i hope this is the correct forum for this question.

i'm was for a strong, open, thru-axle rear hub motor which can fit my yuba mundo v6 bike with two growing kids and loads of cargo on board on a regular basis.
after scanning the market, i came across a supercheap, high-end Go Swissdrive (company closed down a few years ago ) hubdrive which is quite availale here in Germany the only caveat: No controller included, it just comes with bare interfaces,the good side: Should be a great platform for open development, i tought...

my planned setup:
- Lishui contoller (LSW-1216-1-1F) with EBiCS Firmware (master branch) @stancecoke Great to have this!!
- 48 V Battery (13S3P)
- maybe some glue-logic PCB
- a good display (not t hand yet)

The motor provides the rotor position via two quadrature Hall signals, the torque signal via another Hall sensor, and the motor temperature via an NTC resistor; the latter is not of further interest here.
The two analog position signals are output of two Hall sensors (Honeywell SS495A) on a magnetic pole wheel at a rate of 20 sin/cos periods (this is what one would refer to as electrical revolutions ?) per one mechanical revolution.

For this purpose, I have already converted the signals to 3-bit Hall switch signals using a small STM32 microcontroller (Back Pill), some simple filtering is included in order to not get bouncing at edges.
Actually, I’m quite certain that this conversion works correctly; the electrical switching angles are also consistently very similar within successive revolutions, deviating by perhaps +/- 1°
e.g.:
3°
63°
123°
183°
243°
303°
I’ve also already run through these with a small offset (+/-), since i think it's essential to ensure that the magnetic pole wheel runs in sync with the motor’s 20 poles.

The autodetect routine stops after about a 20° rotation, and then the motor continues running at 0.75 U/s.
This rotation sounds like a vintage coffee grinder without beans. It seems to run very inefficient.
(I tested the motor in the exact same mechanical setup — free to move on its axis — as a test using the sensorless_VESC branch; there, it sounds very smooth but doesn’t always run forward.)

Since i feel like i'm starting to get quite desperate about this project not going anywhere...Question for the experts @stancecoke: Since I just can’t seem to find an error in the code, are there any fixed timings or conditions in the firmware that could prevent 20 electrical Hall sequences from being converted into a single mechanical rotation? if there is anything additional information i'd be very happy to provide it.

The pics show the interior of the motor, the PCB essentially only holds the three Hall sensors mentioned earlier, two (label HS1 HS2)located center-bottom-right in a line and one (HS3) closer to the center which gives the torque signal(but this is another topic).

 

[stancecoke]

The autodetect routine stops after about a 20° rotation, and then the motor continues running at 0.75 U/s.

What is the hall signal output sequence of your Blackpill?
It has to be 6-4-5-1-3-2 or backwards.
Have you hooked a USB-UART converter to the controllers TX line of the display connector and have logged the debug output during autodetect?
The autodetect runs the motor in open loop for three electrical revolutions.
So the debug output must show 18 hall events, at least the last 6 must show reasonable angle information.

EBiCS_Firmware/Src/main.c at b371156e2693d929e51751223096dc321caecc56 · EBiCS/EBiCS_Firmware

Free FOC firmware for Lishui E-Bike-Controllers. Contribute to EBiCS/EBiCS_Firmware development by creating an account on GitHub.

github.com

I guess the sequence is not OK, or you are not producing 6 hall states per electrical revolution.

 

[kartoffelbrei]

Thank you very much for that quick reply Stancecoke!

indeed, it was a stupid issue on my side - now it works charmingly

just for the record:
i only used exactly the last sample from the two ADCs, this is very prone to EMI uptake by PWM environment...
-> now i do average of 16 samples
2nd issue: the deeper i was debugging the longer my frequent (blocking) sprintf command got, clogging things up even more, vicious circle :|

next task is to implement this great torque sensor, i'm unsure if the signal of this swissdrive built in torque sensor is strong/clean enough under working conditions - any experiences ?

additionally, would it be possible to generate the pedal signal from the torque sensors signal period ? this may require some serious signal conditioning/proccessing - experiences ?
...or is it way cleaner to use a separate PAS disc style sensor attached to the crank ?

 

[stancecoke]

additionally, would it be possible to generate the pedal signal from the torque sensors signal period ? this may require some serious signal conditioning/proccessing - experiences ?

I started this way when using a strain gauge on the rear axle for detecting the riders effort.
Of course, you can get the cadence from the torque signal wave form. But if you read the torque on the rear sprocket, you don't need the cadence information for the equation

p_motor = assist factor * p_human

as the rear sprocket speed is always the same as the wheel/motor speed.

p_human = cadence * torque on the crank = wheel speed * torque on the rear sprocket

 

[kartoffelbrei]

Thanks again for your reply.
I'll definitely try to go with my already existing torque sensor, i just had the feeling that the signal in terms of quality will need some filtering/processing before it can be sent to an ADC. Pic attached was torque signal by weak hand and about 20 cm lever (AC coupled, offset is ~2.5V)

Now when using the motor with no load on my bench, it seems that nearly irrespective of what i set in SPEEDLIMIT and TS_COEF the motor will pick up acceleration (when just rotating the motor forward by hand) and at some stage and will indefinitely accelerate until it reaches about 40 kmh (100 Hz on any Hall sensor) and stay there even if the stimulus (sprocket movement or pushing) was only active for a short period.
feels like some regulation issue, i'd need it to stop in any case when an external stimulus stops. Spinning the wheel (or motor housing) by hand should not start the assist in any case.

any clues what could be wrong here ? Again some timeout ?
(i am using a lab power suppy at roughly 50V and only 2 A current capability)

i have set:
PULSES_PER_REVOLUTION 20
SPEEDSOURCE INTERNAL
GEAR_RATIO 20
and
PAS_IMP_PER_TURN 20 (i think this my not be neccessary anyway)
(throttle left unconnected)

 

[stancecoke]

any clues what could be wrong here

Without a setpoint different from zero, the PWM is not activated. So you must apply a setpoint somehow. You can look at the iq setpoint in the debug output.
If the setpoint is triggered once, the PWM is switched off after a short period of standstill. So if there is some drift in the phase current offset, it may happen, that the wheel is not stopping in the air, but you can brake it very easy, as the the current is very small. With the wheel on the floor, you will not recognise it at all.

Please push your recent code to your fork of the repo at GitHub, then I can take a look.

 

[kartoffelbrei]

Thanks!

yes, at first (in this acceleration runaway process) the wheel is easy stoppable by hand, but if i left it accelerate further (no load) for a few more seconds it became impossible to stop... but then, under loaded condition this phase may never be reached.

I will check the debug output closely concerning the iq setpoint.

I really didn't change/modify the code apart from the debug string, parameters the config.h and motorcurrent and speed during the autodetect routine.

I could push the code from my backpill "hall emulator", if others are interested in using already present quadrature signals with EBICS. i think from a resource point of view this may even be possible within the STM32F103 - but it would require two additional pins for AD conversion to be routed through, if all others are in use elsewhere.

 

[stancecoke]

but it would require two additional pins for AD

What is the hall sensor output of the original GSD? It seems to be a standard setup with Hall A ,B, C.
Why do you have to process it additionally?

 

[kartoffelbrei]

i attached some images of the open motor.
the mainboard in the motor, has not much on it, apart from three quite expensive analog Hall sensors (Honeywell SS495A) you can see three hall sensors labeled HS1, HS2 and HS3. HS1 and HS2 are located directly under the mag. polewheel, which is on the 2nd half of the motor.
if i supply the sensors with 5V and scope the output while turning the motor, you see a analog quadrature (sin/cos) signal (see pic), showing 20 periods within one full mechanical rotation.
My additional blackpill STM32 is now used for AD conversion and emulation of the expected 3-hall-switch-signal.

HS3 handles the torque sensor, different story. Additionally an NTC resistor is strapped against the winding copper, pic top left.
The three large metal parts seem only to be used for mechanical mounting of the PCB, keeping the ability to fine tune the lateral positioning.

EDIT: I'm unsure if the firmware can handle the fact that with this motor setup we'll still expect 6 hall interrupts per electrical rotation (as commented in Line 2101 of main.c), but we have 20 electrical rotations (or 6*20=120 hall events) per mechanical rotation.

checking the UART debug, the value for "MS.i_q" is never zero, rather 4...8 changing periodically, also audiable ticking sound from the motor. So when i give the motor a push, it will continue accellerating, without obeying any limit, although i wired up one hall signal (having set 20 pulses/mechanical revolution) and e.g. 10 kmh as limit