Revisit some neuropixels device related choices

[saskiad]

I want to look at the devices for Neuropixels related components and make sure we have these structured well - we've found places where the AIND vs MSP teams are using thigns differently enough that we need to revisit this.

1. Remove enum for HeadstageModel and rely on the Device class to specify this (previously discussed)
2. Should we remove the ProbeModel enum in the same way? Reason not to is that controlled vocabulary can be valuable and this might be a place where it helps us.
3. Does NeuropixelsBasestation require its own class? Can this use the generic DaqDevice class? The distinct fields are two firmware versions and the slot field. It might still need to be its own thing.
4. OpenEphysAcquisitionBoard looks like it can use DAQDevice though? No, the ProbePorts are distinct. We should keep this
5. How is StickMicroscopeAssembly different from CameraAssembly? Can we use CameraAssembly for this?
6. LaserAssembly needs to be revisited as the MSP rigs don't use manipulators for the lasers. Or perhaps this can stay and MSP can use the Laser in the LightSources - we need to add information about the galvos, correct?

@jsiegle @mochic Can you take a look and see what you think about these? I don't want to break things

[mochic]

1, 2 - The only potential issue I see with enums for model numbers is just maintaining the enum due to new models coming out.

[dyf]

I will defer to you all on these specific issues, but generally if there are opportunities to simplify the schema here I would encourage that.

[jsiegle]

1. This is fine
2. We will often want to filter recordings by probe type, and having consistent nomenclature is key for this. We can expand this enum when new probes are released, which will only happen once every ~6 months.
3. Firmware version is important to track, because IMEC rolls out new firmware on a regular cadence, and we want to know which basestations have been upgraded. Knowing the slot is important as well.
4. It's helpful to be able to map probes to particular ports, especially when using multiple probes simultaneously.
5. I think StickMicroscopeAssembly can be a CameraAssembly -- the only difference is we need to track the A/P and M/L arc position of the stick microscopes, but this is handled by DomeModule in the session JSON.
6. Can we make the manipulator optional in LaserAssembly, and also add an optional Galvo field?

[saskiad]

Great, thanks everyone. I think we've landed here:

1. handle headstage model via Device class
2. Keep enum ProbeModel for controlled vocabulary sake
3. Keep as is
4. Keep as is
5. remove StickMicroscopeAssembly and adjust session as appropriate.
6. either adjust the LaserAssembly to have optional fields as Josh outlined, or see if using the LightSources Laser is more appropriate for this use case.

I'll tackle this asap.

[saskiad]

I'm still trying to figure out the laser thing. My inclination now is to list the Laser in the LightSources field, and include the galvo as an additional_device as there aren't any specific fields we need for the galvo, correct? I.e. the default Device fields are sufficient (manufacturer, part number, serial number). Right?
What do you think @mochic