gpio temperature and humidity sensors

Could you advise sensors that will be simple to install?
To that drivers will be supported by default system?
Does anyone have knowledge and experience of implementing that sort of solution with Jetson Nano?
I can see that there will be two issues, apart of selection of a sensor model:

  1. sort out pin i/o design [ what to connect and how to connect and to where]
  2. Implement driver support, if it is not represented already [ build kernel module probably]

Hi, we have no such recommended sensors. For IO pins design, you should ask vendor of sensor first. I believe for most of sensors, it is standard IO. We don’t have such third-party device driver support, it also should be from vendor first. So you need to choose the sensor with standard IOs (I2C, UART, SPI or others) and get the source code of driver from vendor.

Thank you for the update!

And DHT11/22?
My research has shown that the manufacturer is :
I contacted them, but they do not appear to provide any software for download.

Upd: probably it is not the case as the manufacturer above seems to offer CHT11 rather than DHT11.
However, I found that Linux Torvalds’s repository seems to have the kernel driver as :

The question is if Linux Tegra for Jetsons nano/tx2/xavier will have the driver included by default or if it will require custom installation.
And once the driver will be installed, which pins to select to connect the sensor? Could help sorting out what pins to pick for jetson devices to connect it?
Github. List of humidity sensors. Retrieved from
Github. List of temperature sensors. Retrieved from
Github. Repository. Retrieved from
Devtalk. Forum Thread. Retrieved from
Datasheet. Retrieved from

Is it 1-wire interface? Jetson has not such hw port. Not sure if it can be simulated by GPIO. It needs vendor to help which kind of IO can be used for it.

Hi Trumany,
Thank you for your response.
I ordered one piece from Hong Kong and when it arrives [in a couple of moths] I will approach wiring it somehow.
It doesn’t appear to be one-wire interface, as it seems to have 4 wires as in the attached picture.
I send couple of emails to the Chinese guys but they do not seem to respond and will hardly explain how to software/hardwire it. However, may be something will be found at forums, as guys reported wiring it to TX, as it seems to me. [ ]



and com port? Can com port be simulated by GPIO? like in the attached image

It really needs vendor to clarify how to use it. And no COM port on Jetson, maybe you need bridge board to convert COM to UART. Anyway, please get help from vendor first, otherwise we are not able to provide help on it.

any known supported co2/o2/air pressure sensors?

could you suggest vendors to check with on the subject of compatible sensors?
any knowledge on getting Bosh BME680 to function? Is it likely that it will work and how to connect it?

BME680.pdf (2.29 MB)

Please ask vendor for the reference design first, we don’t have such resource can be shared.

Hi Trumany,
Thank you for your response.
And for DHT11? Will the list below work in lieu of reference design?

    Will the list above will be redundant to implement reading from DHT11 sensor? Or the information still lacks consideration?
    Could you explain how to build the dht11.c kernel driver support to load it into tegra-linux of Xavier? And how to read from .e.g. 13 pin to there data pin of the dht 11 sensor is connected?

Hi Andrey,

dht11 driver is included inside our kernel source too. Please try to build it by yourself.

You could add CONFIG_DHT11=y inside tegra_defconfig and it would be built into kernel image…

Hi, WayneWWW,
Thank you for your response;
could you help determine what is the location of a file tegra_defconfig, please?
Will it be in:

  1. Jetpack/ sdkmanager folder
    2. kernel source folder downloiaded and unpacked separately from the download center?
    A. At host PC
    B. at Jetson device?
    C. At any of the two?
    Attempt 1:
    #Downloading public AGX sources from

#Unpacking the sources to a folder

tar -jxvf public_sources.tbz2
cd public_sources
tar -jxvf kernel_src.tbz2

Scenario 2B is being approached
#changing dir to kernel_source

cd kernel/kernel-4.9

#adding the dht11 parameter to the tegra_defconfig

nano /home/nvidia/Desktop/kernel/kernel-4.9/arch/arm64/configs/tegra_defconfig

#setting output folder variable

mkdir /home/nvidia/kernel_output/

#creating config files

make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8

creating temporary installation

mkdir /home/nvidia/modules_out
  1. kernel source folder downloiaded and unpacked separately from the download center?
    The file is here. You could build it on either the device or cross compile it on host.

Thank you for your response.
However, in the scenario above I noticed that no dht11.ko module has been built during the first attempt.
Trying again with the same scenario.
Attempt 2

make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make[1]: Entering directory '/home/nvidia/kernel_output'
  HOSTCC  scripts/basic/fixdep
  GEN     ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/
  HOSTLD  scripts/kconfig/conf
# configuration written to .config
make[1]: Leaving directory '/home/nvidia/kernel_output'
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8

Of the latter the output is provided

Is there at the stage a chance to check if the parameter CONFIG_DHT11=y got processed successfully?
How to check it?
Then I am trying to make modules, but again can not find there the dht11.ko as you can see from the attached modules_out file


Thus, second attempt to build dht11.ko at native Xavier device seem failed

locate dht11
~/Desktop/kernel/kernel-4.9/arch$ tail /home/nvidia/Desktop/kernel/kernel-4.9/arch/arm64/configs/tegra_defconfig

Scenario 1A

cd /nvidia_sdk/JetPack_4.2.1_Linux_GA_P2888/Linux_for_Tegra
./ -k tegra-l4t-r32.2.1

that returns

Couldn't find tag tegra-l4t-r32.2.1

make_kernel_output.txt (336 KB)
make_modules.txt (29.8 KB)

Why would you expect a kernel module (.ko) to be built when you set “CONFIG_DHT11=y”?

that is a good question;
at my host pc I have the dht11.ko built by default
and when I am doing modules install it creates a bunch of .ko files, among them there is no dht11.ko that would mean that the flashed OS will nether have it, as far as I understand

It was a rhetorical question if your not understanding what ‘CONFIG_DHT11=y’ will do then read up about ‘compiling built in kernel modules’.

The base kernel would change with the “=y”, and you’d also build modules in that case with a new CONFIG_LOCALVERSION (sometimes you can get away with a new base kernel feature list using the original modules, but not always…it’s better to use a clean module build in that case). The earlier log from kernel build and modules looked successful.

For tags I’m thinking you just need “tegra-l4t-r32.2” and not “tegra-l4t-r32.2.1”. The JetPack/SDKM naming for 4.2.1 is a bit confusing since 4.2 installs R32.1 and 4.2.1 installs R32.2.