Concerning the error you get, it's normal (well, sort of -- let me explain).
SPC files have a very specific content structure where each byte in the file is coding for something (more about that here:
https://www.thepulsar.be/article/implem ... ce-in-c--/). Inside SPC files, you'll find the spectrum data, the blank and all settings to post-process the data (filtering etc.) including the calibration data.
Calibration data itself, because it had to fit in a very limited amount of space on the camera (something like 4 or 5 32 bits words) is very rudimentary and is basically just the coefficients of a cubic polynomial + some checksum & ident to differentiate random bytes (new camera or reseted camera) from a camera that actually contains a calibration.
To implement the quickfix, I simply detect when the camera reports an error when I'm trying to push/pull bytes from it and save the data to disk as a "data" .dat file. Inside that file you have the very same info that I try to store on the camera, so tje 4/5 32 bits words and nothing more.
The button "import calibration from file" was implemented in the original software to load a SPC file and extract the calibration vector to apply it on the currently-connected camera. So it cannot read .dat files because they have a different format. That's for the "it's normal" part of my reply.
On the other hand, your remark points something very interesting that I did not think about in the first time: save the full calibration spectrum + calibration data as SPC file on disk. That would be much smarter because you could not only use the "import from file" option but also reprocess or inspect any calibration data, just like a regular spectrum. On BFS camera, it's even theoretically possible to upload the complete SPC file on the camera but I'm not sure it's the way to go... I initially believed that having the camera holding the calibration was more practical because you could put the setup on a different computer and still have the calibration. It's a nice feature but I'm questioning how many user actually use 2 or more computers with the same spectrometer :-/ I do it often using a laptop & my desktop development PC but maybe this lead to over-engineering something that could have been much simpler!
Now comes the tricky part. The software, while well made, was done in only 2 weeks during some Eastern Holidays years ago. I bypassed a lot of good practices rules to get something working fast (which is not necessarily a bad thing). Conclusion is that the software is somewhat between an "alpha" and "beta" state. With time, I also created a very powerful "core" library that refactors a large part of the code (+ automated testing + linux support -- more on that here:
https://www.more-cpp.com/). Ideally, I should migrate the complete SpectrumAnalyzer program to this new lib but that will take time.
As Andy pointed out, I also had to step back a bit a few months ago already. I'm currently looking for alternatives to work full time on stuff like OpenRAMAN but that's not done yet. So, in the meanwhile, feel free to update the codebase & share your modifications
It's open-source!