I need to count how many times a week i take my wheels off. Everytime there is a sound i don’t know, i have to check what’s causing it.
4 Likes
Since this is the official thread for bitching about bugs. I somewhat added one to the balance app with the latest release.
The new fault delay feature i added is effectively incompatible with the dual switches half state. So if you are expecting the half state to work keep the fault delay at 0.
You’re welcome 
5 Likes
Well so I redid derection on fw4.1 and set the time constant to 1000. When I ran detection, one motor passed fine, but the slave motor started to spin up and then when it reached a certain speed, locked up and made a loud buzzing. I upped the amps for detection, ran it again. It got to a higher RPM before locking up and buzzing. Upped amps again, and then again. At 40amps detection finished, so I closed it up and went on my first proper ride.
On my maiden voyage up and down the street, I was getting the wobbles at 25ish mph, but with the new detection settings I thought ut was fixed at first. Then I tryed pushing the speed and got wobbles up above 30ish mph (I still dont have metr or dageva wired up, so Im judging speed off my buddy on my Metroboard). This time the wobbles were much higher frequency than before, which is interesting.
I may try fw4.2 and see if it can pass motor detection without locking the slave motor. Any ideas what would cause that detection behavior, and why I would still be getting those wobbles?
1 Like
Why don’t you use the latest FW with the fix?
2 Likes
Thanks for sharing, got me curious if my hall sensors were having the same issue, so i did some testing and sure enough, one of my hall sensor phases was shorted to my motor mounts!
You guys can have the cool points back for self balancing on an HFI setup, I’m going back to hall sensors!
I’ll probably still try to wire up encoders tho.
6 Likes
Eh.
Do you also not change your engine oil until it seizes? Or check your tire until it explodes? Regular inspections are important. Every couple thousand miles I open up the boards, check connectors, cut off shrink wrap on battery, check for warping on nickel and solder joints, put on new wrap, inspect wire insulation especially where multiple wires touch. Wipe down the deck really good and check for cracks on the deck, baseplates, hangers, motor mounts, check all bolts/nuts, wheel, pulley and motor bearings, replace any that feels notchy or excessive lateral play, look for fraying on belts, pulley wear etc etc.
2 Likes
If I see a problem, then it’s “broken” and needs service.
This would include dirty oil in your analogy.
1 Like
I mean some problems cannot be seen until you open it up. A cracked solder joint will go undetected in the battery until you pull it apart to look.
Do you open your car battery to search its internals every few months?
3 Likes
Can’t really open a car battery but it’s not important anyway, the alt is what keeps the power going as you’re driving. And you can pull over a car that dies, it won’t launch you through the windshield like an esk8 would. There’s no race event where the engine is not rebuilt/replaced every few hundred miles or multiple times a season and all parts inspected every race, why would an esk8 be so much more durable when used in a similar manner?
1 Like
I don’t use esk8 for racing, I use them for transportation.
1 Like
5char
1 Like
He said that is the next step.
However if it was just time constant being incorrect, him changing the value should fix it, correct?
This is still a valid question:
@BenjaminF was that the same buzzing on spin-up post detection we saw randomly during testing the other evening?
I’ll look into the PR and see all what was changed.
2 Likes
Hey @DerelictRobot, can you just give me a little holler when the latest fw update is up to your standards. Don’t want to risk fucking my shit up for hfi mode, especially when acks workin like a dream. You seem to be the one taking the best documentation at the moment so an all clear would be great
10 Likes
5 Likes
I’m not sure that any one person can or should ever give an ‘all clear’ on a complex system like this. That’s sort of the entire point of the other discussion, we need historical data across a large selection of hardware to be able to inform these decisions.
Currently we are all going on ‘gut feeling’ and rarely recorded empirical evidence which can be pretty subjective.
I can tell you that I personally run Unity at the current (23.46) firmware, but only because prior versions had some critical bugfixes. On my VESC-based hardware I have been running 3.40 on my older 412 hardware and 3.62 on my newer v6 hardware. Anything beyond 3.62 I consider ‘unstable’, but that’s my personal testing, experience, and recent regressions.
Logging as it stands is an issue limited by our current hardware offerings. We need more records, too few people run Metr Pro consistently and across all their boards
6 Likes
This is focking great.
Do you think the phase windings might be shorting to each other now that they’ve been ground up a bit?
3 Likes
It being open source or not doesn’t really matter. Point being is that we have limited options for logging as it stands. There’s really only one good ride logging option as it stands and it requires a cellphone BT tether and conscious user decision to begin a logging session.
IMO logging should be an always-on feature. I think it should be on the receiver, with the ability to handle graceful shutdowns.
8 Likes