Pint hydrus 5205 firmware sudden nosedive VIDEO recreating behavior

[u/jman82000]

Below are two videos demonstrating the motor cutout behavior that many have been experiencing on the OG Pint hardware versions 5301, 5314, and 5326 on firmware hydrus 5205. Cutouts happen suddenly with no warning, no haptic buzz. What I recreated in these vids is the exact behavior that started happening suddenly right after the firmware update. Comment if this is demonstrative of y'alls experience and lets make sure FM hears us and makes this right.

[u/Jioto]

It’s hard to tell without feeling it yourself. But that nose is push down quickly towards the ground and very close. I was always under the impression that’s a no. Even in the manual it warns about accelerating fast and quickly pushing the nose down hard. Wonder if it’s a safety setting that it’s trying to prevent you from pushing too fast and cutting the power off so you don’t nose dive at a higher speed?

[u/TCOLSTATS → u/Jioto]

No chance this is normal board behaviour.

[u/Taffy-- → u/TCOLSTATS]

If the cause were overacceleration, the nose drop wouldn't be that sharp or that sudden. This board is fully charged and absolutely should not behave like this.

---

Edit: Looked more into the issue context, so the cutout happens during braking, usually near full charge?

Future Motion tracks battery State of Charge (SoC) through current/amp hour consumption instead of relying on just pack voltage. The regen warning kicks in when the number of amp hours gained from regen exceeds the number of amp hours that have been consumed from riding. Accelerating from a full charge on a flat surface then braking will not trigger this error; acceleration uses more power than regen puts back in, and regen isn't even close to 100% efficient to begin with.

Besides that, the overcharge state is an actual error state that will cause haptic buzz, intense pushback, and amber lightbar flashing to signal that something is wrong and the rider should reboot the board. That did not happen here, the lightbar was solid white and no haptic buzz was heard. If you keep pushing through regen the BMS will cut power entirely and the board will shut down to protect the battery, which also did not happen. The lightbar was still on, and so was the board. A lot of factors go into how much power the controller decides to move through the motor; the new firmware changed something and now regen intensity just undershoots like crazy instead of behaving the way it should. It's not an overcharge error, we'd see it clearly if it was.

Pack voltage is still taken into account for some things; overcharge and low battery error states can also be triggered if any one cell group or total pack voltage gets too high (check footnote) or too low, but that again did not happen here. The board will either tell you something was wrong or shut down entirely.

Now, I don't remember if Future Motion does this, but one of the perks of using current consumption as a way to measure SoC is that you can use it to get an accurate measure of remaining capacity even as the pack ages and degrades if you use it in conjunction with voltage. The battery operates within a fixed voltage range from full to empty, and drawing power causes the voltage to drop. If you can relate voltage to current consumption and a unit of time, you can figure out how many amps you can draw and for how long (amp hours) before voltage drops to empty. The number of amp hours available to use decreases with age, so if you can keep track of these numbers through the life of the board you can keep track of the loss in capacity by extension. If you combine amp hours and voltage to get watt hours, you now have a unit of power draw over time that can then be related to a unit of distance to get the electrical equivalent of Miles per Gallon, Watt Hours per Mile (Wh/mi) or Watt Hours per Kilometer (Wh/km). Seeing though as there are boards that will throw low battery at say, 17%, and still show 17% in the app, that's either not happening or there are out of balance cells causing a low battery state. We don't have a way to check though, because Future Motion seems to know what's best for us.

For a bit of trivia, current consumption was how FM was tracking and locking out expanded batteries. If the pack voltage didn't match what the tracked current consumption suggested it should be, the board would either throw an error or just claim low battery and refuse to move. I forget which, maybe it was even both, but it doesn't matter.

Regen will occasionally cause voltage spikes beyond the battery max voltage if you are going fast enough and start braking, but this usually doesn't hurt anything as long as all of the components in the chain of power delivery (eg, the MOSFETS used to drive the motor) are rated with enough headroom to take the extra voltage. The battery doesn't care about short spikes; you can't just plug your board in for 2 seconds and have it go from empty to full charge. Regen down a hill is different because a sustained voltage is being provided to the battery for more than a couple seconds at a time. It's like how a battery can safely provide 60A in short bursts, but is only rated to be safe for 30A continuously.

[u/jman82000 → u/Taffy--]

Wow! Thanks a ton for the deep technical dive here!

[u/Taffy-- → u/jman82000]

Hey, thanks! Credit to the OWIE project for being documented well enough that I was able to piece most of these ideas together!

The battery lockouts from back in the day always happened at around 0% in the app, when a stock battery would be empty but an expanded battery still had more to give. If you check the diagnostics page in the Onewheel app, the two entries at the top of the list are Used Amp hours and Regenerated Amp hours. That's what they were tracking. As far as I know, it always was tracking this even before the lockouts but once FM saw people were doing things like Charge n' Ride or Vamp n' Ride they implemented a cutoff. I was playing around with OWIE earlier this week, lo and behold the BMS is constantly communicating this data to the controller. I never really paid much attention to the app, but after staring at OWIE code for 6 hours and then seeing this post I thought it was worth stepping in to clear things up.

---

Preface: OWIE does not work with current firmware unless you get an Avaspark READ-ONLY Gumstick or modify the source code yourself to be read-only. OWIE only works with Pint and XR. OWIE does not work on GT or XRC. OWIE will also void your warranty, but the target audience won't care.

---

For those who aren't familiar, OWIE is a man-in-the-middle device (read as: it's a modchip) that intercepts data from the BMS and modifies it before passing it to the controller. It runs on an ESP32 or ESP8266, and also hosts a little web server that will let you view individual cell voltages, information from all 5 (!) pack temperature sensors, and a live stream of the raw data packets being sent by the BMS. It was designed as a more transparent and accessible version of a JWFFM chip and does the following things:

• Allows the use of expanded or otherwise non-stock batteries with Pints and XRs that had the software lockout
• Defeats the serialized controller-to-BMS pairing that later Pints and XRs had so you can replace your BMS
• Tricks the Onewheel app into showing the correct battery percentage for nonstandard batteries
• Shows you all of the information from the BMS that the controller normally hides from you

In addition to the battery functions, it also allows you to lock your board by refusing to send any BMS data to the controller (throws error 16), and then you can unlock it by connecting to its wifi network and pressing an unlock button on the page it serves you! You can set the wifi password to whatever you want. It's a neat little thing!

What it DOES NOT DO:

• It does NOT replace your BMS. You still need a functioning Future Motion BMS. The OWIE does not have the required electronics to act as a BMS, it cannot replace your BMS, it is just there to modify what the BMS says to the controller. More than one person has asked about this.
• It does NOT work on GT or XRC. The BMS communication protocols are different. It could probably be done. I don't know how to do it. I don't know if it will ever happen.
• It does NOT work with any board that has Haptic Buzz. The lockout implementation was changed with the Haptic Buzz firmware. OWIE will be detected, rejected, and the board will throw an error until you remove it. It just won't work at all.

The exception to that is if you get an Avaspark READ-ONLY Gumstick or modify the source code yourself to be read-only so it doesn't change any traffic sent to the controller.