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 >:/
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.
- RS-485 Serial Interface Explained
- RS-485 Transceiver Tutorial
- ST1480AX Datasheet
- How do I measure differential signals
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.
Needed to dump my thoughts while I have another swing at this.
Pulled my controller to compare again. Seems I was right, the battery sends the first signal and the controller sits and listens.
With just the controller and the charger neither of the data pins have a signal present.
Hooked up the faulty 4206 to my board again this time with the RS-485 chip removed so I only see what the battery sends.
Got a few pics of the data sent, this was what appeared to be the first packet sent, it's a big one so presumably that contains all the BMS serial data and status.
Noticed this packet repeatedly being sent, assuming this to be updates on the battery voltage and temperature.
Currently no point in decoding the signal since the error is a lack of it reaching the chip.
Nothing else here to test till I've then checked signals again on the other side so I need to put an RS-485 chip back on.
Grabbed a fresh RS-485 chip from the new texas instruments batch and soldered that on to see what signal I get and... wait... hold up...
(screamed so much I went light headed...omg...)
NotSure last edited by NotSure
(screamed so much I went light headed...omg...)
Wrong thread. This belongs on r/blackmagicfuckery. I'm still in awe. congratulations @Lia . and @HanahsDax too! had to convert it but there it is! 11K km is approx 6900 miles just to be sure it wasn't urs..
blkwalnutgrwr last edited by
@Lia -- You fixed it! Exciting news! Congratulations! Great work!
@NotSure Felt like it, I kept staring at the app for a solid 10 seconds wondering if I somehow wired my controller to it which was laying across the room. I still don't believe it honestly xD
On a slightly sad note I got to watch the controller slip many positions on the mileage list. That being said I'm happy knowing it won't be stuck at 11214km anymore.
@blkwalnutgrwr Thanks :) Just the home stretch of putting a new motor connector on it, giving it a few test runs to make sure it doesn't die again then ship it back :)
Oh-my. Another success story drived by great skills and persistence. Gratz!
blkwalnutgrwr last edited by
@Lia -- Very impressive to me in your process: The two oscilloscope images and your very sensible interpretation of them.
@blkwalnutgrwr Thanks :)
The signals look really simple, presumably a chip could be made to replicate that first packet from another board then continue passing through the rest as normal to bypass FM's serialisation on later models so you could pack swap again while retaining the functionality of battery updates. That is assuming there is a working BMS to clone the signal and they don't send repeat serial checks.
Personally I'd call it a doppelganger chip (or DGang chip), but I'll leave the naming to whoever actually builds one since I barely have a working grasp on this lol.
@Lia all u need is a tiny cnc for carving ur own pcb's, a toaster, and a decent reflower (toaster ovens aren't decent reflowers imo) and i bet ur current skills are more than sufficient to get started. I sorta biff it when it comes to the patience lol. caveman smash!
@NotSure Aha not even going to touch this one with a barge pole. I don't own an XR that would spit errors at me if I got the serial data wrong, let alone a working knowledge on how to efficiently clone, store and send the data D:
Plenty more technically literate floaters that could do this. JW essentially did something similar with their little JWFFM chip although the purpose was slightly different.
Prepped it all to go back together. Replacement motor port came so took the time to remove old solder and put this new one on. Managed to find one local so shipping wasn't too long or pricey :)
Got the last one they had in stock too >:D
What I didn't realise which had been throwing me off while searching is the plastic under the port in all of the product images is actually just a removable piece to protect the pins. Ended up asking Reddit and everyone said this was indeed the right one.
I'd been thinking that was just a variation of the port and just couldn't find the right one. Doh...
Afterwards did some testing and found literally all the pins on the motor/footpad connector were dead. There is a tiny space between the PCB and the port so any excess force closes the gap and severs the traces and solder.
Probably what happened to mine last year so did the same fix which holds up for me and I bet will outlast the other solder joints.
Put some hot glue over the wire joints then re-assembled the housing. Dragged Slushy's controller out and slid the 4206 one in to take it for a small spin round the apartment.
All works from what I can see. Sensors, bluetooth, gyros, ESC and charge port :D
On a slightly different note from the brief ride round in the apartment I noticed the 4206 and 4208 seem to ride ever so slightly differently. 4206 feels slightly more locked in and elevated than my 4208 which tends to have it's nose down a bit more and feels loosey goosey (which I enjoy regardless).
Left it on charge for the night so I can give it a proper test tomorrow to make sure it is rideable before boxing it up and sending it back to continue it's legacy.
Didn't think this was worth making a new reply so added to the end of the last one~
Alright did testing, works perfectly fine :)
Went out to pickup a drill press and took the controller for a spin and then later rode around with my sis on the Pint as she wants a PintX so... had her practice on my Pint offroad for my second test.
My suspicious were correct, the 4206 is so much more locked in than my 4208. It feels snappier and more awake which took a little bit of adjusting to my usual ride style. My timing for speedbumps, curbs and terrain shifts needed a lil tweak.
Put Slushy's controller back in and now decide how best to ship this back since something else is going in the box.
Presumably this'll be the last update before Dax has it back :)
For anyone curious what the end result of this all was. R49 and U17 had died.
Both had shorted which caused the battery to no longer report it's statistics to the controller which generates error 16.
If your board has error 16 and the harness looks fine check if R49 is reading open and replace it with an equivelent resistor (121ohm in this case).
If that still doesn't work purchase a VP1781 RS-485 Transceiver and replace U17 with it. Make sure all the pads are connected and that there are no dead traces to and from the chip.