Luna M600 Ludicrous V2 controller documentation

[rtp]

marcos Bumping this as I suspect you're the only one knowing the answers on these:
A few new Qs:
1. What is the relationship between the app profiles vs selected # of PAS levels and current PAS mode selected?
2. Torque linearity in the doc mentions throttle specifically? Does it have any impact on PAS? Are there any provisions to adjust the ramp e.g. torque applied vs power added?
3. Can the throttle signal range be set? (I’m assuming probably in full vesc tool?) The OE thumb throttles eat bar space and will be looking at alternatives, some of which may have different min/max signals..
4. This one's purely for my own itching brain - the controller knows wheel size, but presumably it's using the speed sensor which is inside or < the actual wheel diameter. The X2 looks like it's fixed position, but how is speed calculated specifically, e.g. it uses wheel diameter along with a preset sensor offset and # of magnets or something?

[marcos]

1. What is the relationship between the app profiles vs selected # of PAS levels and current PAS mode selected?

The controller doesn't know the # of PAS levels, that's a display setting. If the display is set for 5 levels it just skips levels (1,3,5,7,9).

2. Torque linearity in the doc mentions throttle specifically? Does it have any impact on PAS? Are there any provisions to adjust the ramp e.g. torque applied vs power added?

It applies specifically to throttle, and what it does is affecting the poly exponent that has a fancier presentation on the desktop verision:

There are currently no provisions to make it affect the PAS behavior. This is handled in 1 line of code where the ramping time is applied, if I reduce that ramping time it starts shaking/rattling so its probably as sharp and quick as it can get. Btw if you ask I can't deny you the source code ;)

3. Can the throttle signal range be set? (I’m assuming probably in full vesc tool?) The OE thumb throttles eat bar space and will be looking at alternatives, some of which may have different min/max signals..

Not from the app, but yes from the desktop vesc tool, over USB. I've been conservative about the throttle range because I have no tolerance data, but it could be tuned tighter to remove some of the initial deadband.

4. This one's purely for my own itching brain - the controller knows wheel size, but presumably it's using the speed sensor which is inside or < the actual wheel diameter. The X2 looks like it's fixed position, but how is speed calculated specifically, e.g. it uses wheel diameter along with a preset sensor offset and # of magnets or something?

From the wheel sensor you get wheel RPM, and rpm+wheel diameter gets you speed. No matter where the sensor is placed, you still get 1 pulse per revolution. In the logs you will see both wheel speed and GPS speed.

[StvMan]

Marcos, Are there any special water-proofing or water avoidance considerations that need to be aware of for the X2 … I ride in some areas with shallow stream crossings … obviously not talking of submerging, but are there any water spray/splash concerns?

[marcos]

The v2 should have the same waterproof rating as the stock controller. The antenna opening is sealed and gasket is pretty much the same. The antenna is exposed so once in a while I'd check if there corrosion in there. Internally its not potted like the bbshd so if water does enter it won't be as rugged.

[rtp]

The controller doesn't know the # of PAS levels, that's a display setting. If the display is set for 5 levels it just skips levels (1,3,5,7,9).


It applies specifically to throttle, and what it does is affecting the poly exponent that has a fancier presentation on the desktop verision:

There are currently no provisions to make it affect the PAS behavior. This is handled in 1 line of code where the ramping time is applied, if I reduce that ramping time it starts shaking/rattling so its probably as sharp and quick as it can get. Btw if you ask I can't deny you the source code ;)

Not from the app, but yes from the desktop vesc tool, over USB. I've been conservative about the throttle range because I have no tolerance data, but it could be tuned tighter to remove some of the initial deadband.

Ok, this is good to know and probably worth adding in the doc - I know the doc was based on the BBSHD LudiV2, the 'predecessor' controller, but I'd bet more of the BBHSD guys using the controller are looking for throttle focused applications, where at least some of us on the M600/X2 - are looking for less throttle use, more workout, smooth etc.

So actually, I'd like to slow down the ramp a bit, or be able to play with it, perhaps within some boundaries (like you said, you've already found the quickest/shortest ramp duration.
One of the things in hopping on and off my wife's Bosch, is the power is applied nearly immediately. Might need to play a bit as it's possible it's torque sensitivity/response 'trigger level' more than how quickly it ramps once it's adding power. Underway and moving, at least at low PAS levels, the bike feels really good, just the initial 'jump' needs to possibly tone down a bit.
Hope that makes some sense?

And yes, I know, but I also know eventually you'll merge to mainline and probably have enough fire drills going on right now. Plus, you know, I'd like my BT to work first.. :D :D

From the wheel sensor you get wheel RPM, and rpm+wheel diameter gets you speed. No matter where the sensor is placed, you still get 1 pulse per revolution. In the logs you will see both wheel speed and GPS speed.

NM, I'm having a brain fart making things more complicated than they are. You're right of course. :D

[marcos]

So actually, I'd like to slow down the ramp a bit, or be able to play with it, perhaps within some boundaries (like you said, you've already found the quickest/shortest ramp duration.
One of the things in hopping on and off my wife's Bosch, is the power is applied nearly immediately. Might need to play a bit as it's possible it's torque sensitivity/response 'trigger level' more than how quickly it ramps once it's adding power. Underway and moving, at least at low PAS levels, the bike feels really good, just the initial 'jump' needs to possibly tone down a bit.
Hope that makes some sense?

Duly noted. This will be probably will be the #1 update.

Right now I'm focusing in a few bikes that had issues, yours is one of them, then the code merge, then the m600-specific updates.

[rtp]

A few more Qs (and check your PM RE: next steps on BT issue..):
1. Does anything in the LudiV2 affect the usefulness of the display's battery percentage reading (these are notoriously inaccurate) or is there a means to switch to voltage or more 'believable' percentage readings (including e.g. 'the Ludi V2 app reading is more accurate' or similar..)?
2. What happens on the M600 with Ludi if you lose the candence/speed sensor input (sensor or cable goes bad, etc.)?

[marcos]

1. Does anything in the LudiV2 affect the usefulness of the display's battery percentage reading (these are notoriously inaccurate) or is there a means to switch to voltage or more 'believable' percentage readings (including e.g. 'the Ludi V2 app reading is more accurate' or similar..)?

The VESC firmware now calculates the battery % and sends that info to the display. So the app and handlebar will show the same number.

The SOC % is not something to write home about, the algorithm is optimized for samsung 30q cells and is heavily affected by voltage sag. It does track Ah consumption quite accurately though. The next release uses a longer filter for the voltage so hopefully sag won't affect it that much.

The controller sends battery voltage data to the display but I don't know if you can make the display show it.

2. What happens on the M600 with Ludi if you lose the candence/speed sensor input (sensor or cable goes bad, etc.)?

Right now, nothing because cadence sensor is not being used. If we merge cadence and torque data and cadence sensor fails, the cadence would be measured as zero. PAS is a new thing for VESC and torque/cadence is not logged or displayed in any way. It would be cool to have that data in the logs.

[rtp]

Thanks, sounds promising in the percentage at least has a path to potentially be better than the Bafang version has been then...

Definitely would be useful to have sensor values (both Tq and speed or at least derived speed, crank revolutions) data-logged. Would be useful for future further tuning of params or algorithms, IMO.

You could always start simple RE: cadence sensor and implement Shimano's 'shuttle mode' which would basically turn it into 'BBHSD mode.' One could argue 'but there's throttle' which is true, but I imagine sooner or later you'll allow for (if not already) throttle to not limit by PAS mode, while 'cadence mode' would still track to PAS, and might be a way to either let your <parents, grandma, kid, questionable friend> take a ride or give yourself a break. Maybe not a compelling argument at this point, but logging more data lets you model and play around with outside of implementation etc..

[marcos]

Guys I got 2 separate reports of the odometer not working and I can confirm that. Every other display counts the mileage on its own, but the M600 needs the controller to keep track of the mileage and communicate it to the display.
First we should get the odometer working on the controller, I know how to do that. Then reverse engineer the display protocol deeper to get it to print the mileage, fingers crossed we can pull this off

[Sebz]

I can confirm that ODO/trip does not work on the V2, I swapped to the V1 and odo works fine.

[carlb4u]

no odometer here either works in app

[rtp]

RE: Adjustment of throttle ranges, etc.

Not from the app, but yes from the desktop vesc tool, over USB. I've been conservative about the throttle range because I have no tolerance data, but it could be tuned tighter to remove some of the initial deadband.

Can this not be done over BT with the desktop app? As I'm seeing from our 'sort my BT connectivity' track, the position and orientation of the micro-USB connector orientation along with wire length (mostly the white harness), doesn't make it hugely 'fun' to get to the USB connector. My desktop VESC will pair over BT (as long as I sit right next to it...) ??

FWIW, I have some alternate throttles coming thus the original question on this one. Will need to check and compare them to the Bafang OE thumb throttle once they arrive..

Also, I know you've mentioned this somewhere, but I am NOT seeing how to change settings from metric to imperial - it's not in Bike CFG and didn't see in App Cfg either.... ?? (ideally both for datalogging but also the ride display/speedo) ?

[marcos]

I can do everything from the desktop version of VESC Tool over bluetooth... but that only works on Linux so I just assume nobody out there has such firepower. If you have let me know and I'll get you the exe that matches your firmware version.
Yeah the USB is not that easy to access, now that you mention I had to take out one of the white cables for it to fit. But its only there as a last resort.

In the app if you swipe right a panel appears in the left with a Settings menu. There you can change to imperial. I gotta put this in the manual.

[LarryMagoo]

I have noticed there is no mention of Total Miles. aka ODO...all I have on my Display is Trip...that is resettable. Anyway to have an ODO as well?

[marcos]

Not yet, see 2 posts above. First I have to implement an odometer in the firmware, and then print it on the display because it looks like the display is not doing that on its own :/

[marcos]

I think I forgot to post the update here but a while ago the download link for the app was updated so it points to the 32bit VESC Tool build that works on low end phones and tablets. Every user that had issues installing the app had a 32bit device, and the new build got it working for all of them.

The fix was also implemented on the VESC repository: https://github.com/vedderb/vesc_tool/commit/a2bb07d12f57642b13d548e245f59f70127e9a19

[Steelsnow]

Thanks marcos, just FYI that the link in the documentation had been updated to direct to the 32 bit version when I downloaded a copy last night.

[rtp]

So is there a 64 bit and a 32 bit separate link in the updated/current doc, or everyone use the 32bit now?

[marcos]

Everyone gets downgraded to 32bit because communism works lol
I can't really measure a performance difference when running 32bit on 64bit hardware, so no big deal. When the code merging is finished we will be able to use the official vesc tool from google play which is optimized for each device architecture and OS.

[javastout]

Did i break it? i Downloaded the app couldn't see streetmode ludacris mode etc. So i made a dumb move and uploaded the firmware and now when i boot up the bike it shows error 08. Anyone know how to fix

[ScottyB]

Did you figure this out? I am getting Error 08 after trying to update firmware.

[rtp]

Did i break it? i Downloaded the app couldn't see streetmode ludacris mode etc. So i made a dumb move and uploaded the firmware and now when i boot up the bike it shows error 08. Anyone know how to fix

The position of the magnet needs to be recalibrated after a firmware upload. This is covered in the doc (first post in thread
0, but power on the bike with the bike in a stand or rear wheel off the ground, power on the bike, connect to controller in app, go to bike cfg and re-run the ‘encoder’ calibration. The rear wheel will move a bit(slowly and small amounts, maybe for 15-30 seconds) then you’ll see the value change from 360 to <some value>. Write the vale back to controller from the app and done.

[javastout]

thank you so much i'll try when i get home

[rtp]

A few questions:
1. I noticed the cutoff threshold temp for the Ultras are higher at 140* - which isn't surprising considering the added mass/ability to handle and disperse heat when compared to the M600. On the M600/Ludi combo - is the primary source of heat the motor itself, the controller, or both? I think the LudiV2 M600 isn't potted as well but I'm assuming there are some thermal pads on the 'outside' of the controller?

2. Digging around in old docs I had plus the OpenEBike repository, I came across this for Bafang OE controller error codes, and noticed they don't quite match up with the LudiV2 manual. Any plans to add support for any of the 'missing' fault/error codes? (Looks like a few, e.g. FAULT_CODE_UNDER_VOLTAGE, already have a placeholder in the Ludi doc..).

3. Just seeing Ludi code 12 - presumably this is the code that would be thrown if the BMS kicked in if the Ludi controller was set > BMS threshold values for current?

LudiV2/VESC codes:

Bafang controller codes: (pls correct if wrong)

[marcos]

1. I noticed the cutoff threshold temp for the Ultras are higher at 140* - which isn't surprising considering the added mass/ability to handle and disperse heat when compared to the M600. On the M600/Ludi combo - is the primary source of heat the motor itself, the controller, or both? I think the LudiV2 M600 isn't potted as well but I'm assuming there are some thermal pads on the 'outside' of the controller?

Controller temp is a non-issue. See a typical motor vs controller temp during stress testing:


Down the road we could increase the motor temp allowance, I tested these motors at 150°C for a pretty long time but I want to be on the safe side for now, peek gears don't like to be that hot and the motor cover reaches 120°C which I personally don't mind but could be worrisome for users.

2. Digging around in old docs I had plus the OpenEBike repository, I came across this for Bafang OE controller error codes, and noticed they don't quite match up with the LudiV2 manual. Any plans to add support for any of the 'missing' fault/error codes? (Looks like a few, e.g. FAULT_CODE_UNDER_VOLTAGE, already have a placeholder in the Ludi doc..).

Um, I think that error table doesn't match the table I have been using. As long as vesc can identify the fault source its easy to change the number the display shows.

3. Just seeing Ludi code 12 - presumably this is the code that would be thrown if the BMS kicked in if the Ludi controller was set > BMS threshold values for current?

No, you can flow 1000 Amps through a motor phase while only drawing 10Amps from the battery.

When the BMS trips, the whole system shuts down including the display, so you don't really get any error code. Disconnecting the battery at ful load will likely produce an overvoltage event, not sure if it has time to log it though.