Soldato
Yes lets just hope they are determined to fix this. My CRC's down are 139, 0 up after six days but only on a 40mb connection.
Last edited:
Anyone Using an Asus DSL-AC68U
- Thread starter Socrates470BC
- Start date
I have gone back to my ECI modem for the time being, CRC errors were in the 100,000's in less than 24 hours.
Although it syncs higher than the ECI modem the stability isn't there.
Hopefully this will get resolved soon with the amount of updates ASUS are pumping out.
Although it syncs higher than the ECI modem the stability isn't there.
Hopefully this will get resolved soon with the amount of updates ASUS are pumping out.
I have 1 crc up error on the new Beta 2152 (just after 10 mins normally it would be thousands) - I know they're trying as I've sent diagnostics at the request of Paul Lee.
Ixel*?
Unfortunately I don't have direct contact with any particular person at ASUS at the moment, so am relying on forum posts and sharing my findings here. I'll be installing the latest beta firmware in the next hour or so.
Are you actively uploading in that period?
Just wondering if you upload big files whether your count rises a lot?
I am streaming on netflix as we type, my current stats are: 31 mins CRC's Down: 11 Up: 2, looks promising, but we will see later as normally the evenings are a nightmare.
2152 beta:
Most likely will need to reduce my speed or enable a small amount of error correction, but I'm most interested in seeing if I get any spikes.
Code:
>tcapi get Info_Adsl lineState;wan vdsl2 show mgcnt;tcapi show Info_Adsl
up
near-end path0 fec: 0(207)
near-end path0 crc: 62(40)
near-end fec sec: 0(2)
near-end err sec: 26(25)
near-end ses sec: 1(1)
near-end los sec: 0(0)
near-end ua sec: 0(29)
far-end path0 fec: 69(256234)
far-end path0 crc: 0(1165)
far-end fec sec: 2(5436)
far-end err sec: 0(970)
far-end ses sec: 0(0)
far-end los sec: 0(407)
far-end ua sec: 0(19378)
outDiscards=0
inDiscards=13
outBytes=12714253
inBytes=4016686
outPkts=33356
inPkts=17212
fwVer= FwVer:5.5.1.125_B_A60901 HwVer:T14.F7_0.1
lineState=up
Opmode=ITU G.993.2(VDSL2)
SNRMarginDown=6.1 dB
AttenDown=10.3 dB
SNRMarginUp=6.8 dB
AttenUp=0.1 dB
DataRateDown=79999 kbps
DataRateUp=19999 kbps
WanListMode=1
FECDown=0
FECUp=69
CRCDown=62
CRCUp=0
HECDown=0
HECUp=0
ADSLUpTime=13 min, 25 secs
ADSLActiveTime=0 min, 18 secs
PowerDown=11.6 dbm
PowerUp=4.5 dbm
AttainUp=26191
AttainDown=95712
ShowtimeStart=18
TotalStart=37
ATURANSIRev=0
ATUCANSIRev=0
ATURANSIStd=0
ATUCANSIStd=0
InterleaveDepth=1
AdslStandard=VDSL2
AdslType=ANNEX_B
mtenStandard=G.dmt.bisplus (Annex L)Most likely will need to reduce my speed or enable a small amount of error correction, but I'm most interested in seeing if I get any spikes.
Why you set Annex B/L? Have you seen anything different than Annex B?
I didn't notice that, I did set everything to default and just made it so I specified my max sync rate and error correction manually. Possibly it's caused by annex being set to A/I/J/L/M - I will set it back to A. It probably isn't the cause of my instability however, but I am finding this firmware so far to be worse than 2144.
Associate
- Joined
- 27 Oct 2014
- Posts
- 28
Seems slightly worse than 2144 for me too - More CRCs, although possibly a few less FECs
I have adsl. I told that because when I set mannual annex a/l the web interface responds annex a and the telnet responds
Code:
AdslType=ANNEX_A
mtenStandard=G.dmt.bisplus (Annex L)When I set annex A, both respond annex a. Here, http://en.wikipedia.org/wiki/G.992.3_Annex_L I see that annex L goes above 552kHz, which I think in my connection is wrong because in spectrum I see frequences above 1100kHz. Moreover, I think annex L is only for adsl connections and not vdsl.
I'm going to stay on DLM's settings for the moment to see what kind of FEC count I end up with, at least for the next 12-24 hours anyway. However, I have a feeling 2152 has gone back a step in progress compared to 2144.
EDIT 1:
While on this specific configuration I'm also submitting a diagnostic log, hoping it will help towards a fix.
EDIT 1:
While on this specific configuration I'm also submitting a diagnostic log, hoping it will help towards a fix.
Last edited:
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
Deleted.
PSU Noise + Rant
Well, I didn't have much luck finding a supply with the same connector....Found loads of 18-20V supplies though. I thought the best way to see if the power supply was noisy would be to hook it up to a scope and have a look.
I didn't have much time to do a thorough test so I'm a little reticent about drawing any conclusions at the moment but this is a quick summary:
I did a quick check of the DC level with a DVM just to make sure that it was outputting roughly to spec. My PSU outputs at 19.5V so within typical manufacturing tolerances. Next I hooked the supply up to the scope to look for any frequency content on the output. At this point the supply is unloaded so it's not having to do any work:
This is a switched mode supply so as expected there is a bit of periodic spiking on the PSU, but the spikes are very small at only 25mVpp. The spikes are about 5ms apart.
Next I put a power resistor across the output. I only had access to 5ish Watt resistors so I was a bit limited on how much load I could use. I chose 47Ohms, which equates to about 400mA. Not really stressing the supply, but better than nothing:
The noise does get a bit bigger at this point, the spikes are about 45mVpp and the density of the spikes increases...they're now only 33us apart. I'm not familiar with switched mode power supply design, but it's not surprising to see the frequency increase with load.
Noise of 45mVpp on the external supply doesn't sound that bad to me. Even if there was no further supply conditioning, the supply voltage of the chip will be in the 1.8-3.3V range....so it's at least divided by 5.75 before it hits any of the chips.
I guess the question is, at a normal load (whatever that is), does the noise get worse and is the frequency content in the same band as the VDSL signal? This going to be a bit difficult to test since a resistor isn't really representative of the load that the router will present. Ideally I would build a breakout cable so that I could test PSU while the router is running...However, since I don't have a VDSL connection at work, I'd still not quite be getting something fully representative. I guess if I could rig something up it might be interesting to see what it looked like. It would also be good to FFT the time domain capture to see if there's any frequency content that could interfere with the VDSL.
I'm quite curious to find out if the PSU is the problem, but measuring the PSU output is only part of the equation...I would hope that the router contains suitable power conditioning circuits to filter out any potentially problematic noise.
[/rant]
The thing that's really bothering me about this router is that I seem to be pouring more and more time into debugging a product which really should just work out of the box. Having paid £200 for what is supposed to be a high end router, the fact that I'm even considering taking it to work to debug problem that ASUS clearly are struggling with is quite ridiculous. It's probably burned more than £200 worth of my time already and frankly I think ASUS's lack of a proper statement or timescale for fixing this issue is inexcusable.
I found this BT VDSL testing document on the web and having skimmed through it, I'm quite surprised that the modem got approval to go to market at all. The testing document is quite thorough and it's hard to see how the modem would have passed most of the tests given the performance we're all seeing.
[/rant]
Well, I didn't have much luck finding a supply with the same connector....Found loads of 18-20V supplies though. I thought the best way to see if the power supply was noisy would be to hook it up to a scope and have a look.
I didn't have much time to do a thorough test so I'm a little reticent about drawing any conclusions at the moment but this is a quick summary:
I did a quick check of the DC level with a DVM just to make sure that it was outputting roughly to spec. My PSU outputs at 19.5V so within typical manufacturing tolerances. Next I hooked the supply up to the scope to look for any frequency content on the output. At this point the supply is unloaded so it's not having to do any work:
This is a switched mode supply so as expected there is a bit of periodic spiking on the PSU, but the spikes are very small at only 25mVpp. The spikes are about 5ms apart.
Next I put a power resistor across the output. I only had access to 5ish Watt resistors so I was a bit limited on how much load I could use. I chose 47Ohms, which equates to about 400mA. Not really stressing the supply, but better than nothing:
The noise does get a bit bigger at this point, the spikes are about 45mVpp and the density of the spikes increases...they're now only 33us apart. I'm not familiar with switched mode power supply design, but it's not surprising to see the frequency increase with load.
Noise of 45mVpp on the external supply doesn't sound that bad to me. Even if there was no further supply conditioning, the supply voltage of the chip will be in the 1.8-3.3V range....so it's at least divided by 5.75 before it hits any of the chips.
I guess the question is, at a normal load (whatever that is), does the noise get worse and is the frequency content in the same band as the VDSL signal? This going to be a bit difficult to test since a resistor isn't really representative of the load that the router will present. Ideally I would build a breakout cable so that I could test PSU while the router is running...However, since I don't have a VDSL connection at work, I'd still not quite be getting something fully representative. I guess if I could rig something up it might be interesting to see what it looked like. It would also be good to FFT the time domain capture to see if there's any frequency content that could interfere with the VDSL.
I'm quite curious to find out if the PSU is the problem, but measuring the PSU output is only part of the equation...I would hope that the router contains suitable power conditioning circuits to filter out any potentially problematic noise.
[/rant]
The thing that's really bothering me about this router is that I seem to be pouring more and more time into debugging a product which really should just work out of the box. Having paid £200 for what is supposed to be a high end router, the fact that I'm even considering taking it to work to debug problem that ASUS clearly are struggling with is quite ridiculous. It's probably burned more than £200 worth of my time already and frankly I think ASUS's lack of a proper statement or timescale for fixing this issue is inexcusable.
I found this BT VDSL testing document on the web and having skimmed through it, I'm quite surprised that the modem got approval to go to market at all. The testing document is quite thorough and it's hard to see how the modem would have passed most of the tests given the performance we're all seeing.
[/rant]
Last edited:
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
Before I returned mine to PC World this was one of the things I looked at and documented in my evidence of being 'unfit for purpose'.
1. The ASUS isn't recommended by BT nor any UK ISP.
2. I couldn't find any regulation stating to sell a ADSL/VDSL modem in the UK it has to be approved for BT, just certain EU/INT standards.
3. PC World list it as 'For fibre optic broadband such as BT Infinity', note the 'such as BT' implies compatibility yet it's not approved.
Last edited:
I am pretty much at the point where I think returning it is inevitable. My wife is quite keen on getting rid anyway....she keeps referring to it as an angry space invader! I don't know how much persuading BroadbandBuyer will need to accept a return. They've always been very good in the past, but I've never had to return a 'working' product after this amount of time (3 months for me).
Associate
- Joined
- 8 Oct 2014
- Posts
- 181
The Sale of Goods Act says that your purchase must be fit for purpose.
"It must be as described. It must be of satisfactory quality, sufficiently durable, free from any defects"
For the first six months, you are entitled to replacement or repair of the goods. It is up to the retailer to prove there was nothing wrong with it if they wish to get out of having to do the work. And then after six months, there is still a duty to replace or repair faulty goods, but the onus is on you, the consumer, to prove that there was something wrong.
Proving there is something wrong with this device is right here and other forums. Replacing it with another device is their only real course of action as they all have the same fault unless you drop on lucky with a refund like I did with PC World.
Last edited:
[/rant]
The thing that's really bothering me about this router is that I seem to be pouring more and more time into debugging a product which really should just work out of the box. Having paid £200 for what is supposed to be a high end router, the fact that I'm even considering taking it to work to debug problem that ASUS clearly are struggling with is quite ridiculous. It's probably burned more than £200 worth of my time already and frankly I think ASUS's lack of a proper statement or timescale for fixing this issue is inexcusable.
I totally agree with you!!
The thing that's really bothering me about this router is that I seem to be pouring more and more time into debugging a product which really should just work out of the box. Having paid £200 for what is supposed to be a high end router, the fact that I'm even considering taking it to work to debug problem that ASUS clearly are struggling with is quite ridiculous. It's probably burned more than £200 worth of my time already and frankly I think ASUS's lack of a proper statement or timescale for fixing this issue is inexcusable.
I totally agree with you!!