GUI: annotate links with Link Quality values (as determined by the nodes)

[EskoDijk]

This is a request for a new GUI feature: annotate links with Link Quality values (as determined by the nodes).

This could be enabled via the existing cv (configure visualisation) CLI command, as a viz option.

Some initial ideas:

• a number value for LQ (0,1,2,3) can be shown for a link line, near the node, to indicate the LQ for that link.
• each peer in the link displays its own LQ value.
• possibly there can be a variant to show the "LQ incoming" and "LQ outgoing" separately. I.e. two values shown together, per node.
• possibly there can be a variant to also show Link Margin value in dB.

[arun-mahasenan]

@EskoDijk can this be a generic feature to display not only LQI, but some other KPI also? for eg: PER, RSSI, Tx Power etc?

[EskoDijk]

@arun-mahasenan Good point, that remains to be seen. Displaying multiple things at once will be tricky I think. Displaying 1 selected link KPI could be a starting point.

Certain KPIs can be displayed as a sprite/graphic (such as Thread's Link Quality which is only 0,1,2,3) while others require text rendering.

An initial experiment shows that text rendering in the PixiVisualizer.js where the link lines are drawn is prohibitive: it will crash the browser due to overload of the rendering pipeline.

• for efficiency, a single texture should be generated / selected and then that texture gets re-used in every frame rendered.
• update of the single texture should be purely event-based (e.g. if KPI changes) to reduce texture uploads to the GPU/renderer
• what looks promising, instead, is to attach a Child graphical element to the Node graphic.
  • this Child stays with the Parent and simply moves along with it.
  • when Parent position is changed, or one of its neighbors changes position, the position of the Child graphical element is recalculated to follow along with the link.
• changes in the openthread project are also needed to send the required KPIs as events to the simulator. (Polling for this would be either inaccurate or extremely time-consuming. It needs to be event-based.)
  • for this, we can get started with Link Quality and/or Link Margin value as first KPIs.
• to maintain GUI responsiveness, and simulation speed, the KPIs should not be too volatile.
  • note that overal KPIs over a period of simulation can already be retrieved using the CLI command kpi.
  • such KPIs might also be displayed on the GUI per node, but that's another idea.

[EskoDijk]

There's now a first draft PR available that creates the GUI framework for drawing of "link statistics" or "link stats" as they're called in the code. This is reasonably generic so that new stats can be introduced easily in the Go (server side) code without having to duplicate the Go methods again in JS. (JS takes long to compile, has little compile-time error checking, and is tedious to debug.)

The first "stats" that are introduced are Tx power and Rx RSSI. These are tracked per "link" i.e. pair of nodes that have some sort of link relationship or are mutually reachable. To reduce GUI clutter, only values are drawn when normally a link "line" would be drawn between nodes. It currently shows the values for the last-successfully-received frame between nodes.

It is also event-based: when a change occurs, the local visualization is updated while other elements remain unchanged.