openinverter forum

Did you choose to overclock your kettle with 300V?

Also a good possibility to test the cross talk.

I have managed to break something.
This is with a Focci board, but should not matter as its the underlying library. I am working on writing code to get a CAN mapping written automatically from Zombie to Focci to ensure compatibility. My code was a bit crude as in it could get stuck spamming one frame. Managed to now break it to a point were the CAN subindex 2 is no longer accepted, 0 and 1 are. This is for the Zombie sending it or via the ESP32 interface.

https://openinverter.org/wiki/CAN_communication

Subindex 2 commits the mapping. Maybe you have used up all slots. If you haven't saved to flash just reboot

johu wrote: ↑Tue Jul 30, 2024 4:17 pm Subindex 2 commits the mapping. Maybe you have used up all slots. If you haven't saved to flash just reboot

I have the Zombie run a clean up routine first by emptying the write 0x3100 and read 0x3180 messages, currently no CAN is stored as far as I can tell. As the response from Focci are already 0x80

Rebooting did nothing, same with reflashing the BIN.

Cold boot now, requesting first write ID.

Would the STlink support a mass erase? And then flash bootloader and application should lead to a factory-fresh unit.

I have seen repeated create/erase cycles of CAN maps to cause the device to get in a state where it reports it has an empty map and will not accept creation of new map entries. Not got a full reproduction yet to raise an issue against libopeninv. Rebooting fixes things though.

You might find my unit tests good documentation of how the protocol should work: https://github.com/davefiddes/openinver ... oi_node.py

davefiddes wrote: ↑Tue Jul 30, 2024 4:43 pm Rebooting fixes things though.

Not in my case, so seems I have taken it one step further.

uhi22 wrote: ↑Tue Jul 30, 2024 4:26 pm Would the STlink support a mass erase? And then flash bootloader and application should lead to a factory-fresh unit.

I use STM32CubeProgrammer and it does have memory erase functions, it can do a full erase function. Will hook it up tomorrow with an STlink.

I used the STM32CubeProgrammer to full wipe memory then install CAN bootloader and my own revision of Focci. Back up and CAN mapping

Cleaned things up in my Zombie code and had a time out set for aborts recieved.

Took some cleaning of my state machine but she works now can push my interperation to Zombie, it is not perfectly Chademo because easiest to just keep parameters at gain of 1 for most things and I do not like 8 bit limit for charge current
Next step will be wiring this up first to an AC port for testing and further Zombie and Focci state handeling. After that a DC CCS port, which should be easy to make work due to the work done for the AC charging plus copying they way the BMW I3 LIM works with Zombie.

Just a heads up, the latest 5.1 BOM is making JLCPCB complain about the BOM/CPL not matching. It seems some jumpers and test points are included on the BOM and removing them seemed to do the trick. Here are the lines I removed: 2, 28-30, 36, 63-66.

Also they are out of the QCA7005 again. This is probably going to end up being a winter project for me so I don't necessarily need to order right away. Are there any planned revs coming out soon? The todo list doesn't seem very big so hopefully that's a good sign.

Thanks for analyzing the BOM topic, I was wondering and then ignoring the complaint. Good to know the root cause.
The QCA is seems to be never in the public stock, so either pre-ordering or self-solder was our the way to go.
At the moment the design seems to be quite stable, no changes planned.
Some Focccis are still in the shop, with the advantage that they are flashed and tested.

Hello everyone, I have just been following this interesting discussion.
I successfully flashed the .bin file into the flash chip (the bin file was obtained from this link: https://github.com/uhi22/Ioniq28Investi ... _33_79.bin).

When I connected the QCA7000 to the Raspberry Pi CM4, it detected the eth1 interface, but when I used commands from open-plc-utils, such as plclist, my QCA did not respond to any packets (traced on Wireshark). Can someone help me figure out what I might be doing wrong?

Sincerely, thank you.

Syxn, you may need to ask about that in the user thread: viewtopic.php?f=17&t=4889

Also, regarding enclosures, Digikey recommended this to me as an alternate when the other one was OOS. It was cheaper, and now that I have it in my hands I can verify it fits the connector. Drawing sheet also seemed to have identical critical dimensions when I checked it.
https://www.digikey.ca/en/products/deta ... 4B/9953946

Hi and welcome.
With and without the bin file flashed, the QCA should answer a GetSoftwareVersion request. If the flash is missing or not flashed, the software version would show "bootloader".
I have no real answer, just some points to check:
- Maybe the qca-ethernet driver provides some information in a log, which could help to find out whether it indeed sees the QCA.
- Is the eth1 also available if you completely disconnect the QCA? This would help to understand whether the presence of the eth1 is correlated with the correctly detected QCA.
- The QCA goes to sleep after some seconds, if it does not see a "central coordinator" (other homeplug device, or charging station). You could try again after power off - on of the QCA.
- You could check the 1.2V and 3.3V lines of the QCA.
- If you have an osci or logic analyzer, you could check whether the SPI is talking at all, especially whether the MISO line contains senseful data.
- Not sure whether also the INT line needs to be connected to the raspberry, maybe in general check the wiring.

Edit: Check whether the raspberry is exclusively using the SPI of the QCA. If you have a Foccci, you need to keep the STM32 in reset, otherwise it fights against the raspberry on the SPI.

Zieg wrote: ↑Thu Sep 26, 2024 6:01 pm Digikey recommended this to me as an alternate when the other one was OOS. It was cheaper, and now that I have it in my hands I can verify it fits the connector. Drawing sheet also seemed to have identical critical dimensions when I checked it.
https://www.digikey.ca/en/products/deta ... 4B/9953946

It's cheaper only if you don't include shipping; when I went to checkout, it became at least as expensive as the Jorch:
https://www.aliexpress.us/item/2251832671457223.html
at USD$25 and free shipping.

Also, the Jorch is aluminum; the Amphenol is thermoplastic [shrug].

Ah, fair enough. I got free shipping since I was ordering all the other components at the same time, so it wasn't a factor.

Got some 5.1 boards but i can't seem to find any information about pinout that are user freindly.
Also on the contactors control on version 4.5b that i integrated in an other project, they were High side switched, is that still the case ?
I want to update this schematics :
https://openinverter.org/wiki/File:Foccci_CCS2.png

Yes, the 4.5b, 5 and 5.1 share the same pinout. Yes, the contactor high side switching is still the case for version 5 and 5.1.
I just added this into the wiki page for more clarity. https://openinverter.org/wiki/Foccci

I moved the CP mirroring posts here: viewtopic.php?t=5127

JLCPCB has a small quality issue with the soldering of the RF transformer. On two boards, the transmit path is shortened by a solder bridge below the transformer. Found this during testing, no communication was possible, but the modem did not go to sleep (LED stays green), this means the modem hears the EVSE, but the Foccci was not able to transmit anything.
Measuring the coil reveals 0.0 ohms, while the coils on good Focccis have ~1.5 ohms. We should keep an eye on this when testing new focccis. Or maybe redesign to use a better solderable transformer?

That's unfortunate, is there solder mask between the pads?

There looks to be a surprising amount of solder in there.

You might be able to shrink the pads down slightly or offset the pads away from each other a tiny bit in the footprint for the next batch.

Yes, a lot of solder, much more than on similar sized other pads. Is it possible that they can selectively control the amount of solder paste? They use very small amount for resistors, but for the big transformer they seem to go the safe way. Hm.
Shrinking the pads is a good idea. And yes, there is solder mask between the pads, this works on the pcb side. The tin tends to bridge on the ferrite side, seems the ferrite "pulls" it.

[Edit] Created issue https://github.com/uhi22/foccci/issues/5

The solder paste should start on the pads.

I'm not sure how JLC adds the solder, I don't believe they use the solder paste layer info for that. I think they use the pad info and +/- from that.

Perhaps silly question : do we actually need the transformer on our application? Does the LIM have one?