Print

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

[les-70]

  Many thanks for looking, it looks promising but I can't get a sync. I made the advised changes and checked annex m was enabled -- all looked ready to go.  I set the HG612 ATM to 0 38 PPP0A VCMUX, I left the service type UBR without PCR. No change on PTM. In WAN, selected the atm and gave name/password. Just tries to sync then fails. I will try again this evening!

 I notice the setting is lost on reboot.

  p.s.  Having successfully add serial port pins to an ECI and unlocking it, I thought I  would try the port on an HG612.  I can only get odd garbage characters off the HG612. If there anything subtle about the port settings or may I just have a bad solder job?

[asbokid]

  Many thanks for looking, it looks promising but I can't get a sync. I made the advised changes and checked annex m was enabled -- all looked ready to go.  I set the HG612 ATM to 0 38 PPP0A VCMUX, I left the service type UBR without PCR. No change on PTM. In WAN, selected the atm and gave name/password. Just tries to sync then fails. I will try again this evening!  I notice the setting is lost on reboot.

That's annoying.    If you've made any changes through the web GUI, that will probably reset the DSL configuration options and disable Annex M again.

p.s.  Having successfully add serial port pins to an ECI and unlocking it, I thought I  would try the port on an HG612.  I can only get odd garbage characters off the HG612. If there anything subtle about the port settings or may I just have a bad solder job?

Can't think of any reason for that, if you are sure that the soldering and cable is sound, and the terminal software and serial port parameters are configured okay (115200 8n1).  I've re-populated UART/JTAG pins on four HG612s so far. All work okay. The ground thru-hole was a pain on a couple of them, not being drilled out fully.  But other than that there were no problems. Maybe check the pin continuity, especially GND.

cheers, a

[les-70]

 Still no luck getting a sync with Annex m.  I have been checking with "xdslcmd profile --show" that all is ready before each try so GUI edits should not have been a problem. I looked over your "wordpress" adsl example with the HG612. The only difference I can see is that you had the dialing method as manual when I had auto.  I could try that later but I don't think it relevant.

  p.s. I will try the HG612 again.  I did check pins voltages and had 3.3 on RX and 0.0 TX w.r.t. GND. I will resolder the TX as I think the 3.3 suggests that the other two are OK

[asbokid]

Still no luck getting a sync with Annex m.  I have been checking with "xdslcmd profile --show" that all is ready before each try so GUI edits should not have been a problem. I looked over your "wordpress" adsl example with the HG612. The only difference I can see is that you had the dialing method as manual when I had auto.  I could try that later but I don't think it relevant.

This Huawei is configured for "Auto" dialling mode, too.



TalkTalk (Business) will apparently supply Annex M now [1] so there might be a chance to try it on this line. Not holding out much hope. According to TDR, the exchange is around 1600 metres, perhaps too far to get much gain from it.

p.s. I will try the HG612 again.  I did check pins voltages and had 3.3 on RX and 0.0 TX w.r.t. GND. I will resolder the TX as I think the 3.3 suggests that the other two are OK

Are you using the same (known good) serial cable that you used with the ECI? Maybe see what is shown on a scope trace. At boot, the Huawei dumps its log over the serial port, so that should always be visible.

cheers, a

[1] http://www.talktalkbusiness.co.uk/about-us/news/video-news/partner-bb--annex-m/

[les-70]

  I tried re-soldering and there is no difference, just an erratic character echo with odd bad characters. Once garbage appeared on reboot but that is not consistent in appearing .  I wonder over my clearing out well with a 1mm drill, maybe I removed more than I intended. I assume that I only need the tx/rx/gnd row of header pins or is lack of hardware control my problem?   Later in the week or at the weekend I will try very carefully from scratch on a 2nd HG612 that I got the other week.  They are occasionally very cheap on ebay.

 I will be interested in how you get on with TalkTalk.  I am with them on annex m as an ex Nildram customer and they say they don't do it for their own customers.  They do provide it for resellers and their DSLAMs, like most, support it.   Judging by your stats I would guess that you would loose 1M down and get about 1.8 to 1.9 in total up.  The up speed is very router dependent.

 Good to see your TDR, like me you look to have quite a bit of cable junction and cable impedance changes in the first 800m.  I am going to look at traces on neighbours connections before pronouncing on mine.

   Many thanks for the help

[les-70]

No problems getting the  UART/JTAG pins to work on the second HG612  .  As you warned the GND needed drilling, but I avoided it on the other pins. After all the trouble playing with the last one, this time it seemed too easy!!   I tried Annex M again but still no luck - just long sets of green led flashes trying to sync. 

[asbokid]

  I tried re-soldering and there is no difference, just an erratic character echo with odd bad characters. Once garbage appeared on reboot but that is not consistent in appearing.  I wonder over my clearing out well with a 1mm drill, maybe I removed more than I intended. I assume that I only need the tx/rx/gnd row of header pins or is lack of hardware control my problem?

No worries about hardware control. Maybe pull off a ground somewhere else if the track has gotten broken?

I just re-populated the UART and JTAG pins on an ECI board.  Heck, that took a long while! God knows what solder they used because it needed a huge amount of heat. In the end with a hot air gun. Hopefully it hasn't fried anything.

Later in the week or at the weekend I will try very carefully from scratch on a 2nd HG612 that I got the other week.  They are occasionally very cheap on ebay.

 I will be interested in how you get on with TalkTalk.  I am with them on Annex M as an ex Nildram customer and they say they don't do it for their own customers.  They do provide it for resellers and their DSLAMs, like most, support it.   

Aha! Thank you! So it's not clear cut that Annex M is even available.  And the TalkTalk advert sounded so promising. When I asked them they promised that Sales would call back with a price.

Judging by your stats I would guess that you would lose 1M down and get about 1.8 to 1.9 in total up.  The up speed is very router dependent. Good to see your TDR, like me you look to have quite a bit of cable junction and cable impedance changes in the first 800m.  I am going to look at traces on neighbours connections before pronouncing on mine.

This isn't the best line. Seems to work okay though. TDR has revealed the distances to all the main 'features', but no clues yet where the cabinet can be found.  Must be out there somewhere.  Perhaps an advert in the newsagent window...   "MISSING!  SMALL GREEN PCP.  OLD BUT MUCH LOVED.  ANSWERS TO TDR PINGS.  ANY INFO PLEASE CALL 100"


cheers, a

[les-70]

 Thanks for the helpful advice.  I am afraid that to avoid it bugging me I removed the header pins from the first HG612 and put a "uart/jtag output RIP" notice on the back of it.  With all working on the second I am content with that. 

  Good luck with TalkTalk and please do advise of the outcome.

 You may well have seen my TDR traces ( http://forum.kitz.co.uk/index.php/topic,11309.0.html ).  I was amazed but comforted to find my neighbours traces were just the same with only distance changes.   I wonder on whether one of the TDR features shown there gives a possible clue to my Hlog dips.

[kitz]

At the risk of sounding stupid, because I came in late on this.... and since asbokid knows his stuff, I kept out until now..

But can I just clarify what you meant about the hump in hlog graph?
If you mean the curves that are showing before and after tone 255ish..  this can be indicative of 'normal' crosstalk at the MSAN.

For eg the MSAN could have lots of lines on adsl 1 (using < tone 255) some of those may be very long lines and therefore not using the full tones available for adsl1.  As you reach tones for adsl2+ (>255) then theres not as many users using these frequencies so you see a slight increase in performance again.

[les-70]

Thanks for the thought.  Your correct that there is most likely a change in cross talk at the adsl junction adsl2+.  That is probably what is seen in QLN attached (I am surprised so many look to be left on adsl?).  I don't however think the Hlog should be influenced visually by noise, including cross talk, unless the SNR at those frequencies is very low - it is not. see attached SNR.  The dips occurred suddenly when Openreach were doing work in two places. One a DSLAM move in the exchange. i.e. moving the LLU DSLAM to different part of the building.  The other work was along my route to the CAB.  The DSLAM work was associated with no broadband overnight .  The street work came with no phone or broadband for a short period.  The dips also came with a permanent loss of about 2Mb/sec in sync - not a disaster but an annoyance. Possible dip places are marked in the HLOG plot which come from the TDR post noted in my previous reply.

   I am not expecting to get anything changed but to be prepared to try should another issue arise.  They seem to like disconnecting me at the CAB -- 3 times in the last 4 years, so another issue would not surprise me.

   

[asbokid]

  Good luck with TalkTalk and please do advise of the outcome.

Thank you for contacting the Talk Talk Business Customer Services team.

I can confirm that Talk Talk Business do not supply Annex M.

Kind regards,
TalkTalk Business Customer Services

 

cheers, a

[asbokid]

Just jibbering here really,  but it struck me that perhaps the HG612 isn't sync'ing in ADSL2+ Annex M mode because of an incompatible upstream transmit spectral mask.

Suitable PSD masks for the BT and Kingston networks are listed in what is called the Access Network Frequency Plan (ANFP), a Plan laid down by Ofcom.  Maybe the Huawei, by default, is using a mask that is incompatible with that Plan? And consequently the DSLAM is refusing to synchronise with the CPE modem in ADSL2+ Annex M mode?

The Ofcom Guidelines for the ANFP Plan are found at [1]. Similar documentation on Annex M PSD masks, in respect of the Frequency Plan for the Australian telephone network, can be found at [2]

The DSLAM, now homed under Our Wayne's bed, could be coerced into accepting an Annex M connection. And hopefully with the best sync speed possible, given the local loop length of just 3 metres!  At [3] is the CLI documentation for tweaking the Huawei MA5616 mini-DSLAM for different DSL connection modes, including ADSL2+ Annex M.

Whether the PSD Masks used by the HG612 (and similar Broadcom-chipset CPE) can actually be modified from userspace via a telnet shell doesn't seem to be publicly documented.

The ANFP Guidelines for the UK list five different upstream transmit PSD masks for ADSL2+ Annex M.   The Ozzie Plan lists a total of nine masks.  The mask is chosen according to the subscriber's loop length.    The loop length is presumably determined from measurements observed at DSL initialisation, rather than from any network infrastructure records of physical loop length.  As shown in the diagram below, the five ADSL2+ Annex M PSD masks used in the UK are labelled ushort, eshort, short, medium and long.

The equations for calculating a PSD mask are based on just a handful of constants (for frequency cut-off points, etc.)   Those constants are possibly all that is stored in the CPE, and from which the upstream transmit mask is constructed.

The documents above all reference the ITU-T G.992.3 Recommendations found here [4]

Maybe something interesting there for others?!

cheers, a

[1] http://www.niccstandards.org.uk/files/current/ND1405V3.1.2.pdf?type=pdf
[2] http://www.commsalliance.com.au/..ADSL_Annex_M_NonDeploymentClassSystems_21Feb06.pdf
[3] http://docs.google.com/open?id=0B6wW18mYsk...
[4] http://www.itu.int/rec/T-REC-G.992.3/en