07:23 <electronic_eel> @Greg the INA233 issue is now solved in firmware. you need the wip-revC2-firmware branch which is not merged yet.

07:32 <d1b2> <rwhitby> excellent, I'm buying the board from @Greg Greg so I can use it to help @marcan with the Asahi Linux work. In particular, perhaps adding a USB-PD add-on board using FUSB302.

07:32 <d1b2> <rwhitby> (I also have a campaign Glasgow on order, but wanted one quicker)

07:34 <d1b2> <rwhitby> Currently using a proprietary board to do this https://gist.github.com/rwhitby/b98254e84ae402e87a25c6b981303511 but an open source solution will be better.

19:49 <d1b2> <massi> Hello, i was looking inside glasgow revC2 hw design (PCB specs mostly) in the meanwhile i saw something that to me could be improved

19:49 <d1b2> <massi> current release

19:49 <d1b2> <massi> https://cdn.discordapp.com/attachments/613461005392936961/799364655280554004/gla_after.png

19:50 <d1b2> <massi> revC2

19:50 <d1b2> <massi> https://cdn.discordapp.com/attachments/613461005392936961/799364884730871818/gla_before.png

19:51 <d1b2> <massi> modified

19:51 <d1b2> <massi> https://cdn.discordapp.com/attachments/613461005392936961/799364963310239814/gla_after.png

19:52 <d1b2> <massi> Actually i would avoid to split the powerplane under the Z1...Z7 tracks by VIOB

19:56 <davidc__> Can't VIOB be routed entirely on the top side?

19:56 <davidc__> (or bottom side, whichever is in green)

20:00 <d1b2> <massi> maybe, btw it's just fine avoid to spit plane under "potentially" high speed signal

20:21 <electronic_eel> @massi: i don't know if you've been following glasgow development of the last weeks. esden made revC2 prototypes last year and then i did most of the qualification tests for these. we are now working on revC3, see the wip-revC3-hardware branch.

20:22 <electronic_eel> this branch will contain a bugfix and a few minor improvements. but the goal was to do just very few changes, to be ensure that no new issues creep in

20:22 <electronic_eel> otherwise the planned delivery dates for the campaign aren't realistic

20:23 <electronic_eel> so while the rerouting you propose is an improvement, i currently don't see it as critical

20:26 <electronic_eel> marcan came up with some similar issues after watching a video from a emi expert (see his twitter for the link), but especially esden didn't want to incorporate these changes because of risk breaking something

20:32 <miek> is there actually a problem with that split though?

20:38 <d1b2> <DX-MON> yeah, the split causes the ground return current path on those 8 signal traces to taje a rather substantial detour around the bottom of the addon header and up around the side

20:40 <d1b2> <DX-MON> recalling that every signal trace generates an equal and opposing return current in the ground plane.. makes for some extremely poor EMI performance if it doesn't screw with signal integrity

20:40 <miek> it's a bank of 10kohm pulls though

20:41 <d1b2> <DX-MON> which then have the traces routed on the top side of the board across the gap to the other set of holes/rings.. and then on into the PU/PD control chips

20:42 <d1b2> <DX-MON> when the pull resistors are in use, it will generate ground currents (and technically always anyway because propagation fronts don't ignore a trace segment simply because it's not currently in use for its intended purpose

20:42 <d1b2> <DX-MON> )

20:44 <d1b2> <DX-MON> I'd hazard a guess the overall effect will be low on signal integrity, but it might cause EMI problems which would be desirable to avoid in future revisions if possible

20:55 <electronic_eel> unfortunately i'm currently a bit tight on time to use for Glasgow stuff, but maybe next week or so i could use my revC2 and play a bit with near field probes and my spectrum analyzer. while this is definitely not a reproducible test result, it might show if there is a severe issue somewhere in that area

20:58 <electronic_eel> but as i wrote before, i think the biggest emi issue with Glasgow will be flywires plugged into the ports. Any layout improvements we do on the pcb will be miniscule to the effects of these flywires

21:02 <marcan> DX-MON: your fix does not actually fix the problem, because that is still a 3V3 plane and the I/Os are not referenced to 3V3

21:03 <marcan> the correct fix is to add a small GND pour replacing the 3V3 in that section, and a couple vias around the resistor network to add a path down on that side

21:04 <marcan> anyway I already discovered that exact issue after watching that video, but it's mostly academic at the distances involved and this isn't intended to be EMI certified anyway

21:04 <marcan> signal integrity won't be a problem

21:05 <electronic_eel> hi marcan

21:06 <electronic_eel> marcan: have a good night then

21:06 <d1b2> <DX-MON> that's not my fix.. I was only providing some commentary on it after working out what changed and understanding the implications somewhat

21:07 <d1b2> <DX-MON> credit to massi for the suggested change

21:08 <d1b2> <DX-MON> and fair point out that it's a 3V3 plane.. that wasn't terribly obvious from the screenshots provided so I was working on incomplete information and made the (incorrect) assumption it was a ground plane

21:09 <d1b2> <DX-MON> I agree the correct fix is to use a contiguous ground pour on the next physically closest layer

21:27 <d1b2> <massi> I'm so sorry for what follow after my post!

21:34 <d1b2> <massi> btw i agree with electronic_eel , even if the proposed fix should mitigate some potential issues ,due to the limited amount of time it's better to stay with something already tested

21:41 <d1b2> <massi> Also if you can choose where to reference (GND or PRW plane) an "hi-speed" signal, it's better to go for GND. But if you can't usually PWR plane also works fine.