<d1b2>
<J> wow, just checking in at it's at 453% :pogchamp: 🚀 🎉
<whitequark>
revE is the ECP5 variant
<whitequark>
err, that was a long time ago, nvm
egg|laptop|egg has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
_whitelogger has joined #glasgow
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #glasgow
GNUmoon has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
balrog has quit [Quit: Bye]
<marcan>
whitequark: anyway this stuff will be *exponentially* more important for revE
<marcan>
so I'm glad I learned it now
<marcan>
(also part of revC we got lucky, revD could've been worse)
<marcan>
I had some good gut feelings/instinct when designing revC, but the ones that really caught me are the changing layers bit, and also the things that cross over breaks in the 3V3 plane, into it, or are not referenced to it (LVDS...)
<marcan>
basically putting most of the important stuff on the front (partly for visual/aesthetic reasons!) ended up being a really good idea for EMI/signal integrity reasons, since I kept the GND plane unbroken
<marcan>
it's just some of the stuff on the bottom that's dodgy
<marcan>
(cc esden)
<whitequark>
electronic_eel: re anodized case: I have this case for LimeSDR which actually makes it not pass self-test
<whitequark>
which I suspect might be because it is non-conductive...
<whitequark>
I should sand down the coating or something like that
<whitequark>
esden: so, do you think we should merge revC2 at last?
<whitequark>
that PR has been open for way too long
<esden>
oh hey :) Yes I think we can merge revC2 now.
<esden>
after you have time to review the issues with SMBus and if we need to change the i2c address on the DAC we should do that in revC3
<esden>
aka just changing the one strapping nothing else
<marcan>
esden: if we're still doing design passes for revC3 it probably wouldn't hurt to tweak the planes a bit tbh :)
<marcan>
wasn't sure how far we were on that
<marcan>
but up to you
<esden>
marcan: hard no
<esden>
it will none the less add time
<marcan>
sure
<esden>
we had plenty of time to do that
<esden>
I need to put a lid on it sorry.
<marcan>
(fwiw, what I'd do is add GND pours around the connectors on the 3V3 layer, a few vias around that, and that's pretty much it... the part that bugs me is the pullup stubs on the bottom side, going over 3V3 which is not Vio nor GND)
<esden>
Especially without EMI testing and only on a hunch that there might be an issue I don't see it waranted.
<marcan>
sure
<marcan>
just saying
<whitequark>
marcan: if you're itching to fix something, how about finishing upstreaming of various KLC stuff that's in the issue tracker?
<esden>
marcan: I do not want to dampen your motivation. I am just afraid things will keep being "one more tweek" which we did for a year now. That is all.
<esden>
If we did not do the "while we are at it let's change the ADC" we would not have to do revC3... but I agreed to it as it was a functionally useful addition.
<esden>
I know your change is much smaller than that. Still...
<esden>
I hope you understand my reluctance.
<marcan>
whitequark: good point
<marcan>
esden: I already said it's up to you :p
<esden>
Just trying to be as clear about my motivation as possible. :)
<marcan>
it's why I said if it were me
<marcan>
if I were doing the board run
<marcan>
:p
<marcan>
but I *am* curious about testing this now, because in principle I have an idea of what's bad for EMI now
<marcan>
so it'll be neat to run the experiment one day
<esden>
then please do that, I would love to see some hard data. :)
<d1b2>
<edbordin> esden holding the umbrella against the waterfall of scope creep 😛
<marcan>
I wonder what the slew rates are on the FX2 I²C bus
<marcan>
definitely shit on the rising edge
<marcan>
but if the falling edge is hard enough that could be interesting for EMI, *that* thing on the board is definitely all over the place
<marcan>
though IIRC the spec had some slew rate stuff?
<whitequark>
i've never heard of anyone having EMI problems because of I2C
<whitequark>
(like, normal I2C, not FM+ or stuff like that)
<marcan>
well, because you don't drive it continuously usually
<whitequark>
hm.
<marcan>
but I wonder what happens if you try to set up a worst case scenario of transactions
<marcan>
anyway, actually, back to user LEDs, it's not that bad... *because* I put a shunt across the cut 3V3 plane riiight next to those lines. so I take that back
<marcan>
that was my *one* "uhh I think I need this here for EMI/RF reasons" hunch in Glasgow
<marcan>
and I was right
<whitequark>
nice
<marcan>
I think I'm looking at old gerbers...
<esden>
I redid the led stuff... so it is not the way you had it.
<whitequark>
yeah uh, can someone please regenerate the gerbers and update README?
<whitequark>
I should have asked for that to be done on the branch *facepalm*
<whitequark>
maybe marcan? since you are already about to uh, need the new ones
<whitequark>
and you've updated the README pics before
<marcan>
wait
<marcan>
esden: did you *remove* that shunt in revC2? :D
<marcan>
okay I am not responsible for this :D
<marcan>
the LEDs are in the top layer now though, those are fine
<marcan>
wait no, bottom
<marcan>
yup the shunt is gone :D
<marcan>
come on, that would've fit in shoving the SDA/SCL testpoints aside a bit :p
<marcan>
so yeah, I think the user LED lines are antennas now :D
<marcan>
hope that didn't hurt anything else, there's a lot of stuff referenced to 3V3... that shunt should cut impedance across a bunch of paths on that plane quite a bit, due to the 1V2 getting in the way...
<marcan>
anyway, it *probably* doesn't matter *too* much. probably. :D
<esden>
it does not
<esden>
sorry bit annoyed at the moment... so I will step away
<marcan>
you say that, but I'm totally EMI testing the user LED lines on C0 vs C1 now (seems those were already gone in C1?)
<marcan>
*looks again*
<esden>
look we were working on it for months now you wake up?V
<marcan>
I just watched the video now!!!
<marcan>
but also it's already gone in C1 and I wonder
<marcan>
maybe I screwed up when I redid that area and forgot to put the shunt back in?
<esden>
ok I will let you mull over it ...
<marcan>
look none of this is going to change your run
<marcan>
I'm just having fun because I learned something last night
<marcan>
don't take it personally
<marcan>
whitequark: sure
<whitequark>
thanks!
englishm has quit [Ping timeout: 260 seconds]
lukego has quit [Ping timeout: 260 seconds]
englishm has joined #glasgow
lukego has joined #glasgow
_whitelogger has joined #glasgow
sorear has quit [Read error: Connection reset by peer]
_florent_ has quit [Read error: Connection reset by peer]
egg|laptop|egg has joined #glasgow
_florent_ has joined #glasgow
sorear has joined #glasgow
uovo has quit [Ping timeout: 268 seconds]
uovo has joined #glasgow
sorear has quit [Ping timeout: 256 seconds]
egg|laptop|egg has quit [Remote host closed the connection]
sorear has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<eddyb>
boy oh boy, I may yet get the use the Glasgow on a motherboard: just got the DDR4 for the X99-DELUXE, and it doesn't seem to see any GPU. tho before I start poking around, I could at least try to see if it can boot headless
_whitelogger has joined #glasgow
cyrozap has joined #glasgow
Rondom has joined #glasgow
<d1b2>
<theorbtwo> Hm. I do know an EMI test house guy or two, could ask them to take a gander if there is something specific you want them to look at. Might even be persuaded to do a free test for you, or at least cut rate.
<electronic_eel>
my guess is that any flywires that go to your dut will be far far worse for emi than any led traces, internal i2c or similar stuff within the pcb
<electronic_eel>
whitequark posted a clip of using glasgow as fm radio transmitter, with just a flywire on one of the port pins iirc
<whitequark>
yep
<whitequark>
it's powerful enough i can listen to it two rooms across
<whitequark>
on a commercial radio
<jpa->
"highest emission configuration" in emc tests is a bit difficult to define when the device includes user-programmable fpga :)
<jpa->
EMC tests for usb-connected devices are also very difficult in that many laptops are already almost at limits when you connect an USB cable to them
egg|laptop|egg has joined #glasgow
<d1b2>
<HardWall> Got a notification the crowdfunding campaign just launched today. Great! Just put my order in. In the meantime, I miiight populate those Glasgow PCB's I ordered that I never got around to... maybe I'll have a Glasgow to play with even before you start shipping.
femboyslayer has joined #glasgow
femboyslayer has left #glasgow [#glasgow]
fibmod has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<sharebrained> This. And also the point made about the FPGA being a dynamic part of the design, and USB attachment making for a great laptop noise radiator. All of these are born out in my SDR product development experience.
<d1b2>
<sharebrained> It's test equipment, not a consumer product, and lots of wires or ribbon cables and long ground return paths to the attached project and the ability to entirely reconfigure the design are going to throw any EMC test results out the window.
<d1b2>
<sharebrained> That said, exploring EMC impact from various layout changes certainly sounds like a great opportunity to learn interesting things.
egg|laptop|egg has joined #glasgow
balrog has joined #glasgow
uberushaximus has quit [Quit: uberushaximus]
uberushaximus has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg_ has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
ali_as has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 260 seconds]
sorear has quit [Ping timeout: 260 seconds]
sorear has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]
ali_as has quit [Quit: Bye!]
egg|laptop|egg has quit [Read error: Connection reset by peer]