Anyone Using an Asus DSL-AC68U

Ferrites

I have been experimenting with ferrites on the power cable. After I plugged my ASUS into a UPS I got a noticeable drop in CRC errors, so I figured that the UPS electronics could be filtering out some supply borne impulse noise that was causing problems with the modem. To try and improve things I bought a load of clip on ferrites like this:

http://www.amazon.co.uk/UF90B-Clip-...e=UTF8&qid=1417096082&sr=8-2&keywords=ferrite

I've been clipping them onto various household appliances that I know cause impulse spikes on the mains ring...like my boiler, fish tank heater etc. I've done this before to resolve an impulse noise issue I had with my Freeview signal.

I have put one on the low voltage side of routers power supply cable, but if ASUS's power brick is really that bad I might try putting a couple more on :D

Does anyone know off hand what supply voltage the ASUS router needs? We've got loads of random power bricks knocking about our lab in work...I'm sure I could find one that's the right spec to try out.
 
IronRod said:
I have been experimenting with ferrites on the power cable. After I plugged my ASUS into a UPS I got a noticeable drop in CRC errors, so I figured that the UPS electronics could be filtering out some supply borne impulse noise that was causing problems with the modem. To try and improve things I bought a load of clip on ferrites like this:

http://www.amazon.co.uk/UF90B-Clip-...e=UTF8&qid=1417096082&sr=8-2&keywords=ferrite

I've been clipping them onto various household appliances that I know cause impulse spikes on the mains ring...like my boiler, fish tank heater etc. I've done this before to resolve an impulse noise issue I had with my Freeview signal.

I have put one on the low voltage side of routers power supply cable, but if ASUS's power brick is really that bad I might try putting a couple more on :D

Does anyone know off hand what supply voltage the ASUS router needs? We've got loads of random power bricks knocking about our lab in work...I'm sure I could find one that's the right spec to try out.
Click to expand...

I'm pretty sure they are 19V.
 
sga1111 said:
Ok guy's I moved the cables back in under 2 seconds what do you know....26901 Down CRC errors and a re-sync. I am sure this is the issue here, I am going to have words with ASUS now.
Click to expand...

Surely if it was the case that the power cable was causing excessive CRC's then mine would. The mains adaptor is just behind my Asus modem...
 
chriscatt said:
Surely if it was the case that the power cable was causing excessive CRC's then mine would. The mains adaptor is just behind my Asus modem...
Click to expand...

I'm not sure if it is that, but the adaptor is sending out pulses, you can hear it on an AM radio, I've tried it on other adapters in my home and you don't get the severe noise you do from this ASUS. Now it could be that is a bad batch, or it might not be the problem at all. I just found it improved when I moved the adaptor and crossed the cable. I am just trying to rule out these issues, as people have said its very random?
 
Anyone tried wrapping the power lead in tin foil?

Years ago I had to wrap a cheap TV co-ax cable in extra foil as I was getting cross interference from a VHS player until I could get a quality one.
 
Last edited:
simoncraddock said:
Anyone tried wrapping the power lead in tin foil?

Years ago I had to wrap a cheap TV co-ax cable in extra foil as I was getting cross interference from a VHS player until I could get a quality one.
Click to expand...

While this would help stop the interference coupling onto adjacent cables the noise will still be getting into the router. If the power supply is generating noise of a frequency that is close to or coincident with the VDSL signal, that noise could be doing very nasty things to the VDSL connection.

If the power supply is really noisy, it might also explain why ASUS is struggling to fix the problem. Chances are that any lab tests on the modem will be done with a lab power supply....Even if they do use a consumer supply, given that ASUS and MediaTek are Taiwanese, the power supply will be different to the UK one.

Having said that, constructing power supplies that produce noise that isn't in the operating band of the modem or wireless is pretty basic stuff for any RF product.
 
Unfortunately the RT-N66U power supply has a smaller connector on the end of the wire, so I wasn't able to swap them. I have however done what you've done as best as I can, have the shielded RJ11 cable go off in a different direction to the power cable.
 
sga1111 said:
I will e-mail Paul Lee at ASUS and see what he says. It's a shame it's different, have you found any improvement?
Click to expand...

So far, yes. I'm not getting a spam load of (in large quantities) CRC errors yet. Testing fastpath with 6dB SNRM target at 80Mbps. Usually I do get hundreds to thousands of CRC's within the first 10 minutes.

Code: 
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     0(0)
near-end path0 crc:     54(54)
near-end fec sec:       0(0)
near-end err sec:       25(25)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      0(250631)
far-end path0 crc:      0(1165)
far-end fec sec:        0(5345)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)
outDiscards=0
inDiscards=2
outBytes=16010244
inBytes=44472890
outPkts=47445
inPkts=40857
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.2 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=0
CRCDown=54
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=12 min, 11 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.4 dbm
PowerUp=4.4 dbm
AttainUp=26198
AttainDown=96244
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Early days, and I don't think I can maintain this connection with the error seconds I'm racking up (despite the small amount of CRC's), although I can force fastpath and up to 80Mbps and just ignore DLM on the downstream if I wish. I will most probably try a small delay (e.g. 4ms) to see if I can reduce the rate of error seconds slightly. This however is about normal for my connection at the moment.

EDIT 1:
Spike coming in, spoke too soon maybe. I'll apply a delay to the connection and see how FEC goes. Bear in mind however that I don't have a toroid ferrite on my wire at the moment.

Code: 
near-end path0 fec:     0(0)
near-end path0 crc:     1749(63)
near-end fec sec:       0(0)
near-end err sec:       37(29)
near-end ses sec:       5(5)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      101(250732)
far-end path0 crc:      0(1165)
far-end fec sec:        1(5346)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)

EDIT 2:
I'll give it a bit longer, maybe it was just a one off.
 
Last edited:
Ixel said:
So far, yes. I'm not getting a spam load of (in large quantities) CRC errors yet. Testing fastpath with 6dB SNRM target at 80Mbps. Usually I do get hundreds to thousands of CRC's within the first 10 minutes.

Code: 
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec:     0(0)
near-end path0 crc:     54(54)
near-end fec sec:       0(0)
near-end err sec:       25(25)
near-end ses sec:       0(0)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      0(250631)
far-end path0 crc:      0(1165)
far-end fec sec:        0(5345)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)
outDiscards=0
inDiscards=2
outBytes=16010244
inBytes=44472890
outPkts=47445
inPkts=40857
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1

lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.2 dB
AttenDown=10.3 dB
SNRMarginUp=6.7 dB
AttenUp=0.1 dB
DataRateDown=79999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=0
CRCDown=54
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=12 min, 11 secs
ADSLActiveTime=0 min, 19 secs
PowerDown=11.4 dbm
PowerUp=4.4 dbm
AttainUp=26198
AttainDown=96244
ShowtimeStart=19
TotalStart=19
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus

Early days, and I don't think I can maintain this connection with the error seconds I'm racking up (despite the small amount of CRC's), although I can force fastpath and up to 80Mbps and just ignore DLM on the downstream if I wish. I will most probably try a small delay (e.g. 4ms) to see if I can reduce the rate of error seconds slightly. This however is about normal for my connection at the moment.

EDIT 1:
Spike coming in, spoke too soon maybe. I'll apply a delay to the connection and see how FEC goes. Bear in mind however that I don't have a toroid ferrite on my wire at the moment.

Code: 
near-end path0 fec:     0(0)
near-end path0 crc:     1749(63)
near-end fec sec:       0(0)
near-end err sec:       37(29)
near-end ses sec:       5(5)
near-end los sec:       0(0)
near-end ua  sec:       0(0)
far-end path0 fec:      101(250732)
far-end path0 crc:      0(1165)
far-end fec sec:        1(5346)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)

EDIT 2:
I'll give it a bit longer, maybe it was just a one off.
Click to expand...

Interesting to see that! thanks for posting.

I don't either, gone back on to the openreach box as I can't stop all the errors and if it is a severe leak then we'll never stop it so we will still get bursts. I just find it interesting that they reduce. I have also tried twisting my DSL cable in a figure of 8 and that reduced mine further. I just think it's very coincidental, I might still be barking up the wrong tree 'who knows'. I have seen on a few forums they've had adaptor problems in the past with other products and a router. Could explain why some are suffering and some are not. Unfortunately I don't have an adaptor to try it and rule it out :(
 
sga1111 said:
Interesting to see that! thanks for posting.

I don't either, gone back on to the openreach box as I can't stop all the errors and if it is a severe leak then we'll never stop it so we will still get bursts. I just find it interesting that they reduce. I have also tried twisting my DSL cable in a figure of 8 and that reduced mine further. I just think it's very coincidental, I might still be barking up the wrong tree 'who knows'. I have seen on a few forums they've had adaptor problems in the past with other products and a router. Could explain why some are suffering and some are not. Unfortunately I don't have an adaptor to try it and rule it out :(
Click to expand...

I see.

So far no further spike yet, just the usual trickle of CRC's. I have a spare plug which I believe will fit this device, but that too could be subject to this noise problem (I don't have an AM radio to verify if mine are creating a similar amount of noise). The other plug is from the RT-AC68U and the connector looks identical so it should work I imagine. I might switch them if the bursts continue or the connection gets a loss of sync.
 
Yes it is, and suffice to say unfortunately I had some more spikes later on, didn't lose sync though. I've changed to INP 1 with 8ms delay. I'll swap the power supplies some point tomorrow when the internet usage is quiet here.

Code: 
near-end path0 fec:     0(0)
near-end path0 crc:     10535(110)
near-end fec sec:       0(0)
near-end err sec:       89(63)
near-end ses sec:       12(12)
near-end los sec:       0(0)
near-end ua  sec:       18(18)
far-end path0 fec:      614(251245)
far-end path0 crc:      0(1165)
far-end fec sec:        6(5351)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)
 
Ixel said:
Yes it is, and suffice to say unfortunately I had some more spikes later on, didn't lose sync though. I've changed to INP 1 with 8ms delay. I'll swap the power supplies some point tomorrow when the internet usage is quiet here.

Code: 
near-end path0 fec:     0(0)
near-end path0 crc:     10535(110)
near-end fec sec:       0(0)
near-end err sec:       89(63)
near-end ses sec:       12(12)
near-end los sec:       0(0)
near-end ua  sec:       18(18)
far-end path0 fec:      614(251245)
far-end path0 crc:      0(1165)
far-end fec sec:        6(5351)
far-end err sec:        0(970)
far-end ses sec:        0(0)
far-end los sec:        0(398)
far-end ua  sec:        0(18489)
Click to expand...

Ok be good to see what happens, looks like you have the same type of CRC spikes as I do, my record is 84507 until re-sync lol. I am going to chat with Paul Lee and look at some suppression to.
 
Power supply noise

I've moved my PSU as far as possible from the modem, and I've gained a tiny bit of downstream, but my upstream (which syncs at 19999) has gained lots of spare SNR margin - It went from around 7dB to 15dB
 
Last edited:
chriscatt said:
Another beta up version 2152 http://dlcdnet.asus.com/pub/ASUS/wireless/DSL-AC68U/FW_DSL_AC68U_30043762152beta.zip
Click to expand...

Changelog

ASUS DSL-AC68U Beta Firmware version 3.0.0.4.376_2152-gac64075 (This product supports both Annex A and Annex B)
1. DSL firmware updated - v1.0.2.0.
2. Fixed various UI related issues.
3. Fixed Diagnostic debug log failed to transmit in certain case issue.
4. Fixed previous firmware v3.0.0.4.376_2139 and beta v3.0.0.4.376_2144 Annex mode - Annex B/J/M failed to sync issue.
5. Annex mode - Annex B/J/M option now replaced with Annex B/J mode.
 
danivtec said:
Changelog

ASUS DSL-AC68U Beta Firmware version 3.0.0.4.376_2152-gac64075 (This product supports both Annex A and Annex B)
1. DSL firmware updated - v1.0.2.0.
2. Fixed various UI related issues.
3. Fixed Diagnostic debug log failed to transmit in certain case issue.
4. Fixed previous firmware v3.0.0.4.376_2139 and beta v3.0.0.4.376_2144 Annex mode - Annex B/J/M failed to sync issue.
5. Annex mode - Annex B/J/M option now replaced with Annex B/J mode.
Click to expand...

This is incredible. They're certainly being active with the firmware at the moment. I wonder if this will yield more improvements to the VDSL2 connection. If I can I will try it this afternoon and see what I get.
 
You must log in or register to reply here.
Back
Top Bottom