openinverter forum

mdrobnak wrote: ↑Wed Oct 28, 2020 6:02 am

clanger9 wrote: ↑Tue Oct 20, 2020 7:27 am Looks good.
You can get nasty spikes on the proximity line. Is it worth putting a clamping diodes on the 12V inputs, or is that not necessary?

This is generated by the CP ECU, not directly from the input, as far as I can tell. I think it's used for drive away protection.

This is true. My worry was that the signal line is in the charge cable, so potentially several metres long, unshielded and in close proximity to the high current lines. Not a major issue, but I think inductive pickup is a possibility. We managed to pop the proximity line on one of our charge points las year - not sure how or why, but it seemed like a spike-induced failure.

Sending some can to the cp ecu today with Matt's firmware. My charge port door closed! Good job my finger wasn't inside as old Elon closed it with force

Oh, yeah, there's definitely two speeds for closing - normal and NOW!

I forgot to mention a few details to Damien, so I expect him to have that up and running shortly.

Long and short of it is that as discovered in my 330 build thread, you need the latch control pin seeing some voltage before it will open the door. He's gotten me some logs to look over, and the goal is to make some progress on it by Monday (depending on how different stuff is).

-Matt

LOL. The RTC fun continues: And then???

I had previously noticed it seemed to stop at a random point. I thought the debugger connection was a problem, so I hit reset to allow the board to just execute on its own. Unfortunately, it was not related, so instead, I can't break in and find out what caused it to lose its mind.

For some strange reason the clock doesn't roll over correctly. Embedded is fun!

I'll set it closer to midnight and see what's going on tomorrow.

For now, I've got the ISA shunt wired up (yikes those pins are TINY). I'm trying to think of how I want to support (and how to support) the ISA shunt.

I'll probably write a library that gets passed in an id and an array and updates a given object.
That will definitely be open source, and I'll try and even get that on crates.io.

Looking over some logs - I thought the part number looked funny:
Damien, _not_ a US spec CP:
"CP_type: CP_TYPE_GB"

Again, useful for comparison, however. Also should be interesting to see what happens if you connect a US port to it.
Initial power-on message is slightly different. Same for EU. EU is closer to US.
"CP_type: CP_TYPE_IEC_CCS"
4 unique IDs. Unfortunately not enough clue as to what they are for.

Hopefully Damien can manage to get the door open tomorrow so we can see what the LED reveals about how happy or unhappy they are.

-Matt

Did some digging today, nothing new to report yet. Didn't touch the RTC stuff.
Seeing as there may be differences between US/EU code, and I'll be adding support for the Isabellenhuette shunt, so I broke up the can receive function into one that calls other smaller functions depending on what ID was received.
Untested, so not uploaded. More updates tomorrow if life doesn't get in the way. (It will, weekend chores )

-Matt

Did some weekend chores, as expected.

I had a crazy idea, so I sent something to Damien to test a short while ago.

Only started on the ISA stuff. My goodness, a little too flexible I think. If I'm reading the documentation, _every item_ has configurable endianness, which seems excessive. I'll have a defaults, and a openinverter config that can be pulled up easily...

-Matt

Will test asap. Also doing some weekend chores:)

RTC date is able to be set now



-matt

So I made an assumption. A reasonable one. That the STM32F3 driver I started from, oh, I dunno, worked. Turns out the "hmm there's a couple bugs" is actually "there are lots of bugs, assume none of this is correct." I had to look at the STMCube example to get the init right the first time, and now again made me realize the previous coder flipped the 12/24 hour clock flags, which made everything break when hour > 23...and not moving to the next day.

As of right now, the clock works correctly. I am going to clean up all of my changes and push them to github, and then I'll open a PR to get them in the upstream HAL.

Unfortunately my crazy test didn't work with Damien, so until I can get a HV CAN capture from an EU car, might be dead in the water for now.

My EEPROM arrives tomorrow.
My Molex connector arrives today for SimpBMS.

ToDo for today:
* Clean up and merge in RTC management (set date / time from serial console)
* Continue working on ISA library
* Various wiring bits (SimpBMS, battery connection)

My github for f7 and f4 driver updated. PR opened for F7 repository to get it into upstream. It was very hard not to say 'based on previous work and fixed all over the place' -- but I didn't.

https://github.com/stm32-rs/stm32f7xx-hal/pull/96

Wiring didn't go so well.

Code is updated with the ability to set the Real Time Clock, and the CAN receive code is now broken out. I will basically process the ISA stuff in a function that gets passed in the data from the wire, so that the library doesn't need to deal with CAN, and optionally returns a set of frames to send out.

For the time being, the next item will be the ISA library, then EEPROM settings. Also need to troubleshoot why I'm not getting any data from the Volt BMS boards.

-Matt

On my side of the pond I've gone ahead and ordered another cp ecu from the US Ebay. Only $40 plus a bit of shipping so worth having in the arsenal. Also I'm going to go ahead and order a batch of the hardware from JLCPCB so we both have something to work on and debug.

Jack Bauer wrote: ↑Wed Nov 04, 2020 8:44 am On my side of the pond I've gone ahead and ordered another cp ecu from the US Ebay.

We have two more EU ECU which we can use for verifying your results when you get that far

I've started on the library, and have really, really rough stuff to just get the basics going:
https://github.com/mdrobnak/isa-ivt-shunt-rs

Tomorrow I'm going to try and get more data samples of simply power cycling it in the car with all of the doors closed to see what the init sequence looks like (and try to take note of the latch state as well.)

-Matt

Got some data of simply power cycling it in the car. Definitely a pattern, but sometimes it varies a little. Unclear as of now what causes that.

When idle or unplugged, latch voltage goes no lower than 3.8V (?#?#?~) and is 4.06V when the CP ECU is plugged in.

So I'll try and re-implement the initialization code again (it's missing at the moment) and see if that leads to a little easier start of things.

-Matt

mdrobnak wrote: ↑Mon Nov 02, 2020 7:57 pm Unfortunately my crazy test didn't work with Damien, so until I can get a HV CAN capture from an EU car, might be dead in the water for now.

What capture do you need ?
I have acces to an EU Model3 with CANbus captureport, so it's easy to capture if you need anything...

prensel wrote: ↑Fri Nov 06, 2020 12:20 pm

mdrobnak wrote: ↑Mon Nov 02, 2020 7:57 pm Unfortunately my crazy test didn't work with Damien, so until I can get a HV CAN capture from an EU car, might be dead in the water for now.

What capture do you need ?
I have acces to an EU Model3 with CANbus captureport, so it's easy to capture if you need anything...

Captures of the HV CAN (which the charge port ECU is connected to) is most important, but being able to capture both buses (that one plus the one behind the console in the rear) would be very useful data. What makes this difficult is needing to move part of the trunk carpet to get to it.

I sent a US data capture over to Damien that should automatically open and close the door, and if that works with a white LED, then there's a message that I determined 'wasn't needed' on my Charge Port ECU is actually needed in other variants.

So stay tuned! If you're willing to capture some data, the would be definitely appreciated.

Items for today:
* Initialization code
* Continue work on ISA library

-Matt

Worked on the ISA library a little, but didn't get much done. But at least it doesn't look like a total mess now, only a mostly mess.

Good news on the capture! We at least have a door open with white LED situation now. As I've learned from the why-don't-you-work-you-silly-thing US version, it can still go very wrong after inserting the cable, so I'm trying not to get too excited yet.

Probably won't get too much done this weekend.

-Matt

Remember folks, Matt and I (well Matt anyway) are what you might call experts. Don't try this sort of thing yourselves at home.

Elon is still annoyed with me. But making progress on tracing the source of his anger...

Same on the initialization side. Still working things out.

I learned the inductive sensor on my door _does_ work. Playing back a log in which I am disconnecting and reconnecting the Charge Port ECU, and it turns out that if I can get it to stay in the door closed position but idle long enough, the door will respond to touch.
I've also determined that the IDs I'm sending now are sufficient to satisfy it. So there's something not right with the data.
Digging deeper.

I also was able to remove 3 IDs and still keep it at least happy when just opening the door. We'll see what happens when I try a charge again tomorrow.

Short term goal is to try and get this init sequence under control. Then work on the ISA library a bit. Past that, things are going to get a little crazy as we have Thanksgiving coming up, and then I will be traveling across the US (in my Tesla!) to see my family in NY for Christmas.

-Matt

The door opens via touch???

Jack Bauer wrote: ↑Thu Nov 12, 2020 9:44 am The door opens via touch???

Touch and RFID

Some interface details described here;

viewtopic.php?f=17&t=303#p3634

Quick video showing the various ways that you can open the charge port door;