Introducing HeadlessZombie

[jetpax]

I wanted to introduce something I've been working on for a while, which I call HeadlessZombie.

[In the same way ZombieVerter was an OpenInverter without the Inverter, HeadlessZombie is a cutdown Zombieverter without even the Inverter drivers (supports CAN only inverter comms)]

The basic idea of the project is to enable a sort of "Tesla App" for EV conversions, by providing a flexible and to some degree future proof VCU+4G Gateway hardware platform with OVMS and OpenInverter compatibility.

This can be done using OVMS and ZombieVerter as discrete boxes, but I felt that building them together made sense for me, and hopefully others in the EV conversion community.

So I'm just about to send this 3rd version of the board off to manufacture, and was looking for feedback before I pull the trigger....

Few details about the build...

The board uses an ESP32-S3 N16R2, supports a plugin co-processor using MicroMod, currently targetting the Sparkfun STM32F405 for OI, (but could instead run RP2040, Teensy etc). Both processors expose 2 SPI interfaces one for GPIO, the other for CAN interfaces.

The plugin WWAN interface (accepts M.2 socket B 3042 WWAN modems connected on USB), eg SIM7600 with integrated GPS.

The board has a 48-pin Molex connector with 3 CAN interfaces, SWCAN and LIN/K-line.

I/O is 24 channels IN (analog or digital with optional switch wetting) and 10 channels OUT (HS/LS/HB supported), all run-time assignable, as well as 2 dedicated PWM channels (eg for Speedo/Tacho), a 12V LED strip output for in car ambient lighting, and a 5V protected sensor supply output.

IO is fully protected against shorts, supply reversal etc, and runs from 5-24V

Onboard peripherals include RTC, accelerometer, SDcard slot, SIMcard slot, status LED , user button (on underside), and a warning buzzer.

Nearly all on-board devices can be accessed by either the main processor or the co-processor (but not simultaneously)

ESP32 debugging over JTAG is integrated (requires and ESPprog for firmware development) , and STM32 debugging over SWD.

Firmware is currently based on a heavily modified OVMS, (eg native ESP-IDF web stack instead of Mongoose, native esp-idf PPP, all modules Construct on First Use, etc etc) and with the addition of Arduino SDK compatibility.

Planning to serve the OI web page to control a reduced functionality Zombieverter (No Lexus drive unit support, sorry), running on a Sparkfun Micromod STM32F405, over a CAN backend.

This will require OI drivers for TIC12400 and TLE941xx IO devices (not yet started as I want to get the hardware finalised first)

Any questions/requests let me know, will try to incorporate your suggestions.

[jrbe]

Your board image didn't come through.

[jetpax]

Thanks @jrbe, hopefully fixed now

[jrbe]

Looks great. Really clean layout.

I see lots of antennas and one connector below. They all connecting through the lid besides that one? Any need for a hole or 3 through the PC board to get to the bottom with the antenna wires?

Any reason to add unpopulated screw standoffs for different size expansion boards / support?

[jetpax]

Thanks @jrbe.

Correct, there are 3 antennae, wifi/bluetooth, LTE and GPS.

Current plan is wifi on bottom connector shown, (which routes through one of the large Molex clip holes) other 2 (which are technically optional if the WWAN is not used) use lid mounted pigtails.

Layout is tight in this enclosure so only plan to support M.2 3042 in this 'MINI' version.

Micromod does call out a larger 'Function board' size, but its easy enough to create custom plugins (eg my C1101 sub GHZ board for garage doors) using the processor form factor.

[Jack Bauer]

Github repo?

[jetpax]

Here you go

[Jack Bauer]

Many thanks

[jetpax]

Since HeadlessZombie uses an STM32F405, I've ported the latest STM32_vcu code over (#ifdef'd for F1 or F4) and built it under Platformio for easier debugging

It's in a raw untested state as yet, but the Micromod STAT LED flashes

You can find the code here

[modellfan]

Perfect execution. I had something similar but different in mind for my project. Use one of this T-Call ESP32 boards as modem but just implement an extended oi can interface program to them . This would allow easy compatibility with the whole oi ecosystem while implementing the same functionality.

[jetpax]

Thanks @modellfan, actually I started off a bit like this using a Lilygo T-SIM7600 to port the OVMS code before I made my own hardware.

The M.2 socket (which added very little cost) had the advantage of allowing different modems in the future (ask current Smart453EQ drivers how it feels when the cell network gets upgraded...)

The MicroMod socket similarly provides flexibility for the "Real Time" processor in the future, again at very little additional cost,

[jetpax]

Thanks for your inputs on this and other forums, I released HeadlessZombie to production today.

Fingers crossed!

Now, firmware...

[Scrappyjoe]

Are you planning to sell this as a product in the future?

[outlandnish]

Thanks for your inputs on this and other forums, I released HeadlessZombie to production today.

Fingers crossed!

Now, firmware...

image.png

This is so cool - congrats! You built out something I wanted to do myself - down to the Micromod platform. One challenge I found was the odd omissions of peripherals that the STM32 Micromod omitted (e.g. more than one SPI and CAN interface). It'd be interesting to try building a version of the STM32 Micromod (and expose more I/O) - if those were available, would it change the way your current design for the carrier board?

Also, for firmware - I'm having a pain of a time getting PlatformIO, libopencm3, FreeRTOS and C++ to all play happy. Hope you're having better luck!

[jetpax]

Thanks @outlandnish!

Re Micromod, turns out that the STM32F405 board linked above has 2 SPIs brought out, the second is actually on the "I2S pins", so I was able to use those (the motherboard uses one SPI for IO, the other for CAN controllers)

So actually had no need of more STM32 IO.

See

I suppose you could make an STMF103 board, but frankly I dont see the point


Re firmware , I did a prelim port of STM32-VCU which you can find here.
It compiles under Platformio using the vanilla Platformio libopencm3 (with small change from @johu for CAN), and debugger works great using Blackmagic
(I repurposed a Nucleo breakoff board as a BlackMagic adapter, also works great)

[jetpax]

Are you planning to sell this as a product in the future?

Definitely, if there is any interest.

This is the MINI version that uses a commonly available ECU case

though it has to be drilled for antennae, and will be powder coated.

(Color preferences anyone? )

Will likely do a larger pinout version with beefier drivers/ more pins in the future too depending on demand.

[outlandnish]

Good catch on the second SPI interface being exposed via I2S. It's so bizarre they didn't use their own secondary SPI interface port on the Micromod connector.

I'll give that code a shot, thanks!

[outlandnish]

As another aside, I saw the schematic image shows a TIC10024. That IC is for digital switches only and doesn't have ADC support. Did you mean to use a TIC12400 instead? That one does have an ADC for analog inputs.

[jetpax]

Indeed, well spotted grasshopper, was fixed in production release which uses TIC12400QDCPRQ1

(and also switched to the TI DRV8912 O/P driver, which is almost pin compatible with Infineon part...)

[modellfan]

Why did you move over to TIC12400QDCPRQ1? Infineon at least supported a arduino library .

[jetpax]

Why did you move over to TIC12400QDCPRQ1? Infineon at least supported a arduino library .

Actually the Infineon part was replaced by a DRV8912, for availability reasons.

The TLE94112 driver I think you are referring to is for Arduino framework, is specific to motors, (whereas we want to use the part as a generic HS/LS driver) and has lots of extra abstraction we just dont need in a libopeninv application, so I wrote my own, for both DRV8912 and TIC12400

(They tie into the busio extension to libopeninv together with extension to MCP2515 driver to allow use of the GP O/Ps on those parts)