Decided to add the capability to create DSL line statistics graphs to OpenWRT similar to what the Fritzbox DSL modems provide. Code can be found in https://github.com/turboproc/openwrt-dsl-graph .
For now the repo contains 2 solutions in parallel
one based on the chart.js package which supports way options than required and is a kind of slow in rendering
one based on some bespoke graph rendering routines, just sufficient for this application and a lot faster in rendering
Use it to your liking and looking forward for any feedback.
I didn't notice it before, sorry ... It should be "spectrum" not "statistics"
Other than that, I can only reiterate: Nicely done.
Thnx, no worries, will change by opportunity.
@TurboWrt Awesome. Are you planning to submit the patch to LUCI?
Would do so if I would know how to submit a patch like this. Hence, need a bit of support.
BTW, when submitting it's probably wise to limit to one solution only. Would you prefer the solution based on chart.js or the solution without chart.js.
You should open a new PR on this page.
I am not an expert on JS. I'm mostly familiar with device drivers and the network stack. I think it would be best to ask the LUCI maintainers about this.
I saw, also a request for such a feature in LUCI.
In 2 weeks I will have access to a VDSL line I will test this PR.
Please once you have your VDSL line. There have been quite some updates (bug fixes) and 2 new graphs have been added.
I have this running on a fritzbox 7520 smapshot built from around January* and I must say, pretty sweet!
Two small nits I can't help mentioning:
a) the ranges for some of the plots are pretty generous and thereby hide some interesting detail.
here are the current limits, followed on parenthesis by the range as per ITU standard (T-REC-G.997.1-201902) followed by
SNR spectrum: -40 to -100 dB (-32 to 95)
bitloading: 0 to 16 (this is fine the maximum is 15 IIRC)
quiet line noise (QLN): -20 to -150 (-23 to -150)
Hlog: 10 to -100 (6 to -96.2)
So the chosen ranges allow to show all possible allowed values in the same scale, which is great for comparing between different links/modems on the same link, but especially for QL and Hlog, it might be helpful to see these scaled between actual data minimum and maximum, as that allows easier estimation of e.g. bridge-tap length.
b) for my profile 35 capable fb7520 on a profile 17 link the bitloading graph's zx-axis shows all 8192 subcarriers that profile 35 would allow while the three other graphs (correctly) only show the 4096 subcarriers that plan actually supports. Maybe there is a bug hiding somewhere?
See attached graph for details
*) Just tested a fresh built from today (2023 03 10: OpenWrt SNAPSHOT r22256-14334c222e / LuCI Master git-23.039.28596-41e9b8d) and still see the same, with the bitloading graphs x-axis 8192 bins long.
HI @moeller0 , thnx for for using this feature and your feedback. To start with the latter issue, the way it was designed was to use the number of subcarriers as indicated by the driver ratherthan checking for useful data. Unfortunately I wouldn't have a device anymore to replicate this situation as my current VDSL modem supports 17a profile only.
On the first item, the choice was made to have the Y-axis values displayed at clear 10 fold values (10,20,30, etc) and for this reason the pracatical ranges were made a bit larger. Let me cook on this and explore how ths can be improved. Might take some time as this is not having the highest priority at the moment.
No hurry, this feature is already great as it is, as I said, I was nitpicking...
Yeah the output of the firmware are not as consistent as one would like... I remember having had to deal with one record type that was missing the final closing element (a " IIRC), so occasionally one needs to compare different outputs, e.g. take the number of subcarriers from the SNR data as reference for all others. Again this is mostly cosmetic as there are alternative's like @janh's go-dsl tool if one really needs SNR and bitloading in register...