EtherREGEN: Installation, Usage, Difficulty, Questions thread

[Nenon]

28 minutes ago, lxgreen said:

I have the same problem as dctom  but can’t seem to fix it. I have router to EtherREGEN a side and Ethernet out of b side to an optical module to an optical Rendu. Roon can’t find the Rendu endpoint . If I move the cable from the b side to the a side it does work. I powered on and off several times and clock is internal position. Any thoughts for next steps? Thanks 

 

The B-side is 100Mbps only. I believe your optical module is 1 Gbps (which is determined by the transceiver you are using).

Why don't you remove the optical module completely and follow the ER recommendations? That would mean to connect the opticalRendu to the A-side SFP port and your router to the B-side.

[Nenon]

2 hours ago, dminches said:

Just another data point.

 

Here is my setup:

 

What I have been noticing is that I am periodically losing a connection on my IOS app with the Roon Server.  This isn't happening when music is playing, only when I have paused the music or when the playlist or album has ended.  The connection is eventually re-established within 10 seconds or so.

 

I am not saying this is due to the ER but I don't recall this happening before I added the ER.  

 

 

Is it possible that your Roon server is going on standby/sleep when not playing, and it takes a few seconds after it gets a network signal to "wake up"? That is certainly how my Synology behaves. 

[Nenon]

1 hour ago, Superdad said:

When I first installed my EtherREGEN beta unit I had also been running HQ Player Embedded on the Roon server machine, and at the time that AL server had been set to 100Mbps instead of Gigabit. I freaked out because I was getting lots of dropouts at the beginning of tracks—and sometimes throughout (my music files are not on the server, they are on some shared drives elsewhere on the network). As soon as we set the server to Gigabit the problem went away.

 

Out of curiosity - why switching the NIC on the sender from 100 Mbps to 1 Gbps fixed the drop out issues if the receiver is running at 100 Mbps. I might get it after another cup of coffee too, but at this point I can't get the logic why:

- when the sender and receiver are running at 100 Mbps (i.e. 100 Mbps --> 100 Mbps) you had issues; but

- when you had server @ 1 Gbps --> receiver @ 100 Mbps the issues stopped...

Unless of course your server negotiated at 100 Mbps half duplex somehow.

[Nenon]

11 minutes ago, Iving said:

Surely the EtherREGEN won't baulk at 100 Mbps input?

No one is saying 100 Mbps is a problem. It's more than adequate for streaming. Don't get my message the wrong way. I was just curious about what the root cause was of a problem Superad explained. 

 

One thing that I have not seen suggested here is using ping. Run a continuous ping from a device on your network and check what happens - do you see drops ,or significant latency increase, or something else. The ping tool is your friend when it comes to troubleshooting simple network issues. And there are apps that can be used for your phone... I use a program called Fing on my iPhone. It can scan my network and run various tests including ping.

 

[Nenon]

8 minutes ago, JohnSwenson said:

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.

 

I just checked my Comcast/Xfinity device. The lease time of its DHCP server is 7 days. Just FYI.

 

[Nenon]

5 minutes ago, Dutch said:

FYI; Clients actually start to try to renew their IP address with a DHCP server after half of the lease time has elapsed.

 

Yep, and under any normal circumstances, the IP address would not change.

The two most common causes for DHCP IP changes would be:

1. A restart of the DHCP server (i.e. the Xfinity cable modem in my case).

2. Connecting another device that acts as a DHCP server on the network. 

 

[Nenon]

If the etherREGEN was not passing broadcast traffic, there would be A LOT of issues, and most things would not work at all. ARP is broadcast. Hosts within the same network would not be able to communicate at all without ARP or broadcast. 

[Nenon]

On 11/14/2019 at 7:25 AM, dminches said:

Just another data point.

 

Here is my setup:

 

What I have been noticing is that I am periodically losing a connection on my IOS app with the Roon Server.  This isn't happening when music is playing, only when I have paused the music or when the playlist or album has ended.  The connection is eventually re-established within 10 seconds or so.

 

I am not saying this is due to the ER but I don't recall this happening before I added the ER.  

 

 

@dminches - Since I did not have time today to complete your other request, can I help troubleshooting this? 

 

First, and most importantly, can you install an app called "Fing - Network scanner" on your IOS device? It would scan your network and find your Roon Server. Next time this happens, can you try to ping the Roon Server from Fing? Also, try to ping your ultraRendu at the same time.

 

Second, would it be possible to remove the Trendnet Switch and connect everything to the etherREGEN? Less things, easier to troubleshoot.

 

Third, some reports earlier pointed out to a power supply problems and/or network cable problems. Just to reduce the number of variables, can you confirm if the problem still happens with the stock power supply? And if you have any other ethernet cables to test would be nice. This may even sound like a stupid suggestion... it does not make any sense to me, but just to avoid some really really odd stupidly crazy scenario.

[Nenon]

On 11/14/2019 at 7:13 AM, BigAlMc said:

Interesting (tho I may be stretching the definition of 'interesting' here) data point. When I try to connect to the NUC on Putty it's unavailable and I get a network error. Despite music playing. Power cycle the ER and then Putty connects fine.

 

On 11/14/2019 at 11:43 AM, BigAlMc said:

nteresting. One more thing to try I guess.

 

But as my Server NUC only has one LAN port I guess I'd need to change from:

 

Router to A side of ER, Server to A side of ER, B side of ER to EndPoint

 

To:

 

Router to previous AQVOX switch, AQVOX to Server, AQVOX to A side of ER, B side of ER to EndPoint?

 

Addition of an extra switch in the chain seems counter intuitive to resolving network issues. But might be worth a go

 

@BigAlMc before you try to introduce another switch and complicate things even more, can you please try a couple things?

 

1. Please follow @lmitche suggestion below:

On 11/14/2019 at 2:44 PM, lmitche said:

I'd make sure you NUC endpoint is set at 100mbps and the server to 1000mbps. Plug the endpoint in the B side of the ER, and the server into the A side along with your router connection. This way you don't need any autonegotiation.

 

2. If the issue continues, and you still cannot connect with putty to the NUC, can you please try to:

   a. Ping your NUC from the same computer putty is not working.

   b. Check the arptables on the computer putty is not working. That is typically done with command 'arp -a', but if it does not work, let me know what OS you are using, and I will give you the exact commend.

 

BTW, are you unable to connect to the NUC that's connected on the A-side or the NUC on the B-side? Or is it both? Try to use putty to both and perform #2 to the NUC(s) that is(are) not working. 

[Nenon]

4 hours ago, Superdad said:

 

Stay tuned on that.   

As John and I were studying the most current errata sheet for the main switch chip used in the EtherREGEN, we noticed a section regarding register code changes for improved PHY performance. I asked him to consider trying those.  

He did try those tweaks, and to quote the e-mail he sent me at nearly 1:00 a.m. last night:

 

"And it sounds quite a bit better as well! No Idea why, but it does. It is weird, the headphones are giving quite a bit better soundstage.
Listen to it your self, you might want to recommend this for everyone.
Wow! I'm listening to this as I'm typing, a new song just came on and I got goosebumps." 

 

So yes, it seems that maybe everyone will want the new firmware code loaded. 

 

Now, as usual the morning flew by with all sorts of logistics chores (getting more Crystek clocks delivered, getting parts on order and shipments out, replying to urgent e-mails) and I've yet to have lunch. So while I have the "magic" new firmware file that is to cure the EEE/connectivity problem and potentially bring another sonic bump, I have made zero progress on the instruction sheet. My wife is not well today and we have no food in the house, so I now headed to town for lunch and to market.

 

Will I have a chance to it myself? Not right away.

My first priority is to write the instructions and first send them and the firmware to a group of users in my e-mail box who have the worst cases of the connectivity blues. We want to confirm it solves the issue for them. (John and I both have had a hard time replicating the problem consistently; It never even showed up for any of our beta testers.) Once we have that confirmation, then I will roll it out publicly. Those few users who first test it can also give me feedback on my instruction sheet.

 

Most of you know that I am an easily distracted fellow--especially when it comes to responding here on the forum.  So the quieter you can keep things here, the sooner I'll have the above firmware update roll-out process going.

And please, even if you are having the issue, I'd rather you not e-mail me to jump into the above early test group. The names I already have slated to receive it represent a diverse enough range of devices for us to know if we have the problem licked.

 

Thanks all!

--Alex C.

 

Very exciting indeed! Let me know if you need any beta testers for the new firmware. 

[Nenon]

2 hours ago, Superdad said:

New blog post and firmware released!

https://uptoneaudio.com/blogs/news/etherregen-huge-success-new-firmware-for-november-units-reviews

 

Upgraded mine. Super easy. Great instructions. Thanks, Alex.