Transmitting/querying constant device metadata

[sneakers-the-rat]

The devices transmit data as header/buffer pairs, where the headers contain metadata for the buffer. We also need some way of getting static/constant metadata from a device once-ish per session.

The general motivation is to reduce any potential for mismatch between the firmware on the device and the user supplied config. the "direction" of configuration is somewhat ambiguous:

• currently some values in device configs are device -> config values that are constants determined by the firmware and are just in the config to be read out by the stream daq class, but...
• others are config -> device values that we want to allow the user to control on the device from their config.

i don't think this is a huge problem per se if we document which values are intended to be user-editable (@t-sasatani i believe already made a move in this direction by separating some values into a runtime sub-model), but there are some other related reasons we might want to do this:

• getting device_id (document device_id #57) and also the firmware version (basic metadata needed for reproducibility!)
• to identify/autoconfig a device ( Detect miniscopes #20 ) - we have some miniscopes connected to the computer, and we want to automatically detect what kind of scope/any config values fixed by the firmware
• self describing header format ( Unify metadata definition with firmware #37 ) - e.g. where we currently have BufferHeaderFormat classes that allow us to configure the positions in which different header values are found, the firmware already knows this and it could just tell us which values are where in the headers it transmits
• make the logic in the software match what happens in the firmware, e.g. @hsemwal and i were working today and were wondering how to write the @buffer_npix method for the (っ◔◡◔)っ ♥ mystery scope ♥ , and it turns out that the only parameter that can vary there is the size of the buffer - so if we could get that constant transmitted, then we would be able to remove that set of config values (currently i think 3-4 in the main stream daq method) and have that be entirely automatic, reducing the potential for error by mismatches between software and firmware logic as we go.

@t-sasatani described a few ways this might be possible in firmware, there are some constraints there, so we'll just work the software around whatever is easiest for the hardware/firmware.

• Since the wireless scope doesn't really "start" on command, and is just always streaming data while it's on, there isn't really a way to do a "handshake" style thing where we transmit metadata on device init. To get a full dump of any available metadata separate from the normal header/buffer flow, we would have to pause the DMA operations which may be fragile. If we went this route, we would need some separate parsing routine to recognize start/end of metadata transmission, and would also want to use parity bits/transmit multiple times to ensure that we got an uncorrupted set of values.
• We could also have a blank header field that is sent every time, and then we issue a specific request command asking for a key, and then in the following header that empty header field contains the value set on the scope.