"Underclocking" Ethernet transceivers (using them below standard speeds) - Page 1
Forum section: electronics / projects

author: KhronX
author_rank: Frequent Contributor
timestamp: December 23, 2016, 12:22:37 pm
content: Upon having some light shed on new information in aprevious thread, i've now turned my sights towards simple Ethernet transceivers.The idea is, in an ideal case, to transmit 1-2 streams of data (at 12.288Mbps each) down some CAT5 cable, and take advantage of the galvanic isolation inherent in standard implementations of Ethernet.Now, since this project i have in mind is basically a media-conversion of ADAT Lightpipe signal streams, for mostly personal use (within the confines of a recording studio) i would like to keep both complexity and costs down to a minimum.Enter the SMSC / Microchip LAN8720A transceivers:http://www.mouser.com/ds/2/268/00002165B-977427.pdfUnder 1eu/pc @ 10pcs at Mouser.Really convenient detail - the RMII interface has two input and output lines, respectively. That's perfect for my purposes, since it would allow me the simplest possible method of relaying one or two ADAT streams, with no other encoding / decoding headaches.The big question is, at least until i order a few chips and whip up some test-boards, whether the 100Mbps mode might work with an input / reference clock lower than the standard 25MHz. And/or whether the PLL would work, or scale linearly with a non-standard input clock (either 12.288MHz or 6.144MHz, i'll still have to figure out the math on that).

author: bktemp
author_rank: Super Contributor
timestamp: December 23, 2016, 12:28:46 pm
content: Micah tried that a couple of days ago:It looks like the ethernet transceiver on her TI board works down to about 6MHz (the results are in the last couple of minutes of that long video).She also tried ENC28J60, but wasn't successful.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 23, 2016, 01:06:04 pm
content: Hey, cheers! Thanks for thatI don't suppose you happen to know what was the standard-speed clock for that transceiver, that got reduced to 6MHz, do you?Was it the stock 25MHz crystal that was "replaced"?Talk of Manchester encoding leads me to believe it was the 10Mbps mode that was underclocked. If the stock was 25MHz, a 4:1 reduction is quite impressive indeed.So basically i'm at the mercy of the internal PLL, it would seemEDIT: Suspicions confirmed re: clock, around 4:20 in or so. Waiting to see mention of 10Mbps or 100Mbps modes...

author: cyr
author_rank: Frequent Contributor
timestamp: December 23, 2016, 01:52:38 pm
content: You may run into issues other than bitrate if you try to use an ethernet PHY this way (streaming data rather than packets), e.g. the internal encode/decode logic will expect packet "edges" and gaps to synchronize.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 23, 2016, 02:00:19 pm
content: That did cross my mind, although, on the other hand...http://ww1.microchip.com/downloads/en/AppNotes/01120a.pdfFrom the diagram at page 10, i would understand that these chips are (only) the PHY stage; all the data they encode and spit out is assembled and formatted way before that.... But i could be wrongEither way, the reference clock would / will be coming from the same source as the data i need to transmit, for what it's worth.

author: AndyC_772
author_rank: Super Contributor
timestamp: December 23, 2016, 03:02:49 pm
content: A typical Ethernet PHY is more than a simple physical layer device.The (R)MII interface carries raw data bits to and from the CPU. The Ethernet controller in the CPU breaks up complete bytes and reassembles them, but it doesn't do the scrambling that's part of the Ethernet spec to reduce baseline wander.Also, the PHY contains a small FIFO to accommodate any rate mismatch between the two link partners. For example, even though RMII uses a single clock between PHY and CPU, the PHY must receive data at whatever rate the far end transmits. It buffers up the first few bytes of each packet, then begins sending them on to the CPU at the speed of the local clock. If the local clock is slower than the incoming data, then the FIFO tends to fill throughout the packet, and will empty once the packet on the wire has ended. If the local clock is faster, then the FIFO will tend to empty, which is OK provided it doesn't underrun before the packet has ended.All this is generally transparent from the designer's point of view. Hook up the (R)MII interface and off you go.If I were dead set on the idea of using an Ethernet PHY to transfer data at a slower rate, I'd probably use a buffer of some kind at each end of the link, so the "Ethernet" interface could run at its conventional speed, with idle periods in between packets.Of course, you don't need an Ethernet PHY to take advantage of an isolation transformer designed for Ethernet signals. If your data is, or can be, converted to a format which has no low frequency content, it's possible it may pass through a suitable transformer anyway.

author: nctnico
author_rank: Super Contributor
timestamp: December 23, 2016, 03:19:01 pm
content: Quote from: AndyC_772 on December 23, 2016, 03:02:49 pmIndeed and this is where an ethernet switch chip with an (R)MII (whatever) port comes in handy. In slave mode you can clock it as slow as you like and the chip will put the packets onto the ethernet at normal speed. I've used to trick to bit-bang an RMII interface on a microcontroller.

author: slicendice
author_rank: Frequent Contributor
timestamp: December 23, 2016, 03:31:14 pm
content: Interesting project going on here!I don't see any problems here with the protocols. The clock will come from the Audio source and will be synced in the ADAT decoder in relationship to the the internal clock of the receiver and then be sent to the DAC or other destination as is. Whatever the link speed is and it's high enough to handle 12+Mbps for each stream/channel, all should work just fine. The ADAT data will be contained within the data layer of the Ethernet frame. The data after decoding will look exactly the same at the receiver as the data was before encoded to a frame in the sender.What I don't understand is, why you have to drop speed?

author: KhronX
author_rank: Frequent Contributor
timestamp: December 23, 2016, 04:23:50 pm
content: Primarily, due to clocking concerns on the receiving end. That, and the attempt / hope to keep things as simple as possible.Sure, at the transmitting end, there should be no problem with the Ethernet side being faster than the incoming data - although, i assume, SOME sort of synchronisation might not hurt; the data incoming at 12.288MHz versus the standard 25MHz.On the other hand, on the receiving end, things get interesting. With the standard 25MHz clock, the PHY would be outputting the data at that rate, which is totally not what the ADAT decoder chip is expecting. Even if i were to clock the ADAT decoder externally (ie. not recover the clock from the ADAT stream), i don't think i've seen any mention of any FIFO (or other) data buffer in the datasheet:http://www.wavefrontsemi.com/DataSheetsFolder/WavefrontAL1402.pdfSo the idea behind the speed dropping is trying to keep things as "synchronous" as feasibly possible.I hope this makes (some) sense

author: nctnico
author_rank: Super Contributor
timestamp: December 23, 2016, 07:37:24 pm
content: You'll need to do resampling at the receiving end to match the datastream to the DAC's clock. It is a classic problem with VOIP (voice over IP) where you are also sending data between two devices with a non related clock.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 01:03:44 am
content: From the further digging i've done, something like a long-ish FIFO-like buffer should suffice, but that would still leave the input vs. output clocking pretty much "in the air"

author: nctnico
author_rank: Super Contributor
timestamp: December 24, 2016, 01:05:39 am
content: If the clocks are free running on both ends the FIFO will overflow or underflow at some point.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 01:09:55 am
content: The "output" clock [at the receiving end] should be fixed (12.288MHz), but the input [from the Ethernet receiver] would be relatively free-running.As in, the input, at the transmitting end, would also be fixed (same 12.288MHz), and then that data would be shot down the Ethernet link at 100Mbps.That being said, i'm still kinda wondering how the input data would "get along" with the 25MHz the Ethernet transceiver would expect at its input.See, this is precisely why i'd love it if it were possible to "underclock" the Ethernet transceivers

author: nctnico
author_rank: Super Contributor
timestamp: December 24, 2016, 01:18:43 am
content: You are missing the point: where do the 12.288MHz clocks come from? If they come from different sources then they won't be exactly the same. The ethernet clock rate doesn't matter. You are pumping data into the link at the rate of the transmitter which will also be the effective data output rate. This is something you have to wrap your head around first because it is somewhat counter intuitive.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 01:24:47 am
content: The purpose of this whole project is basically a media conversion.I'd want to transmit one or two ADAT Lightpipe streams (12.288Mbps each, with an embedded clock) to a range of about 10-15m, in as simple and as cheap a way as possible.CAT5 cabling was the first high-enough-speed and common-enough media that came to mind, and the inherent galvanic isolation of Ethernet cabling would help in avoiding potential ground-loops.I... guess you do have a bit of a point regarding the Ethernet speed not being an issue, and you're right, it isn't terribly intuitive, at the transmitting end.** Edit ** I figured out my exact worry about the data rate mismatch. Since the input data is slower than (and not synchronised with) the 25-50MHz that the Ethernet chip takes / expects its data at, the sampled data would virtually "stretch" most of the pulses (ie. for a 0101 string, there would be 2-3 samplings during each bit). How could that be then reconstructed at the receiving end, in order for it to resemble what is/was at the input of the system?But that still leaves the issue of the receiving end. It's a bit of a "circular argument" type thing - the clock is embedded and can be recovered (by the ADAT-to-I2S decoder chip), but that would need some way of converting the 100Mbps received Ethernet data back to the 12.288Mbps that the decoder can take.It's probably naive thinking, but with a moderately-sized FIFO-like buffer, minor clock differences should be possible to get "absorbed", as it wereKinda like the dampening action of a shock-absorber...** Edit no.2** Whoop, had another brainfart... I mean brainwaveIn order to (try to) synchronize the whole system with the input data, I actually wouldn't need to slow down the 100Mbps all the way to 12.288Mbps or 24.576Mbps. Wouldn't / shouldn't a double / quad rate suffice, to then enable, say, 2-4 "Ethernet input bits" for each ADAT bit?

author: nctnico
author_rank: Super Contributor
timestamp: December 24, 2016, 01:44:07 am
content: Nope. One clock will always be faster than the other. Why don't you use 10m fiber optic cables since the link is already optical?

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 01:51:02 am
content: Somewhat expensive, and fragile

author: slicendice
author_rank: Frequent Contributor
timestamp: December 24, 2016, 07:48:49 am
content: The ADAT protocol does all the syncronization for you. It does not matter what the actual link speed is. 10Mbit or 10Gbit, it makes no difference.Like TCP/IP data over LAN, you send the data to the TCP/IP stack for further processing in your application, but with ADAT you send the data to the chip that decodes the data and then sends it forward to the DAC, or some storage controller. Note that ADAT and TCP/IP are not compatible. The frames sent have same structure though, so it should be possible to use normal HUBS and network Switches. At least for this particular project, if both the sender and receiver are built from scratch.I think underclocking the network is just complicating things.While reading through a lot of info regarding ADAT protocol, I found that each packet sent has it's timestamp and a constant clock. And a lot of other values that are calculated based on the clock, to ensure that encoding and decoding is syncronized.If data gets out of sync or there is a link problem the receiving end will just ignore packets coming in late and thus "mute" the output for that particular packet.The whole point in this setup is that the link speed is high enough to fit the data being sent. If the link speed is too low it will cutoff some of the audio transmitted.About optical cables, there's no point in using optical cables just for a stereo signal. If 64-channels are required then optical is a must. While experimenting and developing this project a link speed of 25-100Mbit over CAT5 cable is enough. And the best part, it's relatively cheap and most stuff could be found in an electronics junk bin. :-)

author: Someone
author_rank: Super Contributor
timestamp: December 24, 2016, 10:01:47 am
content: Quote from: KhronX on December 24, 2016, 01:24:47 amThe cheapest way to do it is with the optical cables, they aren't expensive or as fragile as people worry them to be. Products that do what you imagine exist:http://appsys.ch/en/shop/product/9-adx-32bhttp://vintageking.com/hear-technologies-extreme-extender-adat-inBut its still cheaper to use lightpipe as is unless you have some problems running cable and there is already utp infrastructure.Quote from: slicendice on December 24, 2016, 07:48:49 amThe audio clock is usually extracted directly from the ADAT stream and maintained with a PLL, its very simple coding:https://ackspace.nl/wiki/ADAT_projectWhat devices embed timing info with that?

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 10:38:07 am
content: I knew the ADAT protocol had an embedded clock and a sync "frame", but i wasn't aware each packet (also) had an actual timestampAlthough i must admit, i'm still a bit "in the fog" with regards to joining up the 25MHz (as standard) data coming out of the receiving end, with the 6.144Mbps the ADAT decoder(s) expect at their input pinThis exercise is for transmitting 8 or 16 channels of audio (for personal cue mixers), to avoid the need for a "dedicated" person to handle monitor mixing dutiesQuote from: slicendice on December 24, 2016, 07:48:49 am

author: Someone
author_rank: Super Contributor
timestamp: December 24, 2016, 07:29:26 pm
content: Quote from: KhronX on December 24, 2016, 10:38:07 amIt doesn't.Quote from: KhronX on December 24, 2016, 10:38:07 amYou can't jump around with frequencies and fifos, ADAT like most audio data interfaces relies on the underlying coding to maintain the clock. Audio systems of that era are fully synchronous, and for good reasons.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 07:31:49 pm
content: That was my understanding as well, and that's where the whole thought of "moulding" the data-rate to the ADAT rate came to mind...Quote from: Someone on December 24, 2016, 07:29:26 pm** Edit ** I just had another brainfart / brainwave.Since there are 4 twisted-pairs in a CAT5 cable, and a (full-duplex) 100Mbps link only uses half of them... It ought to be quite feasible to stream the clock signal (say, 12.288MHz) down the 3rd pair, shouldn't it?This would be used to provide the reference clock for the receiving Ethernet PHY (via a Schmitt trigger, to clean up the squarewave).

author: Someone
author_rank: Super Contributor
timestamp: December 24, 2016, 10:24:19 pm
content: Quote from: KhronX on December 24, 2016, 07:31:49 pmYou're still over complicating it, the lightpipe data format is already viable to run as is over copper:https://en.wikipedia.org/wiki/Non-return-to-zeroIt has run length limiting so with some non-linear thresholding it could be sent as is along an AC coupled twisted pair. It might even be possible to do it DC coupled with a differential receiver. Why are you wanting to use a clocked PHY?

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 10:30:41 pm
content: The slight problem is, each ADAT frame contains 10 zero-bits, as part of the synchronization scheme.That being said, i might've slightly misunderstood the NRZI encoding, that would reduce that to only 5 effective zero-bits in a row.Which might then be feasible to transmit over an AC-coupled twisted pair..?Quote from: Someone on December 24, 2016, 10:24:19 pm

author: eb4fbz
author_rank: Regular Contributor
timestamp: December 24, 2016, 11:16:01 pm
content: An ethernet PHY is much more complex inside than you may think, it's not just a transceiver. The PLL for clock recovery is designed to work at the ethernet line rate, it will not work at your bitrate. It's not as easy as changing the phy xtal or oscillator.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 24, 2016, 11:23:30 pm
content: That's as a "maybe" - as in the video linked bybktempin the 2nd post here, such a thing COULD potentially be achieved. Micah managed to still have reliable TCP/IP comms on a 10Mbps link slowed down to... 25 / 6 = ~4, so down to about 2.5MbpsQuote from: eb4fbz on December 24, 2016, 11:16:01 pm

author: technogeeky
author_rank: Frequent Contributor
timestamp: December 26, 2016, 07:50:31 am
content: Most of the solutions in this thread are above my head. Heck, the question itself may be beyond me at the moment.But couldn't you do signaling at full speed but simply insert dummy data at the TX point and strip it at RX point? I am imagining reserving for instance audio content consisting of large blocks of all ones (which I suppose would correspond to a maximum audio signal) which you would forbid from being considered a real signal. Then you just insert ~3 of these packets for every ~1 ADAT packet and strip them at the receiver stage.Having typed this nonsense, I think it might introduce more problems; but hey, Merry Christmas.

author: technix
author_rank: Super Contributor
timestamp: December 26, 2016, 11:02:47 am
content: I wonder if you can just tunnel the audio data through normal UDP packets, using normal Ethernet infrastructure?The STM32F107 came into my mind, as it have (R)MII and I2S support. You can program the MCU to handle the ADAT packets as-is, tunneling it through UDP/IP by slapping UDP, IP and Ethernet headers onto it. On the other hand you can use an ADAT to I2S interface to take the raw audio stream and package it into RTP/RTSP, maybe throw in some lossless encoding like FLAC or ALAC for easier computer consumption.

author: KhronX
author_rank: Frequent Contributor
timestamp: December 26, 2016, 11:10:40 am
content: If at all possible, i'd prefer avoiding any and all programmingI got to thinking yesterday, that i might just have to try out my initial idea (RS485 driver chip hooked up straight to a MagJack), and see just how horrible that ten-zero-bit (encoded) synchronization frame looks on the scope, at the other end.

author: technix
author_rank: Super Contributor
timestamp: December 26, 2016, 11:42:50 am
content: If it is the isolation you are eagering for, you can use a small FPGA or MCU to insert (or remove) a lot of EDAC code and a high overhead line code, and use the PHY at full speed.Inserting EDAC code adds redundancy that can combat data corruption, thus you can get a longer cable run out of it. Normal Ethernet have a 100m run limit. With a lot of excessive EDAC you may get half a mile out of it.