EtherREGEN: Installation, Usage, Difficulty, Questions thread

JohnSwenson · November 11, 2019

13 hours ago, Bricki said:

I may as well kick this thread off with a question about ethernet speeds.

I have my server and endpoint bridged and I was thinking of installing my Etheregen in this bridge. I have changed my ethernet speed on this bridge to 10Mb/s and half duplex with auto negotiation turned off, with this slower speed it sounds a little more relaxed. Will the Etheregen work with these current settings? or will I need to change these settings back to full duplex and 1000Mb/s? or 100Mb/s before I install it?

The A side RJ45 jacks are 10/100/1000, the A side SFP port is just 1000, The B side RJ45 is 100.

That's the way it is, there is no way to change any of that.

John S.

JohnSwenson · November 11, 2019

16 minutes ago, André Gosselin said:

In my current network setup, a NAS is connected to my router upstairs. An ethernet cable goes downstairs to an unmanaged switch in my music room. To the switch are connected two different renderers. 1- sonore optical module/optical rendu combo, and 2- Simaudio 780Dv2 with an internal Mind2 ethernet module . No other equipment connects to the switch.

Reading the ER documentation, I see that the ER can be operated in "backward" mode with the connection to a router on the B side, and the SFP module on the A side connected by optical cable to the OpticalRendu. The manual suggests than nothing else be connected to the A side, but I think I saw a post by @JohnSwenson where he limited this restraint to non-audio equipment. So it would not be harmful to connect also the Simaudio 780Dv2 to the A side, but no additional non-audio equipment

In short, I am hoping that using an ER, I could simplify my current setup by :

- getting rid of my unmanaged switch and replacing it by the ER

- removing the optical module and connecting to the OpticalRendu from the SFP on the A side

- connecting the Simaudio 780Dv2 to a second port of the A side

- having only those 2 audio connections to the A side, and nothing else

- running a cable from my router to the ER B side

- having all non-audio equipment (NAS, PC's, etc) connected to the router and not to the ER

Could you comment on the above setup ? Is it a sound one ? In particular, would the 2nd audio equipment (Simaudio 780Dv2) connected to the A side benefit from the ER upstream isolation, or would it harm the SQ of the OpticalRendu ?

Any advice would be greatly appreciated.

What you are describing is probably the best way to go. In this case most of the packets are going to the endpoints, hence crossing the moat, thus there should be little interaction between endpoints.

That is certainly how I would connect things.

John S.

JohnSwenson · November 13, 2019

2 hours ago, BahamaBob said:

My configuration is simple: Modem, Synology NAS, Roon Server (sonic transport); connected to "A" side of ER. Streamer/DAC (Logitech Transporter) connected to "B" side. Everything was working well for first 24 hours, after that I started getting dropouts. The dropouts became more frequent. I removed the ethernet cable from the "B" side and inserted it into the last remaining port on the "A" side, the dropouts disappeared. I repeated switching the cable connection two additional times, same result, "B" side dropouts, "A" side no dropouts.

After approximately 28 hours of use it appeared that the "B" had quit working completely, I then tried a drastic maneuver , I unplugged the ER and powered it up again after a few seconds. It now works on the "B" side. Any ideas why this occurred?

I presume you are using the Roon emulation of LMS, correct? I'm wondering if this has anything to do with it. I've been using LMS with an SBT for a couple months without any such issues, I don't have a Transporter to test with though.

Is it possible to try switching to real LMS on your Sonic Transporter and see if that has the same issues?

John S.

JohnSwenson · November 14, 2019

12 hours ago, BahamaBob said:

My configuration is simple: Modem, Synology NAS, Roon Server (sonic transport); connected to "A" side of ER. Streamer/DAC (Logitech Transporter) connected to "B" side. Everything was working well for first 24 hours, after that I started getting dropouts. The dropouts became more frequent. I removed the ethernet cable from the "B" side and inserted it into the last remaining port on the "A" side, the dropouts disappeared. I repeated switching the cable connection two additional times, same result, "B" side dropouts, "A" side no dropouts.

After approximately 28 hours of use it appeared that the "B" had quit working completely, I then tried a drastic maneuver , I unplugged the ER and powered it up again after a few seconds. It now works on the "B" side. Any ideas why this occurred?

One other bit of information:

when you are having dropouts are they randomly distributed or do they occur at a specific time? The first and last ten seconds of a track are the most likely to have dropouts. During the last ten seconds of a track the player starts filling the buffer for the next track which is much more intensive than "normal" Ethernet traffic which has significant space between packets.The first ten seconds is where things like metadata and cover art gets sent. Thus far more net activity happens at the end and beginning of a track.

Just general information: it is usually best to have the EtherREGEN powered up before other devices are turned on/plugged in. I HAVE seen a couple times that if the EtherREGEN is turned off and other devices connected/powered up, one of the devices can power down because it is not connected to anything. The are SUPPOSED to notice when the switch starts trying to connect and power up again, and most of the time it does, but I have seen a couple times out of thousands of connections the device doesn't connect when the EtherREGEN powers up. Trying again always fixes it, but if you want to make sure that doesn't happen, have the EtherREGEN on when connecting or powering up the other devices.

John S.

JohnSwenson · November 15, 2019

17 hours ago, Ultrarunner said:

So this means the ER won’t be able to feed an opticalModule from the B side?

If so, I guess my only option will be to use the ER in “reverse”, with the router connected to the B side and the A side optical port connecting to my opticalRendu.

Yes, you cannot connect the RJ45 jack of the opticalModule to the RJ45 "B" jack on the EtherREGEN. The oM RJ45 jack just runs at gigabit and the RJ45 B jack on the EtherREGEN only runs at 100Mb. The EtherREGEN was specifically designed so you can run it "backwards" when driving a device such as the opticalRendu.

JohnSwenson · November 15, 2019

16 hours ago, k27R said:

I was having the same drop out issues with my system last night and it was a little frustrating.

My system consists of:

ubquiti edge router->copper->EtherREGEN->copper->pinkfaun (uses a version AudioLinux)

I tried a bunch of different configurations including optical and speeds on both server and router ends. what ended up finally working was switching the Regen around to go B to A ports, and using the stock power supply. For whatever reason, the linear ps I was originally using lead to dropouts and going A to B gave dropouts (no matter what speed settings were used on both ends) as well.

its been playing all night without dropping out so far. I’ll have to play with it more today to see how stable it is with normal use.

Did you try using the supplied SMPS powering the EtherREGEN when going router->A B->DAC? Are your Ethernet cables shielded using metal connectors? This is actually sounding like ground loops.

John S.

JohnSwenson · November 15, 2019

For all of you having problems with droputs and disconnections I think I have figured out what is happening. A little background first: the endpoints most people use get an IP address from a DHCP server on your network (usually in the router). The DHCP server creates a "DHCP lease" which itsends to the endpoint, this contains an IP address and a range of time it is good for. When a music server connects to the endpoint (each protocol does this part differently) the endpoint sends this IP address to the server, which then uses it to talk to the endpoint.

The fun part happens when the lease expires, the endpoint then goes back to the DHCP server and says "renew my lease", in most situations the DHCP server will give it back a new lease with the same IP address it gave it the first time. BUT sometimes the new lease contains a different IP address, this is what causes the problem. The server keeps on sending the audio data to the old address, but the endpoint doesn't get it because it now has a different address. The music data goes into Ye Olde Bit Bucket.

Somehow the music server has to get the new IP address of the endpoint. There are a few ways of doing this:

turn off the endpoint then turn it back on (unplug it, many endpoint's power switch just puts them in low power mode), sometimes this may need to off for 10 to 15 minutes.

Unplug the Ethernet cable for 10 to 15 minutes.

Reboot the music server

This gets the server back talking to the endpoint.

In many instances this is all that is required, from then on the DHCP coninues to renew the lease with the same address it gave out the second time.

For some systems it might take two times for the DHCP server to settle down.

Another option is to make sure the address of the endpoint never changes, there are two ways to do this:

set a static IP address on the endpoint. Not all endpoints allow you to do this.

Set a reserved IP address on your DHCP server, almost all allow you to do this, the endpoint still asks for a lease or renewal, but you reserve a specific address for that specific endpoint, the DHCP server HAS to always use that one.

Most people's system do not have the problem in the first place. For the ones that potentially do have this issue there seems to be some sort of trigger that causes the DHCP server to behave this way, it usually has to do with something "new" in the system. A new endpoint will almost always trigger this. Sometimes the same endpoint but with a different configuration, or a network with a significant change. Simple switches will usually not trigger this, but managed switches (or different configuration of the same switch) being added, or taken out can also trigger this.

So while this seems to happen when you add the EtherREGEN it is probably not anything inherently wrong with the EtherREGEN, but rather that you have significantly changed your network topology that is somehow triggering this behavior in t your DHCP server.

Ether just living with it until the DHCP server settles down or clamping down the IP address of the endpoint should get rid of the issue. If you want to spend time playing with different network configurations, endpoints etc, I would recommend you reserve the IP address of your endpoint so the DHCP server cannot mess you up in the future.

Note: I do not know exactly what the triggers are or exactly how the DHCP server determines when something is "new". And most likely different models behave differently. So please don't ask questions like "will my system have this problem?" "Exactly what do I do if I have it?" "Which router should I buy so it won't happen to me?" I don't know the answers to those questions. Tomorrow I probably will not know the answers either. So please don't ask.

What I know about it is already in this post.

If you do have the problem and you follow the advice above and it does not go away, please post THAT, we will try and get to the bottom of it.

John S.

JohnSwenson · November 16, 2019

7 hours ago, Dutch said:

I don’t get it though. IP addresses can always change so clients need to check cached IP entries of other hosts on the network regularly using DNS, mDNS or whatever.

I’m wondering if the etherREGEN a L2 or L3 (or L2+) switch and if it’s configured correctly to support multicast for mDNS etc.

Of course since I don’t have my Etherregen yet (missed the delivery guy today) I also don’t have the issue yet, let alone troubleshooted it (if I even get the issue). I do feel here we’re attacking the effect and not the cause. Though the cause could be anywhere..I for sure don’t envy John here! 🙄 I hope the above proves to be a good workaround!

Hi Dutch,

Yes I have extensively tested multicast and mDNS, they both work fine in every scenario I've tested.

BTW, there is only one switch in the EtherREGEN--in the A side. One of the ports on the A side switch sends data through the "special sauce" which goes into a format converter which is not a switch. Whatever packets come in go out without any modification.

John S.

JohnSwenson · November 16, 2019

Hi All,

Here are some more focused procedures to try for those of you having connection issues.

First off, I want to establish general network connectivity without bringing audio protocols into this, i.e. make the network connections work first, THEN try and play music. With this we can separate issues with network connectivity from things like Roon or LMS etc.

To do these tests you will need a way to find the IP addresses of your devices (servers, endpoints, etc.) and be able to "ping" them. A ping just sends a command to a device that says "send me a reply." This is a low level test to see if the communication is working at all.

Fortunately there are some tools that make this fairly easy. I'm just going to list one for Windows and one for Mac; there are MANY others. Use what you wish. Nenon mentioned one for iOS, (thanks Nenon for helping with this, we really appreciate it).

Windows :

https://www.advanced-ip-scanner.com

Mac:

https://www.iwaxx.com/lanscan/

These programs will scan your network and show all the devices, including name and IP address. They allow you to ping the device and make sure it is responding.

Some of the names are really weird and you may not be able to identify your devices. If this is the case, turn off your audio related devices (NAS, server, endpoint etc) and do a scan. Then turn on one device, do a rescan, note what was added--and do this for each device. Write down the name and IP address of the audio related devices (you don't need to write down phones, TVs, printers, ovens, toasters etc.)

What I want you to do is run this process WITHOUT the EtherREGEN in the network. Take it out, turn off all the audio devices, turn them back on (no particular order) then run the scan, write the names and IP addresses down, do a ping on each device, make sure they all respond.

Then put the EtherREGEN in the network and do the process all over again. See if any of the IP addresses have changed and if they can all still be pinged.

If the devices still respond to a ping, start playing music, when you have the connectivity issues, do the scan again and check the pings. Note if any of the IP addresses have changed

This information will be a really good starting point for finding out what is going on.

Thanks,

John S.

JohnSwenson · November 19, 2019

45 minutes ago, Bernstein said:

will ER force them not to use

EEE or will it comply with the

EEE rules set by other units?

The problem occurs every now and them. It seems to be random. This makes it incredibly difficult to test. EEE is agreed upon by auto-negotiation, the "fix" turns off the advertisement of EEE during auto-negotiation, thus preventing it from ever being used on it's ports, preventing the issues from happening.

So no, it will never properly perform EEE.

John S.

JohnSwenson · November 20, 2019

21 hours ago, dminches said:

Will turning EEE off on the computer feeding the EtherREGEN accomplish the same thing as your “fix.”

Yes, turning the EEE off on the device directly connected to the A side RJ45 is doing the same thing. Note that EEE only happens between PHYs connected by a cable. So a computer connected to the A port might have the issue, if there is a switch in between changing a setting on the computer would make no difference.

As I mentioned before, even if you connect a device that you know supports EEE, it may not have the problem. Some chips don't exhibit the problem and some do.

John S.

JohnSwenson · November 20, 2019

The temperatures listed here from users are all well within the normal range. I consider the normal range from 49C to 51C. If you are there or under don't worry about it at all. If you are getting significantly higher you might want to consider a heatsink, but one is not really necessary for "normal" or under.

If you really want to cool things down consider putting the EtherREGEN on it's side, this allows for better air flow and does cool it down.

John S.

JohnSwenson · November 20, 2019

9 minutes ago, Theobetley said:

What is EEE?

Please see Alex's post #187.

EEE is Energy Efficient Ethernet. It is a mechanism designed to put Ethernet PHYs into a low power mode when there are no packets going over the wire. It is a cooperative protocol, both devices (on each end of the cable) work together to decide when to do this.

The main switch chip we are using has a bug in it's hardware which sometimes causes this to not work properly and drops the link. The solution is to program the chip so it doesn't use EEE.

John S.

JohnSwenson · November 26, 2019

14 minutes ago, skatbelt said:

I understand your feelings. May be @JohnSwenson can explain - in terminology we earthy people can understand - why it is technically important to keep the clean-side cable as short as possible and of high quality. I know that Jensen transformers advises to use short cabling after their isolators. They say this about it:

"There is no “free lunch” in transformer design........ extremely high noise rejection unavoidably makes their output sensitive to capacitive loading. Since the cable that connects isolator output to equipment input is the main source of capacitance, it must be kept reasonably short. Capacitance up to 200 pF, about 3 feet (1 meter) of standard cable, will preserve the rated high-frequency bandwidth....."

Not saying that this technical explanation also counts for the EtherREGEN but a statement like the above could avoid a lot a questions and uncertainty I think.

My additional question would be: what is considered a cable of high quality? Is this for instance a Ghent JSSG360 (named after the famous...), a (probably expensive) cable of one of the established cable brands or something else?

dCS advises plain CAT6 UTP or at least a non-shielded/non-metal-connector type. For this reason (and may be as a reference for you) I use 3,5m very cheap Belkin CAT 6 UTP on the B-side until now. This is the minimum length I need. I also tried the 10m version of the same cable out of curiosity and could't hear a difference.

There are no definitive technical explanations for any of this except for the connected shield stuff, but for the EtherREGEN even that is iffy.

Maybe someday I'll have enough money to buy some REALLY, REALLY good test equipment to measure this level of thing, but that is highly unlikely. Right now any explanation is hand waving "maybe it works this way". Changes made by different cable lengths and material types etc make such small changes in the signal that they are incredibly hard to measure. The only exception are cables that are radically out of spec. And even if they could be measured how THAT effects sound quality is a whole different ballgame.

The one thing that IS easy to measure is leakage current end to end through tied shields and metal connectors. But this is primarily only a concern on the A side. The B side is isolated both data and power/ground, thus even if you do have an end to end tied shielded cable it is going to have very little if any affect on the B side.

So for now there is no TECHNICAL explanation for any of these cable differences except for shield tie. It all comes down to what sounds best to YOU in YOUR system. I know everybody wants a definitive "use this cable, it is the best there is" but I simply cannot give that. Even if I spent every waking moment listening to cables and found what sounded the best to me, it probably would only apply to a small group of people with similar system.

I'm using some Blue Jeans CAT6A and not worrying about it. Any changes I make in the electronics make vastly larger SQ changes than Ethernet cable changes that I have ZERO interest in spending a lot of time trying to find "THE BEST" cable.

The different cables I've tried have made almost no difference in sound, so why bother. Other people hear significant changes with different cables, only you can determine where you are in that continuum and whether you want to spend time and money trying to find the best for you.

John S.

JohnSwenson · November 28, 2019

12 hours ago, lxgreen said:

I just completed firmware update and everything seems to work fine. FYI, I didn’t realize I had an issue with EtherRegen but now I realize I did. I use a sonictransporter for Roon Core. When I plugged sonictransporter Ethernet cable into sonictransporter, Roon could not find Core. So I got it to work by plugging sonictransporter into Ethernet port on router. Now, after firmware update, I can plug sonictransporter Ethernet directly into EtherRegen. However, now I have copper Ethernet from router going to EtherRegen B port so I can use optical from A side to my optical renduSE. So I have two inputs into A side ( optical to rendu and copper to sonictransporter. I’m still a bit confused on how to use A ports in this configuration. Would I be better off plugging sonictransporter back into router so I leave A ports empty except for optical?

This configuration is not optimal, the music packets are coming from the SonicTransporter to SFP to the oR just through the A side, this doesn't give you the advantage of the ADIM. You would probably be better off with just the oR on the A side and the SonicTransporter and everything else on a switch or router connected to the B side.

You can try various ways but I'm pretty sure this will give you the best sound.

John S.

JohnSwenson · November 28, 2019

2 hours ago, thotdoc said:

The FW update did not cure the dropouts and the music completely stopping in my set up. I've stated this before and people have made suggestions, which I appreciate. But I have a question: Am I the only one who continues to have the drop out problem following the FW update?

Setup: Mac running Roon app (managing Tidal and Qobuz) over wifi sends data to ATT modem, data sent from ATT modem by ethernet metal cable to Cisco switch (2960 8TC) to Sonic Transport by metal ethernet back to Cisco, from Cisco metal ethernet to ER, A side in and B side optical cable out to OR.

I've tried a different zone on Roon and there were dropouts on the 2nd zone, suggesting Roon is the problem.

I've replaced the ER with the OM setup...but no drop outs so far.

My system seems so common Roon, Cisco, ER, OR...so it seems others would be having the problem.

I'm communicating with Roon

BTW Happy Thanksgiving. Family get together later. I hope the same for everyone...

A few things, first are you sure about the sides of the ER you have connected? The SFP cage (For the optical connection) is on the A side, if you are running an optical out from the ER it IS connected to the A side. Thus the B side would be connected to 2960.

The 2960 model you have is a 100Mbps Ethernet on all the ports on the left, the only port that is gigabit is the one on the far right. Is there anyway you can try the system without the 2960? For example do you have enough ports on the router to plug in the Sonic Transporter and B port of the ER? Or if not enough ports do you have a normal gigabit switch you can use instead of the 2960? I have seen a couple reports that Roon does not always like a 100Mbps connection to a server. I would like you to see what happens if the Sonic transporter has a gigabit connection to the router rather than through the 100Mbps 2960.

The wifi connection is just for control, right? The audio data is coming through the router to the 2960?

John S.

JohnSwenson · November 30, 2019

4 hours ago, thotdoc said:

So, I would use the one next to the SFP cage out and one of the 1x-8x in?

Thank you

G

I don't know if this will work, it is just one thing to try. The problem is that all the other ports re still 100Mbps, the throughput is still 100Mbps even if the Sonic Transporter is connected to the gigabit port.

John S.

JohnSwenson · December 4, 2019

1 hour ago, thotdoc said:

I want to try using the 1.2 PS with the ER.

I only use 1-RJ45 into side B and the SFP out of A.

Therefore there is no need for the ground wire. Is that correct?

Yes,

in that configuration the ground wire should not do anything.

John S.

JohnSwenson · December 6, 2019

21 hours ago, AlanProuse said:

Hi folks,

I am new to posting but have been following this thread for ages. I have purchase an Etherregen and am interested in getting the Sonore 9 package with Signature Optical Rendu and was wondering if anyone could advise whether the following setup would work. The Sonicorbiter i9 is designed to connect directly to the Optical Signature Rendu but I would like to connect this via a switch into the B side of the Etherregen, then run from the optical output A side of the Etherregen into the Signature optical rendu and from there into my Denafrips terminator DAC. I am aware of the people from Sonore not recommending this and saying the end result would be noisier but would like to see for myself if that is true or not.

I guess I just have 3 questions.

1) Is setup recommended?

2) Would the setup work at all?

3) Are there any things I would need to consider if the setup works

Many thanks in advance to all for any help and advice

Alan

AP Network.pptx 35.95 kB · 6 downloads

That is the way I would hook it up.

You can also try it without the ER at all, running optical from the Sonic Transporter to the oR SE. But I bet you'll like it better with the ER in the path.

John S.

JohnSwenson · December 9, 2019

Since you have a device that converts WiFi to Ethernet cable, that is where you put the EtherreGEN, connected to the Ethernet Cable coming out of the WiFi converter. The other side of the ER goes to your Usbridge.

John S.

JohnSwenson · December 9, 2019

8 hours ago, guillaume31 said:

Hi all,

My Hifi and my HomeCinema system are integrated together, with some components shared and others separate. I currently have a switch onto which the HC player (HTPC running JRiver), the NAS (where movies and music files are stored) and the NAA (an sMS-200 Ultra) are connected.

I initially thought the EtherRegen could be a drop-in replacement, hence bringing benefits to both systems, but looking at the recommendations here and on UptoneAudio's website, I can see that it is recommended to connect the NAS directly to the modem/router.

I'm now wondering how I could integrate the EtherRegen to benefit both my HC and my Hifi system ? Should my HTPC be connected to it and do you think it would bring any benefits ? (i.e. not having the NAS on the EtherRegen)

Thanks

Guillaume

You are not going to hurt anything by hooking things up the "wrong" way so go ahead and experiment, see what sounds better.

The recommendation for nothing else on the A side is primarily for situations where the A side is used to connect to the primary audio endpoint (such as using optical from the SFP cage to an endpoint with optical input). If you have the B side RJ45 connected to the audio endpoint, then multiple devices on the A side should not be a particular issue. It primarily depends on where things are. If the NAS and and other devices are all in the same area, connecting them to the A jacks on the ER is fine. If the NAS and other devices are on the other side of the house then use a regular switch to connect them, then feed a single cable to the ER which is near the audio endpoint.

This is NOT about "Everybody has to hook their system up the same way". There are really only two recommendations: The packets going to the audio endpoint should cross the moat (A->B or B->A), and the ER should be fairly close to the audio endpoint. This means that if you have a choice between 5 feet away or 60 feet away, go with the 5 feet. This does not mean it will not work at 60 feet, but that you will probably get better sound with the shorter cable from the ER to the audio endpoint.

Pretty much everything else is try it and see if you like it.

John S.

JohnSwenson · December 11, 2019

1 hour ago, Lobbster said:

Advice please, with the JS2 I'm powering a Legacy Wavelet preamp and the ER. I have Optical in and B side copper to a Bricasti M1SE. I also have copper from the A side to the Wavelet (via USB>EN adaptor) for the GUI interface. Is it better to isolate the Wavelet GUI to a separate ethernet jack or no problem ( I have a wall jack in proximity) ?

Congrats on the successful launch and best of the season!

I presume that the Wavelet is connected to the M1SE analog outs? If so you are directly shorting out the moat by powering both from the same JS-2. The negative outputs of the two outputs are directly connected. Neither is connected to power cord safety ground, but they are connected to each other. So you have a situation where the A side gnd is directly connected to the B side gnd through the M1SE power connection.

We need to work on that first before worrying about Ethernet connections.

John S.

JohnSwenson · December 12, 2019

26 minutes ago, jacques_racine said:

Uptone's User Guide recommends using copper Ethernet wire.

Just realized my Starlight 8 is silver...

Should I return my ER?

The copper is referring to "electrically conductive wire" (as opposed to optical) so either copper or silver will work fine.

So "copper" is a common generic term for meaning wire based Ethernet cable rather than optical or some other form, such as Wifi.

John S.

JohnSwenson · December 27, 2019

6 minutes ago, Ponkbutler said:

I have been getting very impressive results from two daisychained Etherregens (for anyone reading who’s interested, the difference is much more subtle than other switches, testifying to the design) and will be getting a dual rail Sean Jacobs power supply made for them. Which voltage would you most recommend for performance and/or cooler running?

MTIA

Mike

Are the two rails completely isolated from each other?

An EtherREGEN runs nicely at 12V, there is almost no difference heat wise from 7v to 12V so I would go with 12V it will pull less current from the supply, reducing any voltage drop across the DC cable from the supply.

John S.

JohnSwenson · December 28, 2019

This is where it gets complicated, you do NOT want the DC- to be the same for both supplies, this bypasses the moat, giving up much of the goodness of the ER. The connecting the DC- to safety ground should ONLY be done for the most upstream ER. Doing for both again shorts out the moat. Whether you need the safety ground on the upstream ER depends on if there are other things plugged into the A side. If nothing else is plugged in, then don't bother with connecting DC- to safety ground. You CAN but I would not do it if it will cost more or take extra time etc.

John S.

EtherREGEN: Installation, Usage, Difficulty, Questions thread

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in