Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: les-70 on January 09, 2014, 10:55:30 AM
-
In case it is of some interest I thought I would post on progress with a new FTTC connection and related testing. The connection is the first on the cabinet so I expect it to start good and then suffer increasing cross-talk.
The install (I have mentioned most of this in a related post but put it here as the starting point.)
An Openreach engineer came last Friday pm and seemed very capable. He installed the filter and ECI modem, did work at the cabinet called the exchange a few times, and tested the sync etc but was not interested in the strange actual download speeds resulting. In spite of a 80/20 sync throughput varied between 1 and 74mb/s :( this continued over the weekend and 1mb/s occurred quite often.
On the following Monday an email re another engineer visit came. I phoned TalkTalk Business and I discovered that Openreach denied that I had had an install and denied that I am or can be connected to FTTC. After a couple more calls to TTB technical support they finally agreed that Openreach must be wrong and TTB think the engineer may have omitted to sign the job off! Just before the engineer finished at 16:30 the poor engineer had a phone call sending him some 50 miles and was not pleased - I guess this relates to his possible omission. The lack of that sign off seems to mean that TTB can't control my connection, they can detect it but most info is just missing apart from the PPOE login and identifying the connection as FTTC. Late on Monday the connection suddenly started to work as it should with a 72 -75 mb/s download each time tested :) - I guess something was done somewhere.
However the saga continued through the week with Openreach finally admitting that I am connected on the Wednesday when an install was done next door. Openreach now on the Thursday say they will "complete" the order today! I will update as this happens or does not............ I am told it has completed a week later to the hour however technical support are still unable to control setting related to my account - I suspect a continuing saga!!
Interestingly I am told that the DLM initialization does not start till it is signed off. You never know what is really true when your told these things but it suggests that in principle it could be turned off.
I hope nothing else goes wrong!!
-
QLN noise as the only FTTC connection and then with just next door as well
The impact of just one other connection was a shock to me :'( and dropped my attainable from 107 to 93 Mb/s and the snrm dropped from 14 to 10. Makes BT wholesale estimate of 80/20 for my line most unlikely as it would not take much more of this to take the snrm below 6. I have long believed that I have a section of split pair but then again maybe this the reality of an just an average connection. I attach the qln before and after my neighbor was connected. It is interesting to flash between them to see the exact change that a single other connection causes. For info the HG612 latest blob 038 and the HG622 on Blob 033 both show qln and hlog for the upstream tones as well.
-
Looking at the tones between 1200 - 1950, I prefer the second graph rather than the first!
Regarding the acronym "blob". As used within the context of the Huawei HG612 firmware image, the term should be Binary BLOB (http://en.wikipedia.org/wiki/Binary_blob). I will go even further and state that most persons making reference to a "blob" really should have used the phrase "firmware image".
-
Have a look at the matching snr and see if you like that! Most of the loss of spikes is to be expected if the cross talk signature is fairly smooth but I am also puzzled why some spikes don't still show. The change in qln is an overall ratio of about 2.5 in power level. Assuming the cross-talk on different lines is incoherent with each other I reckon about another similar 6 connections will get me to 6db at 80Mb/s. I take comfort in it needing (I think!!!) about 40 similar lines to reduce the sync to 60mb/s. That would be more than enough do me fine as to be honest I never found much wrong with my old asdl2 speeds - just could not resist a new thing to play with!
( I hope the cross-talk is incoherent between lines or the effect is much worse - no square root if remember correctly - if coherent its 2-3 more connection to 6db at 80 and only 6 more to 60)
-
Thank you for posting those corresponding SNR graphs.
As you say, the effect is clear to see. :(
-
to les-70, my line had similiar affects from 2 seperate single installs, I also suspected a split pair. In private conversations with asbo he suggested to me tho that a split pair is very unlikely. I have never managed to get a *'permanent' pair swap so I am still on the same pair. But in my area there is supposedbly a fault on the tie pairs on my cabinet.
Also like yourself my crosstalk is most brutal on the lower tones, some other guys on here have commented that seems odd to them as they expect more crosstalk on weaker tones but your line mirrors mine with the effect (except yours is currently much less severe than mine).
* - reference permanent, I had a visit where my drop wire was replaced, I dont know if they also did a new pair on D side but I think they did and my sync went from around 71mbit to an attainable of around 120. However it was temporary as the head openreach guy for my area overuled the engineer telling him to put my original wires back in place.
To barakkucat you seem knowledgable but never reply to my problem threads :(
-
To barakkucat you seem knowledgable but never reply to my problem threads :(
:paperbag: b*cat hides.
-
Chrysalis Yes I also expected more cross talk at the higher frequencies. However I assume that the cross talk is attenuated much like the main vdsl signal and after attenuation the higher frequency cross talk is currently smaller than the noise floor with no cross talk. At least on my and from the sound of it your connection,
-
that was how I always seen it also, but others see it a different way.
another theory was that my line was getting crosstalk from a longer line which only used the lower tones but I doubt that would be the situation with your neighbour.
-
I believe a third line has now been enabled. The second one (taking mine as first) gave a 4db snrm drop and the third a 1.5 db drop. As mentioned above I hope each subsequent drop gets smaller but they will vary in impact according to where they are. Latest snr and qln attached. I will wait until a few more seem to have connected before I post an update on this.
-
I happened to have TBB quality meter running when for while I put in the supplied ECI modem and noticed a difference in the TBB QM with it.
I also have a unlocked ECI , that showed a snrm reduction of 3db compared with the HG612 - it does not encourage to me use it.
The connection was being used quiet heavily at times. The trace has the HG622 up till 10.00 ish, then the ECI until about 14:30. After that it is the HG612 with gaps later on when the router, and not the HG612 had reboots.
I notice no dropped packets with the HG612, just few with the HG622 and a lot more drops with the ECI. I am sure that it maters but it puts me more off the ECI.
-
. . . no dropped packets with the HG612, just few with the HG622 and a lot more drops with the ECI.
Perhaps I am interpreting the TTB "wotsit" incorrectly but I would have said no dropped packets with the HG622, a few with the HG612 but many dropped packets when the ECI B-FOCuS modem was deployed. :-\
-
are you on a huawei cabinet?
-
It is an ECI cabinet hence my puzzling over the poor ECI modem performance. Second I apologize for the small tbb qm picture, here is link to the bigger version.
http://www.thinkbroadband.com/ping/share-large/73b85c4f3f4211b86082544dae641047-08-01-2014.png
On the graph I think the red down is dropped packets and the up spikes are just slow pings due to the connection being busy. ISP congestion tend to raise the whole green and blue floor.
As mentioned above after 14:30 there are two red block due to router reboots. Note that the HG622 loss up to 10:00 is so small it is hard to see and it has some excuse for loosing a few as it is acting as both modem and router.
-
For todays extra I turned off last night and applied my 301c to get a TDR.
At the install I asked the engineer if he could do a TDR and his JDSU tester. He reported in his words "two potential issues are raised by tester" which he said "given the sync speed - did
not matter" and confirming Walters comment else where added "we can't open up all the junction boxes with potential issues unless there is major problem". I suspect I may have got a
more sympathetic response had all the eventual cross talk also been present.
I attach the TDR results before and after FTTC. The one before has distances indicated on it both in the trace and my estimate of the actual distances to features. The tester is
not calibrated and my distances may be off a bit. There is no significant change in the traces apart from the loss of what I thought was the exchange, as it should with FTTC.
It looks like the cab is a bit nearer than I thought if that is the final feature with FTTC. The other features between me and the cabinet can't be good and may be splits or bridged taps or just bad joints and gauge changes.
-
@ Les,
1. Re the 301c, I'm interested that your trace shows a significant blip at the point you suspect is the PCP.
All the ones I've observed show very little change in the trace.
Have you confirmed your FTTC position by seeing the "Beacon" jumping up and down at that distance ?
2. We have now recorded three instances, albeit on the same ECI FTTC, where there has been a significant increase on very poorly performing VDSL lines if the ECI modem is replaced with a currently-upgraded HG612.
Kind regards,
Walter
-
Thanks for that Walter, the blip is about 50m sooner than my most optimistic estimate of the CAB distance and previously with adsl I had attributed it to the end of a gauge change, split pair, bad joint, or less likely a bridged tap. Maybe I also have very little trace of the cabinets and my previous adsl based view is correct.
I did not notice any movement on the TDR trace but I am quite ignorant of beacons and even that they were there. I would be prepared to pay for an SFI visit if I really thought that I would get a professional and carefully check and possible fixes made. I am not keen on paying and being told its fine.
I am using a HG612, as noted above it seems to do better in speed or currently at 80/20 in srnm, but also if you look at the ping plots using TBB BQM above, in packet loss. i.e. the ECI modem seems to loose packets, I tried two one unlocked and one locked - both the same. The HG612 does not loose any.
-
Regarding the MSAN "beacon". It is very characteristic and once seen is never forgotten.
Granted I have only seen it on lines connected to Huawei MSANs (for that is all to which I have access) but it is an upward "blip" that appears and disappears at a frequency of approximately 0.5 Hz. ("Now you see me, now you don't.")
I was told that a decision was made to enable the "beacon" so that the most new recruit (or numpty subcontractor) could easily identify and thus determine the pair length to, the MSAN. :)
-
Had another look at the TDR but this time via the vdsl output of the face plate and not into the test socket. I am assuming that will make little difference. It certainly gives the same trace and no many how long I look the only movement is what I would call an odd tiny 1 "display bit" changes. Assuming any beacons are intended to be clear there seem to be none on or enabled in my ECI cab.
Had what I think is another connection join the party but the impact of each successive connection seems to be dropping. That may however just be luck depending on where connections are located relative to me. Successive snrm drops have been 4.2,1.4, and 0.4 so far and consistent with each 1db drop matching a 4Mb/s drop in attainable speed. I tried setting a few max down load sync speeds ( e.g. xdslcmd configure --maxDataRate 64000 16000 80000) on the HG612- 038 and deduce that things drop like 4Mb/s per db snrm provided all tones are in use and by about half that i.e. 2Mb/s per db if about half the tones have bits. That seems consistent with the adsl2 being about 0.5 Mb/s per db on a fair connection. So far the DLM seems to have tolerated these tests but I won't push my luck with more mucking about for bit.
-
the maxdatarate syntax what does the 3rd value do?
-
Had another look at the TDR but this time via the vdsl output of the face plate and not into the test socket. I am assuming that will make little difference. It certainly gives the same trace and no many how long I look the only movement is what I would call an odd tiny 1 "display bit" changes. Assuming any beacons are intended to be clear there seem to be none on or enabled in my ECI cab.
That is interesting. I wonder if the "beacon" was turned off during the recent MSAN firmware update? Perhaps Walter might be able to "take a look" at an Ewhurstian VDSL2 service, connected via an ECI cabinet?
-
@Chrysalis It called the maxaggregate and I guess that is what it is. I have always used to sum of other two values for it hence xdslcmd configure --maxDataRate 64000 16000 80000. It won't make you faster but if used in moderation may get fast path back or it may break the DLM!!! I would not advise setting value that would upset you too much if the DLM then capped you at that value. The DLM does not seem to have noticed my experiments with it - but!!!
-
I think I am at the end of the training period and no DLM intervention below 80/20 fast path has occurred or probably needed to occur. I had recently in any case capped myself to help it ignore me.
Recently I got out a twisted pair dsl lead -- previously with adsl2 it made no difference that I could detect. It is much the same with the VDSL but at an exactly fixed sync the SNR does increase by 0.1 to 0.2 db. I have changed two and fro twice and each time had a delta or 0.1 or 0.2 up/down and always best with the twisted lead. I am leaving it in place but it is a very small improvement. I guess if the cables runs near some noisy things you might see a bigger change.
-
The details are hazy in my mind but asbo once wrote about it being important for the faceplate > modem cable characteristics to match the lead in to minimise signal loss back up the cable from when it hits the different wire. Can't remember all the tecknical ins and outs but it made sense at the time, maybe someone else also read it and has a better memory. I vowed to get hold of some cable which is the same as my lead in and make a patch cable out of it but have not got around to it yet.
-
FYI ...... may be going off at a tangent, but I visited a premises recently and the guy was using an Ethernet cable (from the output port of the Hub3), and strangely enough had another Ethernet cable wrapped exactly 3 times around the 'connected' Ethernet cable near the jack-plug. Then the two lengths were loosely taped together along their length, and at the other end where the other jack-plug is, he had wrapped it around another 3 times ??.
I asked him what that was all about, and he said he'd read it on some forum where he'd been given good advice before, and that it apparently gave him a better service (Bloke was a 'Gamer' as well). He said the instructions he'd been given were pretty exact about the 3 'wrap arounds' near to the plugs on the 'used' Ethernet cable.
Never seen, or heard about this before but thought it worth a share.
-
@Darren Thanks for that I am sure matching impedance's between the dsl lead and the cable to master socket would be ideal. I also had thought of that but lack the crimping tools for the connectors. Rather like the twisted pair cable I tried I suspect a small improvement may occur if you did that depending on how bad the original cable was. Until recently I had a favorite lead which did seem a little better than the others but just as fttc was installed the locking tag fell off!.
-
FYI ...... may be going off at a tangent, but I visited a premises recently and the guy was using an Ethernet cable (from the output port of the Hub3), and strangely enough had another Ethernet cable wrapped exactly 3 times around the 'connected' Ethernet cable near the jack-plug. Then the two lengths were loosely taped together along their length, and at the other end where the other jack-plug is, he had wrapped it around another 3 times ??.
I asked him what that was all about, and he said he'd read it on some forum where he'd been given good advice before, and that it apparently gave him a better service (Bloke was a 'Gamer' as well). He said the instructions he'd been given were pretty exact about the 3 'wrap arounds' near to the plugs on the 'used' Ethernet cable.
Never seen, or heard about this before but thought it worth a share.
gamers can often get things wrong and misinformation spreads like a plague.
Probably read about twisted cabling been good, and somehow they translated it to twisting ethernet cables on their lan :(
-
gamers can often get things wrong and misinformation spreads like a plague.
Probably read about twisted cabling been good, and somehow they translated it to twisting ethernet cables on their lan :(
That sounds like the gamer is trying to make an RF Choke he would have been better of using a ferrite bead at each end of ethernet cable.
-
les, I got a crimp tool for about £4 of ebay, didn't expect it to be any good but it's been fine for the couple of dozen I've done so far.
NewtronStar, that's what I thought when reading Black Sheeps post. A choke on the power supply cable before it enters the modem/router can apparently sometimes help too.
-
Sorry Darren, it may not have read as well as I would have liked. I didn't mean the 'power supply' lead, I meant the Ethernet cable between the Router/Hub and the PC Tower. :)
-
Maybe I should of been clearer, I understood, I was just saying it can be beneficial to have one on the power cable aswell. In any case no appology necessary :)
-
Currently next door has a HR fault with phones giving out odd random rings, no dial tone most of the time, sync on HH5 FTTC on and off and download down to 8mb/s c.f. attainable of 80+ when it is on. DLM is no doubt quite upset. They have had one engineer who said an v old cable running between poles needs changing. They are waiting for a fix. There is a distinct impact on my line. See the two snr traces below, one with no fault next door and the other with the fault. One day they had a full snr the trace that day was good for me. lost their cross talk and snr remained flat.
When next door looses sync my snr jumps up. When the jumps up and down occur there are spikes -very large ones - in the errors. I wondered it was the surges to and from their bell wire capacitor or maybe just the bit swapping needing to adjust the bit loading. My capping of the line speed seems to be keeping thing manageable on my line but without the extra 4db that I added to the snr I suspect the current crc spikes of about 500 in 30 sec would be a lot lot bigger.
-
I spoke to an engineer at my cabinet today. There are now 24 FTTC connections live from the 128? ECI cabinet. After the obvious individual impacts of the first few connections the snrm seem to just be drifting slowly down now with a drop from 7.8 at the end of January to 7.3 now. The snrm is a long way down from the 14db seen when first connected. I also guess properties actually in my cable run may still be able to produce big drops when and if they get FTTC. The upstream snrm is bigger at 8.5 but suffered a big drop when my upstream power was reduced a week or so ago -probably a sensible change to give others fair shares.
Mostly I have been capping the speed to boost the snrm as the errors started rise a lot below 7.8 db snrm. It is a pity the tolerance of the DLM to errors is not properly known. Does any one have a experience of what crc and ses rates the DLM seems to tolerate and preserve fast path? If the DLM works sensibly and the noise is not unusual this might be a fairly fixed value on lines where the DLM has capped speed but maintained fast path.
-
It is a pity the tolerance of the DLM to errors is not properly known. Does any one have a experience of what crc and ses rates the DLM seems to tolerate and preserve fast path? If the DLM works sensibly and the noise is not unusual this might be a fairly fixed value on lines where the DLM has capped speed but maintained fast path.
Your looking for the Openreach DLM Holy Grail many have searched high & low for this answer many have not come back from this quest, and a few have but they no longer act like inquisitive members more like the life & soul has been taken away from them. ;D
but they did tell me there is a 14 day wait if things go wrong before it returns :(
-
QLN noise as the only FTTC connection and then with just next door as well
The impact of just one other connection was a shock to me :'( and dropped my attainable from 107 to 93 Mb/s and the snrm dropped from 14 to 10. Makes BT wholesale estimate of 80/20 for my line most unlikely as it would not take much more of this to take the snrm below 6. I have long believed that I have a section of split pair but then again maybe this the reality of an just an average connection. I attach the qln before and after my neighbor was connected. It is interesting to flash between them to see the exact change that a single other connection causes. For info the HG612 latest blob 038 and the HG622 on Blob 033 both show qln and hlog for the upstream tones as well.
I realise this is a response to your original older post, but just for fun, I have animated the 2 QLN graphs.
There really is quite a significant difference between them.
-
There really is quite a significant difference between them.
BE1 thats scary those peaks look like my QLN whats going on ?
-
This is what happened to my QLN graph when I forced a resync.
It had been up for 50 days prior to the resync, so probaly due for a refresh.
My connection's too long to use the D3 band, so QLN at those frequencies mustn't have any real effect on the useable bands.
4 days later, the gang installing new street lighting colums & some cabling cut through the underground phone cable, I can only 'suspect' they have done something else somewhere along the route, but as it's not affecting anything I have no need to complain.
The D3 band's QLN is still the strange shape since my phone/broadband services were restored & I have also reistated Asbokid's original firmware & allowed BT to remotely update it since services were restored.
In fact, my connection resynced at almost 2 Mbps higher DS speed.
-
Quote from "So What Is In a BT Mains Conditioning Unit?" http://forum.kitz.co.uk/index.php?topic=13570.0
I have ordered one to try as an experiment. It will be able to power the PC + screen, router and modem, but not an old laser printer (too many watts) that is connected via Ethernet to the router. I will try it powering just the modem and router first. The printer is powered off unless in use and could be disconnected most days.
Recalling neutral experiments reported here with batteries, I am not optimistic, but printer aside it can power all directly or indirectly connected devices. My hope is that the odd burst errors that I get about every other day or so and come with about 10 ses may be reduced.
My BT mains conditioner arrived and emits the low hum typical of a large transformer. The casing seems badly designed to amplify the hum. I hate things that hum but a sound damping pad on the casing either side of the unit reduces the sound a lot and makes to seem fairly hard to notice unless your right by it.
Before taking it apart I decided to try it out for a week. I am only powering the HG612 and the router on it at the moment. The only other connection to those items is ethernet from the PC to the router. I am not sure what can travel down the ethernet to give noise but as noted above I can power the PC and all that is connected to it as well and may try that later on.
I really did not expect any impact but there is clear reproducible impact tried 3 times and always the same. (with fingers crossed re DLM) With my normal plain mains I powered off and then on again via the conditioner, then back to normal and repeated this 3 times with a self speed cap to exactly the same sync of 60Mbs down. The snrm is normally very stable in the day and the test consistently gave +0.2 or +0.3 db with the conditioner c.f. without it, matched with about 0.9 Mhz attainable increase with it. Below I post the snr with and without the conditioner, the visible difference was consistent each time. The difference is however not entirely positive and the extra noise at some frequencies puzzles me.
The initial boost of ~0.2 db is tiny but I am encouraged to now leave things be and see how the error stats over a few days behave. It is nice to see some effect :)
-
An update.
1. Running everything off the mains conditioner was worse, it removed about half the benefit. I assume noise from the PC etc was added back in.
2. Turning off the router gained a further 0.1-0.2 db but is clearly not a viable option as I need the wireless and more LAN ports.
3. MUCH MORE PUZZLING - ??? - I have found moving ethernet, power supply and dsl cables about causes changes comparable with the impacts of the conditioner. What ever is changed the conditioner still helps. I found this when I decided to tiidy up with some 1m ethernet cables rather than 2m ones. Using the 1m cable caused a drop bigger snrm drop than the conditioner gain!! It was linked with much more noise in the highest frequency band. I am quite puzzled by this as I thought ethernet cables were alll much the same unless run over long lengths. Maybe all this a symptom of something noisy aorund the pc area that I have not tracked down.
-
@ Les-70,
If you think you have ethernet cable problems, you could make up your own leads from FTP cable but only earthing the drain wire at one end.
Kind regards,
Walter
-
Ethernet puzzle.
As noted above I was puzzled by sync changes when changing the ethernet cables used to connect the Hg612. I ended up with a laptop on its batteries and the HG612 in sync but not connected to anything other than the lan2 going via the ethernet cable to the laptop. With nothing else at all was power up, this looked as clean a test as I could conduct. The connection is vdsl with an attainable of 83mb/s and during the test no resyncs were made.
Just changing the Ethernet cable caused the snrm to consistently change, usually difference were between 0.1 and 0.3 db but a couple of cables in a fair sized collection gave changes of 1-2 db. The worst were cables from BT home hub 3 pack. The BT wan link cable with a red connector was the very worst at about drop of 2.5 db snrm. I don't know if that is a non standard cable not for a lan, or just a bad cable.
Stats from the modem suggest the "bad" cables give noise mainly in the highest frequency vdsl band. I therefore guess that there may be no effect on an adsl connection. I also note that lan2 is not expected to be in use, but I doubt that is relevant.
-
Just changing the Ethernet cable caused the snrm to consistently change, usually difference were between 0.1 and 0.3 db but a couple of cables in a fair sized collection gave changes of 1-2 db. The worst were cables from BT home hub 3 pack. The BT wan link cable with a red connector was the very worst at about drop of 2.5 db snrm. I don't know if that is a non standard cable not for a lan, or just a bad cable.
I don't understand how changing the ethernet cable from BT Router to HG612 could effect the SNRM as the HG612 modem gets its information from the DSL cable from the master socket and not from the Router ::)
-
Just changing the Ethernet cable caused the snrm to consistently change, usually difference were between 0.1 and 0.3 db but a couple of cables in a fair sized collection gave changes of 1-2 db. The worst were cables from BT home hub 3 pack. The BT wan link cable with a red connector was the very worst at about drop of 2.5 db snrm. I don't know if that is a non standard cable not for a lan, or just a bad cable.
It is not immediately obvious where the Ethernet cable, to which you refer, is connected. Is it the cable that you are using to connect the LAN2 port of the HG612 to the laptop computer?
Like N*Star, I can't see how an Ethernet cable can be having any effect on the SNRM of the CO - CPE segment of the circuit. ???
-
In the test the Hg612 has 3 connections. 1 - power, 2 -vdsl, and 3 pc on batteries via Ethernet only to lan2. lan1 is not connected in the test so the modem is in sync but there is no active ppoe session on lan1. Nothing else in the room has power.
I found the same effect in complete "system" of modem/router/pc but have tried to isolate things to a test. I need to try the same test with a router wan connected to lan1 and changing that cable but I have been trying one thing at a time in an effort to track down the puzzling impacts. I was puzzled ??? to begin with but having narrowed down to this simple configuration am perhaps more puzzled ??? :'( . Perhaps the appearance of extra noise in the highest frequency vdsl downstream band may suggest noise is getting into the router due to or through the Ethernet cable. Perhaps the variability with the cable suggests that the "bad" cables may lack "pair balance" or something else must be odd with offending cables.
-
Ah, I see. :)
<snip>
but there is no active ppoe session on lan2.
<snip>
Reading the above "lan2" as "LAN1". ;)
Perhaps you could set up a test environment in the sheddyian style? Get out the two or three old car batteries that you have stashed away (for a rainy day), connect them to a pair of power bus-bars and then run the HG612 and the computer from the common battery supply. The mains supply can then be isolated / completely off throughout the house.
-
Thanks for correcting the lan2 typo.
I am fairly sure it is bad ethernet cables causing the issue. I have tried about 18 cables now -all I can find and mostly supplied with routers. 10 are within 0.0-0.1db difference when tested i.e. probably no difference, 4 are with 0.1-0,2 difference and 2 with 0.3 and just 2 with ~1 or ~2 db, I conclude 2 or 6 of the cables should be binned. I have a second HG612 and I will try that another day but what every that shows some cables work as I would expect i.e. no impact but a minority are found to have an impact in this test. Below is some Texas Instruments text relation to ethernet noise emissions.
4 Sources of EMI in Ethernet Applications
Ideally, if differential signals are perfectly balanced, no common mode energy exists in the system. In
single ended signal systems, ideally all forward energy is contained within the signal wire or trace and
return energy is contained within a ground wire or plane in close proximity to the signal.
The source of unwanted emissions in network applications is common mode energy, radiating either from
differential signal wires, or directly from the system chassis.
This common mode energy can originate from any of three sources:
1. Imbalance in the differential signal path
2. Noise coupled to or from the system chassis or power supply system
3. Noise coupled to or from the network interface cable
4.1 Differential Signal Path Imbalance
Signal path imbalance can occur in two ways: across the differential signal pair or between the signal
source and destination.
Imbalance that occurs across a twisted pair can result from the cable medium itself being unbalanced, or
from signal termination imbalance. Imbalance across a signal pair results in one signal having a larger
magnitude than the opposite signal, which manifests itself as common mode noise.
5. Differential Signal Path Imbalance
End to end or longitudinal path imbalance can occur if the source impedance, transmission line
impedance, and destination impedance are not exactly matched in a system. This form of mismatch
causes energy reflections across the cable from end to end, which also results in common mode noise.
Recommendations for preventing differential signal path imbalance include:
• Use high quality symmetrically and tightly wound cable. ISO CAT5E or better quality cable is
recommended for 10/100 applications.
• Use equal length differential MDI signal traces with a strip line impedance of 50 ohms.
• Closely match the values and physical placement of signal termination components.
-
@ les-70,
I can confirm that a normal VDSL modem will run quite happily of its power supply connected to a small inverter plugged into a car's cigarette lighter socket.
Kind regards,
Walter
-
Thanks, I am fairly sure the HG612 power supply is not relevant in these tests. I have done the test with a linear power supply on a BT mains conditioner and get exactly the same changes as when run of the normal switched mode psu on the direct mains. The mains conditioner and/or linear psu give a quite separate ~0.3db improvement when used. The linear supply made no difference when I had adsl so I guess the vdsl bandwidth raises the risk of noise.
In the Ethernet cable swap test the issue really has to be a couple of bad Ethernet cables. They seem to work but can't be fully OK. I guess the bad Ethernet cables have poor connections/higher impedance on some the wires used. Most cables give No impact, a few a small impact and a couple (one of which I first used) a large impact.
-
An update:: The two "bad" cables giving drops of 1-2 db snrm are simply faulty, one shows a high impedance where there should be about an ohm and the other has a loose connection somewhere in its makeup. It took a long while and some waggling to spot the loose connection one. The other 3 cables giving smaller snrm drops of about 0.2-0.3 db are also in the bin now but nothing was obviously wrong with them. Below I show the impact each of these 3 poor cables had on the snrm. The impact of the obviously "faulty" cables was similar but much bigger. As I noted above the poor cable adds a lot more noise to the highest frequency band
I have retested all the other cables I have and can't get any effect from them i.e. they just work and don't influence the snrm at all when used on Lan2. They work perfectly in my normal setup and also in the test set up so everything is now as it should be :) . Those thinking it unexpected can be reassured that if the cables are good that is definitely the case.
However 5 cables are in the bin (for recycling) and I assume I may not alone in having some duff cables.
-
That's an interesting result, and quite surprising. It's suprising that so many cables are faulty in this way, and surprising that the fault only affects the top band.
-
I seem to have had 1 in 10 cables with a serious fault and 1 in 5 of those remaining with the "mild issue" seen in the snrm above. 1 in 4 overall does indeed seem very high rate but the collection does include some quite old cables. One of the serious faults was an "brand new" BT hub cable and the other serious one was an old cable that may have been bent once too often.
It is interesting that all bar one of the cables seemed to work perfectly in the sense that all Ethernet traffic got through OK. The one with an intermittent open circuit did fail to pass Ethernet from time to time e.g. with router stats running whilst the cable was used and waggled a few samples were lost.
It was by pure luck that I noticed the noise and 0.3 db drop when I swapped in new cable on Lan2 when tidying the wiring up - I was only aiming to get the Lan1 and Lan2 cable colours different!
-
I have to agree with Eric. It is a most interesting and unexpected result. Thank you for the precise testing and clear explanation of your findings, les-70. :)
-
I can confirm that a normal VDSL modem will run quite happily of its power supply connected to a small inverter plugged into a car's cigarette lighter socket.
Deviating off topic but using Walter's suggestion, above, will add yet another noise-generating device into the circuit! The average small inverter will be a switching based, oscillatory device which generates an approximation to a sine wave. That generated stepped square-wave (~240 V AC) is then transformed back to 12 V DC by the normal switching mode PSU.
For Walter's Wheelbarrow, I would construct an appropriately fused distribution box which takes the ~12 V DC from the car battery (via the cigarette light socket -- until such devices become Verboten) and to which a flying lead can be connected, thus allowing the modem to be directly powered from the car's battery. ;)
-
@burakkaucat
On your deviated topic I have resisted batteries as they don't seem a long term connection solution. One day I may try it simply as an experiment. I started in the direction of mains carried noise with a BT mains conditioner which gave me +0.3db snrm gain with a fixed speed sync.
I then tried using as well a linear PSU for the HG612. That gave a tiny extra benefit of ~0.1db. However leaving out the BT conditioner and just using the linear supply is a very similar benefit to that given by the BT mains conditioner. A linear PSU should have more mains isolation than a switched one and no issue with "switching noise". Since the linear PSU did not give much extra benefit when used with the BT mains conditioner I guess the main benefit of the linear PSU may be just the isolation and filtering due to the linear PSU transformer. I find the linear PSU more attractive as it does not hum and only uses an extra 1-2 watts c.f. the switched supply. The BT conditioner used an extra 10 watts and had a small but noticeable hum.
As a further deviation I have been pleased that the DLM seems to have ignored all the testing. Either it just does not care or it detects and ignores deliberate power downs.
-
As a further deviation I have been pleased that the DLM seems to have ignored all the testing. Either it just does not care or it detects and ignores deliberate power downs.
When reading your posts I was wondering to myself how the DLM would react to your testing and think as long as you leave a minium of 15 minutes in the powered off state between tests you should get away without any DLM intervention :fingers: ;)
-
@ BKK,
If there are concerns about voltages and spikes etc., I would counsel some caution as car electrics can be quite variable too, depending upon engine / generator on and off, use of self starter etc.
Kind regards,
Walter
-
Some good fault-finding experiments from Les. The learning curve continues ............... :)
-
this is interesting, now I am probably going to try swapping out both lan cables between my hg and router, both are isp supplied short cables not the usual long high quality ones I use for rest of my lan.
-
I think that it is well worth trying the Lan cable swap test but judging by my collection there is only a 1 in 4 chance of any difference and then most probably only a change of a few tenth's of a db snrm - but you never know unless you try. It is a nice test as you remain in sync and and can monitor clearly what happens.
-
An update. I have now gained about 0.8 db snrm or 3mb/s of attainable by:-
1. Replacing a dodgy lan cable ~0.1-0.2 db
2. Replacing the flat dsl cable with a homemade dsl cable using twisted pair ~0.1db
3 Running the HG612 on Bt mains conditioner ~0.2-0.3db
4 Using a linear psu for the HG612 ~0.1
5 Earthing the disconnected pair on the incoming drop wire and internal cable to the master socket ~0.2db
Note that the last mod is not legal or recommended and has been done so that it can be easily and quickly removed.
I checked carefully that the unused pair had no connection to earth and was open circuit before adding the earth connection.
With mods 1-4 all in place the average error rate was reduced by about 30% and odd big crc spikes were reduced in size but still gave about 5 ses/day
With mod 5 the error rate has halved and over a period of one week no ses or crc spikes have occurred - I believe this is the biggest useful change. I think I have obtained the benefit from the spare pair giving partial screening of the used pair. It may also be significant that the run to my house is underground until it goes up the pole that drop wire comes from.
-
is mod 5 hard when not engineer or engineer tools?
I find halving of error rate nothing to be sniffed at.
-
Yes it has been a very worthwhile improvement.
It was very easy for me as there was a handy earth near the drop wire to internal wire junction box in the loft. I just added the extra earth connection with a Krone tool. In other cases it would involve checking whether the unused pair is connected all the way from the master socket to the pole and accessing inside the master socket as well as, if needed, connecting both pairs in a junction box. This is also not a legal thing to do as it involves tapering with the BT side, albeit an unused unconnected pair. I guess Blacksheep would warn even more! I also would guess that it would only help installations via a pole and drop wire. I tried it as an experiment and will be leaving it, however it can't be recommended.
-
Can't hear a word of what you're saying Les, you'll have to speak up !! ;) ;D
-
a no go for me then, even engineers shy away from my junction box, Junction box is up on wall near top of building.
-
I tried it as an experiment and will be leaving it, however it can't be recommended.
At least you have the balls to give it a try and it won't be to long before you prise open your PCP cab and do a pair swap :lol:
-
ECI/r modem no longer syncs
I decided after a break of about 8 weeks to go back the supplied ECI modem to see how, with reduced attainable over that period, it performed relative the HG612. I have two ECI/r's the supplied one (unmodified) and an unlocked one, both worked 8 weeks ago and the cabinet is an ECI dslam. Neither would try to sync in the sense of a flashing dsl light. I returned to the HG612 and got an immediate sync. I wonder whether it is too do with my speed capping on the HG612, I removed that and the HG612 synced at full speed OK. I then retried the two ECI/r's but no luck, I left one on the line for 10 mins in case it needed to think on things. ??? Returning to the HG612 all again it worked fine.
I am baffled, I wonder whether either using the HG612 has upset the dslam or my speed capping has done something to it. When I have time I will open up the unlocked ECI/r and see what the serial output on the uart tells me.
-
On my line with the ECI/r the serial output is just the same with and without the dsl line connected -it simply refuses to connect. :(
I had another four tries, two with an unlocked one and two with the un-tampered engineer supplied one. I am just moving the cables between the HG612 and ECI/r and since it connects straight away when I return to the HG612 it hard to see that I am doing anything odd. It seems very odd for a device to be rejected that way. ??? it is hardly a problem but it is annoying me!!
I would assume any suitable vdsl modem would achieve a sync and as I said the line has not been capped. With the HG612 it is free to sync at either 80/20 with snr about 7 db and error rates that seem fine but look on the large size or with my usual reduction to 64/16 and a low error rates. In normal use I can't tell the difference between 80/20 and 64/16 and 64/16 was just intended to keep interleaving at bay. I am surprised that capping would produce this effect. I am using the unlockedgui-nobtagent firmware in the HG612.
Has anyone else with an ECI dslam recently tried to swap an HG612 to an ECi/r?
-
Yes, I recently swapped my ECI/r over to the HG612 to get some connection stats on the Mk2 faceplate and the latest HG612 firmware. I left it in place for about a month before swapping back the ECI/r. I connect to an ECI DSLAM and the ECI modem always syncs about 3/4mbps better than the HG612.
I had no issues with swapping them around.
-
Mystery solved. :) Based on two successful ECI/r connections and two more ECI/r failures the ECI/r seems to be sensitive to which dsl line is A or B. The twisted pair cable that the Hg612 and HG622 were very happy with has the pairs swapped round one end to the other. Using a "no swap cable" the ECI/r syncs as it ought to - just fine. My collection of cables are mostly straight thro but a few are swapped?? I assume the swap is the issue - the only alternative (unlikely I think) is that swapped cable has a plug that the ECI/r does not like. i have had things on and off too many times today to want to risk furthers tests.
Is it a wrong to have a dsl cable which swaps round the pairs??
Current stats without capping don't show much difference. All with 80/20 sync.
HG612 038 BLOB snrm 7.4 attainable 83800
HG622 033 Blob snrm 6.7 attainable 85400
ECI/r n/a attainable 83900
I notice that the srnm's don't seem that well related to the attainables between the two HG's.
-
I assume the swap is the issue -
Eh? Nooo! :no:
It will be a marginal (or defective) connector on the cable or a marginal (or defective) socket on the CPE and not the "polarity" of the pair.
I could send you off to read Beattie's SINs (for she has many, of course) and all the other standards relating to the xDSL interface to a CPE . . .
-
That is what I thought although with less certainty, I was aware the cable had the swap but gave it no significance at all. I only recalled it when puzzling over why I could not get the ECI/r to sync. The said cable has always worked with HG's and has always failed on ECI/r. That is now over about 8 tries on each and with failure free long term use with the HG's. When the connection has had a chance to forget todays on/off's I will cut a spare cable in half and try it spliced either way round in a more definitive test.
-
As B..cat advised I can confirm that the ECI does not care about any swap in the connectors to the dsl line. My troubles with the ECI are what I thought the improbable alternative. It is the plug on the dsl cable/ECI socket combination. The raised plastic ridges on the RJ11 plug that the connector contacts sit in look perhaps marginally narrower in the failed cable than those on the working cables. It does not worry the HG's or the CPE socket which worked 100% with that cable but the ECI was/is a 100% fail with it.
-
b*cat dances the "happy dance" . . . :dance:
-
HG612 038 BLOB snrm 7.4 attainable 83800
HG622 033 Blob snrm 6.7 attainable 85400
ECI/r n/a attainable 83900
I notice that the srnm's don't seem that well related to the attainables between the two HG's.
Glad the RJ11 cable has been sorted out and until you have the ECI/r unlocked if it were me I would be happy with the HG612 038 BLOB snrm 7.4 attainable 83800 slight decrease in speed for more SNRM thats what I look for these days ;)
-
The HG612 038 BLOB is also my choice. One of my ECI/r's is unlocked but I am never sure exactly what to make of all stats from it. edmt does not give an overall snrm value to compare with HG's but the command "btagent_arc_version getstat" includes a single value that may be same thing. That value is 6.3 which is not so good as the HG's.
When as I suspect it will, crosstalk takes me below 80/20, it will be worth a further modem comparison to see what is the difference in sync speeds.
-
b*cat feels somewhat uncomfortable when reading posts that make reference to "blob" . . . especially as the phrase "firmware image" should really be used. Most of the time, that inexactitude is used in the Thinkbroadband forum but now it seems to be making an appearance here. :(
The source code of the various firmware images for the Huawei EchoLife HG612 can be obtained. There is just one component of those images for which the source code is not available -- the Broadcom driver. That driver is only made available as a binary blob (http://en.wikipedia.org/wiki/Binary_blob).
It was with the original unlocked Beattie firmware image that Asbokid performed a binary blob transplant. And it was subsequent to that event that the incorrect usage of the word "blob" first started to appear.
"Blob", "Binary Blob" -- No. :no:
"Firmware Image" -- Yes. :)
-
I can't disagree but the binary large object tends to determine the dsl performance characteristics of the firmware and with a few firmware versions it is the reference number of that object which often needs a reminder. I am afraid I am inclined to be a bit sloppy that way but I will try to do better as I agree that in the end being careful over descriptions will help readers.
-
;D
-
Ouch - another nearby connection. Another nearby property connected today. For the last two months I have just seen the odd drops of 0.3 mb/s from time to time, adding up to about 4mb/s over two months. However with just one extra house on the road today the attainable went down 7mb/s in one go taking me to 76mb/s attainable. If all the 12 properties on the road connect and do that I could be quite unhappy :( . The only other connection on the road was in the first week and reduced the attainable by 14mb/s. I expected later connections to have a smaller impact consistent with a log snrm scale. Today's drop seems contrary to that expectation. Given that I had already dropped from 107 to 83 I hoped that further reductions would be a slower process.
edit - to be clear this last reduction takes me from 83 to about 76 mb/s attainable now.
-
I decided I would try adding a RF3 to my connection. I don't believe that they are intended for FTTC so I was expecting an unfavorable impact. The results on the snr are below and a drop of 17mb/s occurred in the attainable speed. The RF3 has been removed already so I can't say what influence it might have had on errors but a fair test would have involved capping the speed to be the same with and without the filter. Had I been on a 40/10 connection and not worried by the drop in attainable I might have left it in to see the effect on errors.
-
les another 9mbit drop and you have a crosstalk loss not too far of mine currently although at its worst was below 65.
my attainable is now currently 69, dont know when it increased as since I upgraded my rig (last week) I havent been monitoring my hg612 and I only checked in the gui today.
-
Probably why were told to leave our FTTC modems on!
The two neighbors who give me a lot of cross talk have taken to turning off their modems at night. (I do too so I can't really grumble). See the consequences in my SNRM when they switch on - you can see from the times that they are slow starters! This is happening every morning. My speed capping at 64Mb/s down is maintaining a good margin but if left to itself the dlm would probably end up reacting in one way or another. I have wondered over split pairs but I suspect it just cross talk.
-
After another two months not much to report. Running with the HG612 the attainable has dropped another 1Mb/s to 75Mb/s so that from 108 to 75 so far and worryingly most properties round here are still on adsl2. I am about to move the Zyxel VMG8324-B10A which from tests should gain at least 1Mb/s back. I would have moved to it before but the power lead proved too short for just a simple swap.
I am with TalkTalk so the usual BT line info facilities are not available to me. I have however been tracking my next door neighbor on the BT wholesale speed estimator. The estimator seems to be trying to demonstrate its incompetence, earlier figures which ranged from 80-80 on on non impacted, to 80 on impacted high and 67 on impacted low has moved in two separate jumps to now be 69-53, and 60-34 respectively. That is a crazy jump of a factor of two showing that one estimate or the other was/is quite misleading.
-
A small update. Today started with most of my crosstalk missing and an attainable of 93Mb/s, by 8.00am it had dropped to the usual of about 76/77 Mb/s, but Oh dear a man was seen at the cab :( and shortly after I am down to 73Mb/s attainable.
The Zyxel VMG8324-B10A was sent back due to very high errors and strong suspicions of a fault. I now have a Billion 8800NL (which I am pleased with) and I have been trying to compare error rates of the Billion 8800NL with those of a HG612. I discarded all periods with thunderstorms and after a few week and lots of swaps have concluded that the with exactly the same capped speed the error rate of the 8800NL is 20-30% greater than the HG612. With capping that can be offset with a small extra speed cap on the Billion.
I also have a STC Saudi Arabian HG658B which does not support capping. (cost US$8 and $15 postage -- they come up from time to time on Taobao) It has the odd behavior of showing a higher attainable but giving a lower sync than the HG612. In an error comparison with the Hg612 which lasted two weeks and swapped them every day the HG658B has an error rate about 30% less than the HG612. That was in spite of the HG612 being capped at 72 and the Hg658B running at about 75 The HG658B is unlocked and works with Dslstats (but it took months to find the uername and password for telnet) so I have been considering using it but my large attainable swings each day make me worried about possible resyncs.
-
Almost exactly one year from connection I thought I would give an update. The attainable has dropped from 107Mb/s to 70 mb/s (currently higher as someone seems to have gone away) and is still dropping. The bad news is that most neighbors don't have FTTC so there must be plenty of scope for more drops. The only good news is that the cabinet is 75% full so only 25% to go.
I have retested my various efforts at optimization of the line. Although the two go together my main aim has been to keep errors low rather than get a better speed. The speed is way more than enough for my use and the only thing that has annoyed me is two occasions when interleaving was applied and I actually did notice an impact. I am sure that what is best to reduce errors depends a lot on noise that previals on the line. I have a general tick over rate of erors coupled with what seems to be SHINE events that occur about 3-6 times a day with potentially many CRC and one to several SES each time. As noted below the SHINE and some of the general error count seem be mains borne.
My biggest benefit comes from running the modem and router, mainly a HG612 and Dlink Dir-655, on a BT mains conditioner. The Main conditioner seems best, if contrary to recommendations,it is unearthed!
Another a big benefit is also gained if there is NO extra wired ethernet connection to the modem/router but with all access wireless. I guess this set up is close to running on batteries. This has not proved a disadvantage for me but as a matter of principle I do prefer a wired connection.
A smaller but noticeable benefit comes from using a home made common filter using toroidal ferrites. The does not reduce the background error rate but does help reduce the impact of the SHINE like events.
I was previously earthing the unused drop wires but with the new set up that hardly makes a difference and those earth connection been disconnected.
When compared to a straight mains connection - and using just the mains conditioner, the SES rate, a good indicator of SHINE, drops from ~6-10/day to ~1-2/day. With both the conditioner and wireless access only, the SES rate drops to ~0.5/day. With both improvements in place the overall ES/day is also reduced but by only about 30-50%.
-
I have to say being on a long Distribution-side 997 meters with interleaved applied and a SSFP MK3 the SES errors look fanstantic on a daily basis 0 Down and 0 Up.
with the standard MK1 would have seen 1-2 SES per day, so the MK3 for this line is doing a better job than the MK1 and MK2 ;D
-
When interleaved with my current set up (the cause of the interleave is suspected to be work at cab) the ES rate for 10 days was 0.1ES/day and 0.0SES.
I did not get any significant difference is stats between Mark 1 2 or 3 SSFP. My home made common filter takes about 1 Mb/s of the attainable, that could be compared with an RF3 which would currently give a drop of about 12Mb/s. However the home made one is bifilar and should be at least as effective as an RF3 but but with the big speed impact.
I assume I get mains borne spikes and the BT mains conditioner coupled with wireless connection to the devices on the conditioner is eliminating most of these spikes. As I noted what works best will depend on what the error source is.
-
Does any one have a experience of what crc and ses rates the DLM seems to tolerate and preserve fast path? If the DLM works sensibly and the noise is not unusual this might be a fairly fixed value on lines where the DLM has capped speed but maintained fast path.
I know that is an older post, but since this thread has come up to the top again, I think its worth re-visiting
Documents Ive seen would seem to imply that the last known FTTC parameters are
Speed MTBE 30/300
Stable MTBE 60/600
This equates to 2880 ILQ red & 288 ILQ green
I wrote to someone the back end of last year to ask and they promised they'd get back to me if it was any different, but Ive not heard anything and I dont want to pester because I know BT are far more sensitive about DLM information since the ASSIA court case.
I know theres been discussions about a possible 1440, but iirc that was the original (not latest) figure.. and since ronski and a couple of others on MDWS seem to go over this without DLM intervention, then Im inclined to think that unless the ILQ figures were changed since the ASSIA court case, then they are 30/300
-
Almost exactly one year from connection I thought I would give an update. The attainable has dropped from 107Mb/s to 70 mb/s (currently higher as someone seems to have gone away) and is still dropping. The bad news is that most neighbors don't have FTTC so there must be plenty of scope for more drops. The only good news is that the cabinet is 75% full so only 25% to go.
I dont know if anyone else has noticed this or if it is just a co-incidence, but since BTw started messing with MSE bRAS, Ive been noticing my line is far less stable on the upstream and also that I'm noticing the effects of crosstalk more.
For those that dont know MSE bRAS (http://www.kitz.co.uk/adsl/MSE_BRAS.htm) means that more of the small to medium exchanges are now a satellite from a larger neighbouring exchange which has a MSE bRAS (http://www.kitz.co.uk/adsl/MSE_BRAS.htm#MSE_router) installed. The effect in my case is that rather than being attached to an OLT (http://www.kitz.co.uk/adsl/fttc.htm#fttc_how_it_works) in my local exchange, the fibre from the mini DSLAM goes direct to an OLT in the next town, meaning a much longer run of fibre before it joins up to an OLT.
This method has its benefits in that it should mean a shorter backhaul before going on to the core network and slight decreases in latency (which Ive seen), but Im not sure whether its been beneficial for crosstalk or if Ive just been unlucky with picking up some bad disturbers all at once and also seeing a much more unstable upstream since the night I was re-routed.
-
I know theres been discussions about a possible 1440, but iirc that was the original (not latest) figure.. and since ronski and a couple of others on MDWS seem to go over this without DLM intervention, then Im inclined to think that unless the ILQ figures were changed since the ASSIA court case, then they are 30/300
I agree that on MDWS Plusnet has a few users consistently over 1440 now. There were none back in November but that may be a coincidence. For TalkTalk I think the jury out re 1440 or 2880. TT state that all are on "standard" but their nomenclature is not clear and I suspect the 1440 may apply. I recall you thinking Plusnet was speed. I am on TTB and even if I look at a home service Plusnet works out quite a lot dearer when I take phone usage into account. Otherwise their 2880 ES/day might capture me.
-
afaik theres only been Plusnet and Zen who have categorically stated that they use Speed. Its likely that AAISP also use Speed.
Ive seen mention on BT's forums that if you pester they will check & change you to Speed. Re TT, Ive heard that if you have TT TV then you will get placed on the higher profile. How true or not either of those rumours are I dont know. Default profile is supposed to be Standard unless the ISP opts otherwise.
-
Re TT, Ive heard that if you have TT TV then you will get placed on the higher profile.
I'm currently trying to find out this, some say TalkTalk use Openreach Standard and some say Openreach Stable if on TV - although, I have a feeling all customers are on Standard. I'll let you all know if I do get a confirmed answer :)
-
Thanks jamie :)