Hello, I have no qualms with renaming the existing type to just be temperature, I just figured that renaming this macro might break some existing user code. If the NuttX team thinks renaming is a better solution then I'd be happy to go that route!
Matteo On Sat, Jan 18, 2025, 2:30 AM raiden00pl <raiden0...@gmail.com> wrote: > 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 > > > > > >
