Can we just rename `SENSOR_TYPE_AMBIENT_TEMPERATURE` to `SENSOR_TYPE_TEMPERATURE` and update the comments that this type is "a general temperature sensor"? The current definition is taken from Android, but NuttX is a more general OS, used in various embedded scenarios that go far beyond those of Android, like in this specific case: rocket science :)
Is there any reason for keeping it perfectly compatible with Android? Regarding setting the thermocouple type - using a dedicated SNIOC is OK. There is no command available for this purpose yet. sob., 18 sty 2025 o 04:05 董九柱 <dongjiuzhu0...@gmail.com> napisał(a): > hello Matteo Golin: > > I'm Donny. About these questions, i have some suggestions. > > Regarding the first question, we first need to clarify what data the sensor > reports. Can only temperature and time suffice? If they can, try to reuse > the sensor_temp structure instead of introducing a new type. If they cannot > suffice, there are two solutions. > 1>. The first is to populate the sensor_temp structure, but only add > members related to temperature. If the additional data is highly unrelated, > you have to choose the other approach: > 2>. Using custom_sensor. With this, you can fully define your own structure > and size. Register it through sensor_custom_register and specify a name, > which is usually the name of the structure and also the topic name for > subscription through the ORB API. > > Questions 3 and 4: > > For multiple thermocouples, uORB supports multiple instances of topics. You > need to specify the driver type and device number when registering the > driver, which will register them as different nodes. When subscribing using > uORB, you can specify which sensor entity to subscribe to using something > like uorb_subscribe_multi. These entities can all have data structures that > are either sensor_temp or a custom structure you have defined. For example: > /dev/uorb/temp0, /dev/uorb/temp1, etc. You can subscribe to specific > instances using: > > c复制代码 > uorb_subscribe_multi(ORB_ID(SENSOR_TEMPERATURE), 0); > > uorb_subscribe_multi(ORB_ID(SENSOR_TEMPERATURE), 1); > > Actually, when registering the driver, you should know which device uses > which devno, so you can differentiate based on devno. However, if you are > unsure, you can retrieve the info of each sensor to make a judgment. But > regardless, you still need to populate different info for different sensors > when registering the driver. > > Donny. > > > > > Matteo Golin <matteo.go...@gmail.com> 于2025年1月17日周五 11:16写道： > > > 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 > > >
