I never thought of it that way - but I guess the brake current in the balance app means that technically the motor is running. When I first started playing with firmware changes my son once stepped on my board and rode away in the middle of a firmware update.... Agreed - hitting that upload button should stop the motor or switch the app to something safe
Tested the latest dev branch on a different balance setup and it seems to be running nice and smooth. ¯\_(ツ)_/¯
Also I tried a few different sleep commands with specified wake up times but it seemed to make no difference. I also checked the time that the balance app loop takes to run (excluding sleeps), and it sat consistently at 0 microseconds (not sure if that means its fast or i measured incorrectly lol).
I opened an issue for this, but thought I'd share in this thread too - selecting "No App" prior to a Firmware update is a bad idea - doing so disables/brakes Bluetooth forcing me to connect via USB to recover. For now I'll be selecting the UART app for firmware updates...
Are the current spikes you posted gone as well?
The system timer will probably not tick even once while the balance code runs. You can use this 10 MHz timer:
I now always switch to the UART app before uploading firmware, so no more current spikes. But the clunky motor noises are still there and I can't figure out how to get rid of them, and the transition to/from sensorless is also very scary (grinding noises). I had to go back to 5.2 last night so I could enjoy a little evening ride...
Sorry if this is the wrong place to ask this question - but can you point me to any tutorial (document or video) that explains how to properly calibrate and tune a hall-sensored motor by hand? I feel like the whole balance board community is just relying on wizards but nobody seems to understand how to properly troubleshoot or calibrate a motor manually. I would love to use 5.3 but right now I can't even focus on the new features since I can't get my motor control in order
I noticed that you commited some changes to the dev 5.03 of VESC BMS as well.
Is the example schematic ready for sharing?
it's not 100% related to FW 5.03. I'am running 2 x focbox unity (can bus) with FW 5.02 . When I do the motor wizard all wheels are spinning and it seems everything is ok but at the end it just shows me 3 of the 4 Motors in the motor detection list. With FW 5.03 it just shows me 2 Motors. Only with FW 5.01 all motors are shown correctly in the list. In all FW Versions all 4 motors are working when I use the remote.
Still trying to figure out why my motor runs like crap with 5.3, and also why a perfect 5.2 configuration when applied to 5.3 doesn't run smoothly - I noticed that the "Current/Voltage offsets" feature is a feature that appears to be enabled by default. Is there a safe way to disable this feature entirely? I can set "don't calibrate on boot", but what offset value disables the feature entirely? 0? Or 2048, which appears to be the default? Thanks!!
Yay! Beta26 magically fixed my motor issues. Now when restoring my 5.2 config my motor suddenly runs like a charm. It's a bit different, felt a bit weird at first at low speeds, but overall it's potentially even better than 5.2! Great work guys, whatever it is you did, thanks!!
hello I have a 4.2 flipsky vesc and I just did the firmware update that changed it to 5.2 as the latest firmware and now my throttle doesn't show up nor work to spin the motor but I can still use arrow keys to spin the motor? I have no clue HELP NEEDED
hello, i just updated my firmware from 4.2 to 5.2 on a 4.20 flipsky vesc and am not getting any throttle response in the vesc app or on the motor? HELP NEEDED
Did you choose uart+(pwm) ppm in the app tab?
FWIW - with CheapFOCer, LittleFOCer, and BalancePro the odometer still gets reset on a firmware update. Do those VESCs simply not support the required EEPROM? Are there VESCs where the odometer survives a firmware update now?
Currently the odometer only works with hardware that has a shutdown function, as saving is triggered from there. It could probably be done when the input voltage drops below some level, but that has the risk of corrupting all eeprom emulation and thereby reset the motor configuration on the next boot.
What I did in another project was writing odometer value at the moment when RPMs or speed go from any number to 0. With some wear leveling, it can be a viable solution for the life of the controller. Some data can be lost only in an unlikly event of shutting down the controller while the motor is still spinning.
Another way is just writing it all to FRAM any time you want. A 16k chip would add only ~$1 to the bom and can also be used for saving mc and app conf between firmware updates.
Hey Ben, I see Shaman's Cheap Focer v1.0 is now natively supported with the new release; thank you very much for that! Can you please clarify if its for v0.9 or v1.0?
It is for v1.0 only
Mitch's Dterm filter commit in beta37 breaks compatibility with all previous betas and FW 5.2 - may I suggest that we reuse the old Dterm filter config value for the low pass filter value (we could change just the label, not the config value name), this would allow users to try the latest beta by just restoring their previous config.
This is my first E-Board using FocBox Unity hardware and the latest 5.03 beta from 5/23/21 and so far this has been super fun.
Default mode i use is FOC Mode with Hall Sensors on 90mm Hub Motors.
Tested HFI and HFI Start, it was a bit odd where it started great then cogged a bit, probably requires some additional tweaking on my end.
Field Weakening (I know its dangerous) gained another 3-5 MPH with an 8-10 amp change and seemed to work very well, i've been reluctant to go too much past 30 without some additional padding.
There is an odd brake phenomenon that happens around 1-2 mph where i get a noise/buzzing and almost a sticky feel from the brakes, i believe this is unique to the FocBox though.
Overall super smooth, the VESC-Tool on Android has some quirks, if you stay connected for a long period datalogging and go-to change a motor configuration it totally breaks and goes back to default settings in my case the wheels move opposite directions, disconnecting and reconnecting before a motor change seems to keep this from happening.
Thanks for the hard work!
Edit: can someone educate me on the phase filter's? i'd be happy to test but it seemed to make no difference for me.
I managed to blow up a FOCBOX Unity with the 5.03 firmware, but there are ton of different non-firmware-related things that could have caused it. The specific failure mode is a big two-terminal device near the battery-connector-side hall connector burned up (unfortunately the silkscreen label got burned off), and it seems to have taken out the DRV chip on the same side out as well.
I had it configured with FOC and hall sensors and it was working beautifully at low speeds, but when I took it outdoors and descended a really gentle slope at maybe a brisk walking pace I heard a sizzle and smelled smoke. I pulled the battery cable and took it indoors to check out the damage. Turning it back on briefly led to more smoke from the same part.
Things that might have caused this:
I wouldn't read too much into this but I'll probably do the rest of my development with the release firmware/VESC tool on two non-unity FOCBOXen.
Dang, i have been using 5.03 for like two weeks now? Focbox unity and hall sensor with hub motors.
been ripping on it pretty hard, i will say there is a definite funky issue when braking as it switches from sensorless to hall as it follows the threshold ERPM when modifying it, the issue only happens in hall mode, tuning the PI controller made it 10x worse as its trying to correct more aggressively, ill be switching modes until i can diagnose is further.
By chance were you noticing this with yours?
Edit: Did more testing, its like when it gets back into hall sensor mode its position is backwards causing it to act like cogging, very funky. Maybe something to do with one of my motors being inverted? I don't think its why yours toasted though :-\
i guess the 5.03 development seems a bit stale.
Been trying to squeeze a bit more performance out of this thing but i'm confused by these results.
The field weakening i raised up to 93% and same with the Q axis setting to match under advanced but it seems to always activate at 87-89% ? unless i'm reading incorrect and thats just when backEMF starts to hinder performance a ton.
am i misunderstanding id with field weakening, this is all new stuff to me.
edit: figured it out after countless hours of messing with it....must have been a corrupt config? i factory reset it fresh and with the same exact settings it works totally fine now :-|
when the minimum current is set at 0A, vesc can't save the configuration, after rebooting everything goes back to the default configuration
Hello, I'm not very expert about Vesc configuration but I wanted to try this new firmware because the cogging start with HFI when you need a little more torque from standstill really brother me (for example when you start with the wheels stuck in tall grass or mud) and there was even the problem that quote often, mostly giving just a little throttle from standstill or using smart reverse, one wheel turn in the wrong direction. With my configuration (Trampaboard with 6376 160kw and Vesc hd60) this firmware works so much better than the previous version!! When you start you have just a moment of noise, the "whistle" is really for a tenth of a second and is much less loud then with the HFI mode of the 5.02, it give me so much torque and even power, with not load even the speed of rotation of the wheels Is more, zero problems with the wrong direction of the wheels (never happens), and much less cogging from start. The cogging is still present if you need very much torque starting from standstill but is significantly less and It happens much less. Very quiet and I'm not sure but it seems to me that it heats less.
So I'm very happy, with my configuration it works great.
update 2021_06_15 kill switch not working