Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[waltergmw]

Can anyone offer any hints for getting around the " unsupported firmware version " problem illustrated below.
I.e. is there a work-around or special version of DMT that will "see" a Thompson rather than a Speedtouch ?
(I'm accessing the PC remotely using logmeon.com on an Apple Mac.)

Kind regards,
Walter

[attachment deleted by admin]

[kitz]

Yes - as long as its a correct chipset you can over-ride the DMT firware limitations.

To do so, the router must not be connected to DMT when you change it.

The setting is found under
Special >
Misc. Options >
Then in the "Firmware Specific" box >
Tick "allow untested firmware versions"

[waltergmw]

Thanks very much Kitz.

I was hoping to do it remotely but that's obviously not possible.

K R
Walter

[kitz]

You may be able to.

Open DMT on the remote machine - and then just make sure you change the setting before hitting the DMT connect button.

[waltergmw]

You're a genius Kitz - but then you knew that already !

Here's the result and I'm still in my dressing gown !

[attachment deleted by admin]

[attachment deleted by admin]

[kitz]

Is that by any chance that troublesome line that  you have?

Bit loading looks fine nothing much that I can see wrong there...  a couple of unused bins but thats quite common on a line that long when you get to it higher end frequencies... its actually looking very healthy.

It looks like the target SNR is set at 15dB - but difficult to say for certain since its been up a couple of days... but if so  a sync speed of 2624 is very good indeed and the physical line is looking ok. 

Without the high target SNR that line would be very good for its length...  so whats causing the high target SNR? 
I think you need to continue to monitor and graph the SNR Margin....  from what DMT has shown so far nothing I can see wrong with bit allocation at all... it is a bit low.. but again that will be due to the high target SNR.

[waltergmw]

Thanks Kitz,

There seems to be the occasional noise spike which I suspect is causing the problem. Here's a small one.
I also note a small night drop of about 1 dB but that shouldn't be too much of a problem.

Kind regards,
Walter



[attachment deleted by admin]

[kitz]

yep - the 1dB nightly drop is perfectly normal.

That slight noise spike at 8.45 - heating lighting etc switched on/off.

Even so most lines should be able to stand that - and that particular spike is still within acceptable parameters...  would take something a bit more than that to knock out that line.

From what Ive seen so far I still suspect random periodic noise burst which is whats causing it.  Its a case of 'catching it in action'.

-------
btw something that occurred to me - if youre monitoring that line remotely on DMT  - turn off some of the sound settings in DMTtool - or else your client at the other end will be hearing periodic ping and ding noises and may wonder what they are.   

[waltergmw]

Hi Kitz,

Thanks once again and even though my Laptop is in the spare attic bedroom, I've muted the speaker.

The general picture is one of very good stability, although there have been 3 single spikes down to about 11 dB during today.
This morning there were a few DMT reports of bit swopping.

Here's a typical start-up events data:-

Info    00:00:46 (since last boot)   xDSL linestate up (ITU-T G.992.1; downstream: 2720 kbit/s, upstream: 448 kbit/s; output Power Down: 18.0 dBm, Up: 12.5 dBm; line Attenuation Down: 55.0 dB, Up: 31.0 dB; snr Margin Down: 14.0 dB, Up: 16.0 dB)

There's been no sign of the noise storm yet which I suspect is the reason for dropping down to a bRAS of 500 kbps worst case which seemed to have happened in the small hours.

I noted last time I rebooted that a couple of the bins were brought back into service so perhaps I could try restarting the router.
I'll obviously drop my remote connection but it might just make it slightly better - or do you think that's too risky?

Otherwise, perhaps after waiting for another storm, and then experimenting with noise levels ?

Kind regards,
Walter

[attachment deleted by admin]

[kitz]

>> noise storm yet which I suspect is the reason for dropping down to a bRAS of 500 kbps worst case

I think youre correct in the assumption of what it will be.

>> that a couple of the bins were brought back into service so perhaps I could try restarting the router.

Probably not worth it - I'd try and keep the line as stable in an attempt to get rid of the 15dB target SNR that it appears to have picked up.

Because the target SNR is high, there not many bits being loaded into each bin - only about 3 or 4 at the high end.  After 620kHz  its only going to give you around another 12-16 kbps of sync speed per bin that is loaded.

[waltergmw]

Hi Kitz et al,

Not a storm but bad case of the droop ! I would much appreciate thoughts on this anomaly.

Kind regards,
Walter

Further inspection shows the noise margin has, at present (00-16 Sat 28 Feb), increased to 19 db but the sync speed has redced to 1472,
Althought the portal hasn't yet caught up, I suspect that the bRAS will be about 1,000

I'm still baffled as to what could cause such a phenomenon, but I've yet to establish if anything unusual was happening in the area.

[attachment deleted by admin]

[attachment deleted by admin]

[kitz]

hmmm   quick burst of noise..   that looks from that graph that it was recovering again before the router even had time to settle down after the resync.
If the stats are still like that now, then a resync is in order to get the speed back.

Before you do though - just on the offchance that its managed to record it  have a quick look at DMTtool it may show which frequencies have been affected by comparing it to the prev nights and seeing if theres any bins that now arent in use.  It may have all happened too quick for DMTtool to capture it too.

[waltergmw]

Hi Kitz,

Here are some pictures with hopefully sensible titles.

Kind regards,
Walter



[attachment deleted by admin]

[waltergmw]

Hi again Kitz,

Herewith the Sat night shots including a better bRAS.
The 585V7 shows v high FEC errors but I gather these figures can be tempramental.
I'm wondering what to do from here?
I see no reason that this cycle won't be repeated and the end user isn't too much of a techie.
The major problems are so relatively infrequent and others closeby and much further away
have rock solid performance that it seems unlikely (but not impossible) that it's an external REIN problem.
I have another new 585V7, an old DG834V2 and a new DG834V4 so could swop
to see if it's an intermittent problem at our end.
However I don't know how to persuade BT O to change a line card which could be another option.

Kind regards,
Walter

[attachment deleted by admin]

[kitz]

Comparing the 'brefore reset' with your graph you first posted in this thread..  it looks like bit allocation was affected across all bins..  which would seem to indicate that what ever took the connection out was affecting the whole downstream frequency range. 
Even some of the latter upstream frequencies would appear to be affected (bit hard to tell for sure because of the spectral mask that is applied to frequencies in that range but it looks steeper?).

Having seen the bit allocation afterwards Im pretty sure its electromagnetic interference.
The distinct drop in bit loading certainly looks like a large noise problem somewhere..  I was hoping that it may show a particular range which would perhaps make tracking it down a lil bit easier..  but its all across the board.  Some sort of power surge/static... could be anything that causes it

>> new DG834V4

May be worth giving that one a go - different chipset to see if it can cope with the bit allocation a lil bit better.. but I dont expect miracles..  if it is a large noise burst it will probably take that out too at some point.

>> BT O to change a line card

I dont think it is the line card - not to cause those symptoms.