inno_spectra

[chaneylc]

Description

Inno Spectra Nano Trait

Potential improvements:
saving coefficient / reference matrix after first load to speed up subsequent connections

Change Type

• ADDITION (non-breaking change that adds functionality)
• CHANGE (fix or feature that alters existing functionality)
• FIX (non-breaking change that resolves an issue)
• OTHER (use only for changes like tooling, build system, CI, docs, etc.)

Release Note

New Innospectra trait format

[trife]

• It seems that it's possible to scan using the physical button but the data isn't transferred until the software scan button is pressed. I think this is counter to how Prospector operated where the physical button would also initiate and save a scan.
• There are issues with the layout when a device is disconnected- padding/spacing is off and the config button is still displayed. These issues are resolved by going back to Collect.
• Is this implementation device specific or will it work for other devices from InnoSpectra? Regardless, nano is not used in any of InnoSpectra's branding material, so if it's device specific we should refer to it by the model name (InnoSpectra NIR-S-G1) and if it's manufacturer specific we should refer to it by the company name (InnoSpectra -- there are a few places where a space is included)
• Include device battery level and firmware version in the config dialog
• Trait scroller doesn't show that data has been saved after a successful scan
• This is one for conversation: should scan numbers be dynamic or static? From a user perspective, if I scan something 5 times and then delete scan 2, having the remaining scans immediately renumber might be confusing
• I won't be able to immediately test this, but Innospectras have a calibrated range of wavelengths that they collect, i.e. the headers are not equal between devices (though they are close). How would collecting data from two different models in the same experiment impact the data organization and export?

[chaneylc]

I won't be able to immediately test this, but Innospectras have a calibrated range of wavelengths that they collect, i.e. the headers are not equal between devices (though they are close). How would collecting data from two different models in the same experiment impact the data organization and export?

I previously wrote an algorithm to handle this, it would manage one file for devices that capture values across different wavelengths, filling in missing data with 0.0. We ultimately decided against this for now, and currently this should be done by using two different traits; each device having its own spectral file on export. I could reintegrate this algorithm or have a similar approach where the file name changes depending on the device identifiers to only require one trait, in that case there would be one-to-many traits to spectral files (per device).

[chaneylc]

Is this implementation device specific or will it work for other devices from InnoSpectra? Regardless, nano is not used in any of InnoSpectra's branding material, so if it's device specific we should refer to it by the model name (InnoSpectra NIR-S-G1) and if it's manufacturer specific we should refer to it by the company name (InnoSpectra -- there are a few places where a space is included)

If it has bluetooth capabilities and works with their SDK it should work here. They refer to their devices as Nano in their SDK, which is why I used that. I removed Nano from any user-facing string to avoid confusion.

[chaneylc]

This is one for conversation: should scan numbers be dynamic or static? From a user perspective, if I scan something 5 times and then delete scan 2, having the remaining scans immediately renumber might be confusing

I agree this could be confusing.