The good:
Speed increase is real. The increased cruise speed feels downright liberating, I hit 23-24 kph on my 10 cell battery during some quick testing. Still not fast, but way better than the 14 I used to get.
The bad:
Torque took a nosedive. That’s expected, so I compensated by increasing peak motor current from 50A (oof) to 85A (oof) despite being a bit antsy about even the original value. Still wasn’t enough to reach original torgue value, although theoretically it should be (+70%). Not sure why it doesn’t scale, I assume it’s not saturating since control remains good and smooth all the way up there.
I’ll sure leave it as is, the cruise is so much improved. But the lack of torque means I’m no longer able to ride up a particular hill that used to be no problem, and there’s less margin for error when hitting bumps. Curiously, I was able to tune the PID much better now, “death wobble” after something saturates the control is much more manageable. Maybe the lower inductance…?
For anyone building something similar, definitely go with a 12S battery, there’s a good reason higher voltages are used with these hubs. More would be better, but that needs something else than a standard VESC. In my experience the Phub-188 600W version is just at the edge of being good. If the 800W version really has a longer stator, that + this termination mod + 12S battery could be a very nice combo with standard VESCs. Anyone orders and opens that, please take the dimensions
A little update, I had forgot to increase the motor current pushback limit on my firmware and it was hitting that already at 40A. After that got increased to match the new, higher current, things are peachy! I can again climb all the hills in my commute, pretty much to the limit of scraping the deck. And that cruise speed is just so damn nice, Redstar went for a cool proof of concept for tooling around to something actually usable and comfortable Since the torque does not drop off with speed as much anymore, there’s actually more of it available at higher speed than with the stock y-termination.
@arj If you feel like doing this mod, I can recommend the Phub-188. Get a stout 12S pack (really don’t want any sag here), change the termination and you’ll get something that works quite nice indeed.
Really nice to see a fellow Diy onewheeler took the plunge and modified his Phub188!
As some of you may know I have also modded the phub-188 from start to delta. My build is running 12s2p of samsung 30q cells. I’m really happy with how it is performing until now.
@Jopj, what do you mean with increase current pushback, seems like my board can use a little bit more torque. Are you running the latest Firmware on your vesc? And are you willing to share your settings, really curious how you have setup your board so I can compare it with the settings I’m running.
I saw your pictures, if only I saw them before pulling the damn thing open, would have saved me some worries!
I’m not using the vesc balance app, “current pushback” refers to a setting in my own firmware. It triggers pushback before the maximum allowed motor current is reached to leave a bit of margin there. I forgot to modify that along with the maximum which caused my board to push back much earlier than intended.
I’m using max 85A for motor and max 30/8.5A for battery, limited by my cells. What current settings do you use, I see you haven’t burned your motor yet
I can imagine your 12s pack is more suitable for this, my 10s3p of LG M29 cells could do with that extra voltage. Sadly there’s only easy space for 30 cells in the compartment, I could only fit the full 36 cells by removing BMS and the connectors, which I’m loathe to do.
In the future I’d like to put in a small OLED screen, visible on the frame while riding, as well as bluetooth for telemetry. In the meantime, it now spits out a bunch of basic data out of the USB programming port, which can be shown on a phone on the go. Not ideal, but better than nothing.
Also looking at this small, slightly janky looking analog BMS: aliexpress. It’s small enough to fit in the space between cells in the battery housing, and having a charge-only BMS might be smart anyway for a onewheel. Getting rid of the current Daly BMS as well as the cable connectors would free up space for 6 additional cells, for a glorious 12s3p pack of VTC6:s (cheaper than 30q where I’m at). That would move the Redstar from being basically a onewheel Pint with less torque, to a XR with less torque
Should put in some way of measuring individual cell voltages and temperature too. Temp is easy, just a resistor and the board has analog inputs to spare. But monitoring the cells seems to be trickier, haven’t found a small enough board to do it yet. A BMS with a communications interface would be ideal, but the size is the issue as usual here.
If you are not going to use the BMS for discharge functionalities. Perhaps you can make a hatch with a balancer cable underneath so you can plug in an external BMS while charging?
Next up, adding a cute little OLED screen. I’ll make a bunch of different modes for it which can be toggled, showing velocity, battery info, current, trip odometer, last reason for pushback and so on.
Gonna have to slather it with conformal coating. Bit worried about the whole thing, as pulling any wires outside of the box goes against the original “put everything inside armored metal boxes made out of 6mm aluminum” philosophy. What if the wires get chafed and short the CPU’s 3.3v line Maybe some 10 mA fuses
Yeah more of a suggestion of a wire really. It needs to be weak enough that the micrcontrollers output drivers can break it if shorted so those couple of atoms just have to do.
Made a paracord handle with some instructions from youtube, turned out good! At 14 kg Redstar is quite a thing to carry around, it weighs couple of kg more than the Onewheel XR despite being smaller due to the full metal frame
And there it is! Sadly, drawing on that screen takes about 5 ms, which will cause some gyro updates to be missed. It’s robust enough to deal with that but I’m not comfortable with that happening. I’ll need to figure something out if I want to keep using the screen while riding, and not just display readouts while stopped.
That would be a good solution, from a safety point of view as well. Communication could be one way so the main Arduino would just “scream to the void” and so wouldn’t lock up if the other one does (or the screen, or the i2c connection…).
For now, I solved, or rather bypassed the issue. The control was already 100 hz, so I simply dropped the refresh rate of all the IMUs to 100hz as well, and synced that to the control updates. That way, there’s time to calculate control, talk to the VESC and update the screen in each loop.
That would certainly do it. Syncing display write to happen right after the interrupt is served and making sure it’s fast enough to complete before the next one will arrive is what I’m doing now.
That’s an interesting library, I’ll keep it in mind! The Adafruit one uses ram because it is buffered, all the drawing goes in that ram before being pushed to the screen. I have used a hacked version of that with a SPI SSD1331 screen for a flight controller project, by erasing and writing only some particular pixels it’s possible to go really, really fast over SPI. To get some more headroom for this project, I overclocked the display’s i2c interface from 400k to 1200k which surprisingly works great and cuts down on transfer times by a factor of 3.
In this case, the microcontroller I use has a goodly 256k of RAM compared to a Nano’s 2k so no danger of running out (current firmware uses all of 4% of it), and the ability to use fonts and graphical primitives is quite nice. If 100Hz control isn’t enough, I’ll certainly look into getting rid of the display buffering.
Since the torque does not drop off with speed as much anymore, there’s actually more of it available at higher speed than with the stock y-termination.
