Added default temperature for ESP32 and NRF52 repeaters in telemetry

[IoTThinks]

Hi all,
I have added a default temperature for ESP32 and NRF52 repeaters in telemetry.

• The default temperature is from built-in sensor in MCUs.
• I have added a parent object NRF52Board.h and NRF52Board.cpp for all NRF52 boards. The same way we did for ESP32Board.

This is to know the temperature on the repeater box.
I have tested for Heltec v3/V4, RAK4631 and T-echo Lite under room and outdoor roof.
Quite accurate. 25C at 6am and 54C at 2pm.

[IoTThinks]

STM32 based boards have built-in temperature too.
But may be it is in TODO list for you.

The result is like below.

[IoTThinks]

RAK4631 is tested.

[jbrazio]

As it is, this will create confusion: "Temperature" is used for "environmental temperature" we should not show "CPU temperature" under the same label. Nevertheless this is interesting information available "for-free", it would be great to work with @liamcottle so the app could represent this under a different label.

[IoTThinks]

@jbrazio If any sensor regardless built-in or external sensor can give a meaningful value, then it would be useful.
The built-in temperature of NRF52 and ESP32 is even more accurate than the sensor of a T1000-e.
The correctness is due to the heat from NRF52 and ESP32 is not much compared to the environment.

The default temperature should be available to all repeaters as they all need to be temperature monitored under the sun.
External temperature sensors is just addon and I believe not many repeaters have external sensors.

[IoTThinks]

I will add a BME680 to ESP32 and RAK repeaters.
Then we can compare the built-in temperature sensors and BME sensors.

It would be interesting.

[oltaco]

I have no opinion on whether or not this is a PR that we want, but can I suggest it would be cleaner to do a rebase squash first so that the PR is not 21 commits 🙏

[IoTThinks]

Yes, besides temperature, I created NRF52Board parent object like ESP32Board.

So we do not need to copy & paste the same code 10+ times to 10+ NRF52 boards.

The PR alone is just around 20 lines.

They should share the same feature and consistent look&feel.

[jbrazio]

The correctness is due to the heat from NRF52 and ESP32 is not much compared to the environment

Think about it.. the sensor is etched on the dye meaning it's thermally coupled to it thus it cannot ever represent an accurate measurement of an external environment.

The ESP32-S2 has a built-in sensor used to measure the chip's internal temperature.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32s2/api-reference/peripherals/temp_sensor.html

The temperature sensor measures die temperature over the temperature range of the device
https://docs-be.nordicsemi.com/bundle/nRF52832-PS/raw/resource/enus/nRF52832_PS_v1.1.pdf (page 257)

[IoTThinks]

@jbrazio I fully understand the two links you gave me. Thanks a lot.
I would be happy to make this Telemetry as MCU Temperature, too. Rest assured on this point.

However, MeshCore uses CayenneLPP as the framework for telemetry.

However, as I know (correct me if I'm wrong), CayenneLPP has pre-defined and fixed telemetry label like Temperature and Humidity...
There can not be Room Temperature or Roof temperature or MCU temperature, just....temperature.

This will be a great limitation if later we come to Meshcore Sensor.
For sensors, we may have a lot sensors in the same Meshcore sensor node.

So if we can not change / switch CayenneLPP now.
We can use MCU Temperature as the default temperature in Channel 1.
Other temperature is well, optional and can override this temperature in Channel 2...

This is in my room now.

This is from BME680, trusted by many friends.

From Heltec v3, 30.9*C from built-in temperature sensor

This is from RAK4631.

The difference is 1-2 degree. This is close and useful enough.
I'm pretty sure when we have 10 temperature sensors, they will show different values even if they are industrial sensors.
Actually, I feel the temperature in Heltec v3 is more accurate than a BME680.
I have a few more temperature sensors around as a referees.

[IoTThinks]

From friends in Denmark, he said the temperature is more or less correct for his Heltec v3.
Well, 3.9*C.

No idea why wrong battery voltage, I didn't touch the battery voltage.
I saw there were some changes for ADC reading in v1.11.0 or the ADC reading is impacted by the coldness.
It means the built-in temperature is quite useful. Especially when the Heltec v3 is in light sleep to cool down most of the time.

[wel97459]

I like having this on my repeaters, and I have added it myself in my own mod of the firmware. I just pulled this into my branch, you did it cleaner.

[4np]

I was also looking at the code yesterday to add Air Quality Index from BME68X, and running into the same limitations with CayenneLPP. There are just fixed types in there and not much flexibility.

It would help if the telemetry channels could be named. Then Channel 1 could be CPU / Radio, Channel 2 could be Environment Sensor, etcetera. Ideally CayenneLPP should be more flexible, but I guess that deviates from the entire point of the framework - to send telemetry over LoRa with minimal footprint. If we need to be able to support more telemetry readings, perhaps a fork is necessary?

Note: As a side note, I am also getting the impression that some values cause output in the app to halt / break. For example, in the BME680 implementation, altitude based on barometric pressure (which is pretty inaccurate as you need to know the current barometric pressure at sea level for your geolocation and weather conditions) will never show in the app. If you shuffle the way the CayenneLPP is constructed (e.g. altitude first, temperature next, etcetera) you won't see any values at all so somehow altitude (incorrectly computed to 122m in my location) 'breaks' the implementation. I am not sure if that's caused by CayenneLPP or the app as I have no clue how to debug either one of them apart from flashing a newly built firmware.

[IoTThinks]

@4np I think we need to leave CayenneLPP in very near future.

May be for repeaters, it can use CayenneLPP for basic sensors. Well, repeaters do not need to have many sensors.
We can have Channel 1 (Built-in sensors) and Channel 2 (External sensors).

However, for MeshCore sensors, it will be a different story.
In LoRaWAN, we just use bytes[] array and let the application decides how to decode the bytes.
So may be, for MeshCore sensors, I will just send bytes[] array or base64 messages.

[wel97459]

With CatenneLPP you can only have one of any value type in a channel, I ran into this with monitoring battery voltage and solar panel voltage in channel 1 only the last value written is sent. Channel naming could be handled by the client app.

I was also looking at the code yesterday to add Air Quality Index from BME68X, and running into the same limitations with CayenneLPP. There are just fixed types in there and not much flexibility.

It would help if the telemetry channels could be named. Then Channel 1 could be CPU / Radio, Channel 2 could be Environment Sensor, etcetera. Ideally CayenneLPP should be more flexible, but I guess that deviates from the entire point of the framework - to send telemetry over LoRa with minimal footprint. If we need to be able to support more telemetry readings, perhaps a fork is necessary?

Note: As a side note, I am also getting the impression that some values cause output in the app to halt / break. For example, in the BME680 implementation, altitude based on barometric pressure (which is pretty inaccurate as you need to know the current barometric pressure at sea level for your geolocation and weather conditions) will never show in the app. If you shuffle the way the CayenneLPP is constructed (e.g. altitude first, temperature next, etcetera) you won't see any values at all so somehow altitude (incorrectly computed to 122m in my location) 'breaks' the implementation. I am not sure if that's caused by CayenneLPP or the app as I have no clue how to debug either one of them apart from flashing a newly built firmware.

[jbrazio]

The difference is 1-2 degree. This is close and useful enough.

I always said it's useful, specially when it's "for free", the hardware is there.. there is no reason not to publish it's values.

Nevertheless, we should use a different tag/channel/whatever, the point being: do not show it's value where a user expects to see environmental temperature. It's on the product manufacturer's data sheet for both MCU the intended purpose of that sensor.

[IoTThinks]

@jbrazio True.
I suggest to use channel 1 for anything built-in.
Such as battery voltage and MCU temperature.

Channel 2 for external sensors.

Best if we can name the channel to something meaningful to users.

[wel97459]

I could add a channel abbreviation that would fit in 4 byte of the telemetry.

@jbrazio True.
I suggest to use channel 1 for anything built-in.
Such as battery voltage and MCU temperature.

Channel 2 for external sensors.

Best if we can name the channel to something meaningful to users.