Flash e-bike Part 3 (mainboard)
In part 1 of the series, I introduced the background of this particular exercise, and why we're embarking on it. In part 2, I disassembled the bike, and identified the major pieces of its systems. In this part, we're going to look at the mainboard. This isn't going to be a deep-dive; we just want to understand what it does and how it could be used or replaced.
Mainboard overview
Now that the mainboard has been removed from the bike, we can spend some time identifying the main components and guess at their functions. Roughly a third of the area is devoted to power supplies. The power tree alone is a pretty interesting study that we'll address below. Around the periphery of the board we have the components that implement the actual functionality of the board.
ESC Connection
Interestingly, the only really necessary parts are in the bottom left corner. There's a single line that snakes its way from the brake loop connector through to the ESC connector. Next to that is a MOSFET that's responsible for shorting the B+ line from the ESC to its "enable" line. This one signal is responsible for turning the ESC on. The remaining pins are ground pins and two UART signals that come from the I2C TTL UART chip on the right margin of the board.
The UART signals are primarily responsible for getting speed information from the ESC and setting pedal assist modes. It's also possible to get battery pack voltage and current from the ESC, though I don't think that the main IC is actually getting those values this way. We'll dig into this hypothesis a little more in the BMS analysis post.
Lamps
The very large 3-pin connectors on the left margin of the PCB go to the head and tail lamps, and are powered directly by their own buck converter, which is set to 8 volts. The data signals from those connectors are a bit of a mystery, and my probing of the board hasn't located where they originate yet.
Cellular
In the top-right of the board, the cellular modem is placed along with its SIM card socket. The cellular modem appears to be powered via its own 3.8 volt buck converter, which is supplied from the main 12 volt supply.
UARTs
Just below the SIM socket is a section I've labeled "I2C TTL UART", which contains two ICs and two crystals. Both of these ICs are I2C UART devices. It's not immediately clear why they bothered with I2C UARTs rather than using on-chip peripherals. The most likely reason is that they couldn't find a chip they liked with the peripheral mix they desired.
Both UART chips share the same I2C bus, which surprised me a little. Putting UART over I2C is a little tricky because data can arrive at the UART at any time. In contrast, I2C is a command/response model where only the bus leader can initiate transfers. Typically the only ways to handle this are polling or an interrupt. This is OK if the I2C bus is otherwise idle, but if there are two chatty UARTs on one I2C bus, you run the risk of buffer overflows.
I'm not sure how active the communication channel with the cell modem is, but the BMS and ESC communication is at least command/response, so the microcontroller does have some control over how often data will be present. The UARTs that I've been able to discover on the board so far are:
- ESC data connection
- BMS data connection
- Cell modem (presumed)
Application processor
Continuing down the right margin, we come to the main application processor, which is an Infineon Cortex-M0 ARM processor. It seems aimed at the automotive market, and is otherwise quite average. The most interesting thing about it seems to be the decision to use a macroblock/FPGA based model to enable more versatile options for peripherals. Infineon provides a Verilog library that can be used, so you don't have to write your own basic and common peripherals. Clearly, the chip also implements bluetooth low energy (BTLE), and that's used to communicate with the mobile app.
Horn supply and control
Continuing our clockwise march around the edge of the board, we hit the horn connector, and its power transistor. The horn is powered at all times by 12 volts, has two ground pins, and one signal from the transistor. My gut tells me that it has some kind of internal amplification (justifying the constant 12v supply), but I can't find any similar buzzers on DigiKey. The transistor likely implements the tones used for the horn.
LCD Connections
At the bottom center of the PCB, we finally come to the connectors to the LCD module. These connectors contain multiple power and ground pins as well as a high-speed SPI bus for the LCD display and I2C for the touchscreen digitizer. At least one of the power pins is dedicated to a GPS low-noise amplifier block that's in the LCD module.
Power management
Finally, we jump to the center of the board and the power management architecture of the device. Most of the complexity, in my opinion, is justified by the need to step raw battery voltage down to something manageable, all while wasting the minimum amount of energy. Each review of the bike I've read mentions considerable idle power consumption owing to "smarts" of the bike. Below is a simplified diagram for how energy flows into and through the system.
Power supply design is a balance of many factors. A number of them are:
- Bill of Materials (BoM) cost and part availability
- Losses from heat and other inefficiencies
- Electric Magnetic Interference (EMI) concerns and compliance
- Cross-talk or interference between heavy (and variable) loads and sensitive loads
Modern switching regulators do an excellent job at minimizing the impact of number 2, at the expense of greater risk of causing problems with number 3. If you scroll up to the board image, you might see that the power supply section of the board is outlined with a gold trace. This is there so the manufacturer can install a metal shield over the power supplies if they produce too much radiation.
Meanwhile, cross-talk can occur if there is a large and variable load on a power supply that is shared with a sensitive part or system. Notice that the LCD module has a separate 3.3 volt supply than the rest of the logic. I don't actually believe that this supply is powering the LCD itself; the LCD is probably powered by the logic supply. My hunch is that this supply is used for the GPS low-noise amplifier that we'll see in the LCD module post. Separating these supplies would avoid noise from all the rest of the logic that is powered by 3.3 volts imprinting itself onto the GPS signal.
It is my expectation that the reason most of the supplies are fed from the 12 volt supply, rather than directly from the 36-42 volt battery, is that it's harder and more expensive to find chips that are rated for supply voltages that high. Stepping it down to 12v also limits the variability in voltage that these subsequent supplies have to be designed to handle.
Over all, I think this is a sensible design. I think the poor idle consumption problem I mentioned at the beginning is likely caused by the demands placed upon it by product design, not power system design.
It is my understanding that there's a accelerometer chip on the board that's used to detect when the bike is jostled. Such a chip should allow the entire board to be powered off unless it's moved, even by a small amount. At that point, it could do things like powering up the cellular modem, ping the servers, and get a GPS fix. I'm not sure if they ended up implementing that, if it's too sensitive, or if there are other loads that draw the battery down.
Next steps
Even this cursory exploration convinces me that we don't need this board at all. The brake loop goes directly to the ESC, and the enable line is a simple switch. We'll need to figure out what kind of protocol the ESC speaks, so we can control it. That will be addressed in the ESC section.
Because of all this, I'm going to put a pause on investigating this board any further. It's just not going to move the project forward. There are some intellectual curiosities remaining, and I hope to get to them at some point.
The main board will make a brief appearance in the BMS post to seed some of our understanding of how that component communicates with the world. We'll get to that in out next post. It will probably make an appearance in the LCD section as well, for similar reasons.