Here I am already with another additional question: I want to somewhat unify the options that these thermocouple sensors would have, and one of those options would be configuring the type of thermocouple. For instance, the MCP9600 supports K, J, T, ..., etc. types of thermocouples. I'm wondering if I could add a SNIOC command for setting the thermocouple type and also create a shared enum of all the possible thermocouple types so that each thermocouple sensor could implement the ones it supports. Would this be a good approach, and if so, would I store this enum of possible thermocouple values in `sensors/ioctl.h`?
Thanks again, Matteo On Thu, Jan 16, 2025 at 10:15 PM Matteo Golin <matteo.go...@gmail.com> wrote: > 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 >
