Eahora M1PS Knight Restoration

[chuyskywalker]

I think "120" is not the voltage you can run, it's the max voltage on the components.

120 is the voltage, direct from Vedder himself:

At 26s I would still use a Maxim 120 unless you have significant voltage sag in your battery during regen. All voltage regulators, gate drivers etc. are rated over 150V and MOSFETs in a full bridge can usually operate quite close to the limit. The main advantage if the Maxim 120 over the Maxim 150 (except the lower cost) is that it has less than half the MOSFET resistance and capacitor ESR, so it will run much cooler on the same current and it can handle more current.

 

[chuyskywalker]

How about 2 blobs of silicone between the plates? After it cures, shorts will be highly unlikely.

The photo might be deceiving in size, it's a very large gap. I could probably still bridge it do lock it all in place, but it'd really want to get everywhere and be a real pain if I needed to redo something later. I've got some decent spacer ideas going, so I'll keep explore that route for now.

 

[Zambam]

The photo might be deceiving in size, it's a very large gap. I could probably still bridge it do lock it all in place, but it'd really want to get everywhere and be a real pain if I needed to redo something later. I've got some decent spacer ideas going, so I'll keep explore that route for now.

Yes, hard to tell gap size w/o a ruler in the photo. How wide is it?

Cut those rubber tabs you removed to fit the gap then apply some silicone to hold them in place. If you need to do repair later, thread some dental floss in there to cut the silicone. If dental floss don't work well, use a ceramic knife.

 

[chuyskywalker]

Iterations, from left to right:

1 & 2) A "clip" that would install from the front. Probably could have worked, but needed to be more flexible (later realized I was printing with PETG-CF, carbon fiber infused, when I though it was just PETG -- doh! Which, btw, CF is conductive, so probably not a good idea to use here, lol.)
3) A big 3d printed fixing plate, made WAY too many holes.
4) Better, but this is a 3d printer, not 2d...
5) (white) Now we're getting somewhere; this isolates each plate, has some depth, and creates an "exit" for the balance leads.

All of these designs suffered from one flaw, though, in that they assumed all the battery tabs would be aligned and that the fixing plates would be perfectly parallel. If I kept all the through holes and slots and tried to just make them all big enough to allow for rotational slop, it's get kinda silly.

The concept did bear fruit in the form of a stand-alone version:



Which certainly could have worked, but I wanted one last try at a "single piece" setup. I wanted that "all lined up as best as possible" look!

To tackle the problem of being too accurate with the through tabs and hole cuts... I just eliminated them entirely:

This has enough rim for the fixing plates to sit on top of the plastic, but not enough room to "fall through". Additionally, each set of plates is now sequestered into it's own little space. The top and bottom are open for wire cross overs or the pos/neg end of the battery off to the BMS. One of the long edges is recessed to match the plates' combined height so the balance leads can come out.



It works super well. Keeps all of them nicely away from each other, but also provides protection while installing the plates so they're very unlikely to short during install as well as while in use.



Now just gotta print three more of them, reinstall the second "rear" side, and start on the side that can go sparky zap zap.

 

[chuyskywalker]

Got the BMS leads soldered up. While technically the battery can handle 500A, and the BMS can theoretically push 600A, the controller can do 440/660 continuous/peak, the motor is going to be the large limiting factor. I don't really expect it to handle more than 1-200A continuous. As such, I'm guilty of undersizing on the wires a bit, compared to what the bms/controller could potentially use. 8AWG for the negative, 10AWG for the positive leads. The charger is 12awg, though, since the BMS peaks at 30A charge rate. (Don't know where I'm going to find a 96 charger for that -- 109.2V X 30A == 3,276watt charger, lol.)



The battery has come out very nicely, though. The 3d printed plates were a huge success!

Then I spent an ungodly amount of time putting numbers on the BMS leads and triple shrinkwrapping.



1) Shrink on labels, all 27 of 'em
2) Shrink on clear over that (protection and the label shrink doesn't get small enough to not slide all over).
3) Bundle up the leads nicely each "layer" getting into a new pieces of shrink wrap

BUT, the results are dope as heck:



You can also see the pack leads here as well. I ended up just using some 0.1mm copper I have, folding it over, and making my own "tabs" with holes so I could attach leads and a fuse on the positive side (250A).

Now I've got to wire up all the JST plugs and solder the lines on. After that I should be able to actually make the battery "operable". So far all the voltages come out correctly, and nothing sparked during the build, phew!

Then I can finally get around to the outer case I've been putting off.

I should start on the bike re-wiring...oh, and temp sensors...

 

[amberwolf]

Shouldn't the det cord be longer?


Serioulsy, though...that's a nice battery (re)build.

 

[amberwolf]

. (Don't know where I'm going to find a 96 charger for that -- 109.2V X 30A == 3,276watt charger, lol.)

Couple of Sorenson DCS-55-55's in series should do it. They're not small, nor cheap, though. (the one I have on my electronics workstation table takes up about a tenth of the whole table)



Might be able to use a series pair of telecom chargers like these:

Rectifier Huawei R4850G2 48V 42~58V 3000w

What do you think of this rectifier? High efficiency > 96% Ouput voltage 42~58VDC, default value 53,5VDC Ouput Power 3000w (176~300VAC) Weigh =< 2 KG The datasheet...

endless-sphere.com

 

[j bjork]

You can run 2 series connected "48v" psu:s set up to the voltage and current you want, or run one of these modified ones like this for example:

https://www.aliexpress.com/item/1005008348463486.html

 

[chuyskywalker]

Things have progressed, but with a lot of "dealing with reality"'s.

First, the battery case got made up. Polycarbonate sheets and some weld-on4 tack it all together. The top piece is a two part 3d print with some heat set inserts to bolt through holes drilled in the case sides.

I used a 3d print that wraped over the sides and had marker'ing holes for where I would need to drill out:



Worked mostly well. Later on I found the holes not quite perfectly aligned and needed to drill out a few a step or two higher in the bit set. Not the end of the world, but certainly another excuse to get a CNC again so I can cut out my own sheets and all the features needed therein. (Would be have been especially helpful on the "divots" I needed to make on the bottom of the case where the tubes began to angle up early and I needed the rest of the bottom to sit flat.)

Frustratingly, though, the box ended up hitting the main support beam of the bike. On the bright side, the walls were extra tall on purpose, which gave me some wiggle room to adapt. With the help of a set of ever enlarging router templates:



I was able to trim down the rear wall to fit nice and snug around the bike. Honestly, it's kinda cool and really makes it feel like a part of the bike, instead of something just slapped-n-strapped in.

Once that was setup, it was time for allll the test prints to validate the lid. Does it fit side-to-side (no, make it a bit wider), do the bolt holes line up (they did not and needed slight positional tweaking), do the round-overs match (they did!), etc.



Many prints later, and it's fitting good enough. It's definitely not perfect, but it fits well enough that I can move on.



I had some quirky problems with the BMS that required some reflashing to get it to the latest version (early adoptor standard fare), but that's otherwise sorted out it seems.

I still need to drop the battery in the case and get it "locked in". Both internally and externally. Inside, it's going to need a good bit of padding. Externally, I need to figure out how it attaches to the bike. Right now, I'm leaning towards printing something I can screw onto the bottom-front of the battery that will dip below the tubes it is sitting on to prevent side-to-side motion (prevented in the rear by the cutout) and then maybe...a strap to keep it held down? Some bolts from the bottom would be better, but not quite sure how to rig that up yet. Though, I do think some support along the middle of the case in the bottom tray would be advised (even though I'm pretty sure the 1/2" thick polycarb would be fine).

Really big next steps are going to be the controller, display, and maybe this new fancy thing VESCLabs released, their "remote" RMCore which let's you bring controls in at the RMCore location (throttles, lights, switches, etc) both input and output, and then canbus that data back to the controller. Helps clean up wiring. Not sure it's for me though, honestly, because should have plenty of wiring space since the 3 phase and 2 power cables are no longer in the hidden tube run.

 

[lnanek]

Ah, interesting approach with 3D printing the edge guides. I recently 3D printed corner clamps for glueing my laser cut clear acrylic projects:

Corner Clamp by PirateSands2 | Download free STL model | Printables.com

But I actually don't care about the edges being transparent too much. Maybe I'll just 3D print some edge guides next time.

 

[chuyskywalker]

I recently 3D printed corner clamps for glueing my laser cut clear acrylic projects:

I very much considered that, but being able to toss in the drill hole locations at the same time helped a ton. Clamps would have been better for the glue up, as it did want to shift around a bit, since what I printed wasn't super tight.

 

[gromike]

Do you have a VIN? That thing will be a rocket ship.

 

[chuyskywalker]

Do you have a VIN? That thing will be a rocket ship.

Yes, fully titled, plated, and insured. Was actually easier to get that all done than with my scooter.

 

[amberwolf]

THe battery box gave me a flashback...

 

[chuyskywalker]

Some light progress. I added some "tabs" onto the battery box (plastic solvent welding is cool) and put some m5 rivnuts in this handy cross beam in order to secure the battery box down.



The front tab uses some M6's welded on for the original insert piece. Had to bend one of them back to level, but otherwise not too much hassle. Marking where to drill was...an exercise. On the rear piece, I managed to sneak a small drill bit up through the rivnut and scratch the poly where I should drill. For the front, I took off a body piece and was able to stick a sharpie through the mounting tabs.

Then I started to dig into the wiring job I've taken on. There's....a lot. The left and right handle bars have:

1. (right, 11 wire connector)
2. throttle (3 wires)
3. hazard (3 wires, surprisingly. 1 in, dual out)
4. light selector (3 wires, off, running, running + headlight)
5. mode button (2 wires)
6. (left, 10 wire connector)
7. horn (2 wires)
8. blinkers (3 wire)
9. head light low/high (3 wires)
10. park (2 wires)

It would seem the manufacture of these controls didn't believe in shared inputs.

In addition to that, each brake has a 2c, the blinkers are each 2c, the headlight is 4c and the key is 2c. So, another 14 wires coming off the "front". In total that's about 35 wires I'm gonna end up snaking down to the tray area of the bike so I can do all the wiring there. I could certainly combine some of these things in the "tank" to take less wiring down to the controller, but it wouldn't reduce it by enough for me to hassle with "now, where did I make that connection?" later on.

It'll be an interesting combo of sending power just back up to the handle bars vs using the controller to take inputs/outputs. The controller harness can handle a lot of these inputs/outputs, and the controller should have enough 12v power built in to run everything. (Nice to not have to put an extra 12v dcdc step down on the bike.)


(VESCLabs Maxim 120 Controller Pinout)


I made a "simplified" wiring diagram of some of the more important connections I've got to wire up so I can start to work it all out. I left off a lot of redundant things in there like all the ground connections. I'm also switching a few things around (like reassigning mode to cruise instead; likely removing "park" for something else too, probably reverse).

The controller has some interesting....quirks to it. The whole LBM (LispBM) setup on the ESP32 does some interesting things. For instance, the blinker inputs go into the controller and there are 12v outputs for each blinker. So, instead of putting a flasher relay device thing on the blinker lines, instead you wire up something like this in the controller code:

(def lblinker 0.0)
(def rblinker 0.0)

(defun main () {

    ; Setup the blinker pins as outputs
    (gpio-configure 19 'pin-mode-out)
    (gpio-configure 31 'pin-mode-out)

    ; Setup these pins for reading values
    (gpio-configure 12 'pin-mode-analog)
    (gpio-configure 11 'pin-mode-analog)
   
    ; thread to blink if the blinker input is high
    ; includes the on AND off of the blink so that
    ; the blinker doesn't get stuck on if the loop
    ; only did one or the other
    (loopwhile-thd 150 t {
        (if ((or (>= lblinker 1.0) (>= rblinker 1.0))) {
            (if (>= lblinker 1.0) (gpio-write 19 1) )
            (if (>= rblinker 1.0) (gpio-write 31 1) )
            (sleep 1.5)
            (gpio-write 19 0)
            (gpio-write 31 0)
        })
        (sleep 1.5)
    })

    ; Thread that reads and maps the ADCs
    (loopwhile-thd 150 t {
        (setq lblinker (get-adc 12))
        (setq rblinker (get-adc 11))
        (sleep 0.025)
    })
})

(image-save)
(main)

(Wildly untested code at this point, but you get the idea!)

It's an interesting ecosystem. Still not a fan of LISP (I just can't english-brain things like the or statement above), but it's not going to break the bank for making simple additions that would otherwise require much more complex solutions. Well, ok, a blinker flasher isn't a big deal, but you can take this further. For example, if you press the brakes, but the pull very high values from the built in accelerometer, instead of just activating the brake light "high" mode, you could also start flashing the turn signals as well to indicate really hard braking. You could also add some LEDs to the bike and have them change color based on other conditions.

I'm sure there's a bunch of things that before were just "oh well", but now there's some relatively simple way to get custom logic into the controller. Kinda cool.

 

[amberwolf]

It would seem the manufacture of these controls didn't believe in shared inputs.

That means, hypothetically, that they are saleable to more users and companies, as they can be used in "any" system that needs such controls, whether common supply, common ground, or a mix of the two. So, hypothetically, it's more cost-effective for the controls manufacturer as they only have to build and stock "one" version of a part.

It's an interesting ecosystem. Still not a fan of LISP (I just can't english-brain things like the or statement above), but it's not going to break the bank for making simple additions that would otherwise require much more complex solutions. Well, ok, a blinker flasher isn't a big deal, but you can take this further. For example, if you press the brakes, but the pull very high values from the built in accelerometer, instead of just activating the brake light "high" mode, you could also start flashing the turn signals as well to indicate really hard braking. You could also add some LEDs to the bike and have them change color based on other conditions.

That's an interesting set of thoughts, uses.

In addition to that, each brake has a 2c, the blinkers are each 2c, the headlight is 4c and the key is 2c. So, another 14 wires coming off the "front". In total that's about 35 wires I'm gonna end up snaking down to the tray area of the bike so I can do all the wiring there. I could certainly combine some of these things in the "tank" to take less wiring down to the controller, but it wouldn't reduce it by enough for me to hassle with "now, where did I make that connection?" later on.

In dealing with this for my handlebar controls on SBC, with the long tiller down to the bottom of the "triangle" below it, I used an old multi-conductor-pair cable from...something. I don't recall what, as I tend to save cabling and mounting hardware, as well as useful fasteners, from equipment I am recycling or discarding (I also used to do this to ones found in someone else's discard pile, but I rarely ride around enough to do that anymore).

Anyhow, because teh controls on the handlebars are just signal controls, with the actual currents for lights, speakers, DC-Dc, etc, all being handled by the automotive relays down in the triangle where all the power wiring has to pass thru anyway, it doesn't matter that the big cable only uses something like 24AWG wires with a few strands of copper each.

Since each wire is a twisted pair, I can use it as signal/ground, or as a signal pair referencing a common ground, etc.

I do not pass any battery positive (52v) thru that cable, so the CycleAnalyst power is on a separate pair of wires. This ensures that any wiring fault or cable damage inside that cable can't put voltages hugely exceeding what the connected devices can take. It *does* still have mixed 5v and 12v signals; ideally I'd use two separate multiconductor cables for this but I didn't have two with enough wires each at the time, just this big one with many extra wire paires still unused in it.

Even more ideally, I'd use all 5v signals on the handlebar controls, and have them run opto-isolated relays down in the triangle. I have a board to do this, but have yet to have the time, energy, and motivation to get this done.

 

[chuyskywalker]

They just dropped this overview video for a full vesc motorcycle setup:

Along with the repo full of code, 3d models, and a rather nice wiring diagram:

GitHub - vesclabs/ts125: Suzuki TS125 from 1982 electrified with VESC Labs parts

Suzuki TS125 from 1982 electrified with VESC Labs parts - vesclabs/ts125

github.com

Which is pretty great as it's demoing a lot of what I'll need to get my bike up and running right in time for me to do these things. Their bike wiring diagram is a heck of a lot nicer than mine, lol, that's for sure. I'm still in the deep throws of extending control wires, but it's good to have a reference that shows I'm heading in the right direction.

In the mean time, I remixed the display mount to match the stock display position for the bike:



Came out pretty good, especially for a first go print. I'll likely make a second revision with longer arms that angle back a little bit more to give the wires a bit more room and also to "raise" the screen just a bit more above the key. In the last shot you can see how it looks from the rider's perspective. Ignoring the insta360 mount, it's almost clear of the key hiding back there.

 

[j bjork]

Looks nice with the (much needed) extra in and outputs on the controller
But do you have to write scripts to use them, or only if you want something unusual?
Reverse and mode input, finally!

 

[chuyskywalker]

But do you have to write scripts to use them, or only if you want something unusual?

Funny enough, Vedder posted a follow up video saying, "So LISP might be a bit intimidating..." in which, in the 24 hours prior, bro whipped up a UI package that you can load into the vesctool to configure all of that stuff instead of monkeying about with the code.

Personally, I'll still end up using the code (as I plan to have some divergence from what he's setup), but it's a pretty neat testament to the flexibility of the platform.

As a minor progress update:



Yay, controller mounted into the bottom tray. This will shorten up the battery and phase lines tremendously compared to having the controller up in the tank.

The downside, however...



Alllll the wires have to come down to here. Ok, technically, I could do some combining. However, especially at this point in a build, having the flexibility of individual wires is a big plus for me. Clearly, I also leave them extra long so I have room to maneuver. I will, of course, definitely, 100%, without-fail, certainly come back later on and trim these all up nice and neat. Definitely won't just cover up the rats nest with the battery and ignore it. Yup.

I'm also picking up a QS10 connector to go from the battery to the controller.



I will be able to use the 4 extra pins for can high and low between the controller/bms/display, and the other two I will use to complete the BMS's key/switch circuit. Basically, the BMS has two pins that, when shorted, turn on the BMS. I will wire it up so that pin one goes to a regular power switch on the battery case, then the other leg goes into one of the battery side qs ports. Another battery side QS port will go back to the BMS's second pin. On the controller side, the two key pins will simply be shorted together. In this fashion, the battery can't be turned on at all until the plug is connected. (Which works just fine, as the bms has anti-spark pre-charge built in.)

The key input, then, will go to the activating pins on the controller. I'm going with "activate controller" vs. "activate bms" because I actually want the BMS to stay on pretty much all the time, as I put GPS trackers in my bikes which need constant power. The GPS also alerts if the power is lost (which can informed me of malicious behavior, but more often it's helped me to catch an over-drained battery that needs to be charged asap.)

I've revised my rough wire diagram a bit to reflect some of these things.

 

[chuyskywalker]

Back from vacay, and back on to the project...



Finally got the controller to battery and phase wires sorted out. That QS10 is no joke, my goodness.

Did the battery side as well, including designing a panel mount for the QS10. For comparison, the XT connector next to it...



...that's an XT90.

Sheesh!

 

[amberwolf]

So the QS10 is like an SB50 anderson? Doesn't look big enough to be like the SB175 (next one up)

 

[Nix Liou]

So the QS10 is like an SB50 anderson? Doesn't look big enough to be like the SB175 (next one up)

The QS10 is mainly 2 10mm bullet connectors I believe. 170A continuous rating, 500A maximum (qselectronics.com).

I like soldering to them because the nylon composite holds up quite well to soldering, even with such a big joint required.

 

[chuyskywalker]

For some personal reasons, I am stepping away from high powered two-wheelers.

If anyone in the Bay Area is interested in picking this bike up as a project (I'll be working to bring it back to stock for easier FB marketplace sale), feel free to DM me.

 

[chuyskywalker]

(I'll be working to bring it back to stock for easier FB marketplace sale)

And so I did, eventually, get around to this. I went to put the original controller back in and...hrm. See, since I didn't plan to go back to the stock controller, I was a bit caviler with the disassembly. Didn't take pictures, cut off connectors, etc. So, looking at the unlabeled mess of a stock harness soldered together in whatever configuration eahora considered to be correct, I had absolutely no idea how to re-wire it.

I also lamented the lame (binary on/off) regen braking system that fardriver supports.

So, since I have the controller and no reason not too, I went ahead and kept on with that instead.

While wiring it up, all the connections became a bit of a wire mess. I got it all working, but it was decidely a rat's nest in the compartment. Figured I could do better, so I decided to try and make a "routing pcb", I'm gonna call it. Basically, just a bunch of screw terminal connectors for all the incoming wires (blinkers, horn, lights, controller, etc) and then wire jumpers on the board to make all the cross connections.

Flew too close to the sun and something shorted. Now the controllers is falling back to sensorless mode and there's a short between 5v and gnd on the controller. Shit.

Reached out to VESCLabs and the folks over there are, my goodness, absolutely top-notch. They supplied me with instructions on how to make an external hall array (needs some resistors, etc) and then upgraded the firmware to support reading hall signals from 3 other pins on the controller so I could get that functionality back. Try getting that level of individual support from Fardriver/Kelly/anybodyelese, lolnope.



With the hall signals sorted out, and the rat's nest back in place, all of the bike systems are functioning. I'll just live with the shame -- a very well labeled shame, mind you, but oh well.

I whipped up an "inventory" of the wires in the bike, along with a very amateur schematic attempting to detail the wiring schematic.



One of the biggest lifts by a LONG shot, however, was programming the sytem to get everything work in concert. It's a major flex, the flexibility of the VESC Maxim (and related) controllers, but it's also very young and the documentation/examples are few and far between.

First, a bit of topology. While the Maxim has a single 39pin connector, what's hiding inside the unit is two independant MCU's -- one is a STM-something-or-other and the other is an ESP32. The display also has it's own ESP32. Each of these are coordinated, primarily, via CANBus messages. As an example of this coordination:

The "mode" button connects to IOExpander pins that are, in turn, connected to the controller ESP. When you press the mode button, you need to register that in the controller esp and emit a CANBus message that the desired "mode" is now X (drive, 1, park, etc)

The controller STM needs to be listening for the message and actually change the motor control properties to enact the new mode. The controller then also issues a "mode X" message to the canbus indicating that the actual change has taken place.

The display listens for mode from the controller STM (NOT from the controller ESP) in order to update the display showing what mode is active.

There are canbus messages flying all over the place. Inputs, outputs, modes, stats, etc.

What's double tricky is that all of this is orchestrated in....LispBM -- a microcontroller oriented variant of Lisp. I've been a programmer for many, many years, but LISP syntax really stretches my brainpower, gotta be honest. The display rendering is also pretty raw, requiring fonts and images in a pre-made bin format and the tools for doing layout are very rough at this point still. On the plus side, I didn't really do too much advanced stuff for my display output, so that saves my bacon.

I did publish all of my code for this (vesc_pkg/dash35b-simple at simple-dash · chuyskywalker/vesc_pkg) but it's ultra specific to my bike, my wiring, and my busted controller. However, it could prove useful to others for taking and modding, should someone else go down this path.

Ultimately, the bike is back together now, back on the original battery, and has the upgraded controller and screen. It's once again alive and kicking, better than it was before. I'll likely put a few miles on it to make sure all systems are good to go, then see about selling it. (That said, the ebike/emoto market has been really cold as of late.)

No idea what I'm going to do with the massive battery from this build...

 

[chuyskywalker]

Vroom vroom

Some test riding / breaking in the bike. No problems, got some nice pics of it, now off to marketplace with it.