openinverter forum

Great explanation Collin, I am going to be getting help with my soldering for sure.

But do tell us how you REALLY feel

collin80 wrote: ↑Wed Nov 24, 2021 12:47 am 2. You want quality solder. I know you're in the EU but if you can use leaded solder, DO IT. Non-leaded solder is the DEVIL. SATAN in metal form. It flows like crap, it makes tin whiskers, it doesn't wet the parts as well. It's evil. Evil I tell you. Lead based solder is 10x easier to work with. There is no comparison. The EU member states should all be slapped. Every single person who authorized lead free solder should be hit hard with a halibut.

Jack Bauer wrote: ↑Wed Nov 03, 2021 7:13 pm Yeah LIN is not used at the minute in software anyway. I'll send over an mcp2004 to you in a few days.

Thanks, but don't worry about it Damien, we've sourced and fitted this now.

Uppertown wrote: ↑Mon Nov 15, 2021 9:36 pm So I'm trying to get my head around Github and specifically how to compile a binary. I've down loaded arm-none-eabi toolchain, Python and chocolatey and installed them OK -I think, but I don't seem to be able to get any further and entering make get-deps in a shell results in this:Screenshot 2021-11-15 213153.png can anyone tell me what I'm doing wrong and or point me at a complete idiots guide to this?

You're not far off, just need to use a different shell I think. Here's my notes: viewtopic.php?p=32715#p32715

I will be diving back in to VCU stuff shortly, took a hiatus to do the mechanical integration on our GX450 project, but that's ready to roll now.
Glad to see the bits I added to the wiki are being pointed to as a useful resource - glad to help and that's what makes it worthwhile

Is here someone with schematic for Leaf gen2 full set with PDM?

PaulHeystee wrote: ↑Wed Nov 24, 2021 9:54 am Thanks Collin80 for your detailed input, certainly useful.

Damian is right, however, these repair-shops are very rare here in NL, the 'repair' shops here collect the faulty phones and ship them off to a central workshop, there they do standard stuff like changing screens etc.

I will see if I can find a local computer/electronics guy who can help me out if I fail again.

I'm in Orlando, Florida but I just Googled "solder repair near me" and found a shop within a 45 minute drive. Cost $95 to place 6 components and they had it done in about 2 hours with no appointment. Seems a little steep but I would not have been able to do it myself.

Silly question:

Can I run the stm32_foc.bin through the zombie on an unmodified Prius gen 3 inverter or do I have to get a Prius logic board as well? I seem to have found conflicting information in my searching.

https://evbmw.com/index.php/evbmw-websh ... ogic-board

The .bin will upload successfully and the parameters on the web interface reflect the change but I'm not at the point to be able to test this with my motor. From previous posts I know that Damien has been/is using a Siemens motor with a Prius inverter on the Zombie but I wasn't sure if that could be accomplished without first modifying the inverter.

The VCU is designed to control an inverter in its stock form. FOC tuning is designed to run on openinverter boards that are directly controlling an inverter power stage. I suggest reading the relevant wiki pages for the vcu, general openinverter and FOC.

I got my Leaf Gen3 inverter and motor spinning with the ZombieVerter and started to play with my Leaf Gen2 PDM.
I do not have an actual Type2 vehicle inlet nor an actual Type2 charging cable with the fancy relay box with control signaling.
Instead I am trying to spoof the PDM to think that there is.
I made a simple circuit to produce 50% PWM signal with +12V to -12V peak-to-peak which I am supplying through a 1k resistor to the PDM.
Then I have a 1.5k resistor connected between PE and pin 29 (EVSE Connection Signal, White) through a switch to simulate the PP signal and a cable current of 13A max.

I do this sequence to try to start the charging process:
1. Connect the 1.5k resistor and at the same moment introduce a steady +12V to the Pin 30 (control pilot) to indicated charger not ready
- Outcome is that the ZombieVerter drives the PDM Power on (IGN) wakeup signal active for a period of 6ms and stops. On the web interface, the PlugDet stays off, Cable Lim stays at 0A, Pilot Lim stays at 0A and Status stays at WaitStart.
2. Apply 50% PWM to Pin 30 to indicate charger ready
- Outcome, no difference.
3. Switching off the PP resistor or switching off the CP signal makes the ZombieVerter to once again drive the wakeup signal momentarily on, which is very strange as the charging process which never started is supposed to stop with this procedure.

Is this a timing issue or am I doing something totally wrong?

I made some measurements.
First picture shows how applying steady 12V to CP line results in 9V as supposed. Then the PDU apparently wakes the Zombie up as the Zombie momentarily drives the PDU T15 supply up as can be seen from channel 2 on the oscilloscope (yellow). Only for the aforementioned 6ms, though. Then the PDU is also ready to charge and indicates this by 6V on the CP. This situation is continued for a short period and then the PDU apparently notices that T15 is not present anymore, as indicates by the channel 1 on the oscilloscope (blue). In this situation I tried if EVSE ready would help, but the behavior stayed the same - no bonus.

Today I cross checked the PDM output CAN message 390h content and the values that the Zombie is expecting to receive after wake-up by PDM output mesage 679h.
Turns out my Gen2 PDM is not outputting the same PlugStat values.
I did the following modifications and now my PDM is charging happily with the correct output power as per setting in the Zombie Web interface:

// if(PlugStat == 0x08) PPStat = true; //plug inserted
if(PlugStat <= 0x08) PPStat = true; //plug inserted
// if(PlugStat == 0x00) PPStat = false; //plug not inserted
if(PlugStat >= 0x09) PPStat = false; //plug not inserted

The original two code lines are commented out, but I put them here for comparison.

Might be that I need to tweak the code once more as I get an actual Type 2 EVSE, but this works for now.

Hello,

I am very glad that the motor turns !!!

forwards everything is OK
only in reverse the engine turns to a constant speed and stays there until I switch to forward again

what could be the problem ?

Well done Koppi. That’s a strange one!

I have a problem also, trying the new zombie board today.

The wifi module has a different SSID and password than before, I know that, but the connection always has a warning, and it’s not possible to open 192.168.4.1. Tried this on phone and a new laptop with identical results.
I tried swapping in the wifi module from the old unit, it’s possible to connect to that but then the gui is “empty”.
What can cause this?

I've spent more time bashing my head off a wall with these stupid wifi modules over the past few weeks than I care to mention. They worked perfectly up to my latest purchase when OBVIOUSLY something was changed either by Olimex or by Espressif and naturally no one wants to find the issue as all the silly little arduino sketches work fine. Can someone PLEASE PLEASE help the community and me to solve this.

@et0 obviously there is no internet connection but that should not stop the device from connecting to the webpage. If you are still stuck all I can offer is to try and find a spare old module somewhere here and I'll send it over.

Jack Bauer wrote: ↑Tue Nov 30, 2021 3:50 pm @et0 obviously there is no internet connection but that should not stop the device from connecting to the webpage. If you are still stuck all I can offer is to try and find a spare old module somewhere here and I'll send it over.

Yes, I just included that because the other module doesn't show that warning, thought it might be something to do with it. Is this already being discussed somewhere else? I'll lend a hand if I can but remember swearing off ESP32/arduino adventures once before.

If you have one that works we'd really appreciate it to get the new unit up and running. But shouldn't it work with the module from the old board, there's no firmware difference on the STM side is there?

We'll carry on with the old unit in the meantime but I am pretty sure it needs a new STM32 chip, both problems trace back to what look like dead pins on that device (no inv_out signal and the ADC channel for motor temperature is jammed at full count). I know, that's very unlikely too, but I can't find stock anywhere to replace it.

Jack Bauer wrote: ↑Tue Nov 30, 2021 3:50 pm They worked perfectly up to my latest purchase when OBVIOUSLY something was changed either by Olimex or by Espressif and naturally no one wants to find the issue as all the silly little arduino sketches work fine. Can someone PLEASE PLEASE help the community and me to solve this.

Damien in order to help you we need to know how this works.
Where can we read about it?
@johu do you have a wiki or thread with all the info?

For example how does the main chip get into bootloader program from the wifi module?
I Also have issues with the Wifi boards on the inverter it works. On VCU 1 they don't.
i rename the bin file to _sin as a start.

So what is the working theorie? how do we get into bootloader mode?

Do we already use one of these?

https://nl.aliexpress.com/item/10050018 ... 5783%22%7D

et0 wrote: ↑Tue Nov 30, 2021 4:31 pm
Yes, I just included that because the other module doesn't show that warning, thought it might be something to do with it. Is this already being discussed somewhere else? I'll lend a hand if I can but remember swearing off ESP32/arduino adventures once before.

If you have one that works we'd really appreciate it to get the new unit up and running. But shouldn't it work with the module from the old board, there's no firmware difference on the STM side is there?

Don't blame you. Had enough of 'duino myself. Kinda why I've taken the pain and moved to STM32. Original discussion of the wifi issue here :
viewtopic.php?f=5&t=2001

I'll have a look today and see if I can find a module. But yeah should of course work with the old one. No firmware differences in that regard. In therms of the STM32F107 I go to some extreme lengths these days to source known good (ie non cheap possibly fake) devices and hand solder those to the boards, perform a power up test and program prior to dispatch. Doesn't mean they cant have a fault but I do everything in my power to avoid.

Just to remind folks this project will only be as strong as the community that builds up around it. I won't be on here much over the next 3-4 months so it really will need as many people as possible to contribute and assist.

Well we got the vehicle running today - on the original board with a few work-arounds in place but it gives some confidence. And we're not currently blocked by the wifi module issues so don't worry about sending one, we'll wait and/or try to resolve whatever's causing that problem.
Cheers

My next order of business is to get the Zombie to read the battery current value (and other parameters to follow) from CAN messages other than send by the ISA shunt.
I've been banging my head against the wall for a few days already, but I cannot get the Zombie to process the newly introduced CAN id.
Here is how I have modified the code:

I added the message to the CAN1 call back list found in stm32_vcu.cpp:
c.RegisterUserMessage(0x3c3);

I added a new switch case:
case 0x3c3:
LeafINV::Decode3C3(data);
break;

I made the code additions to leafinv.cpp (tried to actually decode the meassage and finally just tried to write a static value:
void LeafINV::Decode3C3(uint32_t data[2]) // THIS MSG CONTAINS CURRENT READING
{
amperes = 2000;
}

Then modified the utils.cpp to update the current value shown on the web interface:
int32_t idc = FP_FROMINT(LeafINV::amperes);

Make works without errors and I can flash the bin-file on the Zombie.
I've tried numerous different things. Is there some other place in the code where the new CAN id needs to be declared?

I'm guessing you ran out of user messages. I fixed that on the refactoring branch. For testing you can increase MAX_USER_MESSAGES in stm32_can.h.

In the future that is done in the Makefile:
https://github.com/damienmaguire/Stm32- ... r/Makefile

et0 wrote: ↑Wed Dec 01, 2021 3:55 pm Well we got the vehicle running today - on the original board with a few work-arounds in place but it gives some confidence. And we're not currently blocked by the wifi module issues so don't worry about sending one, we'll wait and/or try to resolve whatever's causing that problem.
Cheers

Delighted you got up and running but should not have to go through that amount of work. I'll keep working on the wifi issue and will be a release firmware asap.

Throtle pedal question: I bought a VW Polo diesel throtle pedal, I opended it and found that it looks like it is just two potentiometers.
Can I still use this?
What signals does the Zombieveter want to see, just 0 to 5 volts?
Will this work?

PaulHeystee wrote: ↑Thu Dec 02, 2021 8:48 am Throtle pedal question: I bought a VW Polo diesel throtle pedal, I opended it and found that it looks like it is just two potentiometers.
Will this work?

That should work just fine.
You need to figure out which ones of the pins are the center taps of the potentiometer.
Then just wire 5V and GND to the other two pins of each potentiometer.
If you get 5V and GND mixed together, there should be no damage, but you need to get the direction right (that being an increasing voltage in function of percentage of throttle travel).
Keep in mind, that if you mix the center tap with either the 5V or GND, you risk damaging the 5V reference supply of the Zombie or damaging the throttle pedal (Assuming there is no short circuit protection).

johu wrote: ↑Wed Dec 01, 2021 7:31 pm I'm guessing you ran out of user messages. I fixed that on the refactoring branch. For testing you can increase MAX_USER_MESSAGES in stm32_can.h.

Unfortunately there is something else going on.
I increased the MAX_USER_MESSAGE to 20 with no luck. Also tried 12 because I was not sure if 20 is abit too much, but no difference.

Information on setup of throttle is given in the instructional videos.