Develop a QCA7000 board?

[uhi22]

Indeed a good point. From the RF "academical" point of view, coupling an asymmetric line (CP is ground based) to a symmetrical line (QCA RX and TX have + and - which are symmetrical to their reference point) without a transformer is a baaaad design. But well, we want to charge cars, not win the RF design award. Anyway, from RF expert point of view, the PLC/CCS is a funny concept:
The symmetrical approach of the QCA is perfect for immunity and "clean" design. It avoids unwanted radiation, it is best for situation where every dB of signal-to-noise counts. It's a good RF design. And then comes the CCS. Unshielded lines and contacts, multiple volts on a single unshielded line against ground, perfect antenna, radiation pure, no immunity at all.
Thinking this to the end means: Yes, there is no need for a perfect coupler. Just using an L to ground to have high-pass filter should be fine. And then just connect one leg of the RX and one leg of the TX to a common unsymmetrical point.

[Zieg]

Just checked mine, 1.7ohms. Convenient place to test seems to be the two resistors directly beside it!

Although, I suppose it's possible they could bridge any of the 4 corners during production, eh? Have you only seen it on those 2 pins?

[uhi22]

It's worth to check all four pairs, I only found the obvious ones because they did not work at all.

[uhi22]

Made some measurements to compare the original Foccci V5 (including transformer) and a transformerless patch of it.

As expected, the transmit power lowers a little bit, which can be partly compensated by decreasing R25 from 150 ohms to 100ohms. The receiver sensitivity does not show significant difference.

The only concern is, that the transformer was also a "first line of defense" against low frequency high power disturbances. The remaining protection with the diodes is good, but is only the second line of defence. Maybe we should add additional diodes at the front end.

[johu]

That's promising!
A (bidirectional?) TVS would be an easy addition.

[uhi22]

This makes sense. But the currently used TVS SMAJ18A has a capacitance of some hundred pF, which would kill a lot of RF. How to find a TVS with lower capacitance, I think below 50pF would good, because 50pF have already ~100ohms at 30MHz. If available, I would prefer the 10 to 20pF range.

[johu]

Just digikeyed a bit and these exist and are called dataline TVS. Example ESD150B1W0201E6327XTSA1 0,15pF @ 10GHz

JLC has 10 of them so the challenge is to find one that they have plenty

EDIT: here is one https://jlcpcb.com/partdetail/DiodesInc ... 7B/C500765
It is only 5A but I reckon behind the 100 Ohm resistor that will suffice?

[jrbe]

I just went through this hunt in a design I'm doing. Capacitance isn't always listed in datasheets and isn't listed in parametric searches that I know of. Makes it a tough find.

I used www.claude.ai to find options. Tell Claude you're searching for ultra low capacitance tvs, with specs you're looking for. And that you're sourcing them from lcsc and it will add their part number references to the options it finds.

Claude can't give you web links and can't see inventory so it's still a bit of a hunt. It was last updated a few months ago. There are other options too for ai

[johu]

I filtered for "Capacitance @ Frequency" https://www.digikey.com/en/products/fil ... 0jBxUS0sgA

this brought up the dataline types. The data sheet then lists 10 pF. So doesn't resemble the parametric search but still fit for our PLC application.

But yes, AI is probably quicker, thanks for pointing it out

[uhi22]

The 10pF is impressive, and the 5A should be fine with the serial 100ohms and 1nF.
Quite small housing, no chance of hand-soldering

[Zieg]

Yeesh, they'd better not bridge those pads too!

[johu]

Went to my co working space today for some pyPLC hacking using a Foccci as peer. Of course I forgot my CAN dongle. Fortunately one of my co workers had a USB serial cable with him. So I thought lets just run the terminal on the debug port and see what happens.

Challenge was the firmware upgrade, I pressed RX and TX against the gates of the LED mosfets which happen to sit on the uart3 pins

Terminals runs just fine. The first command you want to issue when using it is "set logging 0"
It wouldn't work with an ESP module because there are still some debug messages but that wasn't the requirement here.
https://github.com/uhi22/ccs32clara/com ... 850f6ae187

[uhi22]

Did I understand correct, the bootloader uses different uart pins than the ones on the Foccci uart connector? Would it make sense to add a connector "boot uart"? Or to change Foccci/Clara to use the same ports as the bootloader?

[johu]

Yes the boot loader is hard coded to UART3. There is already the pininit structure that instructs the boot loader to initialize pins. Maybe that could be extended to tell it which UART to use.
Of course bringing out UART3 on a separate pin header would also be a low effort improvement. On the other hand I'd expect users to either have an ESP32 or a USB CAN dongle for setting the parameters, so I think we are looking at a rare corner case.

[uhi22]

I will add the additional pin header for UART3, this is nearly no effort, and offers some flexibility, e.g. adding a serial display or what ever.

[uhi22]

I will add the additional pin header for UART3

Done with https://github.com/uhi22/foccci/commit/ ... 362a79e89f which is a pre-version for 5.2.
Ready for review and comments.

[jrbe]

A lot of this you might know, none of it is a knock, just a second set of eyes and the short version of what I see.
A quick design review:

- Do J3 & J5 have enough room to the box for clearance? If you want you can set a components keepout on the edges where the box lips are - if it has them.. I think the front courtyard area is purple to try to keep stuff out of those sections. Or just for bench testing?
- For the C77-C80 + area there is 1 thin ground for a string of 9? capacitors & resistors. I'd suggest bumping them over a bit and adding a top local thermal relief GND plane with a bunch of stitching vias to gnd. I always try to stitch ground pads to the inner ground plane just to avoid issues.
- You have +3V3 & GND in the 2 inner planes but use a bit of a spiderweb of a plane on top to connect things. It can get hard to track whats going on for good connections using the woven top method. Rules check will see things connected even though it might be a very thin trace, a lot of heavy items on it, or a long convoluted path. I'd suggest using the inner planes as +3V3 & GND and routing the high speed lines on top of the inner ground plane. Dropping vias everywhere they're needed locally.
- Y2 / Y3 backup crystal footprint - Is it still necessary?
- If you leave the planes off the top and bottom layers you can use small sections of planes for ground, power, etc. on the top or bottom layers to connect groups. It takes a bit to remember you have the power and ground pretty much everywhere for you but it helps simplify things a ton. You can likely eliminate the planes on the top and bottom and start there if you want. I usually do one trace and via to power / ground for a pad then just copy / paste that trace and via everywhere its needed.
- the inner power plane can have a trace for the 1.2v line. You can make the 3v3 a U shape around it if you're worried about making a loop. Whats there gets thin and makes some loops around C40.
- via in pad is ok if you are doing filled & capped vias, otherwise theres a chance it ends up a dry solder joint from the solder wicking into the via hole or toumbstoning if the hole is on the edge of the pad. You can put the vias off the edge of the pad, past the solder mask and not worry about the solder going anywhere. The soldermask will block it.
- Pin 1 dots next to ICs help fabrication breeze through the assembly and troubleshooting. I know there are other methods but they are all less quick and clear, at least for me.
- Design Rules Checker (DRC) helps find important and less important issues. There are some footprint overlaps to bump a bit and silkscreen overlaps if it matters to you.
- plane minimum size can be adjusted to flow a bit better between pads and things. JLC is fine with .2 plane sections between items, that's usually all it takes to not have fingers of the plane flow almost touching.
- I usually try to do +3V3 or gnd on an inner layer, via up, capacitor pad, then pad. I try to keep the capacitor pad as the connection between to keep it clean. If it drops back down to the inner planes then up again its hard to say its decoupled well still. Almost every datasheet says to keep the capacitor as close as practical to the pin.
- D13 is close to the main connector screw boss. It should work but could likely move a bit.
-Temp1 male pin pokes through the connector housing. The J2 & J4 connectors look to be an extra though, so maybe it doesn't matter for your use case??
-focci icon has an extra miso / mosi / reset / etc label under him.
- the ground pour on the bottom might be unnecessary. Removing it only sets 1 item as not connected. It shouldn't hurt to leave it there.

Of note:
KiCad added teardrops in version 8. Its not a huge deal but teardrops can be added to all or specific types of areas if you want. Can help the trace connections to vias and other things long term.

No need to reply to this but feel free if you want or need clarity on my gibberish.

[uhi22]

Wow, many thanks, this is a lot of helpful stuff to improve my skills and to improve the product.

[Edit] Created an issue for further tracking of these findings: https://github.com/uhi22/foccci/issues/7

Regarding the pin headers which are colliding with the connector and housing: They populated only if the board is used without the Deutsch connector/housing. So a "dual purpose" board, to offer flexibility without having two board variants. Could the DRC be configured to know such an exclusive-OR-population?

[jrbe]

I'm glad it was well received.

I'm not sure if you can set the DRC to not find something like that. You likely want it to just warn you. You can set certain things to ignore in the drc. I usually turn all the warning options on and just give a quick check of the greyed out ignored warnings.
So for example, I just did a really tight design where there's an optional shunt under a pp capacitor for testing. I set it to ignore but keep it displaying the issue so it shows in the list but it's light grey. You get the error arrows on the screen to see what's going on as well. You start to learn the colors of the arrows.

A few other thing on planes. If you change the snap distance in kicad to something like .1, .25, .5, 1 it helps draw the planes square. I wish you could hold shift while dragging the planes to keep them square but that's not a thing in kicad yet. Kicad has a line come off the corner to help keep it straight.
Turning the kicad crosshairs on in view can help a ton too. I'd recommend everyone tries this for an hour.

Using the plane priority will set the fill priority. So if 2 planes overlap, the higher priority one will fill out first then what's left will go to the next plane with the set gap between them.
Getting into this a bit more, you can set the plane clearance so that a plane overlapping a plane will also draw a clearance border between them as part of a redraw. So no worry about accidently merging planes. Just make sure they have different plane priority levels.
It's a bit odd to leave overlap on planes at first but it makes for clean planes with nice gaps once you wrap your head around it.

[jrbe]

I just found the KiCAD keyboard shortcut for drawing planes and other things 90 / 45°. Shift and space toggles the plane lines to snap to 45° angles. I did not know this existed... It still can leave odd edges but definitely helps draw planes square.

[uhi22]

Short update: made some layout improvements, considering the valuable feedback. Planned to order a set of boards, but jlc again changed the orientation in their data base for multiple components, so it looks like this:

image.png (12.44 KiB) Viewed 1441 times

Is there a way to keep a stable orientation for more than half a year?

[jrbe]

I would be surprised if JLC changed their reference of the rotation / orientation, but they reference the packaging rotation (i believe...) That can differ with the same component but different packaging (for the pick and place machines) so could be inconsistent that way. Sometimes you get the same component in JLC with multiple packaging methods, same part number besides packaging with different LCSC #s because of the packaging.

KiCAD is a mess with this, the way components are supposed to be laid out in KiCAD is the #1 pin is in the top left corner but even the components in KiCAD libraries do not always follow this. This follows IPC orientation recommendations but those can be murky and weren't consistent over the years. Other methods follow the datasheet which follow?.. And to add to this, the multiple orientation conventions, EIA, IEC, IPC and its not surprising this is a cluster. This is old, but see, https://forum.kicad.info/t/jlcpcb-bom-a ... ce/19016/7

*Edit* See also, https://ohm.bu.edu/~pbohn/__Engineering ... raries.pdf

So to avoid the confusion (but not the consistent effort) always add a reference dot for pin 1, helps you and the assembler avoid all the nonsense and be able to see clearly the correct orientation.

The JLC KiCAD Fabrication Toolkit plugin rotation data can get erased if you change the component, even to the same one. You can pull up old CPL files to see the rotation offset but have to work backwards a bit.

You could save a JLC footprint with corrected rotations but then you have multiple footprints to pollute the which one is right efforts.

No matter which way you try to go it can be a struggle. Its just part of the tail end of ordering from JLC and part of their cheap board fab. They will correct the rotations for you but I try to not dump extra effort or chance to make mistakes on them. Other board houses will correct the orientations before making boards but they still need the pin 1 references to check.

Also of note, JLC's file viewer / browser interface has a bug / a cache issue where it can keep old versions of your uploaded files and can show old rotation info - even though you upload a new one.
You have to:
- delete the old file from JLC file manager
- close the browser
- reopen the browser
- then upload the new version to JLC.

This was my mention of going in circles with JLC wen I was doing the Gen3 Leaf adapter board. I'd rotate a part, save new gerbers & files but get the same rotation issue on JLC, most of the time..

Theres also a JLC viewer bug if non ascii characters are used in descriptions in the bom or cpl files. It can shift whole sections of components in their rotation / orientation view for some reason. Sometimes you'll get a symbol in a description that geeks it out.

Lots of oddities, just part of doing these designs unfortunately. I usually need to start a fresh day working through these or I just make too many mistakes or am too tired to pay enough attention.

[johu]

Most of the boards I order have incorrect rotation or even position info but clear pin 1 markers. Their corrections are always spot on.

The only issue I ever had was placing a via at a corner of a QFP and they confused it with the pin 1 marker

[celeron55]

JLCPCB always runs the designs through an actual person who will rotate components to match the board. The most important thing is clear board markings. Anything else is just nice to have.

They can't skip that step because if the placements were wrong, they'd risk their equipment. Just having to clean up a mess would be very costly, let alone fixing broken equipment.

[reactive001]

Just wondering if anyone has experienced problems getting the SPI to work on the QCA7000?

I made up a small PCB using the schematic from the Foccci for the QCA part (the board is for implementing an EVSE on an ESP32P4 devkit) and everything measures and behaves like it should except I can't get it to reply to an SPI request. All voltages measure correct, oscillator is fine, QCA reads the flash as expected but no signs of life from the SPI. It's been driving me slightly insane so I thought it would be worth asking.

Tomorrow night I'll dig out a rPi to flash the firmware again since I used an ESP32 to do it initially, but it wrote and verified just fine. Apart from that, I'm pretty stumped. I think I have to order a aliexpress QCA dev board from aliexpress anyway to get the EVSE firmware but it'll still torture me over the Christmas break if it won't work