feature requests: tighter axis limits for QLN and Hlog plots

[moeller0]

Interpretation of Hlog and QLN plots mostly depends on looking at the precise curves and deviations from theoretical curve "forms". This gets easier if the plot is centered more on the actual range of the individual data compared the the current fixed? and quite generous limits (QLN: -70 to -160 dBm/Hz; Hlog: 0 to -100 dB)

Also a genuine question, why displaying the QLN as bar and not (as is done customarily) as line graph?

Final thought: the up/down qualification in the plots could be slightly more prominent, the current color scheme is quite elegant, but also quite subtle. Maybe turn up the color for these and plot these behind the actual data (currently they seem overlayed)?his would require different colors for max and min on the SNR plots though). But this is mostly cosmetic and a matter of preference, so if you prefer your current design, that also works.

[janh]

Interpretation of Hlog and QLN plots mostly depends on looking at the precise curves and deviations from theoretical curve "forms". This gets easier if the plot is centered more on the actual range of the individual data compared the the current fixed? and quite generous limits (QLN: -70 to -160 dBm/Hz; Hlog: 0 to -100 dB)

This is valid suggestion, and I agree it would make irregularities in the data more obvious. On the other hand, the fixed range makes it easier to compare multiple graphs and makes the magnitude of the data clearer. I guess in the end this is also a question of what you are looking for.

[moeller0]

Yes comparison across links gets somewhat harder, but assessing individual links gets easier.

Here is how I scaled it: https://github.com/moeller0/lantiq_dsl_parser/wiki Note how the autoscaled range can now be diagnostic for line quality ;).

Maybe make this scaling an option?

[janh]

(This reply also takes into account the forum post at https://forum.openwrt.org/t/lantiq-vrx200-xdsl-firmware-recommendation-thread/52937/132)

To me, the current fixed scaling doesn't really seem like a problem that would justify the effort of adding an option and implementing proper auto-scaling. I think any serious faults should already be recognizable with the current fixed scaling. The example you linked also doesn't appear to have dynamic scaling (Hlog matches the valid range, and QLN exceeds it by far), and the faults are easily visible (although to be fair, the aspect ratio of those graphs helps).

For the current scaling of the QLN graphs, I think this is still a remnant from when I originally added QLN support for a Broadcom modem. I suppose I didn't actually look at the specs at the time, and just picked a range that seemed to fit available data (the Broadcom CLI reports -160 for invalid values). So at least changing the lower bound might actually be a good idea here (although for G.fast the valid range actually does extend to -160, but I'm not sure if such low values are really realistic and so far G.fast isn't supported anyway).

[moeller0]

Well, your project your decision. All I can say is that on my link looking at QLN plots scaled close to actual data maximum and minimum* I can see improvements from changing my wiring, which are much harder to see when scaling for the full 'permitted' range. Now, I am set with my crufty old matlab code to extract and plot this data, inelegant and slow as it is, it generates the plots I want to see scaled any way I like them. Then again, for other users your project is so much nicer that I keep recommending to use it; and there for close inspection/diagnosis I would prefer a different scaling of hlog and qln. However, as I said your project your decisions, so I will close this.

*) "autoscaling" really boils down to get the data minimum and maximum, and add like 5% additional range on top and bottom... not sure about go, but in matlab that is coded faster than the time already invested in this issue by the both of us...

[janh]

*) "autoscaling" really boils down to get the data minimum and maximum, and add like 5% additional range on top and bottom... not sure about go, but in matlab that is coded faster than the time already invested in this issue by the both of us...

This project includes its own implementations to actually draw the graphs (Go/SVG and Javascript/Canvas). And the current code isn't even properly designed to draw graphs at arbitrary sizes (as you can see by the axis labels not really adjusting to the graph size). If you look at the errors-history branch, there are already has some graphs with dynamic value ranges. But I'd really like to get that cleaned up and make it properly adjust to the actual graph size, before I also implement something like it for the existing graphs.

I still kept your feature request around, as I might implement it at some point. But so far, it just didn't seem important enough to deal with the graph code, and decide on how to expose it as an option.

My comment in the OpenWrt forum was mainly because don't really want the discussion there to drift off too much. Discussing issues as they come up might be somewhat ok, but I think more general discussion about features should really happen here.

[moeller0]

Sorry for my impatience, I misinterpreted your action as not being that interested in this "feature" and had not considered that implementation wise it might actually be far less simple than I imagined. I closed this to avoid annoying you further. As I said go-dsl is my go-to tool to recommend and ask people to use and post screen shots when DSL issues crop up. And for that usage go-dsl is super-useful independent on small nits like the hlog/qln scaling.

[janh]

I'll look into this after the errors history branch is merged.

[moeller0]

BTW, does luci-mod-dsl use your javascript library?

[janh]

BTW, does luci-mod-dsl use your javascript library?

No, it has its own implementation (not written by me): https://github.com/openwrt/luci/blob/master/modules/luci-mod-dsl/htdocs/luci-static/resources/view/status/dsl/graph.js

I only provided some comments during development and added support for pilot tones.

[moeller0]

That is excellent! Now I am giddy to run this over night to populate the error/5 minutes plots ;)

The auto scaling is working even better than expected...