How a Smartmotion Mid City eBike works, with manual, schematic, circuit diagram, documentation

[whatsaheadwind]

I wrote this manual because I couldn't find any useful information on the internet that would help me diagnose a wierd problem I had on my Mid City, so I dismantled the bike, drew up a circuit diagram, and worked out how everything worked and communicated. This is the documentation of what I found.

MULTIPLE MPUs
The reason they call the PCB in the motor a controller, rather than "the computer", is because there are two microprocessor units (MPUs) in the eBike. The display is also a computer, and it does all the calculations for the odometer and speedometer, displays the PAS setting and error codes, stores the odometer record, and controls the display panel. It is in constant communication with the MPU in the controller, which is tasked with performing diagnostics on startup and with managing the motor thereafter. (If a problem develops during operation, it will cease powering the motor and communicate an error code to the display.)

BRAKE LEVER ASSEMBLIES AND SENSORS
The brake assemblies (and sensors) are made by Tektro. The sensor is a reed switch. It bounces when a magnet passes near it, which results in a pulse or two prior to the hard-on connection. That is normal for mechanical switches activated by magnets - don't be bothered by it. The MPU in the controller will disregard the signals from the bounces and knows to only pay attention to a prolonged signal.
The sensor has to be adjusted to be in the correct position, and there may be an allen-key lock screw to lock the retainer in the correct position after the correct position is found. See https://www.youtube.com/watch?v=7Gnq2Hin9mM for the procedure Tektro use to adjust the sensor location. Their SST (special service tool) is NOT essential equipment. Their tool merely feeds low voltage through the sensor and the LED on the tool detects when current flows/ doesn't flow as you adjust the position of the sensor relative to the magnet inside the brake lever. There is supposed to be a spring behind the sensor to hold the sensor hard against the nut retainer that holds the sensor into position. That spring is very important and must be present.
Adjust the position of the sensor in the brake handle housing by disconnecting the sensor from the 4 to 1 Y harness and connecting your multimeter to the pins of the sensor, with the multimeter set to test connectivity. Tighten or loosen the "nut" retaining the sensor in the housing (which adjusts the pressure on the spring and the position of the sensor in the housing) until you're happy with how much brake handle movement is required before the multimeter indicates that the reed switch has been activated. (If you don't have a multimeter, take a torch apart and wire the sensor in series between the torch battery and the torch light.) Alternatively, just take a 7mm open-ended spanner with you and go for a test ride. You don't need the SST.

CONNECTORS
The plugs/sockets carry the name ANERMA (as seen with 10x magnifier). They are HIGO waterproof connectors. https://www.ebay.com/itm/Higo-Waterproof-Connector-2-3-4-5-6-8-pin-cable-lead-1m-ebike-electric-bafang-/302851067039.
It is possible to purchase components that appear to be identical to what you need, but which have different HIGO connectors on the cable than what you need. Be very careful that the component that you order has the correct HIGO connector on it. The colour of the connector, number of pins, and male or female are all critical.

MOTOR AND DISPLAY
The motor and display in the MidCity are DAPU products. My display is the DAPU DPLCD-P, but the button pad shown in the picture on their website is different to mine. The MD250 is the only midmotor that DAPU currently have on their website. http://www.dapumotors.com/id-26.html?t=en-us Torque sensor and motor controller are integrated within the motor body. There have been multiple generations of DAPU midmotors, seemingly all named MD250, 250 being the power rating of the motor (250W). Apparently there is or has been available an exclusive and custom build 750W version of the motor as well, used only in the US. I suspect, from info I found on the internet, that the first generation MD250 had an external controller, but current versions of the MD250 have an internal controller.
Some web pages say that DAPU is Japanese. Dapu might have been Japanese once, but their webpage http://www.dapumotors.com/Guestbook/index.html?t=en-us gives a Chinese address. One webpage I found says that DAPU is a Chinese manufacturer under Japanese management. Most reviewers on the internet praise the DAPU products highly.
The Hall sensors inside the motor are apparently not available as a separate spare part. You're expected to buy a new motor, at $1000, if the Hall sensors fail. Perhaps it is possible to desolder the faulty Hall sensor and solder in a replacement. Given the difficulty of identifying and obtaining exactly the same Hall sensor, it's probably easier to replace them all with ones of satisfactory spec.

THE CONTROLLER
The controller for the Mid City is built into the LHS of the MD250 motor, and is easily replaced without having to remove the motor. You'll need a set of bits for a screwdriver that includes one that suits the screws that hold the motor cover on, a 1/2" drive hex head to remove the pedal crank, and a gear puller to remove the pedal crank from the motor. Drop a short bolt into the threaded hole before you fit the gear puller - you don't want to damage the thread. Make sure the bolt is a fall-in drop-out fit in the hole, and that the head of the bolt is just the right size to cover the pedal shaft but not the pedal crank. If you do damage the thread with the gear puller, you'll need a mid-tap to retap the thread. You can get one at any good trade tool supplier. Take the retainer bolt with you as a sample of the thread.
All the devices tested by the diagnostics are connected to the controller, therefore it makes sense to run the diagnostics on the controller MPU, not on the display MPU. This is hard to prove, but if you get an error code which you know is a furphy (ie, bogus), then I'd replace the controller, not the display.
Coming from the front harness (as a single multicore) is 8 wires going straight into the controller.
Coming from the motor into the controller are 4 leads:
⦁ thick green
⦁ thick yellow
⦁ thick blue
⦁ a 4-core of blue, green, yellow, red, that comes from the hall sensors. There are usually three hall sensors in a brushless DC motor, so this would be common (VCC) plus three data.
The three heavy leads are required because the motor is brushless. Brushless motors require hall sensors to run, so the 4 core will be from the hall sensors. https://www.allaboutcircuits.com/industry-articles/3-phase-brushless-dc-motor-control-with-hall-sensors/ explains how brushless motors work.
Coming from the pedal axle housing into the controller are 2 leads:
⦁ not connected, capped, 3-core
⦁ 5-core (black, yellow, red, green, blue) going to the controller. This will be from the hall sensors that detects pedal movement. Perhaps 4 hall sensors plus VCC common? Or 3 hall sensors plus VCC plus GND? I think 4 hall sensors are more likely, because the bike is very sensitive to pedal movement.
Coming into the controller from the frame beneath the motor is:
⦁ 1 x heavy red lead providing +ve power source to the controller and motor at full battery voltage, directly from the battery
⦁ 1 x heavy black lead directly from the battery, providing GND.
⦁ 1 x 2-core from the Hall sensor on the frame adjacent to the rear wheel. As the magnet on the spoke passes the Hall sensor, a pulse is sent to the controller, which passes it on to the display MPU.
⦁ 1 x 3-core from the PCB in the front of the battery housing. This is VCC (red), GND (black), and DATA (white) providing on or off instruction to the PCB that controls the lights.
⦁ 1 x 3-core from the gear sensor (labelled gearsensor.com) beneath the motor, accessible by removing the plastic dirt cover under the motor on the frame.

CONFIGURING THE CONTROLLER
It is possible that Smartmotion have a customised version of the controller, with firmware written to their specifications, but far more likely is that they are using the standard DAPU firmware, but have configured the configurable parameters of the firmware to suit their particular specifications, in much the same way that different wheelchair manufacturers configure the parameters of the joystick controller on their wheelchairs to suit their particular requirements using software purchased from the manufacturer of the joystick. I wish I could get my hands on a copy of the software used to configure the (DAPU) controller of the Smartmotion - there's one setting that really irks me.
If one did get one's hands on the configuration software for a DAPU controller, then the means of connecting it to the Smartmotion is to unplug the Display cable from the 4 to 1 Y cable, and connect a special USB cable in place of the 4 to 1 Y cable, then plug the USB connector into a laptop and run the software. The DAPU display is a MPU itself, that communicates to the controller via 3 wire bidirectional serial comms. There are 5 wires in the multicore from the Display; one is VCC+, one is GND, and the other three are for bidirectional serial comms. Most likely SCLK (serial clock), SDIO (serial data in/ out, ie, bidirectional on one wire), and SS_n (slave select, because the chips used are designed to handle multiple slaves (Display) from one master (Controller). I haven't bothered working out which wires are VCC & GND, but that would be easy to do. I also haven't bothered measuring what VCC is, but again that would be easy to do. Probably the easiest way to identify which wire is which in the serial comms is to open up the Display and trace the connectors back to the serial IO chip, and check the pinouts of that chip on manufacturer's specifications. There are cables on the market that have been designed to perform this task for a BAFANG controller, but I have absolutely no idea whether the pinouts on a BAFANG are identical to those on a DAPU. And anyway, the cable is useless unless you also have the software.

PCB IN THE FRONT OF THE BATTERY HOUSING
There is a PCB in the front of the battery housing, underneath the plastic cover. It's accessible by removing a few phillips screws. It is located there purely for convenience; it doesn't connect directly to the batery. It's function is solely to control the lights front and rear.
The PCB controlling the lights is necessary in order to deliver constant correct voltage to the lights. It also simplifies the job of the MPUs by contracting out the task of controlling the lights to a separate device, thus reducing the componentry required in the controller to control the lights and thus allowing a physically smaller controller. It may have a MPU onboard, but that is unlikely - there is no need for one to perform the tasks this PCB does.
Leading to the PCB in the front of the battery housing is:
⦁ 1 x 3 core (red, black, white) leading into the frame of the bike. This lead goes to the controller, so clearly the controller receives instruction from the display to turn on the lights and passes on the instruction to this PCB. Red and black will be power to the PCB and the lights, and white carries the data signal to the PCB to instruct it whether to turn the lights on or off.
⦁ 1 x 2 core (red, black) leading into the frame of the bike and going directly to the headlight. This lead passes over the top of the motor and is seen only by pulling out the motor.
⦁ 1 x 2 core (red, black) leading to the lights at the rear of the bike.

MAIN MULTICORE HARNESS LEADING TO CONTROLLER
The main harness coming down from the handlebars is 8 core. The main harness from the controller connects to a 4 input 1 output Y harness up near the handlebars, and is about 400mm long with no connectors between the controller and the connector outside the frame where it connects to the 4 to 1 Y cable. Those four multicore inputs to the main harness are:
⦁ 1 x 3 core from the throttle. +VCC, gnd, linear data. The throttle is a Hall sensor. The distance between the magnet and the Hall sensor is dependent upon how wide open the throttle is. Wear and tear on the throttle can affect the movement path of the magnet and thus affect the operation of the hall sensor.
⦁ 2 x 2 core from the brakes. +VCC, binary data (ie, connected or not connected).
⦁ 1 x 5 core from the Display. There'll be +VCC, GND, and three others handling bidirectional serial comms between the display MPU and the controller MPU.
This matches the 8 core harness if we assume VCC to all devices. Display has 5 wires; throttle uses VCC and GND that is also supplied to the Display, so throttle adds only 1 wire, to make 6. If the 2 x brakes are wired as OR devices, which is feasible but unlikely, then only 7 of the 8 wires in the 8 core are used. (Application of the brakes creates a connection in the reed relay in the brake sensor, so the two brake sensors could be wired in parallel, thus providing an OR logic connection for the brakes to the controller, but I'm pretty sure that the OR logic connection is done digitally at the controller and that the 2 x brakes connect separately to the controller. So we have 5 wires for the display, 1 more for the throttle, and two more for the brakes, making 8 total, which is the number of pins at the connector for the main harness.

THE DISPLAY
Display has data in (from the controller) and data out (to the controller). The following list may not be complete.
DATA OUT:
⦁ PAS setting
⦁ Operation mode (normal/ torque)
⦁ Control of the lights
⦁ Perhaps some things in settings - I didn't bother checking the manual to find out.
DATA IN:
⦁ Pulse from the Hall sensor on the rear wheel, used for odometer and speedometer
⦁ Inputs from switches go direct to the display by a separate cable - there are two cables at the display: the in cable from the switches, and the cable leading to the harness that leads to the controller
⦁ Error codes. All the inputs needed for diagnostics are connected to the controller, not the display, so it makes sense to run the diagnostics on the controller and report the results to the display MPU.
The display almost certainly calculates battery voltage from it's own VCC+ve and GND, independent of the controller's assessment of voltage, and thus the display is quite capable of displaying the correct battery voltage whilst simultaneously displaying an error code 9 (high voltage), not knowing that it is displaying inconsistent data.
Processing of odometer and speed info is all done in the display MPU (microprocessor unit) from one single input: the pulses generated by the Hall sensor on the rear wheel. The distance travelled is stored in the memory of the display, not in the memory of the controller, because you can replace the controller without affecting the stored memory of distance travelled.

COMMUNICATIONS BETWEEN THE DISPLAY MPU AND THE CONTROLLER MPU
Communications between the display and the controller has to be serial and bidirectional; there aren't enough wires coming out of the display for comms to be anything else. There are five wires to the display.
⦁ VCC
⦁ Gnd
⦁ SDIO (Serial Data In Out)
⦁ SCLK (Serial clock)
⦁ SS_n (Slave Select)
The three wires unaccounted for by VCC and GND have to be bidirectional serial comms - there aren't enough wires to be anything else. Most likely they are SCLK (serial clock), SDIO (serial data in/ out, ie, bidirectional on one wire), and SS_n (slave select). The Slave Select line is probably used for handshaking. In the case of the ebike, there is only one slave: the display, but the chips used are capable of communicating between master and multiple slaves. It's half-duplex synchronous communications, bidirectional over the SDIO line. Typically it's a fixed length packet, so that each end knows if they get the full message. Web page https://www.digikey.com/eewiki/pages/viewpage.action?pageId=27754638 proves 3 wire bidirectional comms components exist; whether this is precisely how the job is done on the Smartmotion is unknown, but it has to be 3 wire bidirectional comms between the display and the controller on the DAPU system because there aren't enough wires for it to be anything else.

 

[amberwolf]

Thank you for posting this information--we get DAPU users here now and then that could use this info.

Regarding this:

⦁ a 4-core of blue, green, yellow, red, that comes from the hall sensors. There are usually three hall sensors in a brushless DC motor, so this would be common (VCC) plus three data.

it requires 5v and ground for each sensor, plus three signals, for the common 3phase BLDC, total of 5 wires minimum. If there's no ground wire (or no power wire), the halls can't work.

If there are only 4 wires, it cannot be this type of sensor arrangement. A sin/cos sensor would only need four, it's a different kind of hall-based encoder using analog signals 90 degrees out of phase with each other, so easy to see which type it is even with a voltmeter.

Alternately, it could just be a speed sensor that's detecting hubmotor shell RPM (vs motor RPM); this is common on geared hubmotors in OEM systems, since you can't use the hall sensors of the motor itself to detect wheel speed due to the freewheel (if motor isn't running at least as fast as the wheel, it doesn't match the wheel speed). These only need three wires, but if it also has a motor temperature sensor could have four.

Coming from the pedal axle housing into the controller are 2 leads:
⦁ not connected, capped, 3-core

Probably a simple cadence sensor. Often hall based digital signal, of varying types. But could be something else.

⦁ 5-core (black, yellow, red, green, blue) going to the controller. This will be from the hall sensors that detects pedal movement. Perhaps 4 hall sensors plus VCC common? Or 3 hall sensors plus VCC plus GND? I think 4 hall sensors are more likely, because the bike is very sensitive to pedal movement.

This is probably a torque sensor. Most of these require power, anything from 5v to main battery level depending on type, and a ground, and then may have a cadence sensor output (digital), and at least one analog voltage output, or a digital serial or other encoding output, to provide torque data.



This might not apply to your system, but there is one DAPU connection diagram here:
https://endless-sphere.com/forums/viewtopic.php?f=2&t=89930

 

[whatsaheadwind]

Corrections to my original text:

Contrary to what I initially wrote, there IS a connector in the 8-core going from the controller up inside the front frame to the 4-to-1 Y harness up near the handlebars. The 8-core lead from the controller is only a few inches long, and connects to a plain 8-core extension cable inside the frame. The hidden connector is only a short way up the frame from the motor. This hidden connector means that replacing the controller DOES require removal of the motor after all, because there is no room to pull the cable (with hidden connector) down the frame past the motor.

Removal of the motor is also required in order to access and disconnect the connectors above the motor in the leads leading up the frame towards the battery.

So I was incorrect when I said you didn't have to remove the motor in order to replace the controller.

My apologies for the errors, and my thanks to amberwolf for his valuable contribution to the topic.

In case anyone is wondering what the wierd problem is that I am trying to track down and fix, it is this: I am getting error codes which I don't entirely trust. First I got an error code telling me that the throttle was faulty, so I replaced the throttle. At first test after replacing the throttle, I got an error 6 error code telling me that the motor hall sensors were faulty. I was still thinking about that one when the error code changed to error 9: overvoltage error, which was absolute nonsense because my multimeter agreed with the voltage displayed on the display, I was using the same battery I had always used, and the voltage was well within limits. Knowing that the error code was nonsense, I suspected the controller and replaced the controller. First test on the new controller gave me an error 6 code again: motor hall sensors faulty. Smartmotion can't supply just the motor hall sensor PCB and want $1000 for a new motor. I suspect the fault is actually a broken wire coming from the motor hall sensors, where it bends backwards over the controller, or perhaps a bad solder joint somewhere. I'm still thinking about that one.

 

[whatsaheadwind]

Further corrections to my original text.

In my original text I incorrectly stated that the lead to the hall sensors in the motor and the lead to the hall sensors in the pedal axle were 4-core. This was incorrect. Upon putting my glasses on and taking another look at them both, I discovered that they were actually 5-core, as amberwolf correctly expected them to be.

I opened up the motor today in the hope of finding a PCB supporting the Hall sensors, so that I could conduct further testing and try to get to the bottom of this Motor Hall Sensor error 6, but I couldn't get to the Hall sensors. They're buried deep down in the metal casting. Blue, yellow, and green are Hall sensor data. Red and black, as one would expect, are common to all three Hall sensors. We can thus reasonably assume that red is VCC+ve and black is GND. The three Hall sensors are quite close together. On the left hand side of the photo (attached) are three groups of three thin white insulations. Those are the leads going down into the casting to the Hall sensors. You can see the red leads tied together. The black leads are beneath the red leads. The black insulation at the bottom of the photo is where the input red lead connects to the three Hall sensor red leads, and likewise for the black leads in the other black insulation. I didn't give much for my chances of opening up those two bits of black insulation, doing the tests I wanted to do, then put everything back in a satisfactory and secure manner when I had finished, so I left it as it was. By the way, there is sealant under the cap covering the motor, to keep moisture out. I didn't bother replacing it, but if the motor was going to go back into service, it should really be replaced.

Attached is a photo of the motor and controller with the covers removed from both.

Upon reassembly of the motor and retesting (just in case by sheer fluke the problem was a bad connection and the work I did today reconnected the bad connection), I immediately got an Error 9 (over voltage error), replaced almost immediately by an Error 6 (Motor Hall sensor error). So there was nothing wrong with the controller I replaced; the replacement controller is reporting the same errors as did the old controller.

Clearly the only solution now is to replace the motor, but at $1000 for a motor, and $1000 for the spare battery that I want to get, that's $2000 on this one when I can buy a new one with two year warranty for $3000 and have heaps of spare parts for it, including a battery.

I'm buying a new eBike, same brand and model as this one: Smartmotion Mid City. They're a fantastic bike - though I do wish the centre of gravity was lower. The problems I have had with this one have all been a consequence of my being stupid enough to allow a dealer who didn't know dick about the products he sells try and fix a problem I had a few months ago, which I realise now was caused by a spring left out of the brake handle assembly during manufacture of the bike.

 

[amberwolf]

I opened up the motor today in the hope of finding a PCB supporting the Hall sensors, so that I could conduct further testing and try to get to the bottom of this Motor Hall Sensor error 6, but I couldn't get to the Hall sensors. They're buried deep down in the metal casting.

Uusally theyre not in a casting, but rather in the stator laminations, and not very far in. Often they are not even glued, simply inserted in. If you can't get to them because of the windings, and you need to, access them, you can remove the rotor, with the circlip on the shaft.

I didn't give much for my chances of opening up those two bits of black insulation, doing the tests I wanted to do,

What test did you want to do?

If you just want to test the sensors, voltage to them, etc., then if you use straght pins, needles, safety pins, etc., very pointy and thin, you can poke thru wire nsulation into the conductors, at the closest point to the testing needed.

 

[whatsaheadwind]

UPDATE - AND SOME NEW SPECIFICATIONS INFORMATION

Covid 19 has delayed import of stock of the Smartmotion eBikes, with the result that all the dealers everywhere are out of stock. I've placed my order for a new one, but have to wait weeks for it, so, with nothing to lose, I decided to strip down the motor and replace the Hall sensors on the bike I have now. If that fixes the bike, I've got a spare eBike, which will be very useful. If it doesn't fix it, then all it's cost me is a bit of time and $40 worth of Hall sensors, and I've got heaps of spare parts for my new eBike. Better than taking the gamble that a $1000 on a new motor will fix the problem.

The socket for the lead going to the motor Hall Sensors (from the controller) has five pins. Looking at the socket, with the cable behind it and leading away from you, and going clockwise from the alignment gap, the connectors are: Black (GND); Yellow (data); Green (data); Blue (data), Red (VCC).

Connectivity can be tested using your multimeter (set to measure ohms) with a fine sewing needle poked into the socket hole at one end, and touching the pin at the Hall sensor at the other end. It is unlikely that you are unable to access at least a tiny bit of each pin on each Hall sensor, but if you can't, you can poke a sewing needle (sewing needles are pointier than pins) into the insulation or the heatshrink.

I made the mistake of tesing only connectivity of the lead, and didn't test close enough to the Hall sensor when I tested each wire for connectivity, with the result that I didn't find the broken connection inside the heatshrink at one of the data pins until AFTER I had concluded that conductivity was ok and that the fault must be one of the Hall sensors, by which time I had (unintentionally) broken most of the pins off the Hall sensors. I was cleaning up the ends of the wires ready for resoldering when I found the broken connection inside one of the heatshrinks. I wish I had found it first up; I could have repaired it and that would have saved having to replace the Hall sensors. Once I found that broken connection inside the heat shrink, I assumed that that was the cause of my Error 6 and Error 9 errors, and continued on with the job of fitting new Hall sensors in expectation of success.
I was unnecessarily concerned about the strings. They turned out to be easy. Just irritate the knot with a small screwdriver and the knot comes undone. The manufacturer did two turns of string around the windings, but one turn would be sufficient, so keep the strings that you remove and when we put them back, we'll put them back as a single turn, not a double, thus giving ourselves sufficient length to tie a knot in the string without problems.

The Hall sensors sit flush with the top of the casting, and are pushed down into their recess until they bottom out. It is not possible to push them in too far, and so long as they are sitting flush with the top of the casting, they are pushed in far enough.
Looking at the shaft of the motor with the Hall sensors between the shaft of the motor and my body, the connections to the Hall sensors are red, black, data. When going anticlockwise around the motor, the data wires are green, blue, yellow.

WHAT I SHOULD HAVE DONE AT THIS POINT WAS TO TEST THE HALL SENSORS IN SITU, CONNECTED TO THE EBIKE BATTERY, BEFORE I TRIED TO REMOVE THE HALL SENSORS. Measuring the voltages at the pins on each Hall sensor would have given me the VCC and the quiescent voltage at the data pin, which would have helped in choosing a replacement Hall sensor. Had I tested by inserting a fine needle through the insulation or the heatshrink, rather than at the pins of the Hall sensors, I might even have detected the broken wire inside the heatshrink.

Anyway, what's done is done.

The Hall sensors are retained in position by two tiny spots of glue attaching them to the fibreglass behind them. The label for the Hall sensor faces in towards the centre shaft, so I discovered once I finally got one out.

My first effort was to use a small, strong, pointy screwdriver to lever the Hall sensor upwards out of it's slot. That worked fine, except that I destroyed the label on the Hall sensor by so doing, and I was hoping to use the label to get the specs of the Hall sensor that the manufacturer had used, so that I could order matching Hall sensors to replace it.
The second Hall sensor I tried to remove by pulling on the pins, so that I wouldn't damage the label, but that didn't work very well either - the pins broke off.

So I tried removing the Circlip on the centreshaft, in the hope of lifting out the armature (do they call it an armature in a brushless motor?) so that I could get in under the Hall sensor and lever it out from below. But the armature is a press fit on the shaft, and removing the circlip got me nowhere, so I put it back.

I tried removing the four Phillips head screws in the hope of lifting out the windings, to make access to the Hall sensor easy, but that didn't achieve anything either, so I put them back.

I inspected the other side of the motor, but nothing there suggested that there was any merit in opening up the gearbox in order to get access to the Hall sensors in the motor.

So with no other option open to me, I removed the last two Hall sensors in the same way I removed the first: with a fine, strong, pointy screwdriver. And destroyed the label on both of those sensors too, with the result that I have no idea of the specs of the correct Hall sensors for the DAPU motor.

I measured the original Hall sensors at 4.3mm wide, 1.6 mm deep.

My local electronics store is Jaycar. They sell only one Hall sensor of these measurements: UGN3503UA. I decided to take the punt on it being compatible with the ones I had removed. Specs of the UGN3503UA are available at https://www.digchip.com/datasheets/parts/datasheet/029/UGN3503UA-pdf.php. There was nothing in the specs that struck me as likely being incompatible with a motor in an eBike. It seemed a reasonable gamble, so I bought five (in expectation of inadvertently destroying some during installation). Jaycar carried them in stock. Price is less than $8 each.

Once I had three new Hall sensors soldered in, I connected the motor up to a controller, connected the controller up to the bike, connected the battery, and turned it on at the battery and at the display.

Nothing was changed. I still got Error 6/ Error 9 errors. Replacing the Hall sensors had not affected the problem I was trying to fix.

So where to next?
⦁ Next step, I think, is to test the new Hall sensors in situ against specs, to see if they survived my soldering efforts, by checking voltages at the pins of the newly installed Hall sensors, with everything all connected and eBike battery powering everything. Maybe I damaged one of the Hall sensors when I was installing it. If you wanted to, you could perhaps test your Hall sensors disconnected from the eBike, by getting +5V from a USB emergency battery. That isn't quite the correct voltage for the sensors, but it might allow you to test them through the lead, if you can't test them at the pins. Specs of the Hall sensors I bought from Jaycar give a VCC range of 4.5V to 6V, with output resistance 50ohm typical, 220 ohm max., and inactive voltage of 2.5V nominal, 2.25 to 2.75V acceptable.
⦁ If the new Hall sensors do NOT test ok, then I simply replace the ones that don't test as ok, and try again.
⦁ If the new Hall sensors DO test ok, then
⦁ perhaps they are simply too different in spec from the originals to work with the DAPU controller? In which case, I ... Don't know the answer to that one. Have to think about that one.
⦁ or perhaps the controller I used for testing is faulty, and maybe I should retest using a known-good controller. (I do have one I can use, because I initially thought the Error 9 code must indicate a faulty controller, and I bought a replacement controller, but the replacement made no difference.

So how does the controller decide if the Hall sensors in the motor are faulty or not? Now that I have read Hall sensor specs and looked up what "quiescent voltage" is, I think the controller simply checks the voltage at each data pin during it's preboot diagnostics and reports an Error 6 to the DISPLAY if the quiescent voltage of any of the Hall sensors is outside spec. WHICH MEANS THAT THIS SHOULD HAVE BEEN THE FIRST TEST I DID RIGHT BACK AT THE BEGINNING! The controller doesn't report which Hall sensor data lead voltage is outside spec, but a voltmeter would have done so, and would have told me which Hall sensor differed from the other two and thus which Hall sensor had the problem!

One reason I didn't go very far down the path of testing the Hall sensors up front is because I mistakenly thought it would probably be necessary to spin the motor in order to test the Hall sensors, but that is NOT the case. It's probably a helpful step in testing, but not a mandatory step. I should have realised it was possible to get meaningful test results without spinning the motor, because the motor isn't spinning when the controller tests the Hall sensors during pre-boot diagnostics.

The attached photos show various stages of the job. The Parfix is what I purchased to retain the replacement Hall sensors in place. The new ones are a little loose in their slot, so I was going to put a tiny dab of silicon on top of them to retain them in position during service. I figured that if I used silicon, I could remove it and replace the Hall sensors again at a later date if I ever needed to. The silicon will also be used to seal the cables at the entry point to the motor, and to seal the lid of the motor against moisture - if I succeed in repairing the motor.

So I still haven't solved the Error 6/ Error 9 problem. (Error 6 is motor Hall sensor; Error 9 is overvoltage, which is an erroneous error message resulting from bad programming of the controller.) But I do have a next step in mind, and I'll report the results of testing of the Hall sensors when I get around to doing it.

 

[whatsaheadwind]

I mention Parfix in my previous post. Here is a photo of the Parfix. It's a non corrosive silicon I bought from Bunnings Hardware store. I intended to use it to seal the wires coming into the motor, seal the cap on the motor (both of these tasks had been performed by the manufacturer using what appeared to me to be a silicon product) and I was going to use a tiny dab of it to retain the Hall sensors in place as well.

 

[whatsaheadwind]

One option for extracting the original Hall sensors without damaging the label that I forgot to mention in my earlier posts does exist. My very first attempt to extract a Hall sensor was to attempt to extract the fibreglass behind it, on the assumption that the Hall sensor was attached to it and retained in position by it - which later proved to be a correct assumption, because the Hall sensor is glued to it by two tiny dots of glue.
My initial attempts to loosen and extract one of the pieces of fibreglass behind a Hall sensor were unsuccessful. You can see in one of the photos that the fibreglass at one of the Hall sensor slots is whiter than the rest, showing the damage I did in attempting to extract it.
Unfortunately I only tried one of the pieces of fibreglass. Had I tried all three, I would have discovered that the technique would have been successful on one of the Hall sensors. The third Hall sensor I extracted (after I had damaged the label, unfortunately) came out WITH it's fibreglass backing, and I had to reinsert the fibreglass backing into the casting.

 

[whatsaheadwind]

This morning I had a go at testing the Hall sensors I had installed, using the eBike as a power source. Seemed like a good idea at the time. The first measurement I sought was VCC, and I got an enormous surprise! VCC was 0.76 V. How could that be? I checked my sewing needles, made sure they were contacting the lead inside the heat shrink ok, and tried again. 0.76 V again! How could that be? I'd tested continuity of the lead from the Hall sensors to the plug where it connected to the controller and that was fine. I'd tried two different controllers prior to replacing the Hall sensors, so if the ridiculously low VCC was caused by a faulty controller, the problem should have gone away on the replacement controller, but it didn't. The 0.76 V had me stumped for a minute, then I realised it was a clever energy-saving strategy of the controller. There was no need for battery energy to be used to power the Hall sensors anytime other than when energy was required to power the windings in the motor, so the controller only delivered power to the Hall sensors when power output was required from the motor!

This means that the idea that I put up in an earlier post of testing VCC prior to extracting the Hall sensors, in order to help identify compatible Hall sensors, is not viable. At the moment I don't see any way to measure VCC on a bike that the controller has disabled because of error codes.

So much for testing the Hall sensors I had installed using the eBike as a power source. I'll have to knock up a +5V or thereabouts power supply and test the Hall sensors I installed with them disconnected from the controller.

Incidentally, I think in an earlier post I suggested the possibility of testing the voltage at the pins of the Hall sensors. When I actually came to do that today, I opted for poking needles through the heatshrink rather than seeking bare metal on the pins at the Hall Sensors, because the pins of the Hall sensors are only 1mm or so away from the aluminium casting, and short circuits would have been a serious risk.

One surprise to pass on in this post. The eBike had all wires connected when I turned on the battery and the power switch at the display, but I hadn't yet turned on the worklight. To my surprise, I discovered that there is a red LED buried inside the controller which delivers error codes in a repeating sequence of the same pattern, one pattern per error code. The display was displaying Error 9 (over voltage), but there were not 9 flashes in the sequence, so the LED codes don't correspond directly to the number of the error code displayed on the display.

One other thing I discovered somewhere along the line and haven't yet addressed. If the battery is left turned on and the eBike is off at the Display, the battery is still delivering +5V to the controller, so something needs power at all times. I suspect that it may be used solely to power memory chips in the Display, to retain the value of kilometres/ miles travelled. The total distance travelled since new is stored in memory in the Display that does not need an ongoing power source, but perhaps the working memory is where the other odometer readings are stored, and perhaps they need ongoing power.

An alternative possibility is that nothing uses that +5V at all, and it is merely a consequence of the circuitry inside the battery producing +5V to power the USB port on the back of the battery, but it would seem odd that t+5V, while the battery is turned off, would be delivered to pins that deliver +42.5V or thereabouts when the battery is turned on. No, I think there must be something in the eBike that requries +5V at all times, and memory is the obvious possibility that jumps to mind.

 

[amberwolf]

The 0.76 V had me stumped for a minute, then I realised it was a clever energy-saving strategy of the controller. There was no need for battery energy to be used to power the Hall sensors anytime other than when energy was required to power the windings in the motor, so the controller only delivered power to the Hall sensors when power output was required from the motor!

FWIW, I've never seen any system do this before, as the halls take such a tiny amount of power it's just about irrelevant. A steady/blinking status LED somewhere on the bike would take more. Did you verify that it does actually power them up when it tries to power the motor?

So much for testing the Hall sensors I had installed using the eBike as a power source. I'll have to knock up a +5V or thereabouts power supply and test the Hall sensors I installed with them disconnected from the controller.

If you disconnect them from the controller, you'll also need to provide a pullup resistor (5kohm-10kohm) from each signal line to the 5v source, as the sensors used in motors are open-collector and simply ground the signal line when they are active.

but it would seem odd that t+5V, while the battery is turned off, would be delivered to pins that deliver +42.5V or thereabouts when the battery is turned on.

If the 5v is on battery-voltage lines, then it simply means the BMS doesn't completely turn off it's output FETs when it is turned off by the bike, so there is some leakage voltage present on them. That is typical, though there's usually enough of a load on most systems to show essentially 0V rather than the 5v you see. For instance, you may only see the 5v when the battery is not connected to the bike but is "off", but see 0V when actually on the bike and off.

 

[whatsaheadwind]

This was drafted prior to seeing Amberwolf's contribution, which certainly includes food for thought, especially in regard to the 0.76V Vcc upon testing. Although I do wonder now if perhaps once the controller decides that there is a problem with the motor Hall sensors, it shuts down power to them. Anyway, I'll have to deliberate over that point Amberwolf made some more. Given the results of testing that I'm reporting in this post, that 0.76V might be the path to solving this problem.

I didn't ignore Amberwolf's advice about how to test the Hall sensors when disconnected from the controller; I didn't read his advice in that regard until AFTER I had tested them without doing what he advised doing, and after I had drafted this post. I must admit, though, that I lack the knowledge he obviously has about open collector and the need for a pull up resistor. That lack of knowledge prevented me understanding why I needed a pull up resistor. I didn't use a pull up resistor in testing, and the test results suggest that everything went ok without one. I would welcome Amberwolf's thoughts on that.

Anyway, now I'll report the outcome of this afternoon's work.

Upon thinking some more about how the controller decides if the motor Hall sensors are faulty or not, I realised that simply measuring the voltage at the data pin of each one wouldn't really tell it a lot unless the voltage was zero, which would definitely indicate a fault. So I no longer think that the controller makes it's decision on whether or not the Hall sensors are ok purely on the basis of whether each one returns a positive voltage greater than zero and less than Vcc. I now think that it probably applies a formula to the values it measures on the data pins and makes it's decision on the basis of the results of applying that equation to the three voltages as inputs to that equation. Perhaps the total of the three voltages has to fall within a tight range? Or perhaps the average of the three voltages has to closely approximate half of Vcc?

The relative location and strength of the magnets, and the characteristics of the particular Hall sensors that the manufacturer used, would result in a predictable relationship between the voltages on the three data pins of the Hall sensors, so it would be possible to check whether everything was rosy if that additional knowledge was incorporated into the equation. Could an equation that takes the three voltages on the data pins as inputs detect substitution of the Hall sensors with different ones than originally installed? Perhaps. If the equation expects the average of the three data voltages to be very close to half of Vcc, for example, might installing Hall sensors more sensitive than the originals produce an average of the three voltages that was greater than 2.5 V and outside the range which the firmware in the controller considers acceptable?

Could the equation take more than just those three voltages as inputs to the equation? Could it take the Output Resistance into account as well, perhaps? Or the current drain while testing the Hall sensors? I think that unlikely. I think an equation that used just the three voltages as inputs and checked that those three voltages were close to what one would theoretically expect given the location of the Hall sensors on the circumference of the casting and the location and strength of the magnets around the circumference of the core would be sufficient to make a decision on whether or not the hall sensors were ok or not.
Anyway, enough of theory for the moment and back to test results.

According to the specs of the Hall sensors I installed, I needed a Vcc of between 4.5V and 6V to test them. Three ordinary alkaline batteries would be at the very low end of that range, but three lituium batteries would be around the middle of the range, so I grabbed an old torch that takes three AAA batteries and adapted the battery carrier to take crocodile clip leads, and put three AAA lithiums in it. Photo attached.

I disconnected the motor Hall sensors lead from the controller and applied VCC from the lithiums, with the Hall sensors in their slots. Using fine sewing needles poked into the heatshrink, results were: yellow: 4.32V; blue: 0.853V; green: 2.85V. Retesting produced figures approximating the results of the first test. Lifting the Hall sensors out of their slots (and thus well away from the magnets in the core) produced the following results: yellow: 2.47V; blue 2.48V; green 2.57V. All very close to the specified quiescent voltage of 2.5V. There was no reason to suspect that I had damaged any of the Hall sensors during installation. Good, but in that case, why was I still getting error codes? Was the lead to the controller faulty? I did test it for continuity before I replaced the Hall sensors and it tested ok then. I decided to test it again.

Taking the voltages at the socket on the end of the lead this time, with the Hall sensors well away from the magnets, results were (gong anticlockwise around the socket, starting at the notch): Vcc (red) 4.7V; 2.4V, 2.57V, 2.42V, and Gnd (black). All good. Nothing wrong with the lead.

Seemingly nothing wrong with the Hall sensors that I had installed, and nothing wrong with the lead. The Hall sensors I had installed are producing results which seem reasonable for a controller to use to control the motor, so the Hall sensors I had installed appeared to be acceptable substitutes for the originals.

So why am I still getting error codes? Why is the ebike still not operational? Is the different sensitivity of the installed Hall sensors resulting in a different result from the equation that is being applied by the controller to the data pin voltages to test if the Hall sensors are ok; a result that is outside what the controller considers to be the acceptable range?

Or was the motor never the problem, the motor now just as satisfactory as it always was, and the real cause of the Error 6 (motor Hall sensors) and Error 9 (over voltage) still eluding me?

Given what Amberwolf said about the 0.76V Vcc when connected to the bike, I think the next step might be to explore further why Vcc is only 0.76V, instead of the approximately 5V that I expected.

I welcome all suggestions. This problem is proving tougher to get to the bottom of than I anticipated.

 

[amberwolf]

I didn't use a pull up resistor in testing, and the test results suggest that everything went ok without one.

If you get 0v and 5v toggling, then the motor could have internal pullups, if the halls wire to a PCB with them on there, but that's rare, becuase of the reason for pullups being inside the controller (see further down in the post).

If the halls you used aren't open-collector types, then they just output a signal, based on their design. Most of those (of the types used in motors) toggle the signal between ground and supply voltage; whether "active" is ground or supply depends on design. Other types (like in throttles) output a continously varying voltage based on the field strenght and polarity relative to the hall sensor position and orientation. But those aren't typically used in motors with 3 sensors in the laminations/windings.


But since you got something else besides 0v and 5v toggling, and instead a changing signal voltage as a magnet passed, with a mid-range voltage when no magnet is present, then you have the wrong kind of hall sensors in there. For a 3-sensor unit, the only operation method I've ever seen is just on and off pulses. For other types, like a SIN/COS encoder, and others like that, you do see a constnatly changing voltage, using a different kind of hall sensor kinda like that in a throttle, but they also dont' use the motor's magnets, they use their own magnet ring.

I would recommend trying Honewell SS411A sensors instead, and see what happens. SS41 works too, as do several other kinds.

Upon thinking some more about how the controller decides if the motor Hall sensors are faulty or not, I realised that simply measuring the voltage at the data pin of each one wouldn't really tell it a lot unless the voltage was zero, which would definitely indicate a fault.

Actually, it would be more likely to decide a hall was faulty if the signal never went to zero, becuase if you have open-collector halls (the kind almost always used in motors, simply because of the electrically noisy environment), then you can only tell if it is working when it goes to zero.

(zero being defined as something from 0v to about 1v, whatever the voltage drop of the transistor inside the hall is at the current the pullup resistor value allows, for the pullup voltage).

Most hall sensors in motors (at least for ebikes/etc) is some variant or clone of the Honeywell SS411A, which has a reasonably wide voltage tolerance on both supply side and output signal via the pullup. Typically around 4v minimum supply, up to 24v-30v. Some controllers use a 5v power supply to the halls, but use 12v or more on the pullups so the signal is clearer in all the noise from the phase wires / etc in the motor. But most of them use 5v on both; typically you'll see *actual* 5v on the signal lines from the pullups, but only about 4.5v on the supply voltage line.


The pullups are used inside the controller instead of at the halls so that it uses a kind of "current loop" (sort of) instead of a voltage for the signal, whcih helps make the signals more immune to electrical noise, of which there is a lot inside a motor.

I now think that it probably applies a formula to the values it measures on the data pins and makes it's decision on the basis of the results of applying that equation to the three voltages as inputs to that equation. Perhaps the total of the three voltages has to fall within a tight range? Or perhaps the average of the three voltages has to closely approximate half of Vcc?

It doesn't add voltages or anything like that.

There is a pattern to the hall signals, whcih is different between a "60 degree" and a "120 degree" placement in a motor, so that the controller can always tell the position of the magnets relative to the stator teeth/phases, so that it can send the current pulses to the motor in the right pattern to make it spin correctly.

There's lookup tables around here or on the web for whcih ones will be on or off at any time; I think that only with 60-dgree setups will you have all of them on or off at the same time, and in 120 degree setups (the most common), you will always have at least one of htem off or on when the others are not. You can watch this pattern occur if you use LEDs on each hall signal, in series with the pullups to 5v.

So what it probably does when the motor is stopped is simply check to see that they are not all on or off, if it's a 120 degree motor. If it's a 60 degree, it can't do a test when stopped, the motor must be moving for it to tell anything. When it's moving it can check for the changing pattern in response to the current pulses it sends to the phases. If the pattern doesnt' change the way it expects, it may try to send the pulses in the reverse pattern, and if it still doesnt' work, it may just error out--what error it shows you depends on what the programmers decided upon.



It is possible your controller is completely different than all the others I know of, and does indeed use varying voltage on the three sensors, but if so, I don't know why it's not working now.


But the broken wire you found on the original sensors is probably why they didnt' work before.

 

[whatsaheadwind]

Thanks for your feedback Amberwolf. Your idea that I've used the wrong type of Hall sensor as replacements makes a lot of sense. I've just placed an online order for half a dozen Honeywell SS411A sensors like you suggested using. All I can do now is wait for them to arrive. That'll be about a week, I guess. I'll let you know the outcome of fitting them. Fingers crossed.

 

[whatsaheadwind]

Good news! The eBike is back on the road. The Honeywell SS411A Hall sensors are indeed the correct Hall sensors for the DAPU MD250 (THANK YOU, AMBERWOLF!), and I have found and remedied the second fault that was concealing the success of replacing the Hall sensors with the Honeywell SS411A sensors.

This post reports the pinouts of the main harness leading from the controller to the devices on the handlebar, reports the repair and diagnostic process, and explains how and why the bike went faulty and why the repairs worked.

Throughout all my testing I kept wondering why VCC (motor Hall sensors) was only 0.7 V, but I never thought what I know now was the explanation. Had I realised that this could happen if there was a short between Vcc (all Hall sensors) and Gnd, I may have made faster progress in identifying the cause of the problem and repairing the bike. Anyway, I got there in the end.

This update has been slow to be posted for two reasons: (1) I had to wait for the arrival of the Honeywell SS411A Hall sensors; (2) all my testing of the new Hall sensors after I installed them produced odd and unexpected resutls, which I couldn't make sense of until I rechecked the specs and discovered that the SS411A Hall sensors SINK on the output pin, not source, which meant that I had to retest them to make sure I hadn't cooked any during installation; (3) replacing the Hall sensors didn't change the error codes reported by the controller, so I had to keep looking.

10 August 2020
The new Honeywell SS411A Hall Sensors finally arrived. I put them in, forgot to connect the motor hall sensor cable to the controller but connected every other cable between the controller and the ebike, plugged in the ebike battery and turned the battery on, then turned on the ebike at the display. Result was error 9: over voltage, which I'd previously identified as an erroneous error message resulting from bad programming of the controller. (Now that I know the cause of the problems, I know that the message should have said "voltage outside spec". The programmer assumed that the voltage could only ever go outside spec if voltage was too high, but the code and hardware were capable of also triggering that message if the voltage was too low, which was the case with my eBike.) Interestingly, there was no error 6 (motor hall sensors) error message, but I'm not sure that means anything, given that it came up with error 9.

I spotted the unconnected motor hall sensor cable, shut everything down, and took the opportunity to test the motor hall sensors in situ in the motor, using VCC of 4.8V from the three AAA lithium cells in the aforementioned battery pack. The Honeywell SS411A are rated for a minimum VCC of 3.8V and a maximum of 30 V, so test VCC was within range, according to specs. This is relevant, because device sensitivity is a function of VCC. (Voltage from the eBike battery is always greater than 30V, therefore there is a voltage regulator in the controller managing VCC to the Hall sensors.)

Going anti-clockwise from the notch in the socket, voltages were VCC 4.8V; blue: fluctuating voltage in the millivolt range; green: roughly 116mv; yellow: roughly 112 mv, and GND.

There were a few things about the test results that perturbed me greatly. (1) All readings were in the low millivolt range. (2) All readings were at least a little unstable. (3) There was no clear and marked difference between reading from a Hall sensor affected by a magnet, and a Hall sensor distant from and unaffected by a magnet.

I wrote up a few notes and decided to mull it over for a while. To make a long story short, it took a few days of unproductive testing before I took another look at the specs for the Honeywell SS411A Hall sensors that I had installed and discovered that they were SINK Hall sensors, and that I had been testing them as if they were SOURCE Hall sensors. No wonder I was getting unstable voltages in the millvolt range instead of the strong stable voltages I was expecting!

16 August 2020
I tested the Honeywell AS411A Hall sensors as SINK, with the Hall sensors in the motor, with the Hall sensors disconnected from the controller and powered by the aforementioned battery pack. Anticlockwise from notch, results were Vcc 4.58 V; blue 4 mV; green 4.57 V; yellow 4.57 V; GND.

Tested as SINK, with Hall sensors extracted from the motor, anticlockwise from notch, results were: Vcc 4.51 V; blue 4.53 V; green 4.53 V; yellow 4.51V; GND

From this I conclude that all three Hall sensors survived installation, and that they are sufficiently sensitive to detect and respond to the magnets in this motor.

Without motor hall sensors connected to the controller, it goes straight to error 9 (over voltage), then error 6 (motor hall sensors).

Testing voltages FROM THE CONTROLLER at the connector on the lead to the Hall sensors, without the Hall sensors lead connected to the controller, going anticlockwise from the alignment notch, gives Gnd, 3.27V, 3.26V, 3.24V, Vcc 0.7V. The voltages destined for the data pins of the Hall sensors very strongly suggest that the required Hall sensors are SINK, not source, and the Honeywell SS411A Hall sensors that I installed are indeed SINK.

But why is Vcc measuring at 0.7V? It should be up around 5V.

(What is this SINK vs SOURCE? Briefly, it means that testing SINK Hall sensors requires delivering Vcc and Gnd to their respective pins on the Hall sensor, and instead of connecting the black lead of the multimeter to Gnd and red lead of the multimeter to the data pin (which one would do for testing SOURCE Hall sensors), one instead connects the red lead of the multimeter to Vcc and connects the black lead of the multimeter to the data pin of the Hall sensor. If you test SINK Hall sensors as though they are SOURCE Hall sensors, then you'll get fluctuating voltages in the millivolt range, and the presence or absence of a magnet will have negligible effect on the voltages measured.)

Testing voltages on the sockets on the eBike leads is easy - just poke fine sewing needles into the hole and touch the multimeter lead to the sewing needle. But how can one test the voltages on the pins, when there are so many pins in such a tiny space? The way I did it was to shrink a bit of heat shrink over the end of the multimeter lead, with the heatshirink protruding 2 or 3 mm past the end of the multimeter lead. Then I can poke the heat shrink over the pin without fear of touching more than one pin with the multimeter lead. The technique worked very well.

The Honeywell SS411A Hall sensors all tested ok when unattached to the controller, using Vcc supplied by the aforementioned battery pack. What happens when we connect them to the ebike and test them on the ebike? Ie, with all connections connected just as they would be were the ebike operational.

The result was unchanged. Error 9 (over voltage) flashed up 3 or 4 times, then switched to error 6 (Hall sensors). We don't seem to be making a lot of progress here.

I switched controllers, and retested using the controller I had bought new when I thought the original controller was the source of the Error 9 messages. Results were no different. Either both controllers are RS, or both controllers are fine and the problem lies elsewhere.

More thinking required.

20 August 2020
An ebike mechanic suggested to me yesterday that perhaps the cables at the front of the bike, leading to the display, brakes, and throttle, were damaged or faulty. It seemed like a reasonable hypothesis, and it made me realise that the Error 9 message, although clearly incorrect because the system was NOT overvoltage at all, probably indicated that a fault had been detected but the incorrect error message was being displayed, therefore I still had to go looking for the fault causing the Error 9 message. In recent times I had been ignoring the Error 9 message totally and had been focusing exclusively on the Error 6 message: Motor Hall sensors.

So today I started testing the cables at the front end of the bike. In so doing, I identified and documented the function of each pin in the main harness.

I disconnected the front main harness from the controller and drew it back up the frame of the bike so that the plug on the end was conveniently close to all the connectors and devices attached to the handlebars.

The attached diagram shows the pinouts of the main harness.

Interestingly, there is only one COMMON pin. I expected two, as I suggested in my first post on this topic in this forum. I assume that the one COMMON pin (being for pin 2 of the display, pin 7 of the throttle, and pins 10 & 12 of the brakes) is Gnd. It makes more sense to have multiple Vcc than it does to have multiple Gnd. Different devices might require different Vcc. Pins 9 & 11 for the brakes are thus Vcc (brakes). Vcc for the throttle is either pin 6 or pin 8; I suspect strongly pin 6. The reason I suspect pin 6 is that when I tested the pinouts on the main harness, pin 6 of the throttle shorted to pin 7 of the throttle while the throttle was connected to the cable. This seemed very odd to me, so I disconnected the throttle (and every other device) from the harness and continued testing. Once I had documented the pinouts, I tested the extension cable end to end and confirmed no shorts or disconnections in the extension cable that runs down inside the frame to the controller.

This unexpected short between pin 6 and pin 7 of the throttle bothered me - and brought back a memory. I realised that I had not had the error 9 or error 6 error codes before I replaced the throttle, and that those codes appeared at first test after I installed the new throttle. (Brief recap: the bike was behaving perfectly until I got an error message saying that the throttle was faulty. I replaced the throttle, and immediately got error messages Error 9 (over voltage) and Error 6 (Motor Hall sensors). Ever since then I have been focusing on finding the cause of the error 9 and error 6 messages. Thinking that this proliferation of messages indicated a faulty controller, I bought a new controller and fitted it, but it made no difference. I still got error 9 and error 6 messages. The error 9 message was a furphy - the system was most definitely NOT overvoltage. The error 6 message was initially correct, because I found a broken wire on a Hall sensor data pin when I stripped down the motor, but replacing the Hall sensors had not made the error 6 message go away.)

With my attention now on the throttle, rather than on the motor hall sensors, I reconnected everything EXCEPT FOR THE THROTTLE and turned on the eBike. There were NO error messages! The controller seemed entirely happy! The controls on the display did what they were supposed to do!

I turned off the eBike, connected the throttle, and retested. Error 9.

I turned off the eBike, disconnected the throttle, and retested. No error codes!

I turned off the eBike, connected the original throttle that I had replaced when I first got the error message telling me that the throttle was faulty, and retested. No error codes!

This is good! I turned everything off, reasssembled the bike (using string and silicone sealant to secure the Hall sensors in place in the motor), replaced the new throttle with the original throttle, and took the bike for a ride. It behaved perfectly! Problem solved!

So what was the problem?

There were two faults. That's why it was so hard to track down. The first fault to develop was the broken wire on the data pin of one of the Hall sensors in the motor. The second fault was created by replacing a perfectly good throttle with one that was either faulty from new, or else the incorrect throttle for my eBike. Because I damaged the Hall sensors before I found the broken wire in the motor, I had to replace the Hall sensors. The Honeywell SS411A Hall sensors have proven to be the correct Hall sensors for the DAPU MD250 motor in my Smartmotion Mid City ebike. (Thank you Amberwolf!) That fixed the first fault that developed. Fixing the second fault was mostly good luck: I found two pins shorted on the throttle that shouldn't have been shorted, which led me to suspect that the replacement throttle was defective. Reverting to the original throttle fixed that problem - and restored the bike to operational order.

My hypothesis of the sequence of events is as follows:

(1) The solder connecting the wire to the data pin of one of the motor Hall sensors fractured and separated, as the result of vibration. I believe it was a bad solder joint right from original manufacture. The wire did not overlap the data pin - the wire had been soldered to the tip of the data pin.

(2) The controller reported a throttle error. (Bad programming! Yes there was a fault, but it was NOT a throttle fault!)

(3) I replaced the throttle with a defective throttle. (The replacement was supplied as a genuine Smartmotion part, but perhaps it was for a different Smartmotion model?)

(4) The controller didn't like the new throttle and reported Error 9, followed by Error 6. Error 6 was motor Hall sensors, so Error 6 was correct diagnosis by the controller. Error 9 was a furphy. There was no overvoltage. I think the reason the controller thought there was overvoltage was because pin 6 on the throttle was Vcc (throttle) and it was shorted to Gnd on pin 7 of the throttle by the defective throttle. This short to Gnd was the reason that Vcc to the Hall sensors in the motor was 0.7 V. The throttle Hall sensor would also have been receiving this same 0.7V as Vcc as the result of the short.

(5) I replaced the motor Hall sensors, but the faulty/ incorrect throttle Hall sensor was still pulling Vcc for the motor Hall sensors down to 0.7V, so the controller continued to report error 6 (motor Hall sensors), and error 9 (because it was detecting Vcc for the Hall sensors outside spec.)

(6) I replaced the throttle, and the controller was happy. Vcc to the Hall sensors was now correct (so no Error 9 any more), and the Hall sensors now passed diagnostics, so no error 6 any more.

PROBLEM SOLVED! Error 9 explained; Error 6 explained. Bike operational once more.

 

[whatsaheadwind]

INSIDE BATTERY CASE
I opened up the battery case on the Smartmotion Mid City today, and attached are the photos of what is inside. I didn't bother tracing any wires, since my only reason for opening the battery case was to reassure myself that the liquid I spilt on it hadn't penetrated the inside.
SPEED ON DISPLAY SHOWS DOUBLE REALITY
One interesting event happened this afternoon. I discovered that the rear wheel on the Mid City wasn't bedded home properly, so I released the lock lever, let the wheel find it's home, and relocked the lock lever. This had a most unexpected consequence. After repositioning the rear wheel, the speed shown on the display was double reality. I checked display settings, but they were still correct, so I checked the position of the rear wheel magnet on my other Mid City, and discovered that the correct position for the magnet is right up the front of the sensor. The magnet on the double-speed Mid City was back about half way along the sensor. I relocated the magnet to the front of the sensor, took the bike for a short ride, and the speed was now showing correctly.

 

[orangedevil]

Great writeup. I'm thinking of buying a SM eCity as well.
https://www.smartmotionbikes.com.au/product/smartmotion-e-city/
However the throttle seems to be limited to 6km/h, after which you use the Pedal Assist function.
Any idea on how to have the throttle active at all speeds?

I have an older eUrban and that throttle always works, very handy.

 

[stringy@hwy.com.au]

Hi there
I have a Smartmotion Xcity with 3000 km on it. I love this bike but recently the lights have stopped working. The display indicates that light should be on. I have tried to contact Smartmotion but no reply. I was hoping you chaps would shine a light for me. :|
HaHa. Hoping it’s a simple fix. Cheers
RayGraham

 

[amberwolf]

Many systems with displays that directly control the light (the light connects to the display) have a little transistor in there that does the switching of light power. This can fail for a number of reasons, usually from too high a load on it (too big a light), but can just be from age or manufacturing defect.

The transistor can be replaced if that's what failed; which part to use depends on what's in there now.

It could also be the light itself, or it's internal electronics.

If you measure no voltage across the two wires to the light when the display says it should be there, it's probably the transistor (if it connects to the display). If there is correct voltage there, then it's probably the light itself.

 

[justy]

Thanks so much to all the contributors to this thread. My issue was with my SM XCity; error codes 04 and 05. A different issue to the error 09 and 06s mentioned above, but these posts were very instructional and put me more into the methodical one-thing-at-a-time mindset than I was already.

In my case my issue was with the 8 core (extension) cable that connects the screen to the controller. I've yet to verify this with my multimeter, but I suspect that one or more of the wires/connectors had broken when turning the handlebars too far.

A couple of days ago I had tried removing that cable and connecting them directly, but in that case got an overvoltage warning. I was using a fully charged battery so I suspect that this warning was due to there being a (slightly!) lower voltage drop than without the cable.

Today I removed the controller from the motor and had hooked it up to my bench power supply, which is only capable of supplying 31 volts, but thankfully that was enough to get it booted up. Sure enough no throttle nor overvoltage warnings, and I was able to use the walk mode and throttle (Which I had replaced; I think there was actually an issue with my thumb throttle too- obviously with the throttle error codes I first tried replacing the throttle, but was still getting the thottle error codes, even with it not plugged in).

I shut it down and re-attached the extension and sure enough got a 04 throttle not returning error again. So I'm very pleased that it will be an inexpensive repair.

On the topic of the Smartmotion company, I love my bike a lot, but not so much the company. I contacted them a week ago when this started happening, hoping to get some support (Where I bought the bike no longer works with the brand- hmm I wonder why?) and have heard back nothing. As a software and electronics engineer I'd really like to be able to connect to the firmware myself but it seems like there's zero chance of that unfortunately; if that changes, let me know! Or I'll let you know!

In any event, thanks to this experience, and the valuable resources here, I should be back on the road soon.

p.s. @whatsaheadwind I think there's an error in your (again, SUPER helpful)schematic as you show a 4 core connector to the Hall effect sensors; it's a 5 core (green) connector. As for how many of those are used, I can't say.

p.p.s Speaking of. are all of the XCity controllers potted in epoxy? It made investigating a little challenging to say the least!