Local vs internet streaming SQ

I don’t believe I mentioned use of a wifi module in the streamer, I simply called out the nonsense of using RF to buffer RF noise.

That’s a valid result for your test setup. I expect the result is skewed by a ‘limitation’ in the test setup, likely on the ADC and capture side. If wifi works for you then great.

I see that you want to ignore what I said :man_shrugging: If you are worried about wifi outside of the streamer, I hope that you turn off the wifi AP and all phones when listening to music

1 Like

Not like the Prime Minister then… :grinning:

2 Likes

The Naim streamers use Fast Ethernet. The carrier is the frequency of the Manchester encoding clock voltage transitions across the send pair using 4B5B MLT-3 with a clocking frequency of approx 31MHz.
1Gbps (twisted pair) uses 8B1Q4 and 4D-PAM5 - however I don’t have its effective carrier / clocking frequency of the two twisted pairs to hand.

Both methods use a similar method Manchester encoding of PAM (Pulse Amplitude Modulation), with the 1Gbps using more blocks of code words (or symbols - which allows a better DC balance when coupled with NRZ) which drives 5 voltage levels, and Fast Ethernet uses 3 voltage levels which are both effectively clocked using PAM. So the voltage pulses are PAM of a stream of varying analogue voltages and shouldn’t be confused with PWM which is a stream of binary (digital) voltages. Ethernet cables carry analogue encoded signals - which when encoded / decoded by the network interface unit converts the encoded voltages to a digital stream.

BTW what do you mean ‘improvement’ . What is improving - from what to what please ?

1 Like

Good point on the use of Fast Ethernet.

With regard to the specification, 4b/5b MLT3 code does not modulate a carrier.
The clock is effectively encoded in the signal by the encoded transmissions and recovered by the receiver using DPLL.
With regard to your specific point, the signal is scrambled specifically to limit RF emission.
This randomisation of the bit stream is used to prevent the same set of byte values generating a completely repetitive pattern, avoiding strong signal components at some characteristic frequencies, i.e. it distributes energy across the frequency spectrum.
Waveform is at 31.25MHz, the bandwidth required across the cable pairs.

Naim themselves do state wifi does not provide for an ideal situation:

For ethernet cables a good quality screened cable will reduce the effect of radiated noise and as Stevesky states, selecting appropriate power supplies and outlets for network equipment can help with injected noise.

:popcorn:

2 Likes

No, it doesn’t modulate a carrier that would be entirely different proposition :grinning:, that would for PhM, FM or AM encoding. The Differential Manchester NRZ encoding has an effective clock duty cycle rate of the possible voltage transitions, but the clock or carrier is encoded into the voltage level transitions. The use of the symbol mapping in 1000BaseT which helps reduce DC offset risk (note not RF suppression, if anything reducing DC offset potentially increase noise emissions) … from from the encoding of NRZ in certain encoding scenarios. This aspect is interesting as DC affects the accuracy of clock recovery, and why with 1000BaseT a different symbol set was used over 100 BaseT because of the higher precision.

The key thing, every probability of a transition change occurs at a point in time determined by the Manchester encoding clock…without a clock you wouldn’t have Manchester encoding and no conveyed meaning from the voltage variations. And of course Manchester encoding allows the clock to be recovered from voltage transitions… I think it’s a very clever and effective technique to produce a self synchronising voltage dataset stream I am sure you agree.

And of course good old SPDIF uses Differential Manchester encoding using just two levels… and there you can determine the DM clock or the carrier frequency by the sample rate and channels… and factoring the framing protocol overheads.

Simon, Manchester encoding was only used with 10Mbps Ethernet over co-ax cable, it is neither a part of the specification for 100BaseT nor 1000BaseT.
For 100Base-TX the encoding is 4B5B encoding. The 4B5B encoding provides DC equalization and spectrum shaping (for RFI control) as stated previously using scrambling prior to MLT3 encoding for the physical layer.
MLT line coding is used as an MLT-3 interface emits less electromagnetic interference and requires less bandwidth than most other binary or ternary interfaces that operate at the same bit rate (see PCM for discussion on bandwidth / quantization tradeoffs), such as Manchester code or Alternate Mark Inversion.

1000Base-T uses 8b/10b and scrambling to distribute energy across the frequency spectrum, again for RFI control.

No (Differential) Manchester encoding is used on 100 BaseT, 1000BaseT and 1000BaseX.
The key thing with Manchester encoding constructs is that they allow self synchronising from a voltage stream, as opposed to having a separate clock…

You might want to refresh yourself from current Ethernet physical design… happy to send you links… but low level data sources from the likes of Cisco and others are readily available.

The MLT-3 (three voltage levels) for fast Ethernet is about maximising the entropy for a given bandwidth whilst allowing for clock recovery and self synchronization. Electromagnetic radiation is managed for the post part by the twisted pair design and CI matching of the transmission line.

ok, we will have to agree to disagree. Reference links are already included in my post above.
Perhaps I’m not the only one that needs a refresher course.

Luckily I passed my exams :wink:… and I still earn a relatively good living from working with this stuff 5 days a week.

http://units.folder101.com/cisco/sem1/Notes/ch7-technologies/encoding.htm

And to be technical DM (Differential Manchester encoding as in MLT-3) here below … DM is the specific case and improvement to the original two level Manchester encoding that you referring to in 10 BaseT. The Manchester Encoding property of Manchester Encoding we are referring to is the property of transition to allow embedded carrier/ clock recovery. (It is not a bit stream which you suggested earlier)

Enjoy :wink:

Have a good read of your reference fella:
image

If you need any advice on this I’m here :slight_smile:

Why is 8 core cable used when 4 core will do? Another 2 could be used if pushing power down the cable, but I don’t think this is usually the case in a domestic environment.

Sure… but I suspect we do agree really … original ME was digital… in Ethernet with 100 and 1000 BaseT we use DM using multiple voltage levels (ie an advancement on original ME) , as opposed two the binary of original ME….
Only the original ME could be referred to as a bit stream, the DM would be typically a voltage stream.
The key thing is the clock/carrier recovery from the embedded voltage transitions.

You might be querying my assertion of Differential Manchester encoding (such as MLT-3) encoding being a derivative / advancement and type of Manchester encoding… which they are in as far as they are self clocking transition formats… but I agree with you in regard they are different in the entropy per given bandwidth by using differing voltage level encodings. Traditional Manchester Encoding has only two levels.
However it was the clock / carrier and it’s encoded nature and recovery which started this particular sub debate r… and this is a feature of all Manchester encoding types.

Actually Fast Ethernet only needs one twisted pair… ie support a half duplex connection… that is transmission occurs only in one direction at time. (Two wires)… think of a single track country lane

Two twisted pairs allows Fast Ethernet to operate in full duplex, that is both directions can communicate at the same time… (four wires) think of a main A road.

Four twisted pairs allows GigEthernet to be supported ; that is two twisted pairs in each direction. You can’t validly run GigEthernet in half duplex. (eight wires) think of a main dual carriageway.

So if you want to use GigE you need 8 wire cables.
Naim only uses fast Ethernet I believe on its streamers … so you need only four wire Ethernet cable (very rare these days)

I have tried wire Ethernet cable with the first gen streamers… it kind of worked a bit but not reliably.

:popcorn::popcorn::popcorn:

1 Like

Thanks. That’s good to know.

I’m testing a 1m length of 4 core (Beldon 3084A) between a wall socket and streamer.
It works fine, no glitches with hires quboz, and the cables aren’t even twisted. :thinking:

LOL yes four wire will be fine… but not twisted is probably not the best… is it specified for Ethernet use?.. I guess I am thinking of characteristic impedance of each pair… over a short distance it might not matter… but more than a few metres, you may have some losses or standing wave reflections which could cause RF noise in your streamer or switch and/or poor reliability… if you have a Cisco 2960 or similar you can look to see if there are line errors with data coming back from your streamer. If all fine… then nothing to worry about… at least in one direction :grinning:

My initial thought, is it sounds more dynamic than Cat5 cable, but maybe a bit fatiguing. Time will tell.

My next cunning plan is to try RS-485. If I’d only known I only needed one twisted pair.

1 Like