Hello everyone, I am working on writing drivers for some of InSpace's new sensors for our hybrid control system. Of these sensors, one of them is the MCP9600 thermocouple amplifier for reading temperatures off of our oxidizer tank and combustion chamber.
I wrote this driver using the legacy format here: https://github.com/apache/nuttx/pull/15525 I want to adapt it to UORB now because that is the direction NuttX is moving in and because that framework provides InSpace with a lot of nice features like mocking, buffering, configurable sampling rate, etc. for free. The UORB implementation as it stands only has one sensor type for temperature, and it is ambient temperature. Thermocouples are measuring the temperature of a specific object. I will need to extend the framework for this functionality, and I have a few questions to consult the community on beforehand so I follow the idiomatic "UORB way". 1) I would add a new type, of which I'm thinking of calling `SENSOR_TYPE_OBJECT_TEMPERATURE`. Are there any name suggestions that might be more intuitive and which convey that this type is for the temperature of a specific object/entity, not ambient? 2) In the same way, I am thinking of calling the topic `therm<n>` instead of `temp<n>` that is used for ambient temperature. This conveys that we are measuring the therm(als) using a therm(ocoupler). Any comments on this name selection? 3) Is it possible to re-use the `struct sensor_temp` data type for this sensor type since a timestamp and temperature `float` are all that's required for both thermocouple temperature and ambient temperature? Or should I add another datatype with a different name but the same members? 4) In a system with thermocouples there are likely to be more than one, each one measuring a different entity. In our case there would be one for an oxidizer tank, source tank, combustion chamber, etc. How should I structure this extension of UORB to allow differentiation between the `/dev/uorb/therm<n>` topics so they can be associated with the entity in question? I don't think I could encode this within the `sensor_device_info_s` struct since that is reserved for sensor and vendor info. Do you think differentiating by `devno` is fine? I.e. user must know that `therm0` is connected to the oxidizer tank, `therm1` is the combustion chamber, etc. If you have any other suggestions for me, please let me know. I'll probably reach out again in this thread once I get started with the implementation. Thank you! -- Matteo Golin
signature.asc
Description: PGP signature
