azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
srk has quit [Remote host closed the connection]
srk has joined ##openfpga
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<pie_>
Flea86: what?
<pie_>
inline coupler?
<pie_>
I plugges all the wires in all the holes
<pie_>
*plugged
<pie_>
thanks for elaborating
<pie_>
Flea86: here is the ethtool output https://bpa.st/KZZA , I assumed full duplex means all the cables work but thats just an unfounded guess because Im unfamiliar with the physical layer protocol
<pie_>
not sure if im reading the right wikipedia summary but IIUC 100baseT used two pairs in each direction, so if something was faulty Id expect it to be half dupley?
<pie_>
duplex
<Flea86>
pie_: To quote google first hit that I found "100 Base-T uses two pairs of wires in at least Category 5 UTP cable (implying one for TX, one for RX), while 100Base-TX requires two pairs in Category 6. 100Base-T4 uses all four wire pairs in older Category 3 cables."
<pie_>
it isnt two pairs for each direction?
<pie_>
that doesnt sound right, but that doesnt mean its wrong
<Flea86>
Nope. only one pair is used for each direction, you only need two pairs for 100 Base-T
<pie_>
that sounds like a waste of bandwidth
<Flea86>
I have a custom PCB that I'm working on that does this, BTW :)
<pie_>
I figured youre not talking out of your bum :P
<Flea86>
haha
<pie_>
but re: if you have 4 pairs why would you use only two?
<Flea86>
four pairs are used for 100 Base-T4 at least to my own understanding
<Flea86>
but that's an old spec I think
<pie_>
It wasnt clear to me which spec is commonly used
<Flea86>
so four pairs are now used for 1000 Base-T
<Flea86>
or 1000 base-TX
<Flea86>
Hope that makes things a bit clearer
<Flea86>
anyway, you say you've got 100Mbits link working right?
<Flea86>
I was thinking, assuming you don't have a scope, you may be able to eliminate or deduce whether it is a pair order miswire or isolated/broken pair wire
<pie_>
I remember reading some ethernet protocol stuff from tanenbaum but I dont actually remember the content
<pie_>
currently trying to google the difference between T and TX xp
<Flea86>
Did you read the link I posted you?
<Flea86>
Have a look at it :)
<pie_>
whoops
<pie_>
Well, its not a 2 minute read, so probably later, I'm in class right now.
<pie_>
I didn't see a subsection explaining the naming scheme.
<pie_>
yes <Flea86> anyway, you say you've got 100Mbits link working right?
<pie_>
well, I have some access to a scope planned today, not sure about specs but i can do some basic measurements
<pie_>
the miswire probability is nonzero
<Flea86>
well, the different BASE terminologies are listed starting from 10% down the top of page
<pie_>
it would be nice if the software / drivers would be more forthcoming about why negotiation fails / if it throws on pairs
<pie_>
but ah well, :'(
<pie_>
i really wish internal diagnostics were better for things in general
<Flea86>
pie_: Not sure if wireshark can provide that, I've yet to install that on this machine
<Flea86>
it's been a few years since I last messed with this stuff, so it is of interest to me as well
<pie_>
why would it? this is a hardware issue?
<pie_>
if ethtool doesnt see it i expect that it doesnt exist
<pie_>
i mean, i dont know how much "coverage" ethtool has, but Id naively expect it to expose it if if can
<pie_>
though the help on it is pretty long so maybe you _can_ get something like that, IDK
<pie_>
I really just expect hardware to not expose this info though :/
<Flea86>
I've not used ethtool myself, but perhaps I should :)
<pie_>
im not sure if its the same info exposed by something like ifconfig / ip link but its what i use to check if layer 1 is functioning when debugging network
<Flea86>
I would've thought the PHY provides some means to tell MAC and higher up what mode it is currently in, but many folks won't care how it works, as long as it does work ;p
<pie_>
I think the question is what kind of information the drivers can / do expose
<pie_>
which i guess becomes chipset dependent
<Flea86>
Agreed
<pie_>
well that much is visible?<Flea86> I would've thought the PHY provides some means to tell MAC and higher up what mode it is currently in, but many folks won't care how it works, as long as it does work ;p
<pie_>
thats how i know the speed is 100Mbs
<Flea86>
yes, meaning autonegotiation failed for some reason
<pie_>
I mean ethtool just says Speed: ..., not 100BASE-whatever
<pie_>
im assuming its deducible from speed and duplex
<pie_>
also yes oops i see it, it just doesnt explicitly state T vs TX<Flea86> well, the different BASE terminologies are listed starting from 10% down the top of page
<Flea86>
sounds like ethtool should tell you what mode the PHY is currently in, cool
<pie_>
hmm
<pie_>
im not sure we can tell if its 100-T or 100-TX
<Flea86>
Now I want to know how 100-T half duplex works ;>
<Flea86>
is that one pair only for tx/rx?
<Flea86>
I'd assume so
<pie_>
it seems like the X is "just" an encoding, but i assume thats used because of how it uses the pairs
<pie_>
a lot of this is nto clear to me yet and im rushing so that doesnt help
<Flea86>
yeah, things start getting a bit more involved beyond 10 Base-T
<pie_>
big sigh do i really have to look at the ethtool and kernel source to try to figure out what they mean by 100baset
<Flea86>
ah, 100 Base-T1 is the mode I was looking for there
<Flea86>
That is half-duplex
<Flea86>
wait no, that is also full duplex
<pie_>
:P see its not so simple xd
<Flea86>
lol yeah
<pie_>
huh didnt realize ethtool is part of the kernel source tree
<Flea86>
I'll let others chime in here ;)
<pie_>
https://en.wikipedia.org/wiki/Ethtool "ethtool is the primary means in Linux kernel-based operating systems (primarily Linux and Android) for displaying and modifying the parameters of network interface controllers (NICs) and their associated device driver software from application programs running in userspace. " "ethtool consists of two components, an API within the Linux kernel through which NICs can send and receive parameters through their
<pie_>
device driver software, and a userspace API based on the Linux SIOCETHTOOL ioctl mechanism through which application programs can communicate with the kernel to send and receive NIC and NIC driver parameters"
<pie_>
so it looks like this is the right tool in any case
* Flea86
nods
<pie_>
well thats some more for the yak stack...
<pie_>
Flea86: ok so to reiterate, in terms of what i can actually currently do in practice, what do you suggest?
<pie_>
i might see...eventually if i can figure out if my drivers or these drivers in general expose something
<Flea86>
pie_: I would start by seeing which signal pair(s) are out of order or broken
<Flea86>
Turn your host PC off, and measure the DC resistance of each individual pair with the inline cable disconnected. If those meter out to roughly the same low resistance (whatever that is), check the pair order
specing has quit [Ping timeout: 260 seconds]
<Flea86>
Oh, before you check pair order, make sure your inter-pair resistance is 150 Ohms between signal pairs
<pie_>
Flea86: i have a continuity checking mode on my multimeter so i can do the beepy thing
<pie_>
though 150 ohms specifically is more precie i suppose :p
<pie_>
precise
specing has joined ##openfpga
<pie_>
ok, thanks, ill do that in about two hours hopefully
<pie_>
ok <Flea86> You don't have to, I can see it's approximate size on the PCB cutout area for it
<Flea86>
yeah, that one's as dumb as a box of rocks
<Flea86>
confirmed :P
<Flea86>
Cool thing about that particular variant, is that it is designed to sit recessed into the PCB to keep a low profile
<pie_>
yeah, the whole problem was that the component of the frame that is supposed to hold the cable connected is broken off / lost, so cant usefully use it
<pie_>
hence hackjob
<pie_>
would have been fine otherwise
<pie_>
heh can just barely *not* make out the pn on the video
<pie_>
ok it might not actually be through hole but whatever
<pie_>
its the big one
<pie_>
meaning? <Flea86> I have noticed, some interfaces isolate the 75 Ohm termination resistor between pairs.. so keep that in mind
<Flea86>
pie_: I see two different versions for GbE interfacing
<pie_>
actually i think this explains some stuff
<pie_>
remember this? :P
<pie_>
<pie_> I just horribly desoldered a rj45 socket from a mobo and a basic dumb continuits tester says there is a connection between 3x 2pairs of pins
<pie_>
<pie_> did i leave a crapton of solder bridges, if i didnt totally burn the whole thing to begin with, or is there something that would fool the tester
<pie_>
<pie_> ok it looks like its the differential pairs
<pie_>
also later i did verify continuity between all 4 pairs after i figured out that the "continuous" pairs correspond to the twistredpairs
<Flea86>
If there are schematics available for your laptop, those will help
<pie_>
bah
<pie_>
i cannot into reading
<pie_>
of *couse* i read this as _intra_-pair <Flea86> Oh, before you check pair order, make sure your inter-pair resistance is 150 Ohms between signal pairs
<pie_>
everything makes sense now
<Flea86>
:D
<pie_>
*course
<Flea86>
Excellent
<pie_>
so now i get what you meant by isolated termination resistors
<pie_>
ok so i should check end-to-end continuity of the pairs, that they are hooked up in the right order, and that if the resitors are not isolated, that the terminations are correctly 2*75 ohms
<Flea86>
Right
<Flea86>
and by 'right order' I mean, any order that satisfies straight through or crossover connection
<Flea86>
*either order
<Flea86>
not any sorry
<pie_>
right, but im too dumb to quickly figure that out so im going to try to check that i actually just got the per-every-internet-diagram-ever color order right
<pie_>
i really hope i dont have to resolder anything
<pie_>
otoh at least then the issue would be obvious
<pie_>
if thats not the problem things are harder .p
<Flea86>
pie_: If I were a desperate fellow, I would simply splice up the cable and leave my mobo handywork alone to correct
<Flea86>
My soldering skillz are competent, thankfully. Only advice I can give you is for you to keep practicing your solder skillz until you are confident enough to tackle rework
<FireFly>
..still regret sending a N900 in for service under warranty from a broken-off USB plug only to get a different model phone back...
<Flea86>
FireFly: Bummer :( Did you eventually get your phone back?
<FireFly>
nope, but this was a long time ago, it's fine :p
<Flea86>
FireFly: I repaired my broken USB port, but too late to prevent me from buying a new phone..
<pie_>
not the worst idea actually <Flea86> pie_: If I were a desperate fellow, I would simply splice up the cable and leave my mobo handywork alone to correct
<FireFly>
was idly reminded though since it was over a lack of own soldering skills that I opted to send it in, in retrospect should've just kept it
<pie_>
its more that i dont want to disassemble and reassemble that assembly because its a bit of a pain and fiddly to deal with the wires
<Flea86>
FireFly: How are your soldering skills nowadays?
<FireFly>
I did find it amusing to get "upgraded" from a Maemo N900 to a Symbian^3 E7 lol
<FireFly>
Flea86: well, they're up from 0 to having soldered things a single-digit number of times, which is at least an improvement :p
<Flea86>
FireFly: lol ok
<FireFly>
but at least these days in such a situation I'd probably either give it a shot myself or at least have people to ask for advice/help with soldering
<Flea86>
pie_: You'll need to figure out some way to relieve the stress on those soldered wires if you want to make it permanent
<Flea86>
pie_: I would just dump hot melt glue over the whole lot lol
<pie_>
oh thats an idea i guess
<pie_>
what i did currently is add some bends to that section to be a bit springy
<pie_>
and then a bunch of ducttape to hold the rest of the wire doen
<pie_>
down
<pie_>
it would be good but the cables still protrude a bit from the jack area so it might still experience some direct stress
<pie_>
the tape is also kinda why i dont want to disassembel it lol
<Flea86>
FireFly: There's always the risk that you'll break something or make things worse, but no risk no reward so
<Flea86>
pie_: I like your solution better, it will be easier to disassemble later on if need be
<Flea86>
FireFly: Also, I totally missed that smartphone era.. back when I was working in the engineering field, I lusted over the Nokia 9000 communicator ;P
<FireFly>
hehe
<FireFly>
I've heard stories about that one as well
<Flea86>
Had to settle for a 6210 instead. WAP internet was... cringe
<Flea86>
Still have that phone
<Flea86>
in the junkbox :P
<pie_>
Flea86: ok all the pairs seem to have continuity (i measured from the rj45 socket end) and 150 between each pair
<pie_>
well, i only measured one wire from each pair, not every individual wire, but given the continuity "it should be fine"
<pie_>
so that only leaves the pin order
<pie_>
Flea86: btw with one cable i was getting 100 even on the usb adapter and with the other gigabit, so yeah apparently cable may actually matter
<pie_>
idk if its possible that the 1 meter of wire im using to break out the jack could be degrading things
<pie_>
Flea86: yeah it *looks* to me like my pinout is fine
<pie_>
none of the pairs are shorted together per the resistance check
<Flea86>
pie_: Ok. What cable are you using to patch the link?
<Flea86>
Going by the video, looks suitable
<Flea86>
Also one metre should allow for _some_ margin to play with, so hacks may still work :)
<Flea86>
Not sure about that coupler thing you're using for optimal performance, never used one so that's an unknown
<Flea86>
Though that may be Ok too given overall cable run
specing_ has joined ##openfpga
specing has quit [Killed (NickServ (GHOST command used by specing_))]
<Flea86>
ignore that last comment, seems those are designed exactly for that purpose :)
<Flea86>
I am distracted rn, so is chatting to me at the moment :)
<Flea86>
*SO
specing_ is now known as specing
<Flea86>
pie_: I find USB and HDMI cable quality to matter more
<Flea86>
pie_: Got a scope? perhaps bring your laptop closer to your other machine and get rid of the inline coupler and patch cable for your point to point test
<Flea86>
oor you can try a simple loopback test instead