angusgr

Hi janosch,

Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.

> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach

For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.

I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.

More blog posts (and open hardware & software) to come, I hope!

If you're interested then click the link in my first reply (which is to a newer post). The first video shows the working car reaching 8000rpm (about 80km/h) around six seconds after the accelerator was released. The second video shows the speed creeping steadily from 38km/h to 44km/h (~2600rpm) after switching to Neutral (before we got nervous again and touched the brake).

(I don't really understand it, but I also haven't managed to think of a safety issue here for normal car use: the broken driveshaft is just a bit scary as the motor spins unloaded at >10,000rpm for a while. The only other time this seems likely to happen is if a mechanic puts the car in Drive on a hoist, and it'll stop as soon as they tap the brake.)

> I think you were emulating the ABS module right? In that case, the spinning out of control is actually probably your fault. If you had not emulated this, the system would realise there is an ABS fault (from the messages not being present) and not use the ABS reported speed. It might even fall back to motor speed automatically.

That's a reasonable expectation, and this got left out of the follow-up post I linked, but in the "full car with wheels off the ground" tests we actually tried unplugging the brake module of an otherwise working car and it didn't change anything (including the gradual constant rpm increase in Neutral). If anything the behaviour might have gotten a little more aggressive with the brake module missing.

Have now observed similar behaviour for all three of "spoofed brake messages with 0 wheel speeds and emulated checksums", "fully operational car with wheels off the ground", and "car with wheels off the ground and ABS/brake module unplugged". ¯\_(ツ)_/¯

> Re: shaft scenario, if the motor shaft is broken the safety risk is pretty minimal because the torque wont actually cause the car to move. > > I guess this is what they arrived to in the FMEA.

Fair enough, that makes sense. I guess if that's the case then the other behaviour is outside of the scope of what they need to care about.

> So wheel speed sensors drop out and the car will accelerate uncontrollably?

No, I don't think any of my bench tests suggest that for this car. The torque is minimal throughout, so if the motor was pushing an actual car then it might not move at all. If it did move, even a light touch on the (mechanical) brake pedal would stop it.

My problem is that I had a bench setup with no load on the motor and no mechanical brake. I could have pulled the safety interlock (all EVs have these for emergency first responders) but this stops the motor at all costs - wasn't sure of potential damage to the motor controller circuitry from back EMF.

(Blog author here)

You're spot on about the PLL stage, a few people on Reddit pointed the same thing out when I first posted it. Makes sense, although I still think it's interesting they added it internally to an otherwise (apparently) cloned design.

You're also right that USB CDC does provide the option for a generic USB Ethernet device, however this silicon is ASIX-specific (not just the USB IDs.) ASIX's Windows drivers include their own system driver binaries, and the ASIX Linux driver has a lot of ASIX-specific stuff in it.

I think it's kind of possible ASIX made this themselves as some kind of no-name branded unadvertised market segmentation effort. I can't understand what their rationale would be exactly but hardware companies do unusual things sometimes...

I haven't tried any of their other products, but the iMX6 has a very large detailed technical manual (publicly available, not under NDA) and their Linux kernel trees are updated in public via git (presumably not everything is public but it's a lot more transparent than the occasional tarball source drop approach), plus they have people involved in yocto development. Better than many/most of the ARM SoC manufacturers.

The only undocumented/secret squirrel business AFAIK is the Vivante GPU. And that's universal across ARM Soc GPUs, sadly.