Outlander VCU - Rear inverter, Charger and BMS

[VEKTOR]

I made some general schematics here:
...
Let me know if you get stuck

Hello, you can share a new connection scheme.? I can't write you in private messages. Thanks.

[johu]

You can only write private messages after your first post was approved.

Just some best practise: don't quote entire posts (I edited yours to reflect what I mean). And preferably communicate public, not private

[aot93]

Thanks Johu

As for connection scheme, each application will be unique so out side of the connections to the boards (which are documented in code and the schematics) you will nee to come up with your own.
Any connections to OEM equipment are well documented on the service manual

[Turbopete]

Hi again - how did you configure the wemos d1 to communicate with the bms - is there an existing web interface that can be used?

[aot93]

I never actually got around to setting that bit up.

Bigpie from here wrote the interface, you can find it on his git page:

https://github.com/jamiejones85/SimpBMSWebUI

[Turbopete]

Much appreciated thank you!

[Turbopete]

Ok - ive been playing with trying to get the SimpBMS web interface working but im tripping over what i think is a small error - When compiling the code i get the error 'MICROS' was not declared in this scope. I see that the title of the repositry is "run the ticker in the loop" which is what makes me think that im missing something obvious and simple! Has anyonly else made any progress with the WEB UI created by Bigpie? https://github.com/jamiejones85/SimpBMS ... 47fb14e625

[Bigpie]

I was missing "sta_tick.update();" in the loop, so the ticker never executed, that's a commit message.

Are you using Platform.io and not Arduino IDE? It's a Platform.io project.

Code: Select all

Dependency Graph
|-- <WebSockets> 2.3.5
|   |-- <ESP8266WiFi> 1.0
|   |-- <Ethernet> 2.0.0
|   |   |-- <SPI> 1.0
|   |-- <SPI> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WebServer> 1.0
|   |   |-- <ESP8266WiFi> 1.0
|-- <Ticker> 3.2.0
|-- <ArduinoJson> 6.17.3
|-- <LittleFS> 0.1.0
|-- <ESP8266WiFi> 1.0
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266mDNS> 1.2
|   |   |-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <ESP8266WebServer> 1.0
|   |-- <ESP8266WiFi> 1.0
Building in release mode

Are your libraries the same versions? Also be sure you're connection to the serial output the nextion display would connect to.

Some parts of it won't work with stock simpbms, like updating the settings and override ac present.

[Turbopete]

Ah thanks very much for that - I was trying to use it as arduino! I will look into platform.io!

[Turbopete]

I was missing "sta_tick.update();" in the loop, so the ticker never executed, that's a commit message.

Are you using Platform.io and not Arduino IDE? It's a Platform.io project.

Code: Select all

Dependency Graph
|-- <WebSockets> 2.3.5
|   |-- <ESP8266WiFi> 1.0
|   |-- <Ethernet> 2.0.0
|   |   |-- <SPI> 1.0
|   |-- <SPI> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WebServer> 1.0
|   |   |-- <ESP8266WiFi> 1.0
|-- <Ticker> 3.2.0
|-- <ArduinoJson> 6.17.3
|-- <LittleFS> 0.1.0
|-- <ESP8266WiFi> 1.0
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266mDNS> 1.2
|   |   |-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <ESP8266WebServer> 1.0
|   |-- <ESP8266WiFi> 1.0
Building in release mode

Are your libraries the same versions? Also be sure you're connection to the serial output the nextion display would connect to.

Some parts of it won't work with stock simpbms, like updating the settings and override ac present.

Ok ive managed to connect to the wemos but it wont let me connect to any web page? is the page the default 192.168.4.1?

[Bigpie]

Yes, you need to also upload the spiffs (Filesystem) image

[Turbopete]

Yes, you need to also upload the spiffs (Filesystem) image
Screenshot 2022-02-02 at 12.34.50 pm.png

So after struggling like mad with this and getting very frustrated at my own inability i discovered this issue:

https://openinverter.org/forum/viewtopic.php?f=5&t=2001

I figured i needed to apply the same sort of fix to the platformio code so i modified the main.cpp file like this:

Code: Select all

void setup(void){
  Serial.begin(115200);
  Serial.setTimeout(100);

  //WIFI INIT
  #ifdef WIFI_IS_OFF_AT_BOOT
    enableWiFiAtBootTime();
  #endif
  WiFi.mode(WIFI_AP_STA);
  WiFi.hostname(host);
  WiFi.begin();
  sta_tick.start();
  
  MDNS.begin(host);

Which now allows me to access the web interface and is communicating nicely with simpBMS.

[Bigpie]

Excellent. Glad its of use.

[Turbopete]

Ok - I’ve got some prototypes programmed and wired to my test board - I’ve used the contactor test feature to check things out but for the next stage in my testing I’d like to see the full precharge sequence while still not connected to hv? Is this possible? And if it is what does the vcu need to achieve this?

[aot93]

Good to hear you are progressing well.

For the contactor sequence to start the follwing has be met:

Code: Select all

    if ((start == 0) && (brake_pedal == 0) && (BMS_Status == 1))
    {
      if ((dir_FWD == 1) && (dir_REV == 1))

So you need the BMS to be drive, direction switch is in neutral and start and brake pedal are low.

With out HV applied the sequence should just hold on the neg and pre-charge contactors. the pre charge waits for the voltage threshold to be exceeded as reported by the inverter before progressing to the next stage.

You could also put the BMS into 'charge' that way the start, brake pedal and direction inputs are ignored.

Cheers.

[Turbopete]

Thanks very much for that! I’ve fried a couple of components already but it’s all part of the learning curve! Enjoying it tho!

[arber333]

@aot93
Can you explain the function of D1 - D4 zener diodes on the VCU?
Would it be ok if i used zeners with threshold of 16V?

tnx

A

[aot93]

Hi Arber,

The aim here was to to provide a bit of input protection to the teensy.
The diodes make a simple clamping circuit limiting the voltage to the vcc rail.

From what I understand the value of the diodes is not too important, but I'm not an exert on this!

[arber333]

Hi Arber,

The aim here was to to provide a bit of input protection to the teensy.
The diodes make a simple clamping circuit limiting the voltage to the vcc rail.

What would be the overvoltage threshold you are trying to protect?

tnx

[aot93]

in theory this should protect even high voltages like static discharge.
But mostly I'm trying to protect against 12v or even 5v from from mis wiring or accidental contact.

Teensy board does not like more than 3,3v for even a moment, I learnt this the hard way more than once!
That's also another reason I chose to opto-isolate all digital inputs.

[arber333]

in theory this should protect even high voltages like static discharge.
But mostly I'm trying to protect against 12v or even 5v from from mis wiring or accidental contact.

Teensy board does not like more than 3,3v for even a moment, I learnt this the hard way more than once!
That's also another reason I chose to opto-isolate all digital inputs.

OK, dont get me wrong, i only want to know the reason behind some of the features and help improve them.

In any case zener diode will conduct from one end as any other. However after specified threshold it will also conduct in reverse. That is the protection feature we want since this will drain overvoltage to GND. But if you want to protect against 18V you need to select 16V zener. Likewise if you want to protect against 7V you select 5V5 zener and so on.

Since i use 5V pedal I would rather put 4K7 inline and 10K for divider and reverse parallel a 3V6 zener with it. That should block any OV on the analog side. Like this:

I noticed you mention 0.1uF elcaps next to analog input. Normally i dont use elcaps for decoupling but rather ceramic caps. No polarity, faster response and much higher voltage. I recommend you use them...

[OutlandishPanda]

That is great work aot93, thanks for sharing everything. I'm doing something similar for my Panda and did quite a bit of research on automotive protection for controllers after having similar bad experiences blowing up micros. I'm with arber, you need quite a bit of protection in the circuit to prevent smoke for car applications. There is so much noise there and we often make mistakes when wiring!

If it is any help, this is what I ended up with for a 5V analog input where you can't easily use cheap opto isolation:

SMBJ is a chunky TVS diode that protects from ESD and big nasties
R57 and 54 are just voltage divider to 3.3v (you can change this for a 14.5V input also)
R56 is input current protection and part of a filter with C11 to smooth the inputs
D26 is Schottky diode that clamps the input to the processor's supply rails
R55 is the final current limiting protection to mean if anything gets through that, the processors own protection has a chance

The goal is, whatever you throw at the input, the mcu never goes out of its safe input range.

This rejects that energy to the supply rails, so you need to protect those also with a zener to not exceed the max voltage limits on those rails:

I always stick a Schottky diode on the power input just in case also.

Same on the 3.3v rail:

Finally, I think the CAN transceivers also need protection, so double TVS on there is the minimum that is advised:

Its all a bit of a faf but probably worth the effort. If opto isolation shares the same ground (which I guess it will do in the car wiring) I don't know if that is fully effective? Much better than nothing I'm sure.

Just thought I'd share that. You can get similar bits in through hole and smd.

I've found this cheap and effective mosfet output works really well also. If you are using PWM, you need a Schottky diode across the load if it is a coil. A normal diode will get very hot, I found out!

Its great seeing all the different ways people are developing their own stuff and getting things on the road. Really inspirational. Its amazing what people in this forum are achieving. I'll post my Panda progress one day. I switched on the HV for the first time yesterday and got the bms, battery, contactors and DC-DC working. Charger next. First steps towards getting the motor turning on the bench before the power saw comes out!

[aot93]

Thanks for the suggestions, all very good and interesting.
I know some people like to use op-amp drivers for analogue inputs, which is also a good approach.
Of course board space and component availability come in to this as well.

The capacitors are tantalum, not sure where the EL reference is coming from, agree you EL's are not ideal for this job.

@outlandishpanda, interesting project, I see you are also in West Sussex, drop me a PM if you want to have a look around the mini.

[Turbopete]

Me again! I’ve connected my inverter to the vcu now but I’m not receiving any data over can - I’ve investigated and found that neither the dash display can transceiver or the inverter can transceiver on the VCU are transmitting? Any idea where I’ve gone wrong? I’ve swapped out the transceivers and checked the supply and earth and no issues there?

[aot93]

If you have not gone through the full the start up sequence then you will not see anything on the inverter bus.

You should see something on the dash bus however as this is called in the main loop at boot.
I would check your bus wiring, you should have 120ohm between canH and canL
Are you using the correct baud rate (50K) for the dash?
You could try running a simple sketch just to prove the hardware, some thing like this should work, sending data on all 3 buses every 500ms;

Code: Select all

#include <FlexCAN_T4.h>

FlexCAN_T4<CAN1, RX_SIZE_256, TX_SIZE_16> can1;
FlexCAN_T4<CAN2, RX_SIZE_256, TX_SIZE_16> can2;
FlexCAN_T4<CAN3, RX_SIZE_256, TX_SIZE_16> can3;

int led = 13;

CAN_message_t msg;

void setup(void) {
  can1.begin();
  can1.setBaudRate(50000);
  can2.begin();
  can2.setBaudRate(50000);
  can3.begin();
  can2.setBaudRate(50000);

  pinMode(led, OUTPUT);
  digitalWrite(led, HIGH);
}

void loop() {

    msg.id = 0x101;
    msg.len = 8;
    msg.buf[0] = 11;
    msg.buf[1] = 21;
    msg.buf[2] = 31;
    msg.buf[3] = 41;
    msg.buf[4] = 51;
    msg.buf[5] = 61;
    msg.buf[6] = 71;
    msg.buf[7] = 81;
    can1.write(msg);
delay(1);

    msg.id = 0x102;
    msg.len = 8;
    msg.buf[0] = 12;
    msg.buf[1] = 22;
    msg.buf[2] = 32;
    msg.buf[3] = 42;
    msg.buf[4] = 52;
    msg.buf[5] = 62;
    msg.buf[6] = 72;
    msg.buf[7] = 82;
    can2.write(msg);
delay(1);

    msg.id = 0x103;
    msg.len = 8;
    msg.buf[0] = 13;
    msg.buf[1] = 23;
    msg.buf[2] = 33;
    msg.buf[3] = 43;
    msg.buf[4] = 53;
    msg.buf[5] = 63;
    msg.buf[6] = 73;
    msg.buf[7] = 83;
    can3.write(msg);

delay(500);

 digitalWrite(led, !digitalRead(led)); // Flash builtin LED
}