<lain>
rqou: so today's "crawl around the roof with a 5.8 GHz dish" test was to see if I could pick up the omni-directional antenna mounted atop the datacenter's tower
<lain>
if so, I can definitely pick up a point to point link, once they mount my other dish on their end
<rqou>
in other news, it turns out you can convert qemu-user-static containers into being unprivileged
<rqou>
unfortunately, for whatever reason, there is a bug somewhere that makes it so that attempts by sshd to allocate a tty get detected as a stack smashing attack
<rqou>
so now i have a container that is "functional" but you can't log in
<rqou>
you can use ssh foo@bar "bash"
<rqou>
but a no-tty login apparently can't magically become converted to a has-tty login
<rqou>
this part of unix sucks
<rqou>
hmm, installing the host architecture sshd works
<rqou>
this is a nice and unholy mixup of architectures
m_w has quit [Quit: Leaving]
promach has joined ##openfpga
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
<cyrozap>
rqou: What's TAPI? Searching just gives me results for some Windows Telephony API.
<rqou>
apple invented a new format for informing the linker about shared library symbols
<rqou>
instead of the old way of feeding the actual shared library to the linker, they created a text file that only defines what the symbols are without containing any code
<rqou>
if you've used the windows/msvc toolchain, it's like using .def files to specify imports to consumers of a module rather than to specify exports from a module
scrts has quit [Ping timeout: 240 seconds]
<rqou>
windows already ships stubs rather than full shared libraries as .lib files
<rqou>
so you have a continuum of sizes from apple .tbd to windows .lib to linux .so
<cyrozap>
I see
<cyrozap>
Thanks for the explanation!
scrts has joined ##openfpga
<lain>
hmm
<lain>
so the omni antenna I'm able to see is a 13dBi thingus
<lain>
and I'll be replacing it with a 25dBi directional dish
<lain>
so I should gain ~12dB in the process, plus it'll use airmax which will go between channels and do other funky things to find the lowest noise floor in the available spectrum
<lain>
from my site survey it looks like I should be able to establish a good link!
<lain>
if it's too marginal, there's newer radios that have higher gain :P
digshadow has quit [Quit: Leaving.]
<cyrozap>
I just discovered clang-analyzer and I love it :)
<cyrozap>
Currently using scan-build to compile OpenOCD in the hopes it'll find some issues in kitprog.c that I missed.
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<cr1901_modern>
lain: Do you have any good references on how to match Z_0 of a connector and the impedance of a PCB trace?
<lain>
cr1901_modern: if it's a connector with a specified impedance, just make the pcb trace the same impedance. or what do you mean?
<lain>
(Z0 is impedance)
<cr1901_modern>
lain: The material change from the PCB to the connector doesn't add any meaningful impedance mismatch?
<lain>
ah ok, so you're concerned about the way the trace launches into the connector
<lain>
hm
<cr1901_modern>
h/o phone
<cr1901_modern>
if you have two cables you need to connect that are inherently different Z_0, it is possible to match their impedances by placing a piece of cable in parallel with the two cables.
<lain>
I've read various pdfs but I can't think of any off the top of my head. if it's an RF connector you can find plenty of reference material online. notably, if it involves thru-hole pins, you'll generally want to launch into it from the bottom layer, otherwise the rest of the thru-hole is a stub... and you may need to play with the anti-pad (clearance between thru-holes and any inner layers) to get the
<lain>
impedance correct throughout the connector
<lain>
oh
<lain>
you want to connect two different impedance things?
<lain>
you can use a balun to do an impedance transformation if it's RF
<lain>
that's a bit out of my expertise though
<cr1901_modern>
I was wondering if there was a similar thing you do w/ PCB to connector if it's not possible/practical to match them
<lain>
typically you just match them, or you calculate that you can suffer the minor losses of not matching them
<cr1901_modern>
I see... *makes a note of anti pad*
<lain>
impedance is kinda unintuitive at least to me
<lain>
but for example, if you have a 50 ohm line and you want to branch it into two, each of those two could be 100 ohm with prettymuch no issues
<lain>
because two 100 ohm lines in parallel makes one 50 ohm line
<lain>
(assuming they're properly terminated to 100 ohms at the end)
<lain>
but usually it's not practical to have such a range of impedances on the same board
<lain>
so branching is discouraged, or you just accept that your SI is going to suffer massively
<cr1901_modern>
SI?
<lain>
signal integrity
<lain>
this is why for example ddr3 moved away from the tree branching structure of ddr2
<lain>
in ddr2, iirc, the signals branched out in a tree: they split to each dimm, and then on each dimm they split to each chip
<lain>
the control signals, that is
<lain>
which puts a limit on how fast you can run them before the SI issues catch up with you
<lain>
in ddr3, it's a fly-by topology
<lain>
meaning the signals run "under" each chip, and they make an effort to minimize the stub that each chip presents, then it's terminated at the end
<lain>
with minimal stubs at each chip, they should see minimal reflections from each chip, so not much SI impact - then the termination at the end ensures no reflections there
<cr1901_modern>
Well... something that bugs me... in uni, most "calculate the characteristic impedance" of a cable examples assume that the cable is the only thing that exists in your world. In PCBs that's just not true. How do I know that fields from nearby traces don't effect Z_0 via second order effects?
<cr1901_modern>
It just seems to get really ugly very quickly
<lain>
they do
<lain>
but there's some simple rules of thumb you can use
<cr1901_modern>
Oh?
<cr1901_modern>
(9:41:53 PM) lain: but usually it's not practical to have such a range of impedances on the same board <-- this is because it's not practical to terminate them?
<lain>
as long as they're far enough apart to not experience crosstalk, impedance shouldn't particularly change. also, on a pcb, coupling side-by-side (so, traces next to each other on the same layer) is pretty minimal -- it's mostly happening by overlap in the return current on the adjacent plane (assuming there's an adjacent plane. if there isn't, then the E-fields are going to interact all over the place as
<lain>
they find their return paths, and you've got a mess on your hands)
<lain>
so crosstalk is mostly overlap in return current (which spreads a bit following some power law I can't recall at the moment) in the reference plane, but there's also some interaction between the stray E-field lines that come off the top and curve back down to the reference plan, or come out the side of the traces (veeery minimal though)
<lain>
since reducing crosstalk (which is necessary) inherently reduces E-field interaction between traces to negligible amounts, there's no real concern about impedance being impacted by nearby traces
<cr1901_modern>
"come out the side of the trace" <-- is this how 2 layer board traces find their return path?
<lain>
well, if you imagine the E-field between a trace and a reference plane below it, there will be field lines going prettymuch straight down off the bottom, some popping off the side and going down, and then some coming off the top and cuuuurving back down to the plane
<lain>
of course there will also be lines to any other different-potential conductor in the vicinity, but the side area of traces is very small compared to top and bottom, so top and bottom are the main concern -- basically you want to avoid traces being in parallel on adjacent /layers/
<lain>
this is where the routing methodology of alternating between horizontal and vertical paths comes from
<lain>
of course you also want reference planes, but if you MUST put signal layers next to each other, it's best to route them orthogonal to each other, to minimize broadside coupling
<lain>
re: the impracticality of many impedances, it's a geometry thing, not a termination thing - you need too wide a range of dielectric thicknesses or trace widths to get such huge changes in impedance, like, you might need huge 50ohm traces to achieve manufacturable 100ohm traces, or maybe your 50ohm are a reasonable width, but 100ohm is then impossibly thin, etc
<lain>
it *can* be done but the (real, dollar) cost of doing it usually outweighs the benefits. probably the most common impedance-controlled signal that needs to branch off into N other traces is a clock, and clock distribution ICs exist for this reason
<lain>
(also because clocks are *especially* sensitive to SI issues like reflections, which can effectively cause the clock to skew by changing the rise time or shape of the rise/fall, etc etc)
* cr1901_modern
should've taken an RF electronics course...
<lain>
hehe
* lain
has never taken one, but reads lots of books
<cr1901_modern>
no guarantee I would've remembered it all by now of cours
<cr1901_modern>
Is there a good book that I can pira- err, buy that discusses the math/modelling?
<lain>
hm, I'm more of an abstract learner - I focus on the broad concepts and knowing when I need to apply which thing, then I just look up the math as needed
<lain>
^ regarding E-field lines, this is a good illustration
<lain>
they are "lensed" by the different materials having different dielectric constants (permittivity)
<cr1901_modern>
Some lines are brown/perpendicular to the grey lines... magnetic?
<lain>
I believe so yeah
<lain>
as the B-field (magnetic) should always be perpendicular to the E-field, which those are
<cr1901_modern>
The bending of the lines makes sense. I was always pretty bad w/ dielectrics tho
<lain>
just snell's law in action :3
<cr1901_modern>
I mean, I had to derive parameters of one to pass the class of course lol, but it never stuck
<lain>
regarding books
<lain>
if you want high-speed design concepts and the relevant math (admittedly light on math, very practical approach rather than heavy-theory), nothing beats:
<lain>
between those three books and the ultracad articles, I think that's the bulk of my information sources :P
<cr1901_modern>
Does Snell's Law apply to things besides light?
<cr1901_modern>
fair enough
<lain>
EM is light
<lain>
:3
<lain>
hence why the Optics book is so relevant even to electronics
<lain>
when you get into high frequency RF where you have to reconcile the fact that your traces are waveguides and such, you're still dealing with the exact same effects as toggling a pin on an arduino once a second, the only difference is how much of the equation you can ignore as negligible
<cr1901_modern>
Huh... I guess I think of light as well... the stuff you see :P. Not EM about 10 orders of magnitude less
<lain>
yeah
<lain>
it's definitely a weird realization :P
<lain>
but light is just the bands we happen to be tuned to
<lain>
RF is still light as well
<lain>
just light we can't see
<lain>
so we don't call it that :P
<cr1901_modern>
"you're still dealing with the exact same effects as toggling a pin on an arduino once a second" <-- hmmm... that's an interesting way of putting it. Somehow I think it kinda misses the trees for the forest tho :D
<lain>
lol
<cr1901_modern>
I suppose I will take a break from learning for tonight, slowly get myself back up to speed
<lain>
really though, all of these effects are always present, it's just a question of how much you can ignore them. or I guess you could say that's what engineering is - knowing what you can and cannot ignore, to achieve the desired result
<cr1901_modern>
that's what I'm afraid of... everything "just works" masking a horrifying complexity that stops me dead in my tracks
<cr1901_modern>
the end result is I get nothing done, contrast to "getting a product done that sucks b/c I ignored the not-ignorable"
<lain>
meh, just have to remind yourself that complexity is just lots of simple things tied together, then start unraveling it ;)
<lain>
also something about failing is a great way to learn
<cr1901_modern>
also a great dent to my bank acct
<lain>
unfortunate but true :D
<cr1901_modern>
Which is why I dislike doing PCBs btw- long return time before you recognize problems
scrts has quit [Ping timeout: 240 seconds]
<lain>
true, and you don't know what you don't know until you know it, and by then it's too late :D
<cr1901_modern>
And doing it right (which is still not anywhere close to a guarantee of a success)- 4 layers, matched traces, planes- is expensive.
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vD7ck
<openfpga-github>
openfpga/master 0e6650e Andrew Zonenberg: gp4par: Added --nocolors argument for batch integration
<openfpga-github>
openfpga/master 6a518fe Andrew Zonenberg: gp4par: Prefixed invalid-arg error messages with "ERROR:" for easier filtering in automated build environments