Luna M600 Ludicrous V2 reverse engineering and firmware making

[harrisonpatm]

There are lots of parts of this thread that are useful for people interested in the topic.

Multiple pages of he-said she-said, useless arguments regarding copyright, moving into personal attacks... this has gotten way off the rails.

Bring it back on topic or we can lock the thread for a week to cool it off.

 

[TPEHAK]

There are lots of parts of this thread that are useful for people interested in the topic.

Multiple pages of he-said she-said, useless arguments regarding copyright, moving into personal attacks... this has gotten way off the rails.

Bring it back on topic or we can lock the thread for a week to cool it off.

Well, we also use this topic to try to make Krasnodar to share the INNOTRACE X1 controller binaries files and necessary programs to setup the controller to keep our motor controllers alive. If this topic will be closed we will likely have no such chance. Krasnodar does not want to share the files and maybe public opinion will make him to reconsider his position. This topic serves multiple purposes.

 

[TPEHAK]

There are lots of parts of this thread that are useful for people interested in the topic.

Multiple pages of he-said she-said, useless arguments regarding copyright, moving into personal attacks... this has gotten way off the rails.

Bring it back on topic or we can lock the thread for a week to cool it off.

By the way, can we please extract this topic from the dumpster since neptronix already censored it? We will use INNOTRACE logo on that controller instead of VESC Labs. Krasnodar has no issues with we will use INNOTRACE name and logo on that controller

VESC for Bafang M560

Now you're just making people who support you mad. 😞

endless-sphere.com

 

[Exma]

There are lots of parts of this thread that are useful for people interested in the topic.

Multiple pages of he-said she-said, useless arguments regarding copyright, moving into personal attacks... this has gotten way off the rails.

Bring it back on topic or we can lock the thread for a week to cool it off.

Thanks for stepping in. As I said, I’m out. Honestly, more than enough has been said already.

 

[TPEHAK]

I hope moderators will correct me if this is not an appropriate question. I know, admins and moderators probably do not care too much about the people have problems with their INNOTRACE motor controllers and want to see plain clean looking threads on this forum without drama strictly follow the topics. But this thread is an opportunity for us the people who was unlucky enough to deal with the INNOTRACE controllers and INNOTRACE company problems to resolve it, so I hope the moderators and admins will be on our side and will help us to resolve the issue with not available firmware and setup programs for fixing the INNORACE controllers were abandoned by Krasnodar and/or Rico and none of them shares the binaries and programs.

So I hope admins and moderators (and maybe some people who is annoyed we have to deal with Krasnodar and Rico business here on the forum publicly) will appreciate all this hard work we put in reversing and designing all these controllers for the public pleasure and will give us an opportunity to talk publicly here with Krasnodar and/or Rico and/or whoever tries to represent them like Exma does and let the topic goes out of the rail (especially all the work here is basically done). This is a little payoff we ask for.

Ladies and gentlemens, may I have your attention please

INNOTRACE controllers are not VESC-based and were never open source.

Yes, INNOTRACE is not open source, but it is VESC-based according to our observations, which is a violation being VESC-based but not being open source.

Can you please explain us in exact technical terms and processes why the INNOTRACE X1 firmware is compatible with the VESC Tool application? I also hope stancecoke will comment here too because of it looks like he is a code guru and is somewhat familiar with VESC firmware and software.

Here is the link with the process of how to connect the INNOTRACE X1 firmware to the VESC Tool and make adjustments to the INNOTRACE X1 motor controller through the VESC Tool and a purposeful built in communication code message which looks like an attempt to protect the INNOTRACE X1 firmware from unauthorized connection to the VESC Tool application to hide the fact of being VESC-based firmware

Archon X1 Programming Thread (questions and experiences)

I had same thoughts before hacked x1tool tried to update my controller. meanwhile I contacted the developer what to do with my firmware update message. guess what: he told me that this x1tool version can't update any firmare online at all. this confirmed my suspicion. so trusting WW would be...

forums.electricbikereview.com

The same process is explored, exposed and demonstrated by the VESC Team developers on the VESC Discord channel in the INNOTRACE X1 reverse engineering threat almost at the very beginning of the threat.

Discord - Group Chat That’s All Fun & Games

Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.

discord.com

According to this public statements made by EXFORCE Krasnodar and Rico used this firmware for the internal development.



According to the Rico public statement he was not aware this firmware is VESC-based.



Unfortunately (or maybe fortunately for us, guys) internal usage of the VESC-based firmware for developing and/or testing the hardware they distributed later on commercial basis (even if there was no intention to flash the VESC-based firmware they used for the internal development and/or tests the commercially distributed hardware) obligates Krasnodar (if both Rico and Krasnodar statements are true, and even if only Krasnodar/EXFORCE statement is true) to share that firmware and the source code publicly.

There are probably going to be more technical questions about the INNOTRACE and VESC controllers schematics, firmware, software and periphery but let's start from this for beginning.

While we do hope Krasnodar will stick with this obligation, here is what we offer. Krasnodar and/or Rico shares the firmware binaries, the setup software and the setup instructions for the INNOTRACE X1 controller with the people on this forum. The INNOTRACE X1 owners obtain the ability to repair and setup their controllers. The VESC Team obtains the ability to check if what Krasnodar claims is true. Krasnodar obtains an ability to confirm his firmware is not VESC-based and helps the INNOTRACE X1 owners to obtain the ability to repair and setup their controllers. Everyone wins and everybody is happy!

End please do not bring "it is his IP" argument and he has the right to not share the firmware and setup software leaving the people without ability to fix the controller they abandoned ever again - INNOTRACE company was well paid for those controllers by their customers and what we demand is more than fair, especially after all we've come through because of the people ran the INNOTRACE company fault.

Krasnodar and/or Rico, it is great it is finally come to your attention! You are both welcome to comment the situation here publicly in this thread and engage in the conversation to clarify/oppose/confirm your/our statements if something was represented appropriately/inappropriately and/or logically/not logically. We are ready to reconsider our opinion if you can clarify if this is not what it looks like.

Ideally we also need Benjamin Vedder here in the discussion to disclose publicly what exactly EXFORCE/Krasnodar responded to him according to the EXFORCE public statement (if his response to the VESC Team differs from what Krasnodar publicly posted) to have an ability to see the situation in more broad range if Krasnodar/EXFORCE will not be willing to disclose his/their response and to start checking what is true and what is not true and to understand the VESC Team role/position in this situation.

 

[Exma]

I hope moderators will correct me if this is not an appropriate question. I know, admins and moderators probably do not care too much about the people have problems with their INNOTRACE motor controllers and want to see plain clean looking threads on this forum without drama strictly follow the topics. But this thread is an opportunity for us the people who was unlucky enough to deal with the INNOTRACE controllers and INNOTRACE company problems to resolve it, so I hope the moderators and admins will be on our side and will help us to resolve the issue with not available firmware and setup programs for fixing the INNORACE controllers were abandoned by Krasnodar and/or Rico and none of them shares the binaries and programs.

So I hope admins and moderators (and maybe some people who is annoyed we have to deal with Krasnodar and Rico business here on the forum publicly) will appreciate all this hard work we put in reversing and designing all these controllers for the public pleasure and will give us an opportunity to talk publicly here with Krasnodar and/or Rico and/or whoever tries to represent them like Exma does and let the topic goes out of the rail (especially all the work here is basically done). This is a little payoff we ask for.

Ladies and gentlemens, may I have your attention please



Yes, INNOTRACE is not open source, but it is VESC-based according to our observations, which is a violation being VESC-based but not being open source.

Can you please explain us in exact technical terms and processes why the INNOTRACE X1 firmware is compatible with the VESC Tool application? I also hope stancecoke will comment here too because of it looks like he is a code guru and is somewhat familiar with VESC firmware and software.

Here is the link with the process of how to connect the INNOTRACE X1 firmware to the VESC Tool and make adjustments to the INNOTRACE X1 motor controller through the VESC Tool and a purposeful built in communication code message which looks like an attempt to protect the INNOTRACE X1 firmware from unauthorized connection to the VESC Tool application to hide the fact of being VESC-based firmware

Archon X1 Programming Thread (questions and experiences)

I had same thoughts before hacked x1tool tried to update my controller. meanwhile I contacted the developer what to do with my firmware update message. guess what: he told me that this x1tool version can't update any firmare online at all. this confirmed my suspicion. so trusting WW would be...

forums.electricbikereview.com

The same process is explored, exposed and demonstrated by the VESC Team developers on the VESC Discord channel in the INNOTRACE X1 reverse engineering threat almost at the very beginning of the threat.

Discord - Group Chat That’s All Fun & Games

Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.

discord.com

According to this public statements made by EXFORCE Krasnodar and Rico used this firmware for the internal development.

View attachment 382299

According to the Rico public statement he was not aware this firmware is VESC-based.

View attachment 382300

Unfortunately (or maybe fortunately for us, guys) internal usage of the VESC-based firmware for developing and/or testing the hardware they distributed later on commercial basis (even if there was no intention to flash the VESC-based firmware they used for the internal development and/or tests the commercially distributed hardware) obligates Krasnodar (if both Rico and Krasnodar statements are true, and even if only Krasnodar/EXFORCE statement is true) to share that firmware and the source code publicly.

There are probably going to be more technical questions about the INNOTRACE and VESC controllers schematics, firmware, software and periphery but let's start from this for beginning.

While we do hope Krasnodar will stick with this obligation, here is what we offer. Krasnodar and/or Rico shares the firmware binaries, the setup software and the setup instructions for the INNOTRACE X1 controller with the people on this forum. The INNOTRACE X1 owners obtain the ability to repair and setup their controllers. The VESC Team obtains the ability to check if what Krasnodar claims is true. Krasnodar obtains an ability to confirm his firmware is not VESC-based and helps the INNOTRACE X1 owners to obtain the ability to repair and setup their controllers. Everyone wins and everybody is happy!

End please do not bring "it is his IP" argument and he has the right to not share the firmware and setup software leaving the people without ability to fix the controller they abandoned ever again - INNOTRACE company was well paid for those controllers by their customers and what we demand is more than fair, especially after all we've come through because of the people ran the INNOTRACE company fault.

Krasnodar and/or Rico, it is great it is finally come to your attention! You are both welcome to comment the situation here publicly in this thread and engage in the conversation to clarify/oppose/confirm your/our statements if something was represented appropriately/inappropriately and/or logically/not logically. We are ready to reconsider our opinion if you can clarify if this is not what it looks like.

Ideally we also need Benjamin Vedder here in the discussion to disclose publicly what exactly EXFORCE/Krasnodar responded to him according to the EXFORCE public statement (if his response to the VESC Team differs from what Krasnodar publicly posted) to have an ability to see the situation in more broad range if Krasnodar/EXFORCE will not be willing to disclose his/their response and to start checking what is true and what is not true and to understand the VESC Team role/position in this situation.

Everything that is needed can be found on github, including an explanation. I have no idea what this nonsense here is supposed to be. Links have already been shared multiple times in the forum.

It only took me 10 minutes to get my motor running with it.

 

[TPEHAK]

Everything that is needed can be found on github, including an explanation. I have no idea what this nonsense here is supposed to be. Links have already been shared multiple times in the forum.

It only took me 10 minutes to get my motor running with it.

Please spend another 5 minutes and dump the binary image from the STM32 MCU from the properly working motor and properly working display with INNOTRACE controller and post it here. Thank you for you hassle.

If what you got is completely functional properly working firmware the people will thank you.

 

[Exma]

Please spend another 5 minutes and dump the binary image from the STM32 MCU from the properly working motor and properly working display with INNOTRACE controller and post it here. Thank you for you hassle.

If what you got is completely functional properly working firmware the people will thank you.

Sorry, but if you can’t manage it yourself via github, it’s better to just leave it alone.

 

[TPEHAK]

Sorry, but if you can’t manage it yourself via github, it’s better to just leave it alone.

So you spent 10 minutes just to report you can not spend another 5 minutes to dump the firmware for the people and blame me for this? Sure, we believe you (no).

So, please, start answering the questions and concerns I posted.

 

[Exma]

So you spent 10 minutes just to report you can not spend another 5 minutes to dump the firmware for the people and blame me for this? Sure, we believe you (no).

So, please, start answering the questions and concerns I posted.

And so you spent months copying the controller, only to fail at copy-and-paste on github? Open source clearly isn’t for you. You’d be better off buying a finished product.

 

[TPEHAK]

And so you spent months copying the controller, only to fail at copy-and-paste on github? Open source clearly isn’t for you. You’d be better off buying a finished product.

Yes, we still need the ability to repair our INNOTRACE controllers.

 

[TPEHAK]

Sorry, but if you can’t manage it yourself via github, it’s better to just leave it alone.

I guess you are talking about the open source VESC firmware you flashed on your INNOTRACE controller since you are talking about github and the links posted here.

You also claims Krasmodar flashed his firmware on your controller here

Luna M600 Ludicrous V2 reverse engineering and firmware making

OK, here is an update guys. Krasnodar told me he does not care if we will use INNOTRACE name. That is a great news! Now INNOTRACE is ours and we are about to bring it back baby! And the e-bikes god won't burn us with a fire! I also asked Krasnodar to make a statement here to stop all the...

endless-sphere.com

What we just observed is you can flash your Innotrace controller with VESC firmware and Krasnodar can flash his firmware on the INNOTRACE controller over the VESC firmware.

This process requires using FTDI chip USB to serial adapter (a cheap programming cable INNOTRACE sold for overprice) connected to the display port of the BAFANG M620 harness and bootloader flashed on the STM32.

What you just exposed to us is Krasnodar flashed your INNOTRACE controller with VESC-based firmware he claims is not VESC-based. The firmware Krasnodar flashed on your controller must be VESC-based in order to be able to update the controller firmware with VESC firmware on the STM32 because of the bootloader on the STM32 chip must be VESC-Based to be able to do so.

It looks like we just got another prove Krasnodar has and uses VESC-compatible firmware, guys! Thank you for the tips.

I am sure the VESC Team guys can comment here too.

Here is the wiring diagrams and circuits chain and connections for the programming device to the STM32 MCU on the INNOTRACE controller in support of what we just investigated.

 

[TPEHAK]

So now let's put a little logic here now. Exma and Krasnodar claim Krasnodar supports the INNOTRACE users and flashes the new firmware over the firmware they used for "internal usage" and that firmware for "internal usage only" is VESC-based and was distributed by Rico without Krasnodar approval. So because of Krasnodar is able to update the firmware over the firmware with VESC-bootloader means even the new firmware in Krasnodar possession is VESC-based.

Please correct me if this conclusion in not correct.

 

[amberwolf]

As I said, I’m out. Honestly, more than enough has been said already.

You don't seem "out", given your further replies after this.... :?

 

[TPEHAK]

While we are still waiting here Krasnodar response, I offer you guys a little challenge: What a single question to Krasnodar can prove he has VESC-compatible INNOTRACE X1 firmware?

Hint: regardless of the answer we got it.

This question is very simple and casual, you do not even need to know embedded software programming and electrical engineering and anyone who communicates with Krasnodar including Exma can ask this question to him and confirm our observations.

 

[TPEHAK]

While we are still waiting here hopefully exciding news with the right decision from Krasnodar we are getting excitingly close to the first real test of our new INNOTRACE M560 controller!

Installing 0.5mm soft thermal pad






Installing the INNOTRACE controller in the Markhor 560RS motor



The motor is installed on the bicycle with 16S 60V battery and set up to 60V 50A 3000W Luna tune with the VESC Express dongle wirelessly and spins nice and smooth!

 

[TPEHAK]

Guys, we need the final logo review before posting the updated INNOTRACE M560 controller and firmware files, we do not want to redo this over again.

stancecoke, mxlemming, DaDo.Bzz, marcos, rezystor1990, A-DamW, neptronix, phobos and others are credited for the hints, tips and stuff, probably the best use for the freed space

 

[TPEHAK]

Took it for a spin today and it works!



This is probably more motor property than controller, but the thermal performance is better! After the same distance and even at faster speed the M560RS motor is significantly less hot than M600 on the touch (I did not connect the VESC Express and did not check the temperature sensors though) and I can even hold my hand on the motor case without burning my hand. It is probably because of M560RS uses thicker wires for the windings and also uses potting.

The controller side of the motor is cold and feels like environment temperature on the touch. So the controller is more cabable than enough.

The power is probably pretty close to INNOTRACE X1 with M620, at least I was able to achieve close to Innotrace X1 M620 speed on my benchmark uphill section with throttle.

The throttle works great.

The only issue is driving the motor torque with torque sensor directly without processing the signal with filters and delays feels awful as expected. Motor cuts off each half stroke (or provides nearly 0 support) and you decelerate due to wind resistance or gravity if you go uphill each half of the stroke. The higher speed or the steeper uphill the more awful it feels. Basically the motor power and wing resistance/gravity constantly jerk you back and forth. It is not bad at low power and you feel it is not so bad on acoustic bicycle but imagine the your leg input precisely and instantly amplified by the motor and jerks you between nearly 0 and 3000W each half stroke. It feels not extremely bad but quite awful.

So we certainly need to figure where in the firmware Luna filters the torque signal and how blends it with the cadence rather than driving the motor power directly.

I already posted here how the torque signal and motor power output should be related to each other

What should be user settable on a torquesensor based EBike system?

Hi, the Open Source Firmware for the Bafang CAN bus controllers is at a point, where I start thinking, which functions should be user settable. Of course, you can implement any gimmick, if you are able to write the necessary code and compile the firmware yourself, but my experience with other...

endless-sphere.com

Bad is what we have. Best is what we want. So we need to figure out the Luna filtering algorithm and delays, or at least the line in the firmware code where it inputs the raw torque sensor torque value.







There should not be delay when you increase the torque on the crank arms but there certainly should be delay or slow not linear decay when you decrease the torque on the crank arms.

According to AI we should implement asymmetric decay

 

[TPEHAK]

There is the "map" function for that. I would pack the steps to read in, normalize, apply a deadband and filter in the function that is called by the PAS app. The code is just an example, of course, you have to declare all the needed variables in the top of the luna_m600_display.c first....

/**
 * Get torque applied to the crank arms
 *
 * @return
 * 0.0 for no torque applied, 1.0 for maximum torque applied
 */
float luna_canbus_get_PAS_torque(void){
                float normalized_torque_sensor_output = utils_map((float)ADC_VOLTS(ADC_IND_EXT2), (float)torque_offset_voltage, (float)torque_offset_voltage, 0.0, 1.0);
                utils_truncate_number(&normalized_torque_sensor_output, 0.0, 1.0);
                utils_deadband(&normalized_torque_sensor_output, torque_sensor_deadband, 1.0);
                UTILS_LP_FAST(torque_sensor_output_filtered, normalized_torque_sensor_output, 0.1);
                return torque_sensor_output_filtered;
            }

If I print in the line 638 of the luna_m600_display.c file this (0.75 is slightly above the lowest voltage of the torque sensor and 1.5 is voltage of the torque sensor should match the maximum motor power):

float normalized_torque_sensor_output = utils_map((float)ADC_VOLTS(ADC_IND_EXT2), 0.75, 1.5, 0.0, 1.0);

and also keep the line 411 of the hw_luna_m600_core.c file as original like this:

return luna_canbus_get_PAS_torque();

and also the line 358 of the app_adc.c file is outcomented like this:

// pwr -= brake;

The torque sensor does nor work.

But it looks like the line 638 of the luna_m600_display.c file is where it inputs the raw torque sensor value in the Luna firmware.

 

[TPEHAK]

I think instead of digging into the VESC firmware we can make it quick and dirty and insert the asymmetric ramping/decay algorithm instead of the line 411 of the hw_luna_m600_core.c file. It looks like it works good, just need to tune the coefficients. Probably not very safe but we will see.

So in case of pushing the pedals harder the torque will be instantly and linearly amplified for proper control. In case of releasing the pressure on the pedals it will slowly decay avoiding jerkiness between the pedal strokes.

We can probably complicate the algorithm including cadence and additional rules depending on cadence but we will see how it feels. Currently cadence works more like just a safety feature check before running the torque control algorithm.

        static float smoothed_torque = 0.0f;

        float raw_torque = (app_adc_get_voltage2() - 0.75f) * 1.33f;
        if (raw_torque < 0) raw_torque = 0;

        if (raw_torque > smoothed_torque) {
            smoothed_torque += 1.0f * (raw_torque - smoothed_torque);
        } else {
            smoothed_torque += 0.010f * (raw_torque - smoothed_torque);
        }
        return smoothed_torque;

 

[TPEHAK]

The M560/510 controller files have been updated and published! I started the new thread about the INNOTRACE M560 motor controller here

VESC based INNOTRACE motor controller for Bafang M560/510

Today is the day guys! Now INNOTRACE belongs to the people! It is like a Christmas miracle! The PCB and the firmware have been updated. I recommend to revive the old thread and include this into the first post, but it is up to you how you want to manage it...

endless-sphere.com

We will leave this thread to give Krasnodar an opportunity for response here, especially he claims he is open for response.

 

[rezystor1990]

Printed the last parts of the battery housing and started assembling the battery!

View attachment 381410

View attachment 381411

View attachment 381412

View attachment 381415

View attachment 381413

View attachment 381414

View attachment 381416

View attachment 381417

View attachment 381418

View attachment 381419

View attachment 381420

View attachment 381421

View attachment 381422

View attachment 381423

View attachment 381424

Here are the settings for the welding if somebody wants to replicate:

For the solid nickel strip 0.2mm thick tab on 0.3mm thick copper on aluminum support surface with each spot welded twice at straight and reversed polarity

View attachment 381425


For the copper nickel sandwich buss bar to the battery cell welded regular way

View attachment 381426

Copper to copper is soldered

View attachment 381427

View attachment 381428

View attachment 381429

I see you welded this sandwich (copper and nickel) using the 30-gear GLITTER 801H welder. Are you sure that's enough? Is the copper sheet 0.3mm thick? From what I've read, copper welding requires powerful welders, and you did it with low power.

 

[TPEHAK]

I see you welded this sandwich (copper and nickel) using the 30-gear GLITTER 801H welder. Are you sure that's enough? Is the copper sheet 0.3mm thick? From what I've read, copper welding requires powerful welders, and you did it with low power.

Yes, I tested it with a dummy battery cell first and the weld is very strong, the copper spot welded areas stay on the battery terminal and tears off the sheet during tear test and requires a lot of force to tear it off. The spot welded areas are impossible to tear off from the battery terminal even with a sharp tool and can be only grinded off. Bare copper is probably not possible to weld with this welding tool, but the layer of nickel they put on the top of the copper layer makes all the magic.

I used this particular product. The copper layer is 0.3mm thick

https://www.alibaba.com/product-detail/WELLGO-Wholesale-Cheap-Price-250A-21700_1601396113170.html?spm=a2756.trade-list-buyer.0.0.4f6476e9i4Sumu

If you want to use the same Markhor Kunlun frame and make the same battery you can find the battery CAD files and parts list here

https://www.emtbforums.com/threads/markhor-kunlun-m510-190mm-super-enduro-build-log.40279/page-6#post-645359

 

[TPEHAK]

I came across a message saying that the 560 motor cannot even maintain the factory torque and needs to be modified for a larger overrunning clutch! So what's the point of a powerful controller if it can't handle the standard values!View attachment 382194

How do they modify it? Do they machine the gear enlarging the bore in it and install an adapter on the shaft for bigger bigger bearing inner race? That adapter/race should have a hardened surface to work properly with the one way bearing. Do they sell such modified reinforced gears with larger one way bearing for M560? That looks like proper solution.

 

[TPEHAK]

Luna released instructions how to log a ride with this controller