I've got around to thinking about this (after fixing the other reported issues). It seems to me, looking at the purple section of the graph in your snapshot, that there are invalid values for upstream tones 0-31, so these can be blanked, but tones 32-95 are 'shared' and therefore could contain valid downstream data. I'm inclined to leave these displayed in purple, unless there is a good reason not to.
We don't seem to have a definitive way of determining the type of DSLAM, and until we do I'll leave the graph colouring as it is, but blanking out the invalid values.
As mentioned, I am connected to a Huawei DSLAM that does NOT report US QLN & Hlog data.
Therefore, as tones 32 to 95 contain valid data, for my Huawei connection, it MUST be DS data.
Would it assist if I were to email/post here an example Plink snapshot log from an ECI DSLAM for you to have a look at (in conjunction with the differing band plans as discovered by Huawei & ECI DSLAMS)?
My scripts don't actually determine which type of DSLAM is used as such, rather they just plot data as US (if it is a valid value - i.e. ECI DSLAM) or simply ignore it if it is an invalid value - HUAWEI DSLAM.
The quickest way to determine the type of DSLAM (if actually needed) seems to be to look at the maximum DS tone "discovered" & reported via xdslcmd info --pbParams.
It is currently tone 3959 for Huawei DSLAMs (it was 3939 for the first few months of the 17a profile) & is currently 4083 for ECI DSLAMs.
Perhaps I haven't explained that very well, but I'm sure you will get the jist of what I actually mean