Jump to content

JohnSwenson

Members
  • Content Count

    1566
  • Joined

  • Last visited

About JohnSwenson

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The A side and B side are actually logical constructs, albeit mostly physical as well. The "moat" separates the A side from the B side. The A side has the 4 port RJ45 jacks, the SFP cage on the "front" of the case and the LED, power jack and grounding screw on the back. The B side contains the rest, single RJ45 jack, switch and external clock BNC jack all on the back. John S.
  2. The Rasberry PI 3B+ has a gigabit Ethernet jack, the bus the Ethernet chip is connected to is only 400Mb, but the connection speed at the jack is gigabit. The USB also shares the same bus so an Ethernet to USB configuration will probably have dropouts all over the place, but using a DAC hat should probably work. I have a couple 3B+ boards (but no DAC hat) I can try squeezelite on one and see if it works at all. The new 4B fixes all this so it should work great with the opticalModule. John S.
  3. The optical by itself means NO leakage current gets through to the Ethernet PHY, this is significant. There is another significant side effect of the optical circuit which is a "reclocking" of the data right next to the Ethernet PHY, it is not because it is optical, but because the reclocking is done by a very good chip and it is close to the PHY. Those two together account for maybe something like 80% of the improvement. Other things are a clock distribution system that uses incredibly low phase noise buffers, and an improved power network which has lower noise and significantly lower impedance over a broad frequency range. The regulator feeding the VBUS pin on the USB jack is much better than before, so if you are using a buss powered DAC, or even one that uses VBUS for its input circuitry, that will also make an improvement. John S.
  4. Definitely, the opticalModule draws significantly less than that. 5V is great for the opticalModule. John S.
  5. Definitely have the opticalModule Ethernet connected to the ultraRendu, run one of the FMCs over optical to the opticalModule. This is much better sounding than the other way around. Of course this needs the SC to LC fiber cable. When you get the opticalRendu you will need a LC to LC fiber cable. John S.
  6. Correct, the Ethernet connection on the microRendu is 10/100/1000 capable. Optical is different. The fiber protocol does not implement auto-negotiation, both sides have to be either 100 or both 1000. The oM is set so both the optical and wired connections are only 1000. John S.
  7. Each SFP module (the thing you plug into the SFP cage) contains a manufacturer ID number. The Cisco switch will only connect through a module which has the Cisco ID number! It has NOTHING to do with differences in protocol etc, purely that Cisco wants to force you to buy a Cisco module. Now some third party module makers include the Cisco ID in THEIR modules in order to fool a Cisco switch. The oR and oM do not check the manufacturer ID so it doesn't make any difference what company made the module. John S.
  8. The opticalModule works quite well with 5V. The Rendu products do NOT work with 5V. John S.
  9. So what did you do to get it to work? John S.
  10. Note that the LPS-1 is iffy powering an EtherREGEN, it MAY work if you just have one connection on the A side, but we are not going to guarantee that. The LPS-1.2, when set to 12V, WILL power an EtherREGEN in any configuration. John S.
  11. Given that Roon works it is probably not a bad connection issue. Dropouts etc could be happening because of the extra two devices the packets are going through, that's about the only thing that can be different from the uR setup. How many network devices do you have between the computer running HQP and the oM? If the HQP computer is connected to the same switch as the oM, one thing to try is to temporarily put it on the same switch and see if that makes any difference. I don't use HQP so I can't give any specific advice on that, I can just ask some general questions. Is there any options in HQP having to do with buffer size or number of buffers? If yes that is good place to start. John S.
  12. Yes, your diagram is correct. Two things you need to be sure of: the two SFP modules are compatible, the optical cable is compatible with the modules and the upstream FMC is gigabit. If you want to use the SFP module that comes from Sonore the other one must match: 850nm; multimode fiber, LC connector The fiber cable must match the above. Just make sure both SFP modules match this and the cable also matches the above and you should be fine. John S.
  13. All the optical does is block leakage, it doesn't get rid of clocking issues at all (it can actually make them worse). The fact that it is optical does not automatically apply some universal quantum time scheme that mystically aligns edges perfectly, If you send in a pulse, then another that is 50ns apart, then another at 51ns, then another at 49, that difference gets preserved at the receiver, the optical does not magically force all of them to be exactly 50ns. The raw data coming out of the optical receiver goes into a chip that rebuilds the Ethernet signal using its own local clock, that is done with flip flops inside the chip, these flop flops behave just like any other flip flops, again no magic here. I was trying to avoid re-iterating what I have said before on this, but it looks like I'm going to have to do it anyway. So how come this reclocking with a new clock is not perfect? As edges from the input stream go into a circuit each and every one of those edges creates a current pulse on the power and ground network inside the chip and on the board. The timing of that pulse is exactly related to the timing of the input data. The timing of the input data is directly related to the jitter on the clock producing the stream. This noise on the PG network changes the threshold voltage of anything receiving data inside the chip, especially the local clock going into the chip. This means the phase noise spectrum of the data coming in gets overlayed on top of the phase noise spectrum of the local clock. It's attenuated from what it is in the source box, but it is definitely still there. THAT is how phase noise gets from one device to the next, EVEN over optical connections. If you look at this in a system containing all uniformly bad clocks, you don't particularly see this, since they are all bad to begin with. BUT when you go from a bad to a very good clock you can definitely see this contamination of the really good clock by the overlaying of the bad clock. This is really hard to directly measure because most of the effect is happening inside the flop flop chip itself. You CAN see the effect on the data coming out of the flip flop. This process happens all the way down the chain, Ethernet to USB, USB into DAC box, and inside the DAC chips themselves, finally winding up on the analog out. Wherever reclocking is happening, how strong this overlay is depends primarily on the impedance of the power and ground network, both on boards and inside chips. A lower impedance PG network produces lower clock overlay, higher PG impedance give stronger overlay. This is something that is difficult to find out about a particular chip, the impedance of the PG network is NEVER listed in the data sheets! I have somewhat of an advantage here having spent 33 years in the semiconductor industry, spending a lot of time designing PG networks in chips, I have some insight into which chips look like good candidates for low impedance PG networks. On a side note, because Ethernet and USB are packet systems the receiving circuit CAN use a completely separate clock, the frequency just has to be close enough to handle the small number of bits in the packet. If it is a little to slow or too fast the difference is made up in the dead time between packets. To reiterate none of this has ANYTHING to do with accurately reading bits, this is assumed. It IS all about high jitter on network clocks working its way down through reclockings to the DAC chips and hence to audio outs. All the work done on DACs in recent years has cleaned up the signals so dramatically that these effects are getting to be audible in many systems. John S.
  14. Take a look at post #658 in the opticalRendu thread. I cover a lot of your questions there. John S.
  15. The circuitry inside the opticalMode takes less than 200mA, but you also have to include what the SFP module consumes. The spec says a maximum of 600mA, but I measured the ones that Sonore ships to be 110mA. I haven't measured other SFP modules so I have no idea what the spread is. So if using the Sonore supplied SFP module you should be around 300mA. I've run an opticalModule at 9V and it works fine, yes the case gets quite warm, but there is nothing wrong with that. John S.
×
×
  • Create New...