It would be nice to be able to see an overall view of Bit-loading across all 4096 tones without needing to scroll back & forth.
The current "zoomed in" view is however useful for seeing bit-loading details for individual tones, so maybe a facility to see a default "overview" with an option to zoom in & scroll around?
That would certainly be possible. I would have to throw away quite a lot of the data of course, because I'm sure you haven't got a > 4096 pixels wide screen.
I have attached a high res (4096 pixels for the plot area) & a low res version of the same bit-loading data as generated via my scripts.
A lot of individual tone detail is definitely lost when plotting at a size that doesn't need to be scrolled, but it does give a reasonable overview that MAY dictate a need to "zoom in" & scroll around.
I don't seem to be able to use the snapshot facility for any of the graphs. Error message screenshot attached.
I'll have to look more at this. It worked on the XP machine that I built the Windows version on, which is the only Windows machine available to me. I'm grasping at straws here, but could you try changing the snapshot directory to one of the standard user directories, such as your Documents directory?
Nope, that didn't fix it.
I'll try this on an old 32 bit XP machine. It may just be a Windows 64 bit issue?
How much data can be stored if running the program 24/7?
i.e. does it accumulate in a log file somewhere, or is it overwritten as a maximum sized data "window" in memory?
In the case of the SNR margin and Connection speed graphs, the historical data is stored internally by the off-the-shelf graphing component which I'm using. I'm going to check with the component author to try to get a definitive answer to this question.
In the case of the bitloading graph, no historical data is stored, so there isn't an issue. But I will be adding an option to store historical data as text files if required.
The ability to store/graph infinite historical data would be most useful (particularly SNRM, Sync, Attenuation, Connection duration beyween resyncs, error counts etc.).
It certainly assisted me when "proving" ongoing faults that were not seen by my ISP & BT.
Do you intend to use "xdslcmd info --stats" data to calculate & graph changes in stats over each sampling period e.g. each 30 seconds, each minute etc?
That's what I do use to get the data. I use xdslcmd info --Bits to get the bitloading data.
Useful additions to bit-loading for static snapshots would be SNR (not SNRM), QLN & Hlog.
Data for these is obtained via "xdslcmd info --linediag".
Of course, the more data being collected, the longer the data collection period needs to be, via my scripts requiring a pause between commands to ensure data isn't overwritten.
SNRM & SYNC graphs & config screenshots attached for reference.
Thanks for those. Two other things I notice:
- the Attenuation figures in the status bar are shown as zero. If you could copy here the first 20 lines or so of the output of xdslcmd info --stats that will help me to see where the error is.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 4492 Kbps, Downstream rate = 31988 Kbps
Path: 0, Upstream rate = 4637 Kbps, Downstream rate = 28533 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.3 5.5
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 6.3
This is a feature/bug of the Broadcom modems on VDSL2 connections.
Nowhere in the stats or GUI can a single value be seen for attenuation.
Line & Signal Attenuation is reported separately for each tone band (via xdslcmd info pbParams).
This data may be obtainable by querying the modem's "hidden" logs, but I don't know how to do that.
- I see in the bitloading chart which you showed above, that there are no blue coloured sections. I would have expected the tones from 32 to 95 to be blue because they could be either upstream or downstream, but this is an area I have to give more attention to.
Yep, I noticed that too.
They are indeed blue higher up the tone bands.
While you are sussing out that aspect, be mindful that Huawei & ECI DSLAMS use slightly different tone bands.