whatsaheadwind
1 mW
- Joined
- Jun 27, 2020
- Messages
- 14
0 kph, ERROR CODE F (LCD COMMUNICATION ERROR) and DATA COMMUNICATIONS in the Smartmotion Mid City eBike.
(Much of what I say here probably also applies to Error Code A (Communication Error - Check all cables), but that is one error code I have never experienced on either of my Mid Citys.)
In order to understand the error codes on the Smartmotion Mid City, one must understand that there are two microprocessors (ie, computers) in the Mid City. The one that everyone knows about is in the motor-gearbox body, and is commonly known as the controller. But there is a second microprocessor, and it is in the display unit that is attached to the handlebars. The workload of managing the ebike and reporting what is happening (to both the other microprocessor and to the user) is shared between the two microprocessor units, with each having it's own allocated tasks to perform and manage.
Communication between the two microprocessors is by 3 wire serial comms. Power (+Vcc) and Gnd are separate, and these five functions account for the five wires leading to the display unit that is attached to the handlebars. Understanding communication errors on the Smartmotion Mid City requires an understanding of how 3-wire serial comms works. https://en-support.renesas.com/knowledgeBase/16978416 provides an excellent explanation quite concisely.
In 3-wire serial comms, one wire is dedicated to carrying communication packets from controller to display, one wire is dedicated to carrying communication packets from display to controller, and one wire is used for the clock pulse. Vcc (voltage in) and Gnd (ground) are also required.
The 3 wires used for communication are serial out (SO), serial in (SI), and serial clock (SCK). SCK is a clock pulse transmitted by the Master, which in the Smartmotion Mid City is the controller in the motor housing. It's job is to time the transmission of data packets, so that the recipient knows when to listen for an incoming packet and the sender knows when to send a packet. It's the controller that turns on power to the display unit and thus initiates the second microprocessor in the system, and it is Master. The display unit acts as Slave in the data communications, and thus has the ability to detect and report to the user the absence of a clock pulse from the Master (ie, the controller) as a communications error.
Two things can cause loss of SCK signal. The most likely is (1) a disconnect in either or both of the main harness or the 4-1 manifold cable; or (2) the failure by the main controller to transmit the SCK signal, which is a lot less likely, given that there would almost certainly be other symptoms indicative of serious problems in the controller if the controller was unable to generate a clock pulse.
If the clock pulse is failing to reach the display unit, which of these is causing the problem can be identified by seeking the SCK (serial clock) pulse at each possibility in turn, starting with the main controller. A multimeter that can detect frequency, or an oscilloscope, would do the job. If there is a clock signal at the main controller, then plug in the main harness. If there is a clock signal on the main harness, plug in the 4-1 manifold connector. If there is a clock signal at the display connector of the 4-1 manifold cable, then the problem has to be in the display unit.
In the implementation used in the Smartmotion Mid City, there is no handshaking or acknowledgement of receipt of a data packet, and no retry in the event of a failure to receive an acknowledgement packet. In other words, communication between the two microprocessors is exceedingly basic, which isn't necessarily a bad thing. It means the microprocessor in the controller can focus on operating the bike instead of being kept unnecessarily busy handling communications with the microprocessor in the display.
The simplicity of this communications arrangement means that it is entirely possible for the display to send communication packets to the controller and affect the operation of the ebike (eg, instruct the controller to change PAS level, or switch between power mode and normal mode, or turn the lights on or off) while the display reports correctly the PAS level, the power mode, and the status of the lights, whilst concurrently and incorrectly reporting that the ebike is doing 0 kmph. (I've experienced this on one of my Mid Citys.) In this situation, communications packets from the display microprocessor are reaching the controller intact, and are being processed correctly by the controller microprocessor, but communications packets from the controller microprocessor are not reaching the display, hence the display of 0 kph.
(Note that there is another possible, and more likely, cause of a display of 0 kph which you should rule out before assuming that you have a communications problem. If the hall sensor (that is attached to the frame) that detects the passing of the magnet that is attached to the spoke on the rear wheel is not in the correct position, or if the magnet on the spoke has been bumped out of correct alignment, you will also get a 0 kph display, but when that is the cause of the 0 kph display, the bike will unexpectedly go to sleep while you are riding it. This is because it is the controller that is responsible for putting the bike to sleep, and if the controller receives no input from the rear wheel hall sensor, than it assumes the bike is not in use, turns off power to the display unit, and puts the bike to sleep. But when the cause of the display of 0 kph is a communications line failure, the controller is receiving pulses from the rear wheel hall sensor but the data packets the controller sends to the display reporting the rotations of the rear wheel never reach the display unit, so the display reports the bike doing 0 kph. Note that it is the microprocessor in the display that converts the pulses that the controller receives (and passes on to the microprocessor in the display) from the hall sensor at the rear wheel into distance and speed for display to the user, using the wheel circumference configuration that is stored in the display settings.
So how do the communication error codes work?
In general, error codes are generated by the main controller (and sometimes the firmware in the main controller gets it wrong and reports a misleading error code. For example, it will report an over-voltage error in response to a short between Vcc and Gnd at the throttle hall sensor. I've also had undocumented error codes; for example, error code 1.) But there are error codes that are generated by the display unit, not the main controller, and those are the alphabetic codes: error code F (LCD Communications Error) and error code A (Communications error - Check all cables). By having only numeric codes generated by the main controller and only alphabetic codes generated by the display, the manufacturer can mix and match different displays and controllers at will, providing the communication packets of each abide by the same specification.
This document addresses only error code F, solely because I've never had an error code A, however probably everything that applies to error code F also applies to error code A. My suspicion is that some display units are programmed to report error code A when there is a communications problem, and some are programmed to report error code F when there is a communications problem, and the instruction manual lists both, even though there is no one display unit in existence that is capable of generating both errors.
These two error codes (A and F) are (and have to be) generated by the microprocessor in the display unit, not by the main controller, because if there genuinely was a communications failure between the two microprocessors, there is no way that the display unit would know it to report it to the user unless the display unit itself had the means to detect the communications failure.
A fault triggering an Error Code F message has to be in one OR MORE of the following components: the main harness between the controller and the manifold cable at the handlebars; the 4-1 "manifold" cable connecting the main harness to the various devices on the handlebars,, the display unit on the handlebars, or the main controller in the motor housing. In my experience the controller is remarkably robust, having survived short circuits between Vcc and Gnd, sensor disconnections, and other abuse on one of my bikes in particular. And I have never had a problem with the display unit. The cables, on the other hand, are riduculously fragile, and do not cope with disconnection at the connectors very well at all. Several times I have had to resolder connector pins to the wires in the cables because of poor soldering by the manufacturer. I've even had one connector that showed absolutely no evidence of tinning from soldering by the manufacturer at all! The only thing that held it together for the first few months of ownership was a little solder-flux, the insulation that was moulded around the connector, and a lot of good luck. So if you get a faulty wire, strip away the insulation from the connectors (male end first; that seems to be where the most problems are) and resolder the disconnected wire with silver solder. When done, use hot melt glue to make a new insulating cap over the connector.
So what communications faults can the display detect and report with error code F? Not the failure to receive any packets from the controller, that's for sure. There is no ongoing handshaking (I'm here, are you there? Have you got anything to tell me?) going on between the two microprocessors. (That would be an overhead on the microprocessors that would slow response to other inputs to the controller and require a higher processing speed or multicore microprocessor to compensate). And not failure to receive an acknowledgement packet or signal from the controller in response to transmission of a packet from the display unit either, because neither microprocessor sends acknowledgement packets after receipt of a data packet, and there is no dedicated acknowledgement line (such as exists in RS232 comms, for example). A disconnect in the data line from the controller to the display unit (as has happened to one of my bikes) does not result in an error code F (or any other error) being reported by the display, so there can not be any handshaking or acknowledgement packets being sent, otherwise their absence could be detected and reported.
So the only types of communications error that the display unit is possibly capable of detecting are (1) receipt of a corrupt data packet from the controller (such as might result from a misbehaving or faulty controller or a poor-quality connection in the data line from the controller to the display unit), or else (2) failure to receive a clock pulse from the controller (which is "Master" in the communications) on the SCK line. It is entirely possible that the firmware is actually only capable of detecting the absence of a clock pulse on the SCK line and is not capable of detecting a corrupt data packet, and that in the event of it receiving a corrupt data packet, it just discards the packet without reporting an error. But if my guess as to what the undocumented errror code 1 indicates is correct, then that hypothesis is unlikely to be true and it is likely that the display unit is capable of detecting a corrupt data packet.
So what happens when the line carrying data packets from the controller to the display is the cause of a 0 kph display?
When there is a disconnect in the communications line (ie, wire) that carries the data packets from the controller to the display, everything on the bike works fine (because the controller is doing its job perfectly), but the only items displayed on the display are those items that the display microprocessor is responsible for calculating, storing, and displaying. Eg, system voltage, PAS setting, whether in power or normal mode etc. Anything that is dependent upon message packets from the controller is not displayed. (eg, odometer, speed, motor power output...) Whilst the line carrying signals from the display to the controller remains intact, the controller can receive and respond correctly to instructions from the display to change mode (power/ normal); to change PAS setting; or to turn the lights on or off. In that situation, the controller doesn't know that the display is not receiving the packets it is sending it, and it continues functioning normally.
When you have a bad connection in one of the comms wires between the controller and the display unit, error code 1 (undocumented in the instruction manual) and error code F (LCD Communication Failure) may intermittently (and briefly) appear. These two error codes may go away all by themselves if the bad connection is only intermittent.
So what is the undocumented error code 1? Given that numeric error codes come from the controller and alphabetic codes come from the display, and that I had both error code F and error code 1 close together and only briefly, I strongly suspect that error code 1 is the controller reporting receipt of a corrupt data packet from the display unit, and miraculously the packet the controller sent to the display unit reporting the corrupt data packet it had received actually managed to reach the display unit intact, whereas other packets sent very soon afterwards did not (as is evidenced by the error code F displayed on the display unit, iindicating either receipt of corrupt data packets from the controller or else loss of clock pulse on the SCK line.) Since the controller microprocessor is the Master in the data communications, error code 1 can not be reporting the absence of a clock pulse on the SCK line, because it is the controller that is generating the clock pulse.
If you have a non-continuous wire problem in the Mid City, the fault is almost certainly bad soldering by the manufacturer at one of the connectors on the defective wire. Close inspection of the plug may reveal localised fragmentation of the insulation. This is heat damage caused by high resistance at the bad connection. I have successfully repaired such problems on many occasions by removing the insulation at the plug, resoldering the wire to the pin with silver solder, and using hot melt glue to create a new insulating covering over the connection. (Note that SILVER solder is essential; the wire is steel, and very difficult to tin using ordinary solder. Silver solder, on the other hand, does the job almost instantly.)
The only electrical problem I've had that was not caused by a broken wire was caused by a faulty hall sensor in the throttle (which resulted in a short between Vcc and Gnd), and that was a really tough problem to track down because it triggered a quite misleading error code. (Namely, over-voltage error.) If you get a really wierd problem that doesn't make the slightest bit of sense, suspect water in the motor, or a short between Vcc and Gnd somewhere.
This document records my understanding of data communications on the Smartmotion Mid City, based upon my experience of problems that I have had on my Mid Citys and what resolved those problems. I'm not perfect; I may have made errors. But in the absence of any useful documentation on the internet from the manufacturer of the Smartmotion ebikes, what I have provided here is at least a starting point to guide your diagnosis of problems.
(Much of what I say here probably also applies to Error Code A (Communication Error - Check all cables), but that is one error code I have never experienced on either of my Mid Citys.)
In order to understand the error codes on the Smartmotion Mid City, one must understand that there are two microprocessors (ie, computers) in the Mid City. The one that everyone knows about is in the motor-gearbox body, and is commonly known as the controller. But there is a second microprocessor, and it is in the display unit that is attached to the handlebars. The workload of managing the ebike and reporting what is happening (to both the other microprocessor and to the user) is shared between the two microprocessor units, with each having it's own allocated tasks to perform and manage.
Communication between the two microprocessors is by 3 wire serial comms. Power (+Vcc) and Gnd are separate, and these five functions account for the five wires leading to the display unit that is attached to the handlebars. Understanding communication errors on the Smartmotion Mid City requires an understanding of how 3-wire serial comms works. https://en-support.renesas.com/knowledgeBase/16978416 provides an excellent explanation quite concisely.
In 3-wire serial comms, one wire is dedicated to carrying communication packets from controller to display, one wire is dedicated to carrying communication packets from display to controller, and one wire is used for the clock pulse. Vcc (voltage in) and Gnd (ground) are also required.
The 3 wires used for communication are serial out (SO), serial in (SI), and serial clock (SCK). SCK is a clock pulse transmitted by the Master, which in the Smartmotion Mid City is the controller in the motor housing. It's job is to time the transmission of data packets, so that the recipient knows when to listen for an incoming packet and the sender knows when to send a packet. It's the controller that turns on power to the display unit and thus initiates the second microprocessor in the system, and it is Master. The display unit acts as Slave in the data communications, and thus has the ability to detect and report to the user the absence of a clock pulse from the Master (ie, the controller) as a communications error.
Two things can cause loss of SCK signal. The most likely is (1) a disconnect in either or both of the main harness or the 4-1 manifold cable; or (2) the failure by the main controller to transmit the SCK signal, which is a lot less likely, given that there would almost certainly be other symptoms indicative of serious problems in the controller if the controller was unable to generate a clock pulse.
If the clock pulse is failing to reach the display unit, which of these is causing the problem can be identified by seeking the SCK (serial clock) pulse at each possibility in turn, starting with the main controller. A multimeter that can detect frequency, or an oscilloscope, would do the job. If there is a clock signal at the main controller, then plug in the main harness. If there is a clock signal on the main harness, plug in the 4-1 manifold connector. If there is a clock signal at the display connector of the 4-1 manifold cable, then the problem has to be in the display unit.
In the implementation used in the Smartmotion Mid City, there is no handshaking or acknowledgement of receipt of a data packet, and no retry in the event of a failure to receive an acknowledgement packet. In other words, communication between the two microprocessors is exceedingly basic, which isn't necessarily a bad thing. It means the microprocessor in the controller can focus on operating the bike instead of being kept unnecessarily busy handling communications with the microprocessor in the display.
The simplicity of this communications arrangement means that it is entirely possible for the display to send communication packets to the controller and affect the operation of the ebike (eg, instruct the controller to change PAS level, or switch between power mode and normal mode, or turn the lights on or off) while the display reports correctly the PAS level, the power mode, and the status of the lights, whilst concurrently and incorrectly reporting that the ebike is doing 0 kmph. (I've experienced this on one of my Mid Citys.) In this situation, communications packets from the display microprocessor are reaching the controller intact, and are being processed correctly by the controller microprocessor, but communications packets from the controller microprocessor are not reaching the display, hence the display of 0 kph.
(Note that there is another possible, and more likely, cause of a display of 0 kph which you should rule out before assuming that you have a communications problem. If the hall sensor (that is attached to the frame) that detects the passing of the magnet that is attached to the spoke on the rear wheel is not in the correct position, or if the magnet on the spoke has been bumped out of correct alignment, you will also get a 0 kph display, but when that is the cause of the 0 kph display, the bike will unexpectedly go to sleep while you are riding it. This is because it is the controller that is responsible for putting the bike to sleep, and if the controller receives no input from the rear wheel hall sensor, than it assumes the bike is not in use, turns off power to the display unit, and puts the bike to sleep. But when the cause of the display of 0 kph is a communications line failure, the controller is receiving pulses from the rear wheel hall sensor but the data packets the controller sends to the display reporting the rotations of the rear wheel never reach the display unit, so the display reports the bike doing 0 kph. Note that it is the microprocessor in the display that converts the pulses that the controller receives (and passes on to the microprocessor in the display) from the hall sensor at the rear wheel into distance and speed for display to the user, using the wheel circumference configuration that is stored in the display settings.
So how do the communication error codes work?
In general, error codes are generated by the main controller (and sometimes the firmware in the main controller gets it wrong and reports a misleading error code. For example, it will report an over-voltage error in response to a short between Vcc and Gnd at the throttle hall sensor. I've also had undocumented error codes; for example, error code 1.) But there are error codes that are generated by the display unit, not the main controller, and those are the alphabetic codes: error code F (LCD Communications Error) and error code A (Communications error - Check all cables). By having only numeric codes generated by the main controller and only alphabetic codes generated by the display, the manufacturer can mix and match different displays and controllers at will, providing the communication packets of each abide by the same specification.
This document addresses only error code F, solely because I've never had an error code A, however probably everything that applies to error code F also applies to error code A. My suspicion is that some display units are programmed to report error code A when there is a communications problem, and some are programmed to report error code F when there is a communications problem, and the instruction manual lists both, even though there is no one display unit in existence that is capable of generating both errors.
These two error codes (A and F) are (and have to be) generated by the microprocessor in the display unit, not by the main controller, because if there genuinely was a communications failure between the two microprocessors, there is no way that the display unit would know it to report it to the user unless the display unit itself had the means to detect the communications failure.
A fault triggering an Error Code F message has to be in one OR MORE of the following components: the main harness between the controller and the manifold cable at the handlebars; the 4-1 "manifold" cable connecting the main harness to the various devices on the handlebars,, the display unit on the handlebars, or the main controller in the motor housing. In my experience the controller is remarkably robust, having survived short circuits between Vcc and Gnd, sensor disconnections, and other abuse on one of my bikes in particular. And I have never had a problem with the display unit. The cables, on the other hand, are riduculously fragile, and do not cope with disconnection at the connectors very well at all. Several times I have had to resolder connector pins to the wires in the cables because of poor soldering by the manufacturer. I've even had one connector that showed absolutely no evidence of tinning from soldering by the manufacturer at all! The only thing that held it together for the first few months of ownership was a little solder-flux, the insulation that was moulded around the connector, and a lot of good luck. So if you get a faulty wire, strip away the insulation from the connectors (male end first; that seems to be where the most problems are) and resolder the disconnected wire with silver solder. When done, use hot melt glue to make a new insulating cap over the connector.
So what communications faults can the display detect and report with error code F? Not the failure to receive any packets from the controller, that's for sure. There is no ongoing handshaking (I'm here, are you there? Have you got anything to tell me?) going on between the two microprocessors. (That would be an overhead on the microprocessors that would slow response to other inputs to the controller and require a higher processing speed or multicore microprocessor to compensate). And not failure to receive an acknowledgement packet or signal from the controller in response to transmission of a packet from the display unit either, because neither microprocessor sends acknowledgement packets after receipt of a data packet, and there is no dedicated acknowledgement line (such as exists in RS232 comms, for example). A disconnect in the data line from the controller to the display unit (as has happened to one of my bikes) does not result in an error code F (or any other error) being reported by the display, so there can not be any handshaking or acknowledgement packets being sent, otherwise their absence could be detected and reported.
So the only types of communications error that the display unit is possibly capable of detecting are (1) receipt of a corrupt data packet from the controller (such as might result from a misbehaving or faulty controller or a poor-quality connection in the data line from the controller to the display unit), or else (2) failure to receive a clock pulse from the controller (which is "Master" in the communications) on the SCK line. It is entirely possible that the firmware is actually only capable of detecting the absence of a clock pulse on the SCK line and is not capable of detecting a corrupt data packet, and that in the event of it receiving a corrupt data packet, it just discards the packet without reporting an error. But if my guess as to what the undocumented errror code 1 indicates is correct, then that hypothesis is unlikely to be true and it is likely that the display unit is capable of detecting a corrupt data packet.
So what happens when the line carrying data packets from the controller to the display is the cause of a 0 kph display?
When there is a disconnect in the communications line (ie, wire) that carries the data packets from the controller to the display, everything on the bike works fine (because the controller is doing its job perfectly), but the only items displayed on the display are those items that the display microprocessor is responsible for calculating, storing, and displaying. Eg, system voltage, PAS setting, whether in power or normal mode etc. Anything that is dependent upon message packets from the controller is not displayed. (eg, odometer, speed, motor power output...) Whilst the line carrying signals from the display to the controller remains intact, the controller can receive and respond correctly to instructions from the display to change mode (power/ normal); to change PAS setting; or to turn the lights on or off. In that situation, the controller doesn't know that the display is not receiving the packets it is sending it, and it continues functioning normally.
When you have a bad connection in one of the comms wires between the controller and the display unit, error code 1 (undocumented in the instruction manual) and error code F (LCD Communication Failure) may intermittently (and briefly) appear. These two error codes may go away all by themselves if the bad connection is only intermittent.
So what is the undocumented error code 1? Given that numeric error codes come from the controller and alphabetic codes come from the display, and that I had both error code F and error code 1 close together and only briefly, I strongly suspect that error code 1 is the controller reporting receipt of a corrupt data packet from the display unit, and miraculously the packet the controller sent to the display unit reporting the corrupt data packet it had received actually managed to reach the display unit intact, whereas other packets sent very soon afterwards did not (as is evidenced by the error code F displayed on the display unit, iindicating either receipt of corrupt data packets from the controller or else loss of clock pulse on the SCK line.) Since the controller microprocessor is the Master in the data communications, error code 1 can not be reporting the absence of a clock pulse on the SCK line, because it is the controller that is generating the clock pulse.
If you have a non-continuous wire problem in the Mid City, the fault is almost certainly bad soldering by the manufacturer at one of the connectors on the defective wire. Close inspection of the plug may reveal localised fragmentation of the insulation. This is heat damage caused by high resistance at the bad connection. I have successfully repaired such problems on many occasions by removing the insulation at the plug, resoldering the wire to the pin with silver solder, and using hot melt glue to create a new insulating covering over the connection. (Note that SILVER solder is essential; the wire is steel, and very difficult to tin using ordinary solder. Silver solder, on the other hand, does the job almost instantly.)
The only electrical problem I've had that was not caused by a broken wire was caused by a faulty hall sensor in the throttle (which resulted in a short between Vcc and Gnd), and that was a really tough problem to track down because it triggered a quite misleading error code. (Namely, over-voltage error.) If you get a really wierd problem that doesn't make the slightest bit of sense, suspect water in the motor, or a short between Vcc and Gnd somewhere.
This document records my understanding of data communications on the Smartmotion Mid City, based upon my experience of problems that I have had on my Mid Citys and what resolved those problems. I'm not perfect; I may have made errors. But in the absence of any useful documentation on the internet from the manufacturer of the Smartmotion ebikes, what I have provided here is at least a starting point to guide your diagnosis of problems.
