My opinion is bldc noise isn’t really equivalent to a loud motorcycle anyway. Making cars around you hear you coming while in traffic is not really the same as zooming past pedestrians. I have worse luck making them aware of me, by the time they hear your motor, turn around, see you coming then freak out and end up getting in your way. I prefer the silent flyby, aim to get past them before they even know you’re there.
Better than broken shit you can’t ride on anyway 
I just installed 4.1 on my FOCBOX. It took about 2 hours. That’s not exactly what I would call fast. I was actually surprised it didn’t fail. Anyone else having the issue or is it just me?
Firmware flash took 2 hours? ;O
Do you have another to roll the dice on to see if that’s reproducible?
I would have hard rebooted it thinking it was stuck long, long, long before 2 hours elapsed.
What FW did you have installed earlier?
Jumping from Ack 3.103 to 4.1 takes that long, even for me.
If you jump from Ack 3.103 to 3.66 for example it takes seconds and then from 3.66 to 4.1 it also takes just seconds like it should. But 3.103 to 4.1 takes literally hours.
That must be it. Thanks.
Anyone knows the reason for this?
Probably those pesky groundloops. I jest.
I would imagine the bootloader is not the same between 3.103 and 4.0+, but as to why it takes hours as opposed to failing or timing out… No idea. Got an Stlink v2 and/or buspirate?
I do. According to what @xsynatic wrote though, it doesn’t seem to have to do with 4.x FW but is rather related to switching from Ack fw to the standard fw in general.
Just wondering if there is any effect on the regen when using HFI?
I believe this is most likely due to memory access operations. Now I don’t know exactly how the flashing routine works for this specific case, but I assume it has to do with sequential vs random read/write operations.
Seeing how large are the changes in c code between Ack fw and 4.x fw, the resulting compiled binary is going to occupy a fairly different memory block addresses. With this in mind, if updating to a contiguous firmware for example, the chances that most of the compiled binary data are going to remain unchanged are high, meaning only a small portion would need to be updated on the memory, this happens relatively quick because the flashing routine reads those blocks first and knows that they are unchanged, thus skipping the expensive write operations.
When a lot has changed code wise, flashing would technically take a longer time to override all the changed blocks, and this depends on how contiguous those block are to each other, how many random read/write vs sequential read/write are there, the page size, and actual written data size.
But of course those are all assumptions, and I’m pretty sure some other factors are weighing in as well.
I assumed it had something to do with firmware compression or something like that that was implemented at some point.
It’s definitely firmware compression.
Keep getting this error when trying to setup my motors in fox with 2x VESC6
Tried resetting the firmware but didn’t help please could someone give me a fix as would love to be riding again tomorrow
Small update review…
Idk what firmware the issue started or if its in all of them
Just a psa since it seems I’m not the only person with this issue.
I get firmware induced speed wobbles. Always at the exact same speed. (Focbox in Foc)
…Went back to Ackmaniac “Speed wobbles” are gone.
Also got cutout under hard acceleration (Not 100% sure if this is firmware issue)
wh/mi calculation is incorrect as far as i can tell (measured against powerlab 6)
The speed wobbles, are they like a rubberband pulling you back a bit, over and over?
