FW v7.7.0 has chaninfo issue

[dkluger]

cbhw\device\nsp throws an error with the get_config() method. RECONFIGALL returns 266 channels on a hub that is configured to 256 channels. This is because of a change where the hub responds with channels it can trigger on an NSP, i.e. the 4x analog outs, 4x digital outs, and 2x analog outs (4+4+2=10, 256+10=266). I made a patch in the hitl_testing_dev branch that counts n_infos based on counting in a for loop when this criteria is met: self._config['channel_types'][i] == CBChannelType.FrontEnd. The old version simply counts based on n_infos = len(self._config["channel_infos"])

There's probably a more elegant solution in lower level packet parsing methods that I am not knowledgeable enough to fix.

[cboulay]

pycbsdk works with legacy NSPs and nPlayServer too, and these always return the FrontEnd channels and NSP front panel channels together, and indeed if they are enabled on the same sample group then they are transmitted together in a single data packet.

By any chance does FW v7.7.0 bundle both the Hub's FrontEnd channels and the NSP front panel channels into the same data packet? I think this is not possible but worth asking.

IMO, this is a fairly major change to the protocol. i.e., the set of configured channels returned by a single device does not exactly parallel the set of channels that occupy the data packets coming from that device. What's the plan for handling that?

[cboulay]

After discussing with Yugesh, it looks like we can leverage instrument id.

1. In the SYSREPRUNLEV handler, store the instrument id.
2. In the CHANINFO handler, discard packets with the wrong instrument id.

[cboulay]

Oops. Turns out that even standalone Hubs have the extra channels (maybe this was implied in the original message but I misunderstood), and they all have the same instrument id as the frontend channels. So the change I made does not fix the problem.

[cboulay]

Fixed in v0.3.1 release