wireless

A common protocol structure is to have a header containing a length field, followed by data of length bytes, followed by additional protocol fields such as a CRC. If the length field is variable, the position of subsequent URH-specified protocol fields defined by fixed position will not be in the correct location.

I do not know the best way to address this, but quick and easy way to support

Feature Description

Dear GNURadio support,

Is it possible to add the method "disable_legend" for "QT GUI Vector sink"? It is already implemented for "QT GUI Constellation/Eye/Frequency/Histogram/Waterfall sink"...

I need this method (and the related GRC block property: "Legend") in my application.

Best regards,
Jérôme

Feature Urgency

medium (would be nice to have in the

Currrently, if users are viewing a sample keymap file, and trying to understand all the behaviors they see there, they need to dig into our individual behavior docs to find each one.

It would be nice to have an aggregated index/lookup page, at the top of the "Behaviors" nested sidebar section, that gives has a table from "sample behavior" to the docs describing that behavior.

Indicator CC V4 adds two new commands:

• Indicator Description Get Command
• Indicator Description Report Command

https://github.com/zwave-js/node-zwave-js/blob/master/specs/SDS13782%20Z-Wave%20Management%20Command%20Class%20Specification.pdf

TODOs:

• Implement the new commands
• Implement a getDescription method on IndicatorCCAPI
• update @implementedVersion decor

Can't be seen easily but if we focus our eyes on the lower part of the button we'll notice it's slightly higher than the other buttons, let's fix this.

Add a variable to specify which version of Django should be installed.
This task should be run after everything is installed by pip to avoid accidental upgrades by any other package.

I think we should default it to ~=3.2.0, since it is an LTS release of Django (open for discussion).