As long as the command is the same, and the data returned is in the same format as the bitloading data, then yes, I can write the code to do the graphs. I won't be able to test it though obviously but as long as the format returned is the same, my guess is it should work.
I could add an option, either a check box on the main screen, or a drop down options menu to select either the ECI/I or the /R so as not to set up graphs that one version can't use.
Looking at my code, a lot of stuff is repeated e.g. send a command, read the response, parse the response. This is bad programming as it could all be handled by one routine so a major re-write is in the offing !! The re-write though will be a side-by-side development. Code will be added to the current program (as it works pretty well) and then ported to the re-write. This will make my development branch pretty untidy and probably quite large, but the release version should be much more compact and more stable because of this. I've also figured out a better way of parsing the returned data that should work regardless of whether the read buffer contains 'command, data, command prompt' or 'data, command prompt' (which occurs quite a lot !! Grrrr )
If you can post attachments containing the results of QLN & Hlog from the /r then I can use that to make sure the code works. I'll just grab the data from the file rather than the ECI whilst testing.
Downstream speed is now being graphed. I'm not too bothered personally about upstream as mine is capped at 2M, but i'll include it at some point as I know various people have had upstream issues.
Because bitloading changes over time, I'm going to change the code to pull the data each sample cycle instead of just snapshot it at the beginning.
Thought - I can get 'gain' easily enough and graph it. Does this also change over time or is it like Hlog, QLN and a one time deal ? - Perhaps I'll graph it anyways to find out !!
On the subject of 'sample cycles', it's currently hard-coded at 15 secs. I reckon it could go lower to around 10s maybe even 5. The problem here is that there needs to be a delay between sending a command (eg cat /var/tmp/pipe/tell_me) and reading the result. Currently i'm delaying by 1/4sec but thats probably far too long and 20ms is likely enough. If I can get it that low, with no loss of stability, then I can make some options for the sample time. Thats in the future though.
