[Help Requested] Reverse-Engineering an undocumented conversion kit

I have an old (first generation?) OxyDrive front hub conversion kit. OxyDrive have not responded to any of my queries, and there is no longer any reference to this kit on their website.

The motor is a 250W geared front hub labelled as DAPU M123 - I can find the part online, but no technical details and there's no way I can see to open it up and find the specs directly. DAPU have also not responded to any of my queries.
http://www.dapumotors.com/portfolio/m123-fs/

The controller looks superficially similar to a KT S06S, and I initially tried replacing it with one but realised my mistake when the capacitors on it blew up. I believe this was due to a mis-configured P1 setting causing current spikes as the power was being delivered to the motor phases out of sync with it's rotation.

After taking the waterproofing layer off the original controller, I can see the circuit looks simpler that the KT controllers, and there are no connection points that look likely to be a programming interface like the KT controllers have.

The board is labelled:
ANANADA REV.S68_V3
and the control chip on it is labelled:
ANANDA12
990HB VG
MYS 139

Searching online for this has yielded nothing at all.

The kit came with a C300 display (C300-1303-D601 36V). Given that these displays communicate via UART, is there some way I can hook it up to a PC and read the configuration from it to figure out the correct settings to use the motor with a KT controller?
I've replaced the capacitors on the KT S06S that I blew up, and flashed it with the OSEC firmware. I could try wiring it up and figuring out the settings by trial and error, but that would be a long and tedious process, and I don't really want to replace the capacitors again if I manage to blow them up in the process of figuring it out.

I wish it could be that easy.

Even if you could read data from it, you'd have no way to know what any of the values mean.

They would not come to you as anything like "Current limit equals 22A", it would just be at best a bunch of hexadecimal (or other digital format) data, without even a way to know which numbers are representing which parameters, much less what scaling/etc they use.

It's pretty much guaranteed that the data format/etc won't have anything to do with the format/etc that the KT uses, so it is unlikely in the extreme that you'd be able to transfer (by hand or otherwise) any of the data, values, parameters, etc from one to the other. :/


You could try it, I don't know if it would hurt anything, but it would most likely be a waste of time.



FWIW, the caps shouldn't blow up if they are of a voltage tolerance that allows for the spikes that can happen, unless something is going on that causes reverse current thru them sufficient to begin boiling the electrolyte. Or unless they happen to be such high ESR that any significant ripple current boils it.

Given that it's only the P1 value for the timing that I don't know I assume it should work OK in sensorless mode, though at a reduced efficiency than if I could get the timings correct.
As I write this, I've had an idea - what if I hooked the hall sensors in the motor up to an oscilloscope and looked at how they triggered during one complete rotation of the wheel. Would it be possible to calculate the appropriate P1 value from that?

My understanding is that if the P1 value is incorrect, the mis-timed application of power to the motor results in back EMF producing a reverse voltage across the capacitors. The bike was run like this for almost 1000 miles, I assume the constant reverse voltages across the capacitors wore them down until they finally failed.

gutyex said:

As I write this, I've had an idea - what if I hooked the hall sensors in the motor up to an oscilloscope and looked at how they triggered during one complete rotation of the wheel. Would it be possible to calculate the appropriate P1 value from that?

Click to expand...

Sorry, I have no idea, because I don't know what P1 is, or is for.

My understanding is that if the P1 value is incorrect, the mis-timed application of power to the motor results in back EMF producing a reverse voltage across the capacitors.

Click to expand...

Since the main capacitors (and almost all secondary caps) of a controller are directly across the battery power bus, it would have to actually reverse the battery voltage to be able to put a reverse voltage on the caps.

With the wiring lengths being what they are from controller to battery, then between inductance and resistance there could be some spikey reduction and increase of voltage across the caps, but it couldn't actually reverse it.

If you have an oscilloscope you can see what's actually happening.


If it worked for a thousand miles, then the most likely thing that caused caps to blow up is age and heat. If the controller is out in the open airflow, caps can last longer, but if the controller gets hot enough inside, for long enough at a time, it'll slowly cook the caps. Caps have a rated voltage and a rated temperature, as well as an MTBF rating or lifespan rating (whcih usually assumes you are not always running it at the limits); the closer it's run to those limits teh shorter it's life is likely to be.

Reversing voltage on a cap can very quickly cause it to explode, so I think it's unlikely to be many reverses over time causing the failure you saw.

The P1 value on KT controllers is the number of permanent magnets in the motor times the reduction ratio of it's internal gears.
It's used to synchronise the controller with the motor's rotation, and having it set wrong causes reduced efficiency, torque & top speed, and excess noise from the motor & heat from the controller.

If I could open the motor, I could count the magnets & the teeth on the internal gears to work it out, but unfortunately this doesn't seem to be possible.

Given what you've said, overheating seems like the most likely reason for the caps to blow - it was a new controller, but it was definitely running much hotter than it should due to the above mentioned issues.

gutyex said:

If I could open the motor, I could count the magnets & the teeth on the internal gears to work it out, but unfortunately this doesn't seem to be possible.

Click to expand...

Opening various motors takes different tools/etc depending on the model/brand. The two most common ways are bolts on the side cover near the flange, or the side cover threading directly in like a big screw-on cap (in which case it will probably have some sort slots or castellations or splines at the bearing area).

But you don't always have to open it to figure it out.

Is it a sensorless motor, or does it have hall sensors?

If the latter, flip the bike upside down, and put a voltmeter set to 20vdc range, black lead on hall ground, red lead on any of the three hall signal wires. You'll need to leave the hall connector plugged into the controller so the halls have power (everything should be left connected), and just put the meter leads in thru teh back of the connector if it's got open housings, or you may have to either open the controller or peel back some of the cable housing to reach the individual wires within it, somewhere along the cable length.

Put the valve stem aligned with something like the fork or frame so you know it's exact position and can stop turning the wheel once it reaches exactly the same position again. Then by hand turn teh wheel *backwards* (so the internal gearing will be forced to turn the motor), watching the voltmeter. Count up one every time the voltage changes; it'll go down close to zero and up close to 5v repeatedly.

When its' reached the same position, stop counting and write the number down.

For a DD motor it's usually 23 (46); I can't remember how many magnets my smaller Fusin had. Some of the Cute and other similar sized motors have 20 magnets for the outrunner style, and 17 for the inrunner. Many geared hubs are 4:1 or 5:1 ratio.
So let's say you get a hundred pulses; it's likely you have 20 magnets and a 5:1 ratio. If you get 68, it's probably 17 and 4:1. Etc.


If it's a sensorless motor, you may be able to short all the phases together with the motor disconnected from the controller. Then turn the wheel backwards very slowly, and count the number of times the wheel feels like it drags or pulls.

I've asked various people with more experience than me in dealing with mechanical stuff and no-one's been able to figure a non-destructive way to open it - If there's a screwthread in there anywhere it's either jammed tight from years of abuse, or deliberately sealed somehow.

The motor has hall sensors, I can power them up with a 5V supply and get readings from the sensor lines as they trigger. I'll try counting the pulses per rotation over the weekend and see if I can get anywhere with it.

Since the hall sensors are open collector devices, just giving them 5v doesn't let you test them. You also have to use a pullup resistor, say 10kohm ish, on each signal line to the power supply positive voltage.

The simplest way is to just leave it hooked to the controller while it's powered on, otherwise you have to build something to do it.

There's info here
https://www.ebikes.ca/learn/troubleshooting.html
on how to test a number of things on an ebike, but their hall sensor test suggest teh same method I gave first.

It'll be much quicker & easier for me to wire in a pullup resistor than to connect it all back up to the controller at this point, but thanks for the warning.

amberwolf said:

Put the valve stem aligned with something like the fork or frame so you know it's exact position and can stop turning the wheel once it reaches exactly the same position again. Then by hand turn teh wheel *backwards* (so the internal gearing will be forced to turn the motor), watching the voltmeter. Count up one every time the voltage changes; it'll go down close to zero and up close to 5v repeatedly.

When its' reached the same position, stop counting and write the number down.

For a DD motor it's usually 23 (46); I can't remember how many magnets my smaller Fusin had. Some of the Cute and other similar sized motors have 20 magnets for the outrunner style, and 17 for the inrunner. Many geared hubs are 4:1 or 5:1 ratio.
So let's say you get a hundred pulses; it's likely you have 20 magnets and a 5:1 ratio. If you get 68, it's probably 17 and 4:1. Etc.

Click to expand...

I count 55/56 times it goes to 0, so 110/112 total changes.

110/5 = 22, 112/4 = 28.

Seeing as the P1 setting is the product of the number of magnets & the gear ratio, the individual numbers don't matter. Is the number I counted the same thing, and I just use that number directly? I can't get my head around how that works.

EDIT: after some more thinking I see exactly how this works. Imagineering 3D things I can't see or hold was never my strong point.

I didn't get the point of your post. Is the idea to get the DAPU motor running on the KT controller? Did you have it running when you blew out the capacitors?

I have read that P1 is used to make the speedometer reading accurate for a geared motor. The controller doesn't need to know the gearing ratio to spin the motor. It's using the hall sensors to synchronize the phases. For speed though, it would seem than that P1 gives it the gear info if there is no speed sensor.

My fatbike uses a Bafang G06 500W motor with a KT controller. The G06 has 20 magnets pairs and a gear ratio of 5:1. So P1 = 100. It works there, and I just ran it with P1 = 1. The speedometer read zero, as expected with the motor running. When I let the wheel coast, the LCD3 picks up the speed from a wheel sensor and I got a speedometer reading again.

I also have a Q100H motor and a different KT controller. That motor is a 12.6:1 ratio. Users have counted 16 magnets, so P1 =201 which I use. I also played around with P1, but got inconsistent results. It did run with P1 at 1 and at 100, but the displayed speed didn't change so maybe that LCD3 ran full time off my speed sensor.

Anyway, you may be pursuing the P1 number when it isn't important as far as getting the motor to run.

gutyex said:

The kit came with a C300 display (C300-1303-D601 36V). Given that these displays communicate via UART, is there some way I can hook it up to a PC and read the configuration from it to figure out the correct settings to use the motor with a KT controller?

Click to expand...

Unlikely. You'd have to get the original controller working well enough to communicate with the display and sniff it, and even then all you will likely see are the updates to speed, power etc - not any config settings.

But as others have said, the controller doesn't need much - primarily Halls (in the right sequence) and phase wires. Almost any controller will be able to support a motor with those signals available.

docw009 said:

I didn't get the point of your post. Is the idea to get the DAPU motor running on the KT controller? Did you have it running when you blew out the capacitors?

Click to expand...

Yes, and yes.
I'd also like to know more about the mystery controller as I can't find mention of it, or anything like it, anywhere. But that's just curiosity rather than actually trying to get things working.

docw009 said:

I have read that P1 is used to make the speedometer reading accurate for a geared motor. The controller doesn't need to know the gearing ratio to spin the motor. It's using the hall sensors to synchronize the phases. For speed though, it would seem than that P1 gives it the gear info if there is no speed sensor.

My fatbike uses a Bafang G06 500W motor with a KT controller. The G06 has 20 magnets pairs and a gear ratio of 5:1. So P1 = 100. It works there, and I just ran it with P1 = 1. The speedometer read zero, as expected with the motor running. When I let the wheel coast, the LCD3 picks up the speed from a wheel sensor and I got a speedometer reading again.

I also have a Q100H motor and a different KT controller. That motor is a 12.6:1 ratio. Users have counted 16 magnets, so P1 =201 which I use. I also played around with P1, but got inconsistent results. It did run with P1 at 1 and at 100, but the displayed speed didn't change so maybe that LCD3 ran full time off my speed sensor.

Anyway, you may be pursuing the P1 number when it isn't important as far as getting the motor to run.

Click to expand...

I also have a Q100H with a KT S06S and LCD3. I bought the S06S first when the connectors etc around the old controller broke, then bought the Q100H when I realised that I couldn't get the DAPU motor running properly with the S06S.

The P1 setting is definitely required to get the motor running properly, not just for speed info. The Q100H has a 4th internal hall sensor for this which gives 1 pulse per wheel rotation, to be connected to the controller's speed sensor input. If this (or an external speed sensor) is not connected, the controller then tries to derive the speed from the other sensors and the P1 setting.

The Q100H comes in 3 different gear ratios - 8.2, 12.6, & 14.2. I also have the 12.6 version, and have it running with P1 = 202 as 12.6*16 = 201.6 so should be rounded up.
Try lifting the wheel off the ground and turning the throttle up with different P1 settings. At 202 the motor runs full speed & relatively quiet. Other settings will reduce top speed & torque, and increase noise. Multiples / divisions of the correct value (or values close to them) seem to come close to working well, but are not perfect.

billvon said:

You'd have to get the original controller working well enough to communicate with the display and sniff it, and even then all you will likely see are the updates to speed, power etc - not any config settings.

Click to expand...

The old controller works fine still, but it's all disconnected and the C300 display has seen better days. The kit was replaced because the controller was integrated into the battery mount, and there were design issues with how the whole thing fitted together which meant I had to contantly repair bits of it.

With the KT controllers the config settings are communicated from the display to the controller (see https://endless-sphere.com/forums/viewtopic.php?t=73471 ) so I was hoping that the C300 might have something similar that I could read.

billvon said:

But as others have said, the controller doesn't need much - primarily Halls (in the right sequence) and phase wires. Almost any controller will be able to support a motor with those signals available.

Click to expand...

As I understand things from reading the discussion & documentation around https://opensourceebikefirmware.bitbucket.io/, other controllers can make do with just the phase wires & hall sensors because they are capable of FOC, however the processor in the KT controllers is not fast enough to do those calculations in real-time so requires a bit more information to run the motor effectively.

Many (most) common ebike controllers are not FOC; they just use the phases and halls to control the motor. (or just phases, no halls, running entirely sensorless). Some work better than others, and some work better with some motors than ohters, but mostly they just all work. Most of them are trapezoidal, some are sinewave.

Controllers that work more precisely with motors (i.e., "know" what the motor "is" and what kind of feedback to expect from it, so better able to feed it the right current at the right time to be more efficient and perform better) *do* need some motor parameters setup, and the closer they are the better they work.

Some of those controllers can "autotune" to the motor they're hooked up to...but they don't all do that, and those that do don't always do it well.

gutyex said:

other controllers can make do with just the phase wires & hall sensors because they are capable of FOC

Click to expand...

Most controllers are far simpler and do direct (i.e. combinatorial) control. When the Hall sensors say the motor is at angle 1, then output + + -, when at angle 2, output + - -, etc etc. No computation required.

Some do indeed do phase control / field oriented control, where it assumes intermediate phases based on timing of Hall signals - but most don't.

billvon said:

Some do indeed do phase control / field oriented control, where it assumes intermediate phases based on timing of Hall signals - but most don't.

Click to expand...

amberwolf said:

Many (most) common ebike controllers are not FOC; they just use the phases and halls to control the motor.

Click to expand...

In that case I have no explanation for why the KT controllers require the P1 value to run properly, but I know from experience that they do.

gutyex said:

In that case I have no explanation for why the KT controllers require the P1 value to run properly, but I know from experience that they do.

Click to expand...

A few possible reasons:

It uses the P1 signal to detect a stall, and when the motor stalls, it reduces/cuts power to prevent overheating.
It uses the P1 signal to deduce direction of spin, and switches it if the direction is incorrect.

billvon said:

A few possible reasons:

It uses the P1 signal to detect a stall, and when the motor stalls, it reduces/cuts power to prevent overheating.
It uses the P1 signal to deduce direction of spin, and switches it if the direction is incorrect.

Click to expand...

It's more than simply detecting problems, because as I've said previously if it's set wrong the motor will not run correctly even at no load. I can upload a video demonstrating this if anyone is interested.

gutyex said:

It's more than simply detecting problems, because as I've said previously if it's set wrong the motor will not run correctly even at no load. I can upload a video demonstrating this if anyone is interested.

Click to expand...

So what does it do? Run slowly? Just twitch at random? Do nothing?

This reminded me that one of my bikes uses an LCD3 and 20A KT sinewave controller with an unknown (ebikeling) motor. The LCD speedometer always went nuts when accelerating past 15 mph. Quit pedaling or roll off throttle, and the external speed sensor would give a stable speed on the LCD3.

I check this morning and P1 was set at 230. Probably from when I used this LCD with a Q100. Anyway, I rolled it down to 50, but it's too cold/icy to test ride. I did spin it no load at P1 =1 and it hummed away. Until then, I can't say whether the power or speedometer will be affected. I do have two of these motors though. The other one is run with a matched 810LED display and 22A controller, and both have shown the same top speed.

billvon said:

So what does it do? Run slowly? Just twitch at random? Do nothing?

Click to expand...

Per my previous comment:

gutyex said:

reduced efficiency, torque & top speed, and excess noise from the motor & heat from the controller.

Click to expand...

docw009 said:

This reminded me that one of my bikes uses an LCD3 and 20A KT sinewave controller with an unknown (ebikeling) motor. The LCD speedometer always went nuts when accelerating past 15 mph. Quit pedaling or roll off throttle, and the external speed sensor would give a stable speed on the LCD3.

I check this morning and P1 was set at 230. Probably from when I used this LCD with a Q100. Anyway, I rolled it down to 50, but it's too cold/icy to test ride. I did spin it no load at P1 =1 and it hummed away. Until then, I can't say whether the power or speedometer will be affected. I do have two of these motors though. The other one is run with a matched 810LED display and 22A controller, and both have shown the same top speed.

Click to expand...

Some incorrect P1 values there's not much difference at no load, but it's much more noticeable once you start actually riding. I did a test with my Q100H; the correct value is 202, top speed ~24mph. Values of 255 and 150 didn't make much difference with no load (though they're noticeably worse when riding), but a value of 75 is noisier and maxes out at ~16mph.

I also tried hooking up the mystery DAPU motor to my working bike - leaving the P1 value at 202 it made a horrible noise, but when I reduced it to 110 / 112 it seemed to run fine. Once I have a spare battery I'll be building it into a backup bike with the KT S06S controller that it blew the capacitors on. I've replaced them with fresh ones and flashed the OSEC firmware to play around with.