The dreaded Error 16 code

  • @stinkyface It was a 4206 ordered on 05/22/18 and was received 06/19/22. I remember checking the “Dude, where’s my board?” feature on the shipping info everyday. I ended up taking half a day off work the day it arrived and recorded my first ride which I titled Genesis and made up public on the ride section of the app. I used the board everyday expect for one which totaled to 1,038 days of use. Its ending mileage was at 6968 and I topped out at #49 for overall mileage the day it died.

    @Lia Thanks for the offer, I may take you up on that. My original idea was to make a tribute with the rails and PCBA sort of like the one you did for your Vega. To be honest I wanted to give the board a makeover several miles back but couldn’t cuz I loved the pic you created of me and wanted to keep it resembling the artwork piece.

    @blkwalnutgrwr I’ll post a pic of what I got. I actually have a plus controller I disassembled a while back and found a plus battery cell pack minus the casing, BMS and wiring harness so I could possibly create a plus with XR rails if the BMS in my original battery pack is able to accommodate a plus cell pack and is in decent working order. Thanks for the suggestion.

  • @HanahsDax A tribute would be cool, but I feel that board has so much more left to offer before it's retired. I bet we can get it working again :)
    The brain of it clearly works as it connects to the app and processes everything. All that's stopping it is the controller not seeing the thumbs up from the BMS. Might take a while but I'll reverse engineer a schematic from mine if I have to in order to find the loss in communication.

    Don't worry about changing the style, I'd be more than happy to do another once it's settled into it's new look. Will need some new vids for source material though so another reason to get you back on that XR ;)

  • @HanahsDax -- I concur with Lia, get your XR back in action!

    If you are building a Plus, I have a BMS/battery-pack/case/&harness you can have. I took it out of my Plus this spring and have been using EGO batteries exclusively to power my Plus (and my V1, too).

  • @blkwalnutgrwr you got first dibs on whatever part you want/need/desire.

  • @HanahsDax -- Nice collection. All I need is a motor -- the well used one would work fine or the hub with no tire (although that one looks brand new) -- and a sensor footpad, which I like looking beat-up since they get that way quick anyway, and yours looks new, although I would take it. Let's talk prices in email. I am excited, I have been looking for a suitable motor for almost a year now.

    Are you sure you want to disperse all those painstakingly collected Onewheel parts? My own collection of parts has not happened overnight, it has taken three years of watching, thinking, acting quickly, and gambling a little, too.

  • Hi All,

    The patient has made it's way to me and I've spent this morning taking a look.

    So far all checks out as we left off. Board powers on, everything measures normally but if you get it in a startup orientation error code 16 rears it's ugly head.

    Did some probing and found resistor R49 was dead. This resistor runs between the green and white wires from the BMS which I assume to be RX and TX by the colours. These are pins 14 and 6 on the big 16 pin connector leading into the controller from the battery. I've highlighted the traces for you on a pic from my board.
    The resistor connects both RX and TX just before entering U17 (I don't know why, maybe some pull-down solution). When measuring between the pins I get an open circuit so R49 has died open.

    R49 is an 121ohm resistor according to the silk screen and I confirmed by probing my controller's pins 14 and 6. 121ohm resistors are.... uncommon so I made a 122ohm resistor from a 100ohm and 22ohm resistor in series.

    Removed the dead one and wired in my resistor further back to give it more of a contact pad to solder to since these are larger and there are high voltage pins just next to it.

    Alas, still error 16. This leads me to believe U17 is faulty which could have caused R49 to die. Unfortunately I can barely read the silk screen on it. I can make out the ST logo meaning it's a SGS Thomson chip.

    I can just make out what appears to be 14 _ _ _ _ and below that either GX _ _ _ or 6K _ _ _. I'd take a pic but my phone refuses to get anything but a smudge.
    I've toned back what appears to be Gnd and Vin for U17 so it looks like it should be getting power although I have yet to verify what is present on those pins when active.

    Possible issues I've got it down to is

    • Debris on the board is causing interference, gonna give it a clean later.
    • My resistor replacement, albeit the right resistance may be inducing some other quirk that's ruining the signal.
    • U17 isn't getting the right power input from elsewhere in the board.
    • U17 is dead.
    • A broken component/trace between U17 and the main ARM chip
    • The ARM chip is faulty.

    I don't think it's the last once since the rest of it works so unless something dumped voltage on some sensitive pins I can't see why that would be the case. My concern is if U17 is a programmed chip or I just cannot locate what it is. If so I'll need a donor board. I assume I might be able to pick up a "dead" one from somewhere if need be unless anyone has one lingering around they'd be happy to sell me for transplanting U17.

    Edit: Looked back through my notes, the black pin being Gnd for the BMS's communication appears to come in on pin 5 but after a bit of tracing I actually cannot find where that pin comes back out.... maybe... just maybe.... that's the fault.

    You've seen how many vias are on this board... gonna be a while >.>

  • @Lia said in The dreaded Error 16 code:

    The patient has made it's way to me and I've spent this morning taking a look.


  • FOUND IT!!!!!
    U17 : ST1480AB. Got the datasheet toooooooo.

    Looks like the dead resistor was needed too. There's an implementation on another doc I found with a similar chip but paired with another to act as send/receive either side of the line. Note the 120ohm resisistors either end of the A/B lines.
    (changing the values shouldn't matter as long as they're the same either side which seems like why I haven't fixed it yet)
    I won't pretend I know more than some very basic stuff on these sheets, a lot of it is beyond me. I've gathered enough to verify the chip is being fed the right voltage though now and what pins are what.

    Better yet though, this chip isn't programmed, it's just logic gates so if it's shot I can just get another.

    Still haven't found where that ground pin has gone though, poked a few other tinkers to see if they know before I pop open Slushy to see where her's goes although I feel like this may be a red herring.

    In the meantime since there are 2 resistors, 1 either side I assume both have to match so I'm going to order an actual replacement SMD resistor. When stuff like this fails assuming they don't cascade then only one thing is bust. It may just be this resistor after all and I'm just big dumb!

    EDIT: Ordered the appropriate resistor, figured out what one I'll need to appropriately replace this. On the downside I'm waiting a week :(

  • @NotSure said in The dreaded Error 16 code:

    @Lia said in The dreaded Error 16 code:

    The patient has made it's way to me and I've spent this morning taking a look.


    from planet catwheel trying to phone home

  • Swapped the resistor, issue persists!
    alt text
    So that means the ST1480AB chip might be dead. Good thing it's replaceable.

    Having to order from China because Mouser, Digikey and Farnell are all out of stock for this chip with an expected wait time of November. Found one on eBay so ordered that. Gonna take a while since shipping seems to be economy.

    While I had the board out I gave it some more poking with the multimetre. Traced back the pins on the other side of the chip, they all lead back to the ARM chip (stm32f103VB) as suggested by the datasheet for the ST1480AB. The actual via's are under the chip so I spent a while probing everywhere coming up empty till I realised there were some under the chip I had to probe from behind.

    Here's what that all looks like.

    The other 4 (3 since 2 are connected) pins coming off the ST1480AB appear to go back to 3 I/O pins on the ARM chip. They'll be programmed in the firmware for reading the data. Assuming those are where the pins are meant to go then no break/short appears to be present.

    So with that all in mind it brings me back to ST1480AB is bad or... the Arm chip. Fingers crossed it's the ST1480AB otherwise some sort of hack will be needed to tell the ARM chip to ignore battery info if at all possible.

    I'd like to imagine it's ST1480AB that died and in turn caused the resistor to die, or the resistor died and caused ST1480AB to die... Either way it makes more sense that it's the problem. We'll have to see when this replacement comes in... a few weeks >.>


    Edit: So looks like even if the main ARM chip is dead some people have managed to extract the firmware from this type of chip already. If this one is dead there could be a chance that I could extract the existing firmware and write it to a new chip that isn't faulty.
    alt text
    Here's a video of someone doing it to the same family of chip.

    Edit again: Still waiting on this ST1480AB chip to arrive.
    Shipping from China is so slooooooooooooooooooow

  • Chip arrived early but I still get the same fault.
    Dunce Fox.png

    Silver lining to this is I haven't killed the board further or mine while using it as a donor for testing.

    Removed the old chip and compared it to the new one before soldering and found that pins 7 and 6 have a resistance between them on a fresh chip but not the old one.
    Ignore the slight variation in silk-screening, they're the same ST1480AB chip just made at different times and probably a different country.

    This implies the old chip has failed open much like the 121ohm resistor had. Whatever caused it isn't present anymore since the new chip and resistor haven't died, question is what still is? I really Really REALLY don't want it to be the ARM chip...
    Onewheel Error16.jpg

    Going to take a step back and think a bit more on this, pick a few peoples brains and for good measure beg FM's support to give me a hint.

    One thought came to mind, wondering if during development of the different hardware revisions they swapped the data pins from the battery. This is HW4206 and mine is HW4208 so if they did between those then they'd fail to communicate. Going to verify that first by asking around before just blindly swapping data pins.

  • @Lia -- Impressive work you are doing! Best of luck and good wishes on this!

  • @Lia, I really love your artwork! Great story telling. :)

  • @blkwalnutgrwr Thanks :) If anything comes of this hopefully it guides another person having this issue in the right direction. This seems to be a woefully uncommon fault.

    @HorsePlay Aha glad you like it, can't take credit for that sadly. I just modified the original meme which in itself was a re-drawing of another.
    Sadly whoever did the re-drawing of it didn't leave a signature or anything in the corner so it's unclear who actually made it.

  • Needed to take Slushy apart to modify her power button and fix the front light that's been flickering like mad for the past few months. Decided to compare both the controllers and see what might explain the failure of the 4206.

    Here are both controllers almost exactly matched in framing for comparing.

    Small differences, one of which I think is how FM disabled CnR on later models, I'll go into that later.
    HD versions below.
    Onewheel 4206 vs 4208 (4206).jpg
    Onewheel 4206 vs 4208 (4208).jpg

    So far other than minor variations in resistance across certain parts I've been looking at seem to be present but nothing that looks like a short where there shouldn't or an open line where there should be resistance.

    Going to keep poking, eventually I'll find a significant difference, failing that a redditor suggested I probe the signals coming in and out of the chips to see if they're actually doing anything.


    Regarding the CnR theory from earlier, after 4206 CnR was impossible. Plugging a charger into your board prevented you from riding it. Before you could just connect up a battery to the charge port and away you go. The disabling of CnR will have been hardware related otherwise we'd all be unable to do it if it was purely firmware.

    Onewheel XR Charger Input.jpg

    Comparing the 2 boards it looks like an additional diode (D31) and resistor (R34) between Batt+ and Batt- makes it's way to a formerly unused pin on the Arm chip being PD8. Presumably tampering with this new circuitry might enable it. I don't think it will be as simple as cutting the trace to PD8 but I'll see.

    Edit: Apparently this was already solved lol. Clearly I don't keep up. Can't find instructions but a guy in this vid says "cut the resistor" which I can only assume is R34.
    Gonna test it out and see if that actually works.

  • @Lia said in The dreaded Error 16 code:

    Comparing the 2 boards it looks like an additional diode (D31) and resistor (R34) between Batt+ and Batt- makes it's way to a formerly unused pin on the Arm chip being PD8. Presumably tampering with this new circuitry might enable it. I don't think it will be as simple as cutting the trace to PD8 but I'll see.
    Edit: Apparently this was already solved lol. Clearly I don't keep up. Can't find instructions but a guy in this vid says "cut the resistor" which I can only assume is R34.
    Gonna test it out and see if that actually works.

    Lol... soooo... why did they disable it? just curious.

  • @NotSure FM don't like battery mods, each major hardware revision usually has measures in to prevent the latest ways to add range to the board. CnR was the first to go and was the simplest way to charge on the go without warranty voiding methods.

    I imagine it's down to the bad press they'll get when someone's modded board catches fire or injures them. Headlines don't typically explain the nuance of a given situation so they'll probably just say "Death by Onewheel" and suddenly our boards get lumped in with all the other "dangerous" self balancing products :(

    Personally I think CnR was the safest of all the methods minus the chance of snagging the cable and destroying the port if you roll the board. All variants after it involved a fair bit of DiY that results in absolute destruction if something goes wrong.

  • Found a difference!

    On my board probing between either of the signal wires from the battery and ground results in an open line.
    On the faulty board between either of the signal wires from the battery and ground results in a resistance of a few mega ohms.

    If I remove the new chip that goes away, if I add the old one I get 121 ohms, the resistance of R49 suggesting a short in the chip.

    Probing the faulty chip again I get a short between pin 6 and 5 (white data line to ground). Not sure if this happened when removing the chip but even with the new one something isn't right suggesting the old chip is faulty and the new one isn't quite right. According to the chip specifications the chip is designed to handle a short in this manner so it's possible the arm chip is safe (hooray).

    Another thing of note is they changed the chips between models. On the 4206 the RS-485 Transceiver is a ST1480AB but on my 4208 it's a VP1781.

    Going to try one of those instead under the assumption that maybe... just maybe the eBay ST1480AB was a fake/wrong or for some reason the corresponding VP1781 in my battery doesn't want to talk to a ST1480AB on the controller. Not sure why since I don't believe anyone else has had issues changing boards but this at least seems like a worthy thing to chase.

    Noticed on part of the datasheet the pinouts appear to be swapped on A and B however looking at the actual pin layout I can see they are correct.



    Going forward with the replacement VP1781 since the chips differ in terms of their internal resistances enough that I assume you shouldn't mix different brands. Fingers crossed.

  • This delivery time is killing me >:/
    alt text

  • So the chip arrived. Same issue...
    Looks like it's not the chip then, can't see how 2 alternatives would have the same issue if they were at fault.

    Guess I best learn RS-485 signalling and how to use my osciloscope. I'm already down 2 monsters... send help lol.

    So I'm now looking to find out if there is any signal coming from the ARM chip.
    Below I'm first testing to see if any signal exists on either of the A/B pairs leaving the 16 pin connector to the battery. As you can see I get a noisy non existent signal measuring peaks of only a few milivolts. That's 1000th of a volt, the differential signal should be at least 200mv. In other words... no signal is present.


    So I now try to measure before the RS-485 chip to see if the ARM chip is feeding it anything.
    I'm seeing a constant 3.2v voltage on the receive pin and constant 0v on the transmit pin. So no signal at all.


    So what does this all mean?
    Well looking through the specs and how these things work it looks like the RE and DE pins enable/disable transmit or receive.
    RE and DE are connected together and wired to Pin90 on the ARM chip. The way this works is when pulled low (no voltage) the receive pin is enabled and transmit is disabled. When high the receive pin is disabled and transmit is enabled.
    This way the chip can only listen and not transmit or vice versa when instructed to by pin90. Hence the chip being listed as "Half Duplex" (Half-duplex devices can only transmit in one direction at one time).

    Because of this it makes sense there is no output on the A/B pins as there is nothing on the circuit sending a signal (as I have the battery removed).

    I assume RE is pulled high at 3.2v constantly is because it requires a signal coming in on the A/B pins to pull it low to create a signal, like below. (Linky)

    With that all in mind I assume once the battery sends a signal to the controller RE/DE get pulled high meaning R goes to 0v and D should send a signal causing A/B to show data in a differential pattern. This is how I believe it should work, assuming I'm correct I can start picking apart the data and find WHY it doesn't communicate.

    I've reached out to another redditor that said they work with RS-485 to see if my assumptions so far are correct before I connect my battery and try reading what happens at each pin.

    If anyone is interested in this I've linked below some resources I was using to try figure this out.


    Not giving up on this, there has to be a fault and a fix/bodge I can do to rectify this! I refuse to let this legendary controller bite the dust.

Log in to reply