More robust input data protocol

[kaklik]

Hello,

currently, the Gamma MCA uses only a very simple data transfer protocol, which does not contain any metadata. That solution transfers the decision about the used data format to the user choice. The user is therefore obliged to select the correct data format e.g. Histogram or Chronological stream and also the correct number of channels and delimiter.

I suggest improving the situation by introducing a more sophisticated data format.
We successfully used NMEA-like strings, which have numerous advantages:

• Possibility to identify, instrument type, serial number, firmware version
• Mix multiple data types. e.g. Histogram messages and single events with precision time.
• Add additional measured metadata to the data stream e.g. GPS position, temperature, humidity, barometric pressure, etc.
• Rid of a malfunction caused by incorrect configuration by the user.

As a reference there are links to two instruments with the description of the messages:

• GEODOS01
• LABDOS01

The use of the NMEA format is beneficial in the possible mix with standard outputs from GPS receivers. The resulting stream could be also parsed by existing javascript libraries like following:

• https://github.com/infusion/GPS.js/
• https://github.com/101100/nmea-simple
• https://github.com/jamesp/node-nmea

[NuclearPhoenixx]

The idea with the current setup is that hobbyists can quickly program something and try it out. This means that the settings should be pretty comprehensive as to not restrict somebody. That's why you can select the data mode and also the EOL character, baud and stuff like that.

I fully aggree with you that a more robust data format would be better suited for ease-of-use and meta data transfer (that would presume that every device is in accordance with the exact requirements proposed by Gamma MCA, which would be more restrictive than now).

However, at the moment there is no way to actually save any data coming from the serial port other than actual raw spectrometry data. If you wanted to implement something like this, you'd also need to keep all the devices in mind that work just fine now. These would all need to be updated (flashed) with new software to keep working. Maybe an override option would be needed? 🤔

[kaklik]

We made attempt to simple implementation of our device's output format. The first iteration is selectable as a new input variant by the radio button.

Currently is parsing the histogram only.

[NuclearPhoenixx]

Nice, that's a better solution for now instead of overwriting the other input formats.

Didn't look at your implementation, but you could make a separate class that handles the format. You could parse the serial data with the serial manager just like usual, but give the raw data to your new class before going into the further hist processing and so on. The class could then sort the incoming data, check for the type (i.e. is it device info, histogram, whatever) and just return the histogram data to the Serial Manager for it to process as the hist data, so it won't notice a difference.

The rest of the data, e.g. device info and so on could be stored in your class in the mean time, so that it can be collected whenever you want to.

Let me know what you think.

[NuclearPhoenixx]

I know it's been quite a long time, but I really liked the idea with the additional mode. I still wonder what you think about it and also I'd like to see how you implemented this so that I can consider adding it to the official app too. Thanks.