Full-Duplex 10Base-T "Micro Transeiver" MAU (connects to AUI 15-pin D-Sub) - Page 1
Forum section: electronics / general

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 08, 2025, 08:35:25 pm
content: I have a piece of test equipment that has an ancient AUI (attachment unit interface) connector (15-pin D-sub). This is used to connect a MAU or "media attachment unit" for providing 10Base-T (normal twisted-pair Ethernet), fiber optic or even "thick net" or "thin net" coax. Basically, it lets people pick their preferred media type, which made sense back in the 90s but is pretty much pointless now. Twisted-pair Ethernet won. Fiber makes sense for really long runs or when you need >= 10Gb/s or thinner / more flexible cables I guess.Anyways, I currently have an Allied Telesis / CentreCOM AT-MX20T MAU / "micro transceiver" attached to the equipment, but I can only get half-duplex operation (which I think is causing a lot of latency for the remote X11 connection to the equipment). Looking at the datasheet and "user manual" (a tiny pamphlet that has no useful information) I see no mention of the MAU's duplex capability. Allied Telesis / CentreCOM also made an AT-210T that looks pretty similar but has slightly different LED annuciators. It also shows no mention of duplex capabilities... I did find some fiber optic MAUs that specifically stated they supported full-duplex operation, but I would like to avoid fiber since I would then need to find cables and a media converter to use it with my home network. So, at least in theory, there were full-duplex 10Base-<whatever> MAUs available.I was hoping someone might know if there ever were any 10Base-T MAUs that support full-duplex operation. And if so, what brand/model to look for.

author: Halcyon
author_rank: Unknown
timestamp: October 08, 2025, 10:50:34 pm
content: I have a few at home, but I'm interstate at the moment, so I'll have to get back to you.Have you tried forcing the switch port itself into full-duplex mode? If the MAU does indeed support full-duplex, perhaps it's not very good at auto-negotiating it?

author: amyk
author_rank: Super Contributor
timestamp: October 09, 2025, 02:05:29 am
content: If 10M is all it supports, as the use of an AUI would suggest, the device predates autonegotiation and will link up at half-duplex via a process called "parallel detection". You can force the other end to 10M-full but may want to check what chip is connected to the AUI to confirm that it's capable of full duplex first.

author: Zoli
author_rank: Frequent Contributor
timestamp: October 09, 2025, 04:37:36 am
content: I have a few(one model); tomorrow I will be back with more info.

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 09, 2025, 04:41:54 am
content: Makes sense that it would default to half-duplex. I have not tried forcing the switch port to full-duplex (didn't even think to do that if I'm being honest). I'll give that a go here in the next day or two (got to get it out of storage, was planning on using it but remembered how slow the X11 connection was and posted here first). I'll also open up the MAU and pull the AUI board to take photos. Hopefully I can get this to go FD and get better latency with the X11 connection.EDIT: Looks like I already took photos of the AUI board. I've also attached some generic photos of the AT-MX20 and AT-210T MAUs from online.

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 09, 2025, 11:07:28 pm
content: I got a little time to look up datasheets for the ICs on the AUI board. Looks like a Crystal CS83C92C-CL is used for the coax/"thin net" port and a National DP83932CVF-25 SONIC "second generation Ethernet controller" is connected to the AUI port and Crystal IC.Looking at the datasheet for the DP83932, it specifically states it can do "full-duplex loop-back diagnostics" but it doesn't ever mention if the chip can actually use full-duplex over the AUI port... The word duplex is literally never mentioned again in the datasheet. I guess I also need to check the MAU too. I'll try and get some photos of it up soon.

author: Zoli
author_rank: Frequent Contributor
timestamp: October 10, 2025, 01:02:20 am
content: Pix:

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 10, 2025, 04:57:56 am
content: Did some reading on Wikipedia and the "Fast Ethernet" page had this little tidbit that agrees with what amyk has said:QuoteThe part in bold (emphasis mine) suggests that some 10base-T NICs could autonegotiate, but as far as I understand, no 10base-T NICs could do that. But more importantly, those that cannot autonegotiate default to half-duplex... Which means every 10base-T NIC is always in half-duplex mode. The question I have though, does changing the duplex at the switch even work? How did anyone ever get 10base-T to go full-duplex in the first place? I'm confused on how this ever worked in practice since it seems everything just defaulted to half-duplex...

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 10, 2025, 07:42:10 am
content: Hmmm. Seems only the fiber optic 10Mb networks actually ever used full-duplex? I can find no relevant information on real twisted-pair hardware (pre "Fast Ethernet") ever using full-duplex for 10base-T. Seems like I may actually need to go fiber to get FD operation and I will need the media converter to have a 10/100TX port--otherwise I am back in half-duplex town with 10base-T Ethernet being (for all intents an purposes from my research) half-duplex only.I'll still try forcing the switch port to FD, but I don't think this is actually how you get FD with 10base-T. The MAU probably needs to have a jumper or dip switch to manually set FD. Forcing the other side of the link is unlikely to actually make the 10base-T NIC enable full-duplex operation on its own.I think the use of FD 10Mb Ethernet over twisted-pair actually came with "Fast Ethernet". I have no proof of this, but there is absolutely no explicit documentation stating otherwise in any of the pre "Fast Ethernet" era manuals or datasheets for the MAUs I've looked at. FD Ethernet appears to be exclusive to fiber optic networks of the time; which is weird, since twisted-pair finally made this practical for copper media.Feel free to correct me on the above conclusions... I only learned about / started using Ethernet networks when "Fast Ethernet" was already a thing. CAT5 was basically all we ever used when I was growing up, so I have no real working knowledge of 10base-T or 10base-2 HW other than having seen old parts that were pulled from service.

author: Someone
author_rank: Super Contributor
timestamp: October 10, 2025, 08:04:42 am
content: Quote from: RaymondMack on October 10, 2025, 07:42:10 amhttps://en.wikipedia.org/wiki/Ethernet_over_twisted_pairTalks about physical full duplex being the standard, but you'd probably need to read IEEE 802.3i

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 10, 2025, 08:50:55 am
content: I've now finally found two *actual* pieces of commercially sold HW that explicitly state they can do FD over 10base-T, but these MAUs were made circa 2007/2008 (according to their datasheets) for legacy upgrades/inter-op. So I do not think *any* real products ever shipped that supported FD operation over twisted-pair Ethernet that *predates* the advent of "Fast Ethernet" (which introduced autonegotiation). FD 10Mb Ethernet seems to only be used by fiber optic networks of the time. This essentially means all twisted-pair MAUs that were designed and sold for those systems are HD only.I'll try buying one of these newer MAUs (simpler than going down the fiber optic MAU to media converter route) and see if I can improve the remote X11 connection to my VSA.UPDATE: I found an older datasheet from 2002 that shows FD operation for a 10base-T MAU. So yeah, I don't think there ever were commerical products that did FD 10Mb over twisted-pair before 100Mb Fast Ethernet. It might be in the spec., but no commercial twisted-pair MAUs were made that supported FD until much later.

author: Phaseseeker
author_rank: Regular Contributor
timestamp: October 10, 2025, 09:21:42 am
content: For what's worth, I've tried using X11 over 10Base-T on an HP 1600C and I don't recall it being laggy... Though I was using it with an Ethernet cable connecting directly the analyzer to my laptop. I can't find the datasheet for the National SS9130AP PHY, so no idea if it's full duplex, but it's definitely old enough to predate Fast Ethernet...

author: RaymondMack
author_rank: Regular Contributor
timestamp: October 10, 2025, 10:42:27 am
content: @Phaseseeker, the VSA is just slow to be honest. But half-duplex signaling is terrible for latency with Ethernet. I'm just trying to make it less slow since I basically do everything over the network with it (transfer files over FTP, use the virtual instrument panel over X11, ect.) I'm not looking for a miracle, just any improvement really.I think most AUI ports can do full-duplex. So that's not really the issue. The issue is that period accurate twisted-pair HW (like my current MAU) seems to only have used half-duplex signaling. Fiber optic MAUs from DIGI explicitly state they do full-duplex Ethernet and in their media converter datasheet they go out of their way to call half-duplex operation "standard Ethernet". I find this odd since twisted-pair made full-duplex over copper media cheap and simple. Its seemingly poor adoption until Fast Ethernet became a thing is even stranger. FD signaling offered a free upgrade in network throughput / efficiency. But maybe the copper based media hubs/repeaters/switches of the day were stuck on half-duplex operation? All the later MAUs that support FD have to be manually configured with dip switches which reinforces how entrenched half-duplex operation was for 10base-T and why I don't think forcing the other side of the link to FD with an older MAU will actually work.

author: amyk
author_rank: Super Contributor
timestamp: October 11, 2025, 02:13:23 am
content: Quote from: RaymondMack on October 10, 2025, 07:42:10 amKeep in mind that early Ethernet was a shared medium. Every station could hear what it and every other station was sending, and collisions were detected accordingly. Forcing a port to full duplex just causes it to ignore the collision detection function.If the transmit and receive paths of the MAU are separate (which should be the case for BASE-T), then it can naturally do full duplex, although an older MAC may not be capable of full duplex operation.

author: helius
author_rank: Super Contributor
timestamp: October 11, 2025, 03:12:56 am
content: The AUI interface is only capable of half-duplex by its nature, because it needs to support shared-media like 10base2 and 10base5, which can only transmit when the cable is idle. For a network port to be full-duplex, it must be able to transmit when other stations are also transmitting, and AUI does not support that mode of operation.There may be some AUI ports where the MAC is prepared to ignore the idle state of the cable (which would be incompatible with an actual shared media), but then there is separate issue of how two full-duplex-capable ports recognize each other. This was later standardized as N-Way Negotiation, but before that each port would have to be manually configured for full duplex.

author: Haenk
author_rank: Super Contributor
timestamp: October 11, 2025, 09:23:35 am
content: Quote from: RaymondMack on October 10, 2025, 04:57:56 amAFAIR you had to configure this in the switch (back in the days when you had to use a selfmade serial cable and a terminal to configure these), but this did not work for all machines. Also, some cheaper (and maybe older) AUI adapters could not be forced into full duplex, the more expensive ones mostly supported full duplex. Funny enough, I don't remember anyone ever complaining about too slow network connectivity or transfer speed...

author: helius
author_rank: Super Contributor
timestamp: October 11, 2025, 06:48:39 pm
content: Quote from: amyk on October 11, 2025, 02:13:23 amThis isn't completely accurate, as there is also an idle timer. The way a MAC knows it can begin transmitting a frame is by counting microseconds since the last frame was received. The collision signal is only available after the local station has started to transmit, so it can't be used to detect when the cable is idle. Transmission never starts when a frame is currently being received.This all goes back to ALOHANET and the Experimental 3 Megabit Ethernet at Xerox PARC in 1970.