Vectrix VX1 MotorController OpenSource/DIY

[prensel]

I finally decided to put some TLC to my next project which has been gathering dust for ..say about 3 or 4 years....
This project is focussing on making a drop-in replacement Vectrix VX1 motorcontroller using as many of the OEM controller parts or better/cheaper parts together with the OpenInverter board.
At least the MC backplate/coolerplate has to be used as this act as the mounting plate as well.
Since the VX1 is using mainly CANbus comms between the InstrumentControlModule and charger (can probably be left out when using the OpenInverter charger capabilities) this protocol has te be implemented as well.

[marcexec]

Love the Vectrix, nearly bought one of the few in Ireland. The motor has an encoder, correct?
Maybe the Honda IMA-based Lebowski is the right size and Roger (Kiwifiat) sells conversion boards for this inverters - I'm running one myself.
Not much CAN, though, but likely tuneable to the funny throttle the VX-1 has (regen on roll forward).

Edit: also see viewtopic.php?f=39&t=6198

[skr]

I have also thought about this for some time, not sure if I have much time to spare for a project unless forced by a dead MC.
To me it seems that doing something like this project seems the path of least resistance https://github.com/kaminaris/GigaESC as FW is fully open source and all of the VESCs I have used have been eons ahead of other BLDC controllers in terms of functionality and actual "feel" of use.
I have not used any zombieverter to comment, so maybe it's a much more sane approach.

Problem is that no matter how you approach it (unless going the hacked IMA path) - it would still end up costing 500+ish € when all is said and done.

Another problem I see is lack of compact power bricks for HV->12V dcdc, so most likely something like GigaESC power board + external server power supply should be used to run all of the other onboard electronics.

[skr]

A new MC or dremeling automotive inverter to fit is a pretty gargantuan task imo.

How about these much simpler tasks:

1) Magnetic encoder based on AS5047P + RP2040 PIO to emulate the optical encoder? BOM cost <20€, can delete first link for garbage data given how bad of a reputation there is for the existing optical encoder, at the same time it could release gatekept community out on to nicely oriented magnetic fields. Imo timings totally make sense even with "slow fast" PIO on rp2040. A few standoffs + 1 pcb + magnet disc holder.

2) Zombify the original MC, throw out TMS320F241, make 64-Pin QFP castellated edge zombie-adapter, fork for any of the brainboards to nicely be attached on top of the MC using existing mechanical fixturing points. Emulate whatever the DSP is doing, this would not be trivial but totally doable given that the full schematic of MC can be found on the internet as well as ancient dsp assambler source code from early protos. Still super cheap, easily replicable by even novice soldering iron people. Again, moves community forward, maybe makes the bike feel fresher.

Question is if any gains from making the firmware transparent and using a more modern (albeit slow given the PM300CLA060 relic status) FOC for the SPM with what we have is worth it? My guesstimates if we skin off extra 200-800W of heat produced by more efficient commutation from peak power output around 30kW, it could make for a much more enjoyable ride, not even talking about all the extra torque to be found there somewhere.

Main things to cover, what existing dsp is doing:
1) 6pack IGBT control, pwm period approx 33.5us up and down, 3us dead time, approx 15kHz. 5V logic
2) encoder signal, either use whatever exotic comes out of optical encoder along ABZ or see step 1 above. A pcb with encoder + diff transducer should be enough.
3) ADC channels sampled at pwm half period (2 x LEM transducers, diff +-2.5V, afaik SPI FRAM stores offset calibration values on powerdown either use that or reimplement), not sure what happens with bus voltage as it is read as pwm, but probabbly no biggie to read.
4)Temperatures - DS18B20 on SPI on IGBT, 3 ADC channels (use external spi adc for this maybe?)
5)Canbus - nothing too complex, a few PGNS to transmit, a few to read some logic (i.e. regen reduce on BMS data, etc)
6)Random IOs (keyswitch, PS monitoring/control, FAN PWM, interlocks, fault detect, protections, etc)

What scares me the most is how this feels like a few weekend project would still turn out to be multi month stint, question still remains - if full control, slight gains in efficiency, full and modern source code and documentation for this would outweigh the time spent. Now the control loops feel awfully rudimentary, which is understandable as it was designed 20 years ago on tools made 30+ years ago.

Maybe anyone can do a sanity check on possible EMI issues, FOC control with PM300CLA060, imo totally doable, just no sure if worth the effort.

I will have another motor controller soon to experiment with, I found a person willing to send me an optical encoder to experiment with (most likely just put on cnc spindle and see what it does, record waveforms). An extra for this project would probably be ease of porting all of this to any other inverter to basically do the same thing on the same bike.

[skr]

Making a whole new MC is also doable, but much more labor intensive imo. RP2040 for encoder would probably be a bit more sketchy than using ice40 (at least it is an excuse to finally play with it), price wise makes no big difference, however, I would like total bom to be <35€, which is 1/10 of what the cancerous alternatives cost.

[skr]

I would like to slowly proceed with creating a zombie for the bike MC, the old DSP is doing a pretty rough commutation, with phase advance at higher RPMs.

Hopefully this brings:

• Longer life for IGBT power brick due to much more effective switching.

• Free choice in sixpack switching frequency, thus reducing switching heat, as being problematic for people in hot climates

• Adjustable curves and gains, most likely more torque.

• Single digit % efficiency increase overall

• Ability to replace the stock failure prone optical encoder with a modern magnetic encoder.

• Open source firmware and hardware for future generations to use.

I have an extra motor controller with some issues I have not yet worked on, but it should be a perfect zombification candidate, as the IGBT seems to be alive. I am hoping to get a donor bike for cheap to have a motor on bench, just have to figure out transportation across europe, as I have no will to experiment on the "normal" bike in an unheated shed. I do not plan on doing much unless I get the donor in my hands.

My idea is as follows:
Create a mezzanine DSP replacement PCB emulating the QFP package with castellated edge solder joints, have a connector for signals.
Create a main zombie board containing an STM32 MCU, LDO for it 5V->3V3, logic level shifting jelly beans. I could go with a wire modboard and pull dsp to reset, but I think it is sketchy long term in a vibrating and EMI noisy environment.

I have identified most of the signals, levels and logic behind the DSP footprint and will further proceed with a zombie brainboard creation once I have the donor bike. The DSP pin outline and functionality is in the attached spreadsheet.

dsp-pins.ods

(20.14 KiB) Downloaded 7 times

[skr]

What worries me is that this being a SPM motor (or SPMSM as called in fw), it may not get as many benefits as one could desire or require head bashing amounts of tuning to get running right. There were similar concerns in this thread, for Alta bike, which, funnily enough uses the same power brick, and a very similar but newer inverter architecture https://openinverter.org/forum/viewtopi ... lta#p27044

Another aspect I am worried about are the 17.6/8.8/4.4 kHz PWMFRQS, default firmware switches at 16kHz, IGBT is rated at <20kHz. If the aim is to prolong the IGBT life by giving it an easier workout- 8.8kHz would make more sense, albeit much louder, switching losses woud definitely decrease, but not sure about the driveability aspect or some things I don't know of yet about. My magnetics/power electronics 101 is inadequate here.

Another - in the stock DSP ASM code found online from 20 years ago (not sure how close to production version, however the registers seem sameish for late binaries), the commutation logic explicitly tri-states (“Hi-Z”) the unused inverter legs depending on electrical angle, with a comment: “prevents reverse current spikes when legs switch.” My initial assumption was that this might just be an artifact of the power brick input stage (DSP sinks opto LED current, high Z otherwise, after opto power brick inputs pulled up to 15V (OFF), etc., idea being that opto can not conduct in unknown state thus partially pulling down any of the IGBT pins), but I’m now thinking it’s more about power-stage current commutation behavior: diode reverse-recovery / current path transitions / switching-loss reduction during sector changes.

From what I can tell in stm32-sine codebase, PWM modulation is continuous SVPWM (min/max offset) with short-pulse suppression only. I couldn’t find any discontinuous PWM / clamped SVPWM (DPWM) sector logic, and I don’t see any deliberate “float phase / Hi-Z” behavior during normal modulation, other than deadtime and fault/disable states (MOE/channel disable).

I’m fine with inverting PWM logic and handling level shifting/buffering correctly, but I’d appreciate confirmation: is “continuous SVPWM only” the intended design here, and is there any known concern (or mitigation) for commutation spikes / diode recovery compared to a clamped/Hi-Z style strategy like the stock VX-1 DSP? No DPWM artifacts or similar ideas found on VESC or Lebowski codebases.

There's tons of academic literature on modulation schemes, with some covering DPWM increasing IGBT longevity, my concern here being if 20 years ago people in a big corporation were concerned about the unused leg state in commutation- is this even relevant for FOC commutation?

[skr]

so my observations from stock inverter operation seem to be correct- the stock inverter firmware runs sine LUT + phase advance LUT and something akin to DPWMish scheme at all times, where it makes sure only two legs are switching at any time, meaning, that implementing STM32-SINE -FOC build as is would actually increase heat generation in the inverter given the constant SVPWM switching in all legs at all times, if the switching carrier frequency remains the same (16kHz vs 17ish on OI FW). So, if main goal is to increase MTBF for this ancient inverter, refactor of STM32-SINE -foc build with addition of some dynamic SVPWM/DPWM1 (which seems closest to stock idea of tristated legs) with dynamic switchover on. I am currently investigating simulation of power stage switching losses using a fork here to come up with a good SVPWM/DPWM strategy fo all FOC using inverters: https://openinverter.org/forum/viewtopic.php?t=6928