• Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
    Can you donate? Please see our fundraising page. Thank you!

Luna M600 Ludicrous V2 reverse engineering and firmware making

I used it to check if the MCU obtains the quadrature signal because of I do not see any other interface in the VESC Tool would allow it. And it looks like it does not obtain the PAS encoder signal or does not process it properly. Do you know how to check if the MCU obtains the quadrature signals? Or maybe there is an enhanced PAS application for the VESC Tool somebody coded allows to visualize the signals?

I guess there is no reason to do anything with the code before making sure it obtains the signals and there are no electrical issues because of if there are electrical issues it will cause just more confusion.
 
Last edited:
As I already said: start a debug session from the CubeIDE and set breakpoints to the interested code parts. You have to start the openOCD debugger with "-rtos auto" to debug the VESC, as it is a multithreading application.

You can check the quadrature signals from the sensor simply with a scope or with a multimeter. But there should be no difference to the M600.

Don't try to get the motor run on the workbench without real pedaling, as it is extremely difficult to get the "right" signals "by hand". Therefore I've introduced the torquesensor emulator a few weeks ago.
 
Last edited:
Yeah, that sounds complicated. I guess I will need to figure out the connections for this and other stuff. I was thinking maybe there is a way to diagnose it quick and easy without diving into this rabbit hole.

I have a Bafang M620 UART torque sensor laying around, it looks like it has the same pinout, but different encoder sensor. If that thing will work the issue is certainly the PAS encoder circuits are not suitable for the new sensor.

If that thing will not work then we have to get back to the drawing board with our trusty multimeter.
 
Last edited:
It looks like the lines 188 and 189 in the "app_pas.c" file in the VESC firmware is what configures the pins PA6 and PA7 responsible for receiving the quadrature signals from the PAS sensor. It looks like they are configured to actively maintain condition 1 on them. And if the optical encoder on the Bafang M560RS switches between voltage and float signal then of cause the conditions of the pins do not switch between 0 and 1 when we rotate the crank arms, it always stay 1 and the VESC algorithm thinks the RPM (cadence) is 0.

I guess we can try to configure them to actively maintain 0 on them writing something like this in those lines instead

Code:
palSetPadMode(HW_PAS1_PORT, HW_PAS1_PIN, PAL_MODE_INPUT_PULLDOWN);
palSetPadMode(HW_PAS2_PORT, HW_PAS2_PIN, PAL_MODE_INPUT_PULLDOWN);

And also unsolder the 10K resistors connect the signal lines and +5V

1765584719616.png
 
Last edited:
I guess we can try to configure them to actively maintain 0 on them writing something like this in those lines instead
You should use no pullup or pulldown at all, just let the sensor drive the logic state of the pin.
For a normal Hallsensor PAS you would need the pullup. My experience from my early tests with the Bafang sensor several years ago, was the same, the sensor was not able to pull the signal down against the pullup resistor.

Code:
palSetPadMode(HW_PAS1_PORT, HW_PAS1_PIN, PAL_MODE_INPUT);

 
We are getting closer to solving the misery guys! I managed to make the motor spins in PAS/cadence mode with M600 PAS quadrature sensor (using just the quadrature sensor wires). I also measured the voltages on both wires of the quadrature signals of the M600 and M560RS sensors on the sensors connectors side (not on the MCU pins) and they are certainly different.

The voltages on M560RS PAS sensor connector switch between 1.4V and 3.6V on both wires of the sensor connector connected to the PA6 and PA7 pins of the MCU with a little offset between switching moments (like very little, I am not sure it is big enough for the PAS algorithm to detect the offset and rotation direction, but maybe it is OK). It does not trigger the motor rotation in PAS/cadence mode of cause.

Those signals also look more like duplicated signals of cadence for safety rather than quadrature signal and maybe Bafang M560RS defines the rotation direction somehow with another wire, but maybe it is just my impression because of such little offset between the signals.

1765669430258.png

The voltages on the M600 PAS sensor connector switch between 0V and 4.5V on circuit connected to the PA6 pin of the MCU and between around -0.1V and 0.1V on the circuit connected to the PA7 pin of the MCU which is weird but it makes the motor spin and it certainly somehow defines the direction because of I can spin it only one direction and I can switch the spinning direction selecting different pedals rotation direction mode in the VESC Tool in the PAS application.

1765669826504.png
1765670538207.png
1765670570805.png

So it looks like we need to unsolder these two resistors first

1765672627522.png
 
Last edited:
The moment of truth is cumming guys! The resistors have been unsoldered from the PCB! We are getting closer!

1765676856413.png

1765675298478.png
 
We did it guys! The new Bafang M560RS optical encoder PAS quadrature signal sensor works and does it nice and smooth like a butter!

So yeah, it was different PAS optical rotary encoder sensor signal nature not pulling down hard enough required removing the 10K +5V pull-up resistors.

I did not change the PAS pins modes in the firmware so the PAS pins are still in pull-up mode and since it works we are probably better to keep them in this mode without switching to float mode for safety reason to prevent false cadence reading in case of the PAS encoder malfunction.

Now we have both signals working, the torque sensor and the cadence sensor! Now the only last thing we need to figure out is how to blend them together in the firmware.

 
Last edited:
Obviously, you can't resist using the VESC logo. Even though you've now changed it to "SECS", using the font and the obvious risk of confusion is not okay!
 
That is NASA font and style, isn't it? Luna uses it too. You think people will believe NASA does it? Like an aerospace grade motor controller? That would be cool!

But that's OK, we blurred it for censoring purpose, so we are good, neither VESC or NASA will have issues with it. And the forum administration can ask Benjamin Vedder just to be sure.
 
Last edited:
Speaking about the controller logo. Since Benjamin Vedder and VESC Labs guys do not want to be credited, how about INNOTRACE logo?

We can call this controller INNOTRACE M560 Open. What do you think guys?

This is still recognizable logo can attract people. Plus Krasnodar and Innotrace deserve to be credited because of they are the pioneers in this mid drive electric bicycle fully integrated aftermarket motor controllers. They were the only one who dared to prove this amazing concept! Hell, all these controllers we reversed and designed would not even exist without Krasnodar Jandrijevic and INNOTRACE company. Regardless the controversies around the INNOTRACE company and Krasnodar Jandrijevic they are the only one why we have all these nice open source VESC based controllers. They created the best motor controller ever for the best mid drive motor ever and this inspired LUNA controllers, the whole generation of young engineers like Marcos, and all these controllers we reversed and designed, and this is going to be our way to thank them, the INNORACE guys are legends!

1765743002597.png
 
Last edited:
Holy cow! It looks like we got a new kid on the block! That thing looks amazing!

And it also works with higher voltages than Innotrace! And the price is like twice more competitive than the EXFORCE EX8 620 MAX Controller! And it work with the open source VESC firmware! It looks like now this is the best mid drive controller on the market!


1765768235863.png
 
Last edited:
Speaking about the controller logo. Since Benjamin Vedder and VESC Labs guys do not want to be credited, how about INNOTRACE logo?

We can call this controller INNOTRACE M560 Open. What do you think guys?

This is still recognizable logo can attract people. Plus Krasnodar and Innotrace deserve to be credited because of they are the pioneers in this mid drive electric bicycle fully integrated aftermarket motor controllers. They were the only one who dared to prove this amazing concept! Hell, all these controllers we reversed and designed would not even exist without Krasnodar Jandrijevic and INNOTRACE company. Regardless the controversies around the INNOTRACE company and Krasnodar Jandrijevic they are the only one why we have all these nice open source VESC based controllers. They created the best motor controller ever for the best mid drive motor ever and this inspired LUNA controllers, the whole generation of young engineers like Marcos, and all these controllers we reversed and designed, and this is going to be our way to thank them, the INNORACE guys are legends!

View attachment 382104
INNOTRACE never had a controller for the Bafang M560.
INNOTRACE controllers are not VESC-based and were never open source.
LUNA will most likely not appreciate this either: you are copying their hardware and putting a third-party logo on it.
Why not just use your own name, for example TESC?
 
INNOTRACE never had a controller for the Bafang M560.
INNOTRACE controllers are not VESC-based and were never open source.
LUNA will most likely not appreciate this either: you are copying their hardware and putting a third-party logo on it.
Why not just use your own name, for example TESC?
How do you know it is not VESC based? Did you analyze it? As far as I know the VESC guys analyzed it and completely reverse engineered it and claim it is VESC based. I am sure they know what they are talking about if they were able to reverse engineer it. They even were able to create VESC firmware for the INNOTRCE controller!

I have no such privilege to post my own name on it. Only a few companies and individuals like INNOTRACE, VESC, Marcos, LUNA and Krasnodar have such privilege. You need to deserve it. VESC, Marcos and LUNA gave up this privilege, so now it is INNOTRACE and Krasnodar lucky day!

Alternatively we can call this controller EXFORCE M560 Open. Yes, nobody knows about the EXFORCE controllers and it is not going to be as attractive and INNOTRACE name, but doing so we will thank the former INNOTRACE guys and Krasnodar for their work, it looks like they work in EXFORCE now. And it also looks like EXFORCE has a controller for M560


What do you think guys? I am sure Karsnodar will appreciate it because it will advertise his new company and his products (and it looks like he needs some advertisement because of there are still not a single review of his new controllers), and doing so we will thank him for creating INNORACE controller!

UPDATE: Krasnodar asked us to remove this picture, but I am sure disclosure is enough to make him happy:

DISCLOSURE: THE PICTURE BELOW IN NOT A REAL PRODUCT AND NOT AN EXFORCE PRODUCT AND SERVES AS AN EXAMPLE OF HOW THIS ITEM WOULD LOOK LIKE IF KRASNODAR WOULD ALLOW US TO USE HIS COMPANY LOGO. WE ARE NOT PLANNING TO MARK THIS MOTOR CONTROLLER WITH EXFORCE LOGO AS KRASNODAR REQUESTED.


UPDATE: Krasnodar was still not not happy with the disclosure, so the picture with EXFORCE logo was removed in a good will and in hope Krasnodar will join the discussion and clarify his concerns and situation with the INNOTRACE firmware. The picture did not violate anything and was completely in compliance with fair use doctrine.

1766146667475.png
 
Last edited:
Last edited:
Why should they be happy to be named in a VESC based product, if they always pronounce, that they don't use the VESC hard- and/or firmware? It will only cause additional trouble for them and confusion for the customers.

Because of it looks like nobody knows about EXFORCE and they desperately need advertisement. And we will name the controller EXFORCE M560 Open, the word "Open" clearly separates this controller from other EXFORCE products standing for the open source nature of this entity. EXFORCE are not going to call other their products "Open".

Basically what Krasnodar is stating in this post is they did use VESC firmware, but they used it for internal development of the INNOTRACE controller and have no obligations to share the VESC firmware they created for the internal usage which I guess is completely legal.

To be fair LUNA and Marcos have kinda similar crooked philosophy. They refuse to provide simplest support on their controller even if you own their controller but did not pay them $5000. So yeah, both entities are kinda ugly.
 
Last edited:
You are cloning a Luna controller, brand it with Exforce and think this is a good advertisement? For whom? :unsure:
This forum with it's five users will do nothing.
No critical mass here to start a hype ;)
That Luna doesn't support you is understandable, as you are involved in all this Innotrace/Exforce stuff somehow obviously. :ROFLMAO:

The thing, that I can't understand at all, why people are paying hundreds of Dollars/Euros for a controller, that costs 20€ in manufacturing and can't do anything better than cheap Chinese controllers.🤷‍♂️
 
Last edited:
You are cloning a Luna controller, brand it with Exforce and think this is a good advertisement? For whom? :unsure:
I mean probably more suitable term here is PR. So let's call it PR for EXFORCE.

The thing, that I can't understand at all, why people are paying hundreds of Dollars/Euros for a controller, that costs 20€ in manufacturing and can't do anything better than cheap Chinese controllers.🤷‍♂️
The reason is the INNOTRACE, LUNA, EXFORCE and PulseDrive controllers are completely integrated plug and play controllers for popular mid drive motors paired with good looking frames (and there is a lot of different cool looking frames for those motors) offering more performance. This is a unique combination of properties people want but no one offers and it allows them to demand such hefty money.
 
Last edited:
offering more performance
No, nothing settable for individual ride modes. Just a very basic implementation of bicycle features. Only stupid power. Completely boring. If I want to ride a motor bike, I ride a motor bike with registration and insurance. Not a bicycle on dopamine, that can't be used on public roads legally.. 🤷‍♂️
 
Last edited:
No, nothing settable for individual ride modes. Just a very basic implementation of bicycle features. Only stupid power. Completely boring. If I want to ride a motor bike, I ride a motor bike, not bicycle on dopamine. 🤷‍♂️
Well, I am happy with what INNOTRACE and Luna controllers offer. It looks like Luna has a custom user interface in the VESC Application for individual tuning (I did not try it because of I do not care, but it exists). It also looks like Krasnodar evolves his EXFORCE controllers offering individual settings settable with a mobile application. Maybe PulseDrive will offer something similar in the future, they are new guys on this market.

 
There is whole dedicated website about that new controller! And it looks like there are at least 3 lucky guys who already use it if the website does not lie.

What is also weird www.innotrace.de website reroutes to the www.pulsedrive.de website

So who is who? And who designed that PulseDrive controller? Krasnodar?

 
Last edited:
We did it guys! Both cadence sensor and torque sensor work together nicely and properly! Thanks to everyone who participated in this enormous effort!

It requires changing two lines

Line 358 in "app_adc.c" file (disabling the brake function from the ADC2)

and Line 411 in "hw_luna_m600_core.c file (scaling the torque sensor voltage to the range between 0 and 1)


We still need to figure the firmware for the brake, but that is more complicated and maybe not necessary and we can live without it for now.

By the way, we do not need to swap the cadence sensor signal lines, those are correct, so keep them as is and just do not solder these 2 resistors

1765865902520.png
 
Last edited:
So who is who?
You can find the name Rico Czernig, if you look at the company information. So same old Mafia. But this time he uses the VESC© directly, so he doesn't deny using VESC any longer. I don't know if he has published his code, how he makes the torquesensor work. If he has not published it, he still violates the open source rules... 🤷‍♂️

 
Last edited:
I'm really glad that there's finally progress in this area. It's been mentioned for years that a VESC solution would be available soon. I've been using the Innotrace for a long time and now the M560 Exforce for 1.5 years, and I'm simply happy. I think your work is fantastic, and it's great that things are finally moving forward in this area. I just find it really unfortunate that we users are immediately excluded from our discussions here and everywhere else when we mention the names Innotrace, Exforce, Luna, VESC, etc. The people who are fighting over whether it's VESC or not should please keep it to themselves and leave us in peace to have our discussions. And again, before I get kicked or banned again, I am not an employee of Innotrace, Luna, Exforce, or anything similar.
 
So same old Mafia. But this time he uses the VESC© directly, so he doesn't deny using VESC any longer.


Yeah, why would they deny it? VESC compatibility is basically a selling point nowadays. Why would I purchase an unknown EXFORCE M620 controller with locked firmware or locked INNOTRACE controller if I can purchase PulseDrive with VESC on the board and open settings and for cheaper price?

I feel like they created EXFORCE just to deter the attention from the INNOTRCE drama and get away from the VESC wrath. I can not explain such absurdly high prices of the EXFORCE controllers other than they do not care if they will sell it and had plans to release those controller with VESC compatibility later for more attractive price. And then magically new PulseDrive controller appeared with more attractive price and popular VESC ecosystem on the board.

I am even not sure if that EXFORCE M620 controller is real, the pictures on that website look strange, nothing demonstrates those controllers clearly for some reason.
 
Last edited:
Back
Top