The dreaded Error 16 code



  • 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.
    IMG_7670.JPG
    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.
    Onewheel-4206-vs-4208.gif

    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.

    ST1480AB
    da87b4f1-5aba-4b13-b389-8994a32e7a6d-image.png

    VP1781
    b429885c-324e-4128-b7c9-a698bfb822ef-image.png

    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 >:/
    9378f5db-551c-4d2c-bb8a-8f592027796f-image.png
    alt text



  • So the chip arrived. Same issue...
    930b7bc5-5f5d-4ee5-9225-368cd1014945-image.png
    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.
    IMG_8051.JPG

    IMG_8052.JPG

    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.
    IMG_8067.JPG

    IMG_8066.JPG

    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.
    0f70d6b8-2aa2-4754-ae83-658134f47594-image.png
    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)
    e467f8b0-1d81-4082-8113-e77609579be8-image.png

    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.
    639.gif

    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