openinverter forum

Found my solder sucker, in the wrong bin as usual.

Charlie's pic was enormously helpful, but I either bought a bum unit (foolishly, I forgot to plug it in to mains before attacking with the Dremel) or I managed to zap it, though I was being quite careful. It draws no current at all, either at 5V up to 12v, and of course none of the three LEDs light, button is non-op.

Off to buy another . . .


Charlie's on the left, mine on the right.

Uwe, the PLC wiring on these two pictures at https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md don't seem to agree? Am I making a bad comparison?

asavage wrote: ↑Sun Apr 02, 2023 12:31 am Found my solder sucker, in the wrong bin as usual.

Charlie's pic was enormously helpful, but I either bought a bum unit (foolishly, I forgot to plug it in to mains before attacking with the Dremel) or I managed to zap it, though I was being quite careful. It draws no current at all, either at 5V up to 12v, and of course none of the three LEDs light, button is non-op.

Sorry, my fault for not being clear enough. See rear of board! Those 2 points on the board where I connect +12V are NOT actually the supply rails, I just use them as a convenient place to add pins to connect things.

asavage wrote: ↑Sun Apr 02, 2023 12:47 am uhi22, the PLC wiring on these two pictures at https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md don't seem to agree? Am I making a bad comparison?


DieterLV_schematic_compared_01b.jpg

I believe with the board you and I have, the protective components for the mains voltage are are still in place. Therefore you should be able to connect "L" to CP, and "N" to PE without the need to add any additional components in between. The big yellow box should be the necessary 1uF capacitor. In any case, the exact location of the capacitor and resistor shouldn't matter, as long as they're both in series somewhere between CP, PE, and the PLC.

asavage wrote: ↑Sun Apr 02, 2023 12:47 am uhi22, the PLC wiring on these two pictures at https://github.com/uhi22/pyPLC/blob/master/doc/hardware.md don't seem to agree? Am I making a bad comparison?


DieterLV_schematic_compared_01b.jpg

You are right, the pictures show different orders of the transformer, the R and the C. The important point is, that these three components are in series between the CP and the PE. The order does not matter, also the polarity does not matter. And the precise values also not, I guess everything between 33 ohms and 220 ohm should work, and also 0.5nF, 1nF and 2.2nF. Higher capacitor values could slow the edges of the 1kHz PWM, so this should be avoided.

Ah, well, that's a help. I've added those jumpers, and I've now got some LEDs on, much thanks.

[Hah! you posted info on all the below just seconds before I posted, so below is all out-of-date now. Timing is all-imporant ]

catphish wrote: ↑Sun Apr 02, 2023 3:02 pm In any case, the exact location of the capacitor and resistor shouldn't matter, as long as they're both in series somewhere between CP, PE, and the PLC.

Hmmm, the schem. has them in series on one leg of the PLC to the CP and I couldn't reconcile that with the shown wiring (yellow leads). The other PLC leg is to GND . . . Oh, I'd forgotten that PE = GND, duh. I've been thinking of PE as an undefined symbol; it helps to more fully flesh out some of this mentally. I'm a bit slow.

Also, 150 ohm note on wiring, vs 180 ohm on schematic?

Regarding the supply, a good orientation gives the big electrolyte capacitor 470µF/16V. That's the point to connect the power (12V or 5V or something in between).

I can see why Charlie selected the location he did, as it is handy for header pins. And, I think his choice also retains D1 (BX310) as reverse polarity protection. On reflection, S1 (+) and S2 (-) are where I should have placed my leads. Those vias are too small for header pins, but would work for surface leads.

That's where the original output from the PS connected, I think.

Indeed, the points S1 and S2 are the secondary coil of the original power transformer, and the D1 was the rectifying diode. Using this as reverse-polarity protection makes perfect sense, if we have 12V supply. My modifications rely on 5V supply from USB power bank, that's why I skip the diode, to avoid additional voltage drop.

Alrighty, hardware is now set up. I'm using part of an OI board to generate 5V and 3V3 and also got the elcap on there. On the other end I'd plug into the cigarette lighter. Probably I could just use 12V straight but thought it was safer to have the regulator.

Now you mention open-plc-utils . Is there anything I need to do to enable SLAC or something?

Yes, the TPlink needs a special configuration, to be able to support the SLAC. This needs to be done with the open-plc-utils. We need to read the config file from the device, change some settings and write it back to the device. There is a summary in https://github.com/uhi22/pyPLC#configur ... lc-adaptor, and a more detailed description in the docu of the open-plc-utils.

johu wrote: ↑Mon Apr 03, 2023 8:17 am Now you mention open-plc-utils . Is there anything I need to do to enable SLAC or something?

Yes, you need to use open-plc-utils to set 4 parameters in the device. This hasn't been clearly documented on this thread, so I will try to outline the process here. There are two ways to do this, I'd definitely try the first way first:

1) Make a note of the old settings with plctool -aI -eth0
2) Use plctool to download the PIB from your device.
3) Use setpib to modify the 4 settings in the device as per the commands here: viewtopic.php?p=47024#p47024
4) Use plctool to re-upload the modified PIB to the device
5) Verify the new settings with plctool -aI -eth0

The alternative (more involved way that includes upgrading the firmware to a known working version)

1) Make a note of the old settings with plctool -aI -eth0 (this is important as you need to note the MAC address)
2) Download firmware QCA7420-MAC-QCA7420-1.5.0.26-02-20200114-CS - this should come with a PIB file as well as a NVM firmware file
3) Use setpib to modify the 4 settings in the PIB file, and also set the correct MAC address
4) Use plctool to re-upload the new NVM and modified PIB to the device
5) Verify the new settings with plctool -aI -eth0

EDIT: I see uhi22 has done a better job of documenting it here: https://github.com/uhi22/pyPLC#configur ... lc-adaptor

Did follow uhis instructions and they worked flawlessly.
So now I can just drive up to an EVSE with some crocodile clips, connect the PLC transformer to CP and PE via 1nF/150R, run uhis script and start communicating. Oh and do the CP resistor thingy. If I'm so inclined I could take a kettle with me and boil some water. Right?

Oh man looking forward to a video of that

For the kettle we also need to satisfy the end-of-precharge, means to compare the target voltage and the actual voltage. In the GitHub version of fsmPev.py this relies on physical measurement, hardwareInterface.getInletVoltage(). So either to add this, or use the EVSE reported voltage. This is not yet implemented.

Mashing up yours and Uwe's excellent recipes (on Ubuntu*) for a bit more granularity/elaboration, for folks with slightly less experience, as our audience will likely include all backgrounds . . . certainly, I had to interpolate a bit . . .

[*= Win will have a different default directory location, and possibly different MAC address syntax, and Win MAC notation generally uses hyphens '-' rather than colons ':' as byte separators for MACs.]

The open-plc-utils: programs to manipulate the AR7420 IC in the TL-PA4010
There is a .deb package available for install -- no compiling from source -- for Linux distributions that can use .deb packaging. If you are comfortable installing from a PPA (a non-secured repository), the package lives on https://launchpad.net/~roguescholar/+archive/ubuntu/snapshots. I have not used it.

AFAICT, aside from that .deb, the open-plc-utils are not available as precompiled binaries, meaning the sources have to be downloaded and compiled for the target system (unless someone knows of precompiled binaries, in which case I'll edit this out). Obtain the open-plc-utils by cloning (copying) the source files from its Git repository. Assuming you have git installed ("sudo apt install git"), the following command will copy the source files to a new directory that will be created:

asavage@Ubuntu1:~$ git clone https://github.com/qca/open-plc-utils

Copying a snippet from its README:

[ . . . ]
1. Enter package folder using "cd open-plc-utils".
2. Compile all tools using "make".
3. Install all tools to /usr/local/bin using "sudo make install".
[ . . . omitting steps for documentation installation, which isn't really necessary unless getting into the nitty-gritty stuff . . . ]

Now you have actual utilities that can be run.

Connect the hardware to your host
The RL-PA4010 needs power, and it needs an enet cable from it to your host. Make sure you have an LED lit on the unit (power is on).
For enet, use a std cable to your host or your host's network. I plugged into a local enet switch, but plugging directly into your host will be fine with modern hardware (I remember when Auto-MDIX didn't exist . . . ).

Take a copy of your unit's Parameter Information Block (PIB)
From the open-plc-utils folder . . .
asavage@Ubuntu1:~$ int6klist -ieth0 -v
Note: I don't have "eth0", I have "enp6s0", so be aware that your ethernet interface name may vary. If, when you run the above line, your output is something like: try to find your active ethernet interface name, and use it instead of "eth0". It will almost certainly begin with 'e'. If you have multiple interfaces whose name begins with 'e', you'll have to try them sequentially to figure out which one your TL-PA4010 is connected to. Here's the output on my system:





The output of int6klist should be similar to this:
. . . and the MAC address is listed in two places.

Alternatively, use:
asavage@Ubuntu1:~$ plcstat -t -i eth0
Output for my unit: Copy the the MAC address (including the ':' separators), and use this command read the configuration (the PIB) from the PLC adapter and write it to a .pib file:

asavage@Ubuntu1:~$ plctool -ieth0 -p original.pib F4:F2:6D:BA:3C:FA // Change the blue text to your adapter's MAC address.

You can name this PIB file anything you like, and if you'll be working with multiple units, possibly from multiple markets (UK, EU, US, etc.) you may want to be more creative with the filename, to keep them discrete.

Updating the firmware
Take a copy of your unit's Parameter Information Block (PIB) before changing the firmware! (see above).

I chose to update the firmware at this step. My unit's firmware is dated 2012. TP-Link lists firmware for "V1" and "V3" versions, and while there's no way for me to determine which version of hardware I have . . . and because I see sporadic issues with people having seemingly unrecoverable issues with upgrading the TL-PA4010 when starting from very old firmware, and because I've lived a long time and have seen a few things, I upgraded in steps: first to a 2015 firmware, then to the 2020/latest. Turns out, while the two "V1" and "V3" firmware at TP-Link's site both installed OK -- I updated them sequentially -- they both have the same firmware date after flashing, though when inspecting hex they have small internal diffs.

I obtained the 2015 firmware from https://www.tp-link.com/us/support/download/tl-pa4010-kit/v1/#Firmware: https://static.tp-link.com/TL-PA4010(US)_V1_160316.zip. I extracted the NVM & PIB files from it, to the open-plc-utils folder (though that's not necessary, but I like shorter commandlines). The following command will write the new firmware (NVM) and configuration (PIB) to the unit:

asavage@Ubuntu1:~$ plctool -i eth0 -P QCA7420-WallAdapter-HomePlugAV_CE-ClassB.pib -N MAC-7420-v1.3.0-00-CS.nvm -R F4:F2:6D:BA:3C:FA // Change the blue text to your adapter's MAC address.

The update process took about ten seconds to complete. Lots of output on the screen, but summarizing: Checking using plcstat again:
asavage@Ubuntu1:~$ plcstat -t -i eth0 2015: looks good.

I have been unable to locate catphish's QCA7420-MAC-QCA7420-1.5.0.26-02-20200114-CS as a package (ie NVM + PIB files), but the NVM alone can be found at https://mega.nz/file/ocNDhYzK#xuSQXd-b6CzzfpSXaK7r5BV4i3pXmnstYMjZX5WEWHc and he also uploaded it to OI earlier in this thread: https://openinverter.org/forum/download/file.php?id=19195. AFAICT, having a replacement PIB is not strictly necessary, as long as you have saved a copy of your unit's, or can locate a compatible one, and then only in the event of something screwing up. If you update the firmware, you'll want to pull another PIB from your unit to use anyway (read on).

asavage@Ubuntu1:~$ plctool -i eth0 -P QCA7420-WallAdapter-HomePlugAV_CE-ClassB_us_401030.pib -N FW-QCA7420-1.5.0.0026-02-CS-20200114.nvm -R F4:F2:6D:BA:3C:FA // Change the blue text to your adapter's MAC address.

asavage@Ubuntu1:~$ plcstat -t -i eth0 2020, yea.

Modifying the PIB to enable EVCC use
I renamed "original.pib", which was in the unit with 2012 firmware, to something else. Then I took another copy of the PIB from the unit with 2020 firmware: it's different. Rather than modifying the early PIB, I used the later one. Use the same step as earlier:
asavage@Ubuntu1:~$ plctool -ieth0 -p 20200114_original.pib F4:F2:6D:BA:3C:FA // Change the blue text to your adapter's MAC address.

Use the setpib tool to modify this PIB for EVCC use:
asavage@Ubuntu1:~$ setpib 20200114_pev.pib 74 hfid "PEV"
asavage@Ubuntu1:~$ setpib 20200114_pev.pib F4 byte 1
asavage@Ubuntu1:~$ setpib 20200114_pev.pib 1653 byte 1
asavage@Ubuntu1:~$ setpib 20200114_pev.pib 1C98 long 10240 long 102400

Write the configuration file to the PLC adaptor:
asavage@Ubuntu1:~$ plctool -ieth0 -P TL-PA4010_20200114_pev.pib F4:F2:6D:BA:3C:FA // Change the blue text to your adapter's MAC address.

This takes about one second to accomplish, mostly the reset. At this point, you're done with configuring the AR7420 on the TL-PA4010

catphish wrote: ↑Mon Apr 03, 2023 9:08 am 1) Make a note of the old settings with plctool -aI -eth0

Perhaps the order of your steps isn't optimum. This did not work for me with unmodified PIB. With the 2020 firmware:
asavage@Ubuntu1:~$ plctool -aI -ienp6s0 (With the 2012 firmware, the msg was less verbose but essentially, "nah".)

After modifying the PIB for pev, that command yielded similar results to yours.

catphish wrote: ↑Mon Apr 03, 2023 9:08 am The alternative (more involved way that includes upgrading the firmware to a known working version)
[ . . . ]
2) Download firmware QCA7420-MAC-QCA7420-1.5.0.26-02-20200114-CS - this should come with a PIB file as well as a NVM firmware file

I wasn't able to find a matching PIB for this firmware, and reading the 3-page thread over at TP-Link, others didn't either.

catphish wrote: ↑Mon Apr 03, 2023 9:08 am 3) Use setpib to modify the 4 settings in the PIB file, and also set the correct MAC address

Because I updated the firmware, then pulled the PIB to modify, I didn't need to set the MAC; it was the same.
If I had had a "fresh" PIB with the 2020 firmware, I'm sure this would be necessary.

catphish wrote: ↑Mon Apr 03, 2023 9:08 am EDIT: I see uhi22 has done a better job of documenting it here: https://github.com/uhi22/pyPLC#configuration-of-the-plc-adaptor

That's a really good body of work he's done!

I created a skeleton OI Wiki article for the QCA7420. While Uwe's git write-up is stellar, it's also not editable by all as a Wiki is. I love one-stop-shopping but I also like many to be able to contribute to documentation, errors and changes can be quickly updated via Wiki. Use or ignore as you like.

Thanks for that, successfully flashed the 2020 firmware now.

Unfortunately I also flashed my QCA7500 (ALL1681205) with the same firmware because I'm silly. I have the other adapter but didn't find a command to read out its firmware. Any ideas?

To stay on topic here is my test setup. It lacks the "Dieter" circuits so may have to patch the code a bit. The inverter board supplies 5V and 3.3V, has the 1nF and 180R resistor on it and also the CP circuitry. Tested with granny cable and works.

Also tried supplying the modem from Beaglebones 5V output but that is too weak and the power LED blinks. So for now I'll need to plug in to 12V. Might go out and test later today.

First trip to the charger

We actually talked some EXI. I had brought some loads but then realized the CCS plug doesn't have pins but holes for pins. So need to think of something to contact them.

I patched the "Dieter" Comms with constant values, always reporting 230V port voltage.

I packed up after it didn't output voltage but back home realized that I had just waited to long to blip my card.

8mm brass tube works fine, or just a folded 2,5qmm for the beginning...

Yes, ended up using two 8mm bolts, they slide in smoothly.

Unfortunately no power from the charger and in the end the charger locked up telling me to unplug the car even though I had already removed all wires and put the handle back.

This looks very good. The blocker is the exi-decoder of the ContractAuthenticationRes. It should show This is what the latest decoder shows using the exi from your log. But in your log we do not see the EVSEProcessing = Finished, that's why the state machine does not move on.
I guess it is just an outdated revision of the openV2Gx used, which had incomplete decoder implementation.

Edit: The log file looks like a decoder before 2022-12-02, before the commit https://github.com/uhi22/OpenV2Gx/commi ... 67cd8776b3.

Ok cool, just pulled the latest source. Will retry later. Hopefully the charger is fixed.

Ok, the latest openv2g version spits out usage info instead of decoded data

EDIT: sorry I'm silly. I didn't use your fork

To much hectic This output is produced by the OpenV2G from "git clone http://github.com/Martin-P/OpenV2G". But we wanted the extended one with the command line interface, from "git clone http://github.com/uhi22/OpenV2Gx".

True - well I'm very ecited So will not go out again today.
BTW that charger unlocked when I started another session. Left it non-working for 3 hours though. Maybe it would have unlocked if someone else started a "regular" session.