Luna M600 Ludicrous V2 reverse engineering and firmware making

[TPEHAK]

The archive with the current versions of the files ( KiCAD (Version 9.0.0) motor controller files, firmware files, CAD files of the CNC machined and 3D printed custom parts, CAD files of the fasteners, Luna manuals collection, Gerber files) can be downloaded here (updated on 2025-10-08)

Bafang M600 VESC Controller board KiCAD files (Final Version Release #2) (2025-10-08).7z

drive.google.com

How to build the controller

Alrighty guys, I think it's time to liberate the Luna M600 Ludicrous V2 VESC motor controller for Bafang M520/560/600 motors.

By the way, if you are interested in VESC motor controller for Bafang M620 it was already liberated here:

Archon X1 Programming Thread (questions and experiences)

Hello, did you try to contact Krasnodar first for assistance? I would contact him first. Maybe ask him when he is planning to make the online server available again (he promised to make it available soon some time ago). If he does not respond here is the link for the bypassed tool with advanced...

forums.electricbikereview.com

Now the time has come and it is the Luna M600 Ludicrous V2 turn.

The subject of reverse engineering is specifically M600-Rev6 2022-12 version of the controller. I believe this is the latest iteration of this controller.

I already did some good progress and I am planning to post the reverse engineering progress reports, pictures and files here. All the reversed files will be publicly shared for your pleasure and you are free to use it however you want. At the end of the day we would need to build the PCBS and test how it works to make sure the unit was reverse engineered properly and just for fun.

If you have something to contribute in to this effort feel free to join the discussion. Any helpful information and links are welcome.

So here is the M600 Ludicrous V2 VESC motor controller for Bafang M520/560/600 motors I got:





Connected it to the computer with USB cable and launched VESC Tool application. According the the VESC Toll the hardware revision is Rev5, but the mark on the PCB indicates Rev6.








The PCB is mounted to a custom CNC machined black anodized aluminum cover. The MOSFETs make contact with the cover through a thermal pad. The Bluetooth antenna wire goes through the hole in the cover outside under a 3D printed plastic cup and sealed with black silicone.




The MOSFETs have flat top face with metal housing for contact with cooling surface. By the way the Innotrace controller uses different MOSFETs with cooling directed to the heavy copper PCB.



First thing first. I figured out the SWD connector pins for ST-Link and dumped the original firmware from the STM32 MCU







Here is the firmware bin file I dumped. We need to make sure we save it because of it is our starting point and the gold standard.

Ludicrous v2 m600 2022 Rev5 dumped from the controller 2025-06-18.bin

drive.google.com

The bulk capacitors were lifted and the PCB was cleaned from the white silicone to expose the components for reverse engineering



Took high resolution pictures of both sides of the board and started the project in KiCAD. The STM32 power supply and ST-Link pins are already reverse engineered. Stay tuned!

 

[TPEHAK]

PCB shaping in progress

 

[BikeDev]

Alrighty guys, I think it's time to liberate the Luna M600 Ludicrous V2 VESC motor controller for Bafang M520/560/600 motors.

By the way, if you are interested in VESC motor controller for Bafang M620 it was already liberated here:

Archon X1 Programming Thread (questions and experiences)

Hello, did you try to contact Krasnodar first for assistance? I would contact him first. Maybe ask him when he is planning to make the online server available again (he promised to make it available soon some time ago). If he does not respond here is the link for the bypassed tool with advanced...

forums.electricbikereview.com

Now the time has come and it is the Luna M600 Ludicrous V2 turn.

The subject of reverse engineering is specifically M600-Rev6 2022-12 version of the controller. I believe this is the latest iteration of this controller.

I already did some good progress and I am planning to post the reverse engineering progress reports, pictures and files here. All the reversed files will be publicly shared for your pleasure and you are free to use it however you want. At the end of the day we would need to build the PCBS and test how it works to make sure the unit was reverse engineered properly and just for fun.

If you have something to contribute in to this effort feel free to join the discussion. Any helpful information and links are welcome.

So here is the M600 Ludicrous V2 VESC motor controller for Bafang M520/560/600 motors I got:

View attachment 372010

View attachment 372011

Connected it to the computer with USB cable and launched VESC Tool application. According the the VESC Toll the hardware revision is Rev5, but the mark on the PCB indicates Rev6.

View attachment 372012

View attachment 372013

View attachment 372014


The PCB is mounted to a custom CNC machined black anodized aluminum cover. The MOSFETs make contact with the cover through a thermal pad. The Bluetooth antenna wire goes through the hole in the cover outside under a 3D printed plastic cup and sealed with black silicone.

View attachment 372015


The MOSFETs have flat top face with metal housing for contact with cooling surface. By the way the Innotrace controller uses different MOSFETs with cooling directed to the heavy copper PCB.

View attachment 372016

First thing first. I figured out the SWD connector pins for ST-Link and dumped the original firmware from the STM32 MCU

View attachment 372017

View attachment 372018

View attachment 372019

Here is the firmware bin file I dumped. We need to make sure we save it because of it is our starting point and the gold standard.

Ludicrous v2 m600 2022 Rev5 dumped from the controller 2025-06-18.bin

drive.google.com

The bulk capacitors were lifted and the PCB was cleaned from the white silicone to expose the components for reverse engineering

View attachment 372020

Took high resolution pictures of both sides of the board and started the project in KiCAD. The STM32 power supply and ST-Link pins are already reverse engineered. Stay tuned!

View attachment 372021

View attachment 372022

Klar – hier die Übersetzung:

That’s interesting. But how does it actually capture every layer of the PCB?

 

[TPEHAK]

Klar – hier die Übersetzung:

The top and bottom layers of the PCB can be captured visually double checking with multimeter. The internal layers are build based on the continuity you test with multimeter and PCB design rules after the external layers are complete or almost complete. It is like a puzzle, the more obvious stuff you captured, the easier to figure out the hidden stiff.

 

[BikeDev]

The top and bottom layers of the PCB can be captured visually double checking with multimeter. The internal layers are build based on the continuity you test with multimeter and PCB design rules. It is like a puzzle, the more obvious stuff you captured, the easier to figure out the hidden stiff.

Really cool. Good work.

 

[BikeDev]

Really cool. Good work.

The top and bottom layers of the PCB can be captured visually double checking with multimeter. The internal layers are build based on the continuity you test with multimeter and PCB design rules after the external layers are complete or almost complete. It is like a puzzle, the more obvious stuff you captured, the easier to figure out the hidden stiff.

The hardware schematics are proprietary. Don’t you have any concerns about copying something like that publicly?

 

[TPEHAK]

The hardware schematics are proprietary. Don’t you have any concerns about copying something like that publicly?

That's totally fine. It is also is not proprietary, this is copy of VESC 6 MK5 controller laid on BAFANG m600 shaped board with connected torque sensor. Even If someone wants to fabricate this controller for commercial purpose it is going to be fine, especially it is not going to be possible to make it complete copy, there are some obsolete components on the board have to be replaced by something available for instance.

 

[TPEHAK]

Took some high resolution pictures highlighting the traces for reference for PCB layout



Started placing the high count pins components and connectors to start building the circuitry around them

 

[BikeDev]

That's totally fine. It is also is not proprietary, this is copy of VESC 6 MK5 controller laid on BAFANG m600 shaped board with connected torque sensor. Even If someone wants to fabricate this controller for commercial purpose it is going to be fine, especially it is not going to be possible to make it complete copy, there are some obsolete components on the board have to be replaced by something available for instance.

Then all your reverse-engineering work doesn’t make any sense. The schematics for the VESC-6-MK5 controller are already public. Why go through the trouble of reverse-engineering a copy when the original is available as a schematic?

And the X1 hardware is definitely proprietary.

 

[TPEHAK]

Then all your reverse-engineering work doesn’t make any sense. The schematics for the VESC-6-MK5 controller are already public. Why go through the trouble of reverse-engineering a copy when the original is available as a schematic?

And the X1 hardware is definitely proprietary.

For educational purposes, for repair, for improvement, for curiosity satisfaction, for liberation, for motivating people to get involved in VESC development, for fun. You can use VESC 6 MK5 schematic and firmware and reverse engineer the motor to layup the controller for BAFANG m600, it is just going to be slow, not fun, not effective.

If you want to be completely proprietary, you need to design completely new system with both proprietary firmware and proprietary hardware. There is nothing proprietary about VESC based systems. And there is a purpose the companies like Luna and Innotrace use VESC - saving time and money on development and using the open source idea and the VESC name for marketing purposes, but the trade off for commercially driven development is it is basically open source both, firmware and hardware and anyone can use your development and start competing you.

And to be fair, everything is open source if you know how to read the stuff )

And there is a difference between proprietary design and copyrighted design )

 

[DaDo.Bzz]

Then all your reverse-engineering work doesn’t make any sense. The schematics for the VESC-6-MK5 controller are already public. Why go through the trouble of reverse-engineering a copy when the original is available as a schematic?

And the X1 hardware is definitely proprietary.

You are funny BikeDev! Maybe you dont understand VESC is opensource HW and FW.
If it does not make sense for you, doesnt mean it is useless for everyone!

You even did not notice this is not X1, but Luna V2. X1 did nothing, just buying motors from Innotrance, and these guys there did not respect opensource licence. Maybe you should write and attacking Innotrance!

 

[BikeDev]

You are funny BikeDev! Maybe you dont understand VESC is opensource HW and FW!
If it does not make sense for you, doesnt mean it is useless for everyone!

You even did not notice this is not X1, but Luna V2. X1 did nothing, just buying motors from Innotrance, and these guys there did not respect opensource licence. Maybe you should write and attacking Innotrance!

Most manufacturers (ST, Infineon, TI, etc.) publish "typical application circuits" that are technically optimal or even necessary for their components (e.g., gate driver control, shunt measurement, bootstrap capacitor setup). Because of that, many products will have very similar or even identical schematics, independently of each other. That’s intentional.


Just because hardware looks similar doesn’t mean you can claim “this is based on VESC” or “this is based on an ST application note.” For example, the X1 uses a different DRV and many other components compared to VESC. You can recognize the hardware developer’s signature by the routing of power paths, EMC optimization, spacing, etc. So you have actually checked and compared all that?


I know this is about Luna here. But TPEHAK previously presented his X1 project, and I was referring to both projects.



As for Innotrace, I probably can’t turn to them anymore thanks to Rico. Anyone who has bothered to research beyond the rumor mill knows the company had to file for insolvency after Rico stepped down as managing director, and there are indications that authorities are looking into the case.

VESC uses standard reference circuits from the datasheets and application notes of the components it employs — this is absolutely common practice and also intended.

A few examples:

• The typical bootstrap circuits for gate drivers (e.g. IR2101, DRV8302, or DRV8301).
• Recommended current measurement via shunt resistors, as described in the motor control IC datasheets.
• The ESD and decoupling capacitors around power stages or microcontroller pins.

These “standard circuits” are considered part of the state of the art. The component manufacturers publish them specifically so their products can be used optimally.

What I’m saying is that not every project using these circuits is necessarily based on VESC. None of you can say with certainty whether a board is VESC-based — and thus open source — or not. Simply assuming this and publicly copying a board is pretty reckless.


Honestly, none of this concerns me. I just want to enjoy riding... but I really hate it when people mindlessly repeat whatever they overheard somewhere.

 

[TPEHAK]

Laser cut a template based on the reversed engineered shape of the board to check proper alignment with the holes





Aligned the high resolution images of the PCB faces with the board CAD model



Exported the transformed images to KiCAD. Now each component can be precisely placed and each via can be linked between the top and the bottom faces of the board

 

[TPEHAK]

Slowly but surely the details are growing

 

[TPEHAK]

Is there any way to tell which pins of the Bluetooth module are connected to which pins of the MCU and maybe also somewhere else looking on the Luna firmware and the Luna VESC tool application for the phone source code? I already see there are some differences between the VESC 6 MK5 Bluetooth connections and the Luna controller Bluetooth connections. The Bluetooth PCB pins are hidden under the board I would like to avoid lifting the Bluetooth board.

 

[DaDo.Bzz]

Could be just a mistake in Benjamin scheme. Should have been named PC11_TX and PC12_RX. In 300A scheme version it is OK.

What caught my eyes is SWCLK and SWDIO. Does it mean STM32 in VESC can update firmware of the BT module?
I guess we need only Tx and Rx for BT communication.

Also check 300A VESC scheme. I guess this was the source for Luna as they have also 16S, no?

 

[TPEHAK]

I do not know what VESC and Bluetooth do with those pins.

I will check VESC 300A schematic, that might be closer to the Luna controller.

 

[TPEHAK]

OK, the 12V power source is mostly complete. Still need to figure the circuit controls enabling the buck convertor.







It looks like the Luna controller sends 12V from the buck convertor to the "48V" pin of the Bafang harness connector. I guess the controller uses this voltage to turn itself and the controller ON, for PAS/Toque sensor and for the motor stator temperature sensor (I guess it sends voltage back on the "5V" pin. But does it step it down to 5V or keep it 12V? There is buck convertor in the Bafang CANBUS displays?).

The weird thing is Luna controller has connected battery positive terminal to the pin which correlates with the unmarked pin on the Bafang controller



On another Bafang controller this pin in marked as GND. How is this pin connected to the rest of the Bafang system and what does it do?

 

[TPEHAK]

OK, It looks like I found the 5V source on the controller board, so that voltage is not from the display. So it looks like this controller cares at least 4 voltages for the devices - the battery voltage (up to 100V), 12V, 5V, 3.3V. The battery feeds the MOSFETs, the wiring harness and the 12V buck convertor. 12V feeds the MOSFETS drivers, the wiring harness and the 5V buck convertor. 5V feeds the 3.3V linear voltage regulator and the wiring harness. 3.3V feeds the MCU.

And I guess the display turns the controller ON and OFF using the battery voltage and the transistors circuitry connected to the "Enable" pin on the 12V buck convertor chip just like in Innotrace controller.

 

[TPEHAK]

Does anyone know if Bafang M600 M500 integrated plug PCB was the same for all the the years and all M600 and M500 motors?

I connected the integrated plug PCB to the Luna controller and as expected is caused shortage between the positive and the negative battery terminals!

The pin with the battery positive terminal voltage is connected to the pin on the integrated plug PCB marked as "GND". I am not sure what is going on here but maybe Luna designed this controller for different version of the connectors PCB? Or maybe Luna modifies their motors connectors PCB and probably the wiring harness (maybe the reason is to make it the turning ON and OFF because of they were not able to figure out how to make turning On and OFF function works with the stock BAFANG M600 wiring and display)? That's would explain why they do not sell their controller and only offer it as an upgrade to their motor they sell with their bicycles.

The Green Bike Kit shows exactly the same connectors PCB as I have.

Bafang M600 M500 M510 M560 power plug pcb-Greenbikekit.com BBS, ebike batteries, Bafang M620, Bafang M600, Bafang M500, Bafang M510, KT controller with display-GreenBikeKit.com

Bafang M600 M500 intergraded plug PCB;

www.greenbikekit.com

Well, I guess we will figure out what is going on here.

By the way, during reverse engineering I found a weird resistor on the PCB marked as "22R0" (which means 22 Ohms). But that resistor shown resistance in kOhms. I unsoldered it checked it again and it showed the same big resistance initially and then it started showing unlimited resistance (open). Well, I replaced it by a good 22 Ohm resistor and it might be that resistor connects that GND pin on the connectors PCB and the battery positive terminal. That needs to be investigated. Some weirs stuff is going on here. Is it like an indicator the controller was used or something?




But that thing is fused

 

[DaDo.Bzz]

You are too fast. )

That does not make sense, why is B+ connected to GND over a resistor. They could have gone to GND also on a controller board.
Anyway that pin is also grounded on bafang controller. Unused pins (unlabeled and IO) are grounded. Is it also grounded on Luna?

That connector board could have changed during history, started in first M500/M600. But your board looks untouched.

Turning on is similar as on UARTs. Just other logic, power button is grounding over 500 Ohm resistor. And turning on EN on 12V buck.
Anyway I think also voltage regulators will be fine for 5V and 3.3V. Less components around. Looks like Luna stick to Benjamin scheme.

 

[TPEHAK]

That pin is not grounded on the Luna controller. It becomes grounded only after connecting the Bafang M600 connectors PCB ( because of that pin is connected to the other ground pins on the the connectors PCB) which looks like Luna breaks the trace from that pin on the connectors PCB and uses it for something else.

The battery power pin is already occupied with 12V and it makes sense because of the controller is capable up to 100V and the Bafang display is probably can not handle 100V from the battery (I do not know if it can handle 72V also).

The motor with the controller I got was not assembled by Luna.

 

[TPEHAK]

The 5V buck convertor circuit has been reverse engineered

 

[TPEHAK]

Here is what I suspect Luna does about that mysterious battery power goes through the 22 Ohm resistor and shortened on the ground pin on the M600 motor connectors PCB. They cut the track open from that pin on the motor connectors PCB and solder a wire to that pin and somewhere on an unused pin on a connector. They also probably solder a second wire to another pin on the connectors PCB an on an unused pun on a connector. They connect the switch button (the one on the bicycle frame) to those pins so when you toggle that switch on the frame it completes the circuit and returns the battery voltage back to the controller and straight to the transistors circuit which controls the 12V buck convertor "Enable" pin to turn all the powers and the controller ON.

This explains why Luna sells their own batteries and does not sell the controllers without complete bicycle with motor - it requires modifications of the wiring harness and the connectors PCB.

I think they made this button to operate that circuit



In that sense the Innotrace controller is more plug and play solution because of it does not require any modifications other than replacing the controller and installing more powerful battery, but it operates only up to 60V.

Alternatively you can probably remove that 22 Ohm resistor and solder a jumper somewhere on the Luna controller board to make it constantly turned ON. But in this case you need a battery with smart BMS wired to that switch on the frame which can turn the battery power ON and OFF because of you do not want to keep the controller constantly turned ON.

 

[DaDo.Bzz]

Aaah, so now make sense. It was not original Luna connector board from the pictures.

So that two extra pins are used for turning on controller. Looks like you can not turn on Luna controller with PWR button on original displays. As Benjamin has different logic for turning on/off in his scheme. I am surprised, it is not that difficult to redesign it to support bafang pwr buttons.
I can check on original controller and try to trace bafangs power on/off circuitry.

To display voltage. Displays are turning on at 15V(dpc245). Some also less (dpc181 at 5V). Here is a wrong design and bafang is sending full battery voltage to display. It should have been on standard 5V.
So again will be some Luna modification if you measuring only 12V at 48V pin. Display would not power up.

Not sure how you mean it with smart batteries, powering on/off Luna controller does not have anything with bms communication (I can be wrong though). It would be a complication to code also some battery authentication. Also powering on bms is no needed. That original button on E10 bikes was for switching off bms, thats true. It will shut output and going to deep sleep. When you leave battery just rest, bmses going usually to sleep (if used microcomputer). I did short these pins inside battery, was doing just harm.