ChanServ changed the topic of #glasgow to: glasgow interface explorer · code https://github.com/GlasgowEmbedded/glasgow · logs https://freenode.irclog.whitequark.org/glasgow · discord https://1bitsquared.com/pages/chat · production https://www.crowdsupply.com/1bitsquared/glasgow · CrowdSupply campaign is LIVE!
modwizcode has quit [Quit: Later]
futarisIRCcloud has joined #glasgow
trongate has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 264 seconds]
PyroPeter_ has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
egg|anbo|egg has joined #glasgow
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
electronic_eel_ has quit [Remote host closed the connection]
electronic_eel has joined #glasgow
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 272 seconds]
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #glasgow
electronic_eel_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
electronic_eel has joined #glasgow
<electronic_eel> @Greg the INA233 issue is now solved in firmware. you need the wip-revC2-firmware branch which is not merged yet.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
<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.
GNUmoon has quit [Remote host closed the connection]
<d1b2> <rwhitby> (I also have a campaign Glasgow on order, but wanted one quicker)
GNUmoon has joined #glasgow
<d1b2> <rwhitby> Currently using a proprietary board to do this https://gist.github.com/rwhitby/b98254e84ae402e87a25c6b981303511 but an open source solution will be better.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
egg|anbo|egg has joined #glasgow
trongate has quit [Ping timeout: 272 seconds]
GNUmoon2 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
modwizcode has joined #glasgow
m42uko has quit [Remote host closed the connection]
m42uko has joined #glasgow
fibmod has quit [Ping timeout: 260 seconds]
fibmod has joined #glasgow
bvernoux has joined #glasgow
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
egg|anbo|egg_ has joined #glasgow
<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
<d1b2> <massi> current release
<d1b2> <massi> revC2
<d1b2> <massi> modified
<d1b2> <massi> Actually i would avoid to split the powerplane under the Z1...Z7 tracks by VIOB
<davidc__> Can't VIOB be routed entirely on the top side?
<davidc__> (or bottom side, whichever is in green)
<d1b2> <massi> maybe, btw it's just fine avoid to spit plane under "potentially" high speed signal
nicoo has quit [Ping timeout: 240 seconds]
<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.
nicoo has joined #glasgow
<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
<electronic_eel> otherwise the planned delivery dates for the campaign aren't realistic
<electronic_eel> so while the rerouting you propose is an improvement, i currently don't see it as critical
<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
<miek> is there actually a problem with that split though?
<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
<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
<miek> it's a bank of 10kohm pulls though
<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
<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
<d1b2> <DX-MON> )
<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
<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
<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
GNUmoon has quit [Ping timeout: 240 seconds]
<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
<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
bvernoux has quit [Quit: Leaving]
<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
<marcan> signal integrity won't be a problem
<electronic_eel> hi marcan
* marcan --> sleep
<electronic_eel> marcan: have a good night then
<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
<d1b2> <DX-MON> credit to massi for the suggested change
<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
<d1b2> <DX-MON> I agree the correct fix is to use a contiguous ground pour on the next physically closest layer
<d1b2> <massi> I'm so sorry for what follow after my post!
GNUmoon has joined #glasgow
<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
<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.
egg|anbo|egg__ has joined #glasgow
ali_as has joined #glasgow
egg|anbo|egg_ has quit [Ping timeout: 246 seconds]