Since open source you can flash whatever you like and then flash the original FW back whenever you like.
No one can proof that you used different FW in the meantime.
If you don’t have the original FW you can ask for it and there is a duty for Enertion to send it to you or offer a download. They need to do that for another 3 years after last distribution of software or hardware with that FW on.
You should always use the latest VESC-Tool and FW anyway. There are some safety improvements in VESC-Tool that do not come with the older stuff. Benjamin highly recommends not to use the old BLDC-Tool any longer. It doesn’t get any critical safety updates and is outdated.
One feature that is very important to have is Acceleration temperature decrease. Without that feature your brakes can drop out at when your motors reach critical temperatures. The ESC will cut back the power when the motors overheat. It will also cut back the power of the brakes! In consequence you will not have any brakes when needed. Acceleration temperature decrease will give the brakes headroom to work at any time. Especially with hub motors this feature can be your life saver! Hubs tend to overheat faster and the risk of ending up without brakes is very high.
Since sources for the Enertion distribution of BLDC-Tool are still non existent, the community has no chance to work such a feature into that software or find existing issues. Open Source should work in a way that many eyes look at the code and weed out the weaknesses, so that it gets better and better, safer and safer.
The issue is with all vesc firmwware? The code I’m talking about is all in reference to vedders repository. The unity code would be completely useless as no one has unity hardware for testing. Anything I code up should be plug and play with a regular vesc but I’ve only identified what I think is the problem so far.
@trampa I’m going to flag this as off topic because I don’t want to distract from the issue this thread is trying to address, but I hear what you are saying. We actually tracked down the source files for the raptor 2 tool and they were supposed to be posted weeks ago, I’m not sure why that never happened but I will get it fixed. The focbox firmware is just stock firmware with a few #defines changes and the vesc project ethos page suggests not creating new repos for such small changes.
Seeing as to how the focbox is working reliably for many users with the firmware that is locked into it I think there are pros and cons to continuous firmware updates that you aren’t addressing. The phrase “If it ain’t broke don’t fix it” comes to mind. That said I am personally a fan of the rolling FW updating but you can’t ignore the fact that there are tradeoffs.
Just throwing some ideas, I remember about vedder saying about active braking in his old forum a few years back, could this be an answer? Using energy to modulate the braking a really low speed or you get back to same problem since you can’t determine the motor position and speed?
And the behavior is exactly what you describe, the worst is that when you actually enter the shorting phase you can’t modulate it anymore, some hills you want to go down really slow, below the 3%, but full brake will still bring you to a stop
The other thing that happens is once you enter that braking range the duty is commanded to zero so even if you speed back up going down the hill it stays in the full stop mode and doesn’t exit properly.
My thoughts were to look into a model for active field collapse, see if maybe I could get some kind of torque estimate, then pwm rapidly in and out zero duty and modulate it to try and better match forces during transition. Just one idea though.
On Topic: Geared systems suffer less since the motor spins 3 - 6x faster at a low speeds. Higher ratio = smoother braking. A high accuracy encoder works very well (AS5047P) to run the motor at super slow ERPMs Non geared systems have a lower ERPM at the same physical speed. “Lockups” will probably happen at higher speeds. I Never tried it out, no hub to hand - still paddling my bike to work.
Personally I never encountered such lockup issues. I can brake any of my boards to a standstill without a motor lockup. Just before the board totally stops (1-2KM/h) you can feel that the motor can’t be tracked properly any more. A generator works when it spins…
OFF Topic: The Ethos page suggests no to fork for minor changes that could also be worked into the original distribution. A repo is always needed along with all other obligations. Once you run a fork you are all in!
A small change can make a big difference. For example a changed FW revision number can make FW updates impossible. Small change big impact! This is why any changed software needs to be shared.
This is exactly the thing I was trying to describe in the @Ackmaniac firmware thread. It’s a sticky latching type feeling on steep hills that is kinda dangerous. The slow speed to stop on flat ground also feels similar to me. Just less violent.
I run BLDC so its not just a FOC thing. It may be more apparent in FOC I don’t know I have not tried. I did not experience it in the firmware 2.17 but then did in 3.102. I kept the same settings when I switch over to 3.1.
I have kind of got used to it, just need to release the brake slowly as you slow down, where as before I could just hold the brake in one positing and get fairly constant stopping force relative to speed. Not an increase in stopping force when the speed decreases.
For reference. I am using 4.12 hardware in BLDC, ackmaniac 3.102 firmware, 12s lipo, 140kv 5065 dual, 18:36 gearing, 97mm wheels, 100kg rider.
That is the same understanding that I have and tried to explain in my first post in this thread. Its great to see that you are working on it. The only perfect solution I see right now to solve that low speed tracking issue is using encoders.
Off topic:
That is actually what I do on the skateboard. Pulling 100% brake at full speed. At full speed the battery current is the one limiting braking and I actually would like to brake harder and am far off from being thrown off. But I can’t use higher values without harming the battery.
When you recommend people to use -30A battery current on dual setups then it is your thing. Just thinking about my board with 5200mAH LiPos that are specced at 1C max charge the 60A you recommend are more than 11 times as high as the manufactures max specification. That leads to more than just a slightly decreased battery lifetime…
One fact that you just oversee is that your motor needs a temp sensor inside for that feature and thats just not the case for a lot of motors, so that this “very important life saving” feature is useless for builds using the popular SK3 motors for an example.
Yes I do recommend to have settings that result in a strong and reliable brake. Better a slightly decreased battery life than a decreased personal life. In reality your battery will not see 30A ever.
The C rating refers to a complete charge.
A Twin MTB like @rich has doesn’t run of a single 5200mAh pack.
Acceleration temp decrease: No motor sensors no problem. You will be able to push your motor temp till the motor falls apart. Most loose magnet issues happen because of to high motor temps.
The heat expansion cracks up the glue holding the magnets.
The problem with sensors on outdated software: If the ESC cuts back the power due to hitting motor temp limits, it also cuts back the brakes.
Motors get hot when you cane the board and when you go fast. In that scenario you don’t want to end without brakes! We tested it out with deactivated setting, driving our motors to 110deg. 100% loss of brakes! Benjamin had the fix out within a night shift.
The R2 has sensors, hot motors, lacks the feature and the riders do not necessarily understand the tech. This combo ain’t good and in consequence users should update to Vesc-Tool ASAP. Discouraging people to do so puts people at risk! If the source code would be public someone could have updated the Software. This is a perfect example why it is important to have the sources accessible.
Motor lockups at ultra low speed: We will have a look into this next weekend. Without having encoders installed low speed FOC rotor tracking and ultra low ERPM motor driving is an issue.
It’s nothing you can solve with ease.
I think this motor temperature thing is really not a concern for certain individuals. My motors rarely ever even get warm to the touch and I run 80A -80A, so I think that is completely different than the raptor which basically has motor cozies (the wheel) around the motor.
Did a new recording with full electrical braking to a full stop (no mechanical brakes). You can see how the motor phase gets shorted at around 8-10kmh. Maybe you are also interested in the current graph from that record.
I did for Ackmaniac’s FW v3.102, see link above. I could make the change on the latest standard firmware, and as long as the firmware builds without errors I can upload it tonight, I won’t be testing it though.
It seems this fix is still a work in progress, some quirks but progress for sure.
The only perfect solution I see right now to solve that low speed tracking issue is using encoders.