I wonder if the value you had (0.9/0.3) was somehow what the vescs had stored. When I used read button in the app screen it said 0.3/0.1 for ramping stock. I then changed to 0.1 and 0.1 and it feels a lot better. Now when I changed back to 0.3/0.1 it’s noticeable again but not as bad as when I first startes playing with this issue. I never thought ramping times could cause this kind of lag issue when using asymmetrical values. Have you looked in the code how it’s handled?
I’m only basing this conclusion on my subjective street test. I can’t log the pwm/ppm input at all so there really isn’t any way to log the issue as I see it. I’ll poke more into the logging but with the vesc tool the log I included a screenshot from is the best I can get. I removed some columns that wasn’t fit for this but there is nothing related to input.
I tried to log my test session now as well but it didn’t log… Same thing as yesterday. Piece of sh*** android Buggy feeling wish they made a iPhone app instead so I didn’t have to use my P30 pro for Esk8…
Yeah, with the latest firmware, I got those values too. So before it was 0.9 and 0.3, by default, which was much worse. So that explains why the effect was strong before.
I use metr pro, it’s best of both world. You can use it like a regular vesc_nrf51 module using vesc_tool app and also using metr pro app for interactive logs.
Isn’t it still limited to what the vesc firmware is sending? Do you have the possibility to log pwm/ppm with metr pro? I think the CSV files isn’t to bad to look at without graphs either. Even if the ms counter is in the vesc and it could be transmissions error to the log file it’s showing a more clear picture then graphs when looking at what happens from 1 second to another. For a trip the graphs are nice but for debugging raw values has their place I think.
I did a new short session. It’s much less of a problem than what it was before but I still think it’s around. It’s not very scientific without having the input but have a look at this. I accelerated to about 10km/h (15200rpm/28 poles = 543. 10.1 × 543 × 0.001885 = 10.3km/h) and here you can see that I have 70 motor amps and it’s falling off to zero for 488ms (0.5sec) before it ramps braking. It takes a while before it applies full brakes but this might be due to it slipping. The braking force is quite strong so my weight shifts to the front and then it’s slipping on the rear… Wish I had more parameters so It would be easier to see what’s really going on.
Btw this log shows why I like having higher motor amps for acc/regen. It’s clear to see that I can pull 70 motor amps with only 26 battery amps. If I limited the motor to 40Amps since that is my battery max it would basically perform only 60% ish of what I got now when accelerating from a dead stop. Same with braking. I think it’s healthy to set the batt max to what the battery can handle continues. As an example in case you are bombing a hill and don’t consider that you shouldn’t be pulling 140Amps through the battery that can only handle 80A for such a long time. Most are not picking up their phone and looking if they are above/below their batt amp when doing such things so it would be better to set a limit that is somewhat within the specs of the battery.
erpm/pole_pairs = rpm. I think 28 is #poles and 14 is pole pairs.
Yeah, the motor and battery amps being 0 over 0.539 seconds is suspicious. PWM values would be super helpful here. The Metr Pro can plot ppm, so that information is available from vesc. I am surprised vesc_app doesn’t log it. It could be in 1000-2000ms format. 1000ms being max negative throttle and 2000ms being max positive throttle.
I agree, it should be set to the right values to avoid surprises.
A side thought is that power = volt*amps. Assuming the battery voltage is constant, the battery current peaks in the middle of the rpm range and not at the highest rpm. Unless, I am making some assumptions that is incorrect.
Will that separate command get a synced reply so we can trust that it’s in sync with the rest of the data? Gotta try that. Does your app work with nrf51 regular modules?
This tool gives me a timeout on motor detection, the motors spin as they are supposed to and goes throug all the steps but frezes at the end. Setting up each motor individually and using ackamnia works as it is supposed two. Has any1 else got this problem?
Have re-runned it many time, also tried reflashing firmare on both through can, and seperatly. Restarted the vesc and vesc tool. Also tried the usb port on both of the vescs. Running 2x flipsky 6.6 single
This is quite a nice update!
One thing that changed: Most features stay usable, without the need to re-run the wizards.
Profiles, Settings, RT-Data, SWD Prog etc.
We now have a quick pairing button for the WAND-Remote, so no need to run any wizards for the remote.
Basically it is a big fat convenience update. Simply better UX.
Thank god for that. If I had to run detection and then re enter all my settings to see RT data once more I may have lost the plot.
Sounds like a good update. Once this wand is out the way some work on the telemetry side of things would be wonderful! Still, I love it, no more laptops to change things around
I have a 4.12 vesc from enertion, metr hooked to it and vesc tool on my phone and pc(no wifi).
Vesc tool mobile told me to update the vesc fw so i did. Its now 3.59. problem: connection over ble disconnects everytime while trying to run motor detection. So i downloaded latest vesc tool for pc and connect to vesc over usb. PC vesc tool tells me that it can only handle fw 3.6 on the vesc…
So i am at software gunpoint.
Where can i download fw 3.6 for my vesc or how can i talk metr into keeping a connection to my phone alive?
wish they made a iPhone app instead so I didn’t have to use my P30 pro for Esk8…
