Multiple channels, low-cost, and dual data storage data logger for building a soil temperature network

Graphical abstract


Hardware in context
Temperature is a critical factor in many research areas, particularly in agriculture, due to its direct impact on crop health and yield [1,2].Investigation of temperature effects is essential for understanding its impact on crop systems [3,4].In particular, assessment of soil temperature is vital due to its influence on germination, root development, and microbial activity, all crucial for healthy plant growth [5][6][7].Additionally, soil temperature affects nutrient availability and uptake, impacting overall yield [8,9].By monitoring soil temperature, farmers can optimize planting times, irrigation, and fertilization schedules, leading to more sustainable agricultural practices [10][11][12].Soil temperature monitoring also aids in root disease research and improves crop protection management techniques [13,14].
In experiments requiring extensive temperature data, mainly in greenhouses and growth chambers, such as seed emergence studies, numerous sensors are needed to obtain comprehensive information [15].Data loggers, which record temperature along with date and time, are commonly used for such investigations [16].However, commercially available data loggers have some limitations, addressed by Eze et al. [17], which include a lack of long-range wireless data transmission capabilities, reduced memory storage capacities, and the capacity to read and record many data at the same time.Gandra et al. [18], while developing a data logging system for ecological applications also observed limitations on power consumption and, consequently, autonomy.Another limitation includes the limited number of non-customizable channels for temperature data and high unit cost [19].When researchers need more sensors than a data logger can accommodate, additional units must be purchased, thus increasing the research budget.The costs multiply further if the research involves different blocks or larger field-scale studies requiring a set of data loggers [20].These cost constraints to deploying a network of data loggers, which can often result in incomplete datasets that impact continuous monitoring and research studies [18].
These data loggers typically do not interconnect, storing data locally on the device, necessitating laborious and time-consuming data manipulation to combine collected data from multiple loggers.Commercial data loggers usually store data on local databases, such as Secure Digital (SD) cards.While locally stored data is reliable, accessing measurements from distant experimental sites can be cumbersome and time-consuming [21].Some commercial data loggers can upload data to remote databases, but these tend to be more expensive and lack of open-source flexibility, preventing user modifications [22,23].
Considering these challenges, some attempts have been made to develop hardware that addresses specific needs.Gandra et al. [18] developed a low-cost and versatile data logging system for environmental applications at a cost of €150 using Arduino, a real-time clock, and an SD memory card, a reduced amount compared to commercial versions.Hernández-Rodríguez et al. [24] demonstrated the possibilities of using low-cost and multi-purpose data loggers for monitoring air quality, human activity, motion, and exhaust gas monitoring, focusing on robustness, response time, replicability, calibration, and similarity.A system for storing data collected for solar thermal collectors in the cloud and displaying it to the user has been developed by Panagopoulos & Argiriou [25], illustrating attempts performed to move data storage to remote systems.However, to the best of our knowledge, no low-cost network of multi-channel data loggers storing data in local and remote systems has been developed so far.Following this rationale and aiming to fill this research gap, the objective of this study is to develop a network of open-source, lowcost data loggers with multiple customizable channels for storing temperature data in both local and remote databases.A secondary objective is to develop a digital tool to visualize current and historical readings without maintenance or usage costs.

Hardware description
The hardware, basic design of the data logger, is presented in Table 1.A visualization of the hardware is presented in Fig. 1.The DS18B20 Temperature sensor(s) (A1) is responsible for reading the temperature data.More than 1 temperature sensor can be used at the same time, for that, it is necessary to attach the temperature sensors to a Printed Circuit Board (PCB) (B2) designed exclusively for this purpose.This PCB is then connected to the Arduino Uno (B3) through wires.The DS3231 RTC (B5) provides the date and time information.The date time, and temperature data, are then sent via LoRa using the RFM96 LoRa board (B4) to the LILYGO TTGO microcontroller (C1).A network is obtained by combining more than 1 data logger.When the LILYGO TTGO microcontroller receives the information, it stores it in the 32 GB microSD card (C2) in.txt format and uploads it to the cloud.To upload data to the cloud, the LILYGO TTGO must be connected to the internet through Wi-Fi and have an Application Programming Interface (API) and a MongoDB database running on a remote web server.If the researchers do not want to upload data to the cloud, they can store data only in the microSD card.A flowchart illustrating the process is presented in Fig. 2. The DS18B20 temperature sensor was chosen for its affordability, waterproof options, wide range of temperature measurements (− 55 • C to +125 • C), high accuracy (±0.5 • C), and easy of configuration and use.The Arduino Uno was chosen for its simplicity, popularity, and price, allowing users with little experience in hardware design to reproduce this study.The RFM96 LoRa board was used due to its low cost, diverse available tutorials that facilitate further customization, low power consumption, and long range communication.The LILYGOTTGO LoRa32 ESP32 SD Card was chosen because this board has embedded WiFi, Bluetooth, a microSD card slot, an LED display, and LoRa, and is very affordable for its specifications.
The data logger presented in this study offers the ability to include a high number of temperature sensors within a single unit.Commercial data loggers typically support up to 12 channels, with prices ranging from US$80 to US$350, excluding sensors.In contrast, our data logger supports up to 24 channels and costs a minimum of US$72, including one sensor.For studies requiring 24 temperature measurements, instead of purchasing at least two commercial data loggers (minimum cost of US$160) plus sensors, researchers can assemble our data logger for US$126.Furthermore, if an additional block is needed for an experiment, there is no need to spend US$80 to US$350 on a completely new system; instead, researchers can add a single data logger for only US$35 (current prices for July 2024).This cost efficiency increases with the scale of the study, making our data logger a more economical choice for extensive research.
The connectivity of our data logger is another significant advantage over commercial options.Data sent from the data loggers to the LILYGO TTGO via LoRa connection eliminates the need to place data loggers close to each other, allowing installation in different and distant locations.Additionally, our data logger can store data in two ways: locally on a microSD card or remotely in a MongoDB Fig. 1.Parts described in Table 1 with the labels.
database.Commercial data loggers with remote data storage capabilities are significantly more expensive (starting at US$220) and offer a limited number of channels.
Finally, our data logger uses open hardware and open software, making it fully customizable to meet the specific needs of researchers.
Key benefits of our data logger network include: • Reduced overall research costs, • remote data transmission to a database, eliminating the need for physical presence in the sampling area to verify readings, • inexpensive maintenance and repair, and • fully customizable, allowing adjustments to meet the specific research needs.

Design files
All packages and files can be downloaded from the Mendeley repository, and these GitHub links: TempVis, Soil_Temperatur-e_Datalogger, TempDataLogger_API with the description of each file provided in Table 2.The README section of these GitHub links provides supplementary code explanations and running instructions.
The board schematics for the Arduino Shield and the sensor board are shown in Fig. 3.Note that in the lower part of the Arduino shield schematic (Fig. 3a), some text informs that these wires come from the sensors board (Fig. 3b).In addition, note that the sensor board is designed to fit a custom number of sensors connected in parallel (Fig. 3b).The respective PCBs have a text layer to indicate where the parts must be placed, aiding in the assembly process.
The R [26] code in Table 2 is a digital tool that can be used to visualize the data collected by the data loggers in a more user-friendly format; the data can be later exported in CSV format for later analysis and manipulation by the researchers.The Arduino (.ino) codes must be modified to include the number of sensors used in each data logger, the internet and LoRa configurations, and the API's URL.We provided files in the cases where the researcher desires to use both remote and local databases, only the local database or only the remote database.The pseudocode for the Arduino codes and the Python API is shown in Fig. 4. The pseudo-code for the data logger (Fig. 4a) initializes various components, reads sensor data, and transmits it via LoRa communication before entering a sleep state.The pseudo-code for the LILYGO TTGO (Fig. 4b) receives data via LoRa, stores it on an SD card, sends it to an API, and displays various statuses and confirmations.Lastly, the pseudo-code for the Python API (Fig. 4c) sets up a Flask application, configures a MongoDB connection, and defines two functions i) receives data via JSON and posts it to the database, and ii) retrieves all elements from the database and returns them as JSON; finally, it launches the Flask application.
In this study, we provided json files, which allow modifications in the PCB design or the schematics of the project, increasing the customizability and contributing to the open-source community.The gerber files are files ready to be sent to a PCB maker company to be manufactured.The stl files provided here can be used to print cases and protective structures in a 3D printer.The last two stl files were not developed by the authors but developed by the user "mason_swiss" and obtained through the open-source ThingIverse community.

Bill of materials
The table with the bill of a minimum data logger network is listed in Table 3.The starting cost of the data logger network presented in this study is US$72.3(current prices for July 2024).This initial cost is the minimum required to build one data logger using one sensor.If more temperature sensors are required, the researchers have to spend an additional US$2.32 for each sensor.For each desired data logger, researchers will have to spend a minimum of US$35.4 in each additional unit, since it will not be necessary to buy another LLYGO TTGO and a 32 GB microSD card.In addition, this microSD card capacity is a suggestion and can be replaced by another microSD card with a lower price.
Both PCBs were ordered with 2 layers, a board thickness of 1.6 mm, an Outer copper weight of 1 oz, and a base material of FR-4.
Another detail that must be noted is the frequency of the LoRa at the location where the data logger network will be used.At the location where this data logger network was developed (USA), it is required to use frequencies between 902 and 928 MHz.The LoRa frequency will change the product specifications of the LILYGO TTGO and RFM LoRa boards.
Lastly, if the remote databases are planned to be used, it is necessary to count the charges of the web server that is hosting the API and the hosting cost of the MongoDB database.For hosting the API, a simpler server can be used since the computational requirements are not high.There are some options starting from US$ 5 per month.For the MongoDB database, a low amount of data can be stored for free in some web services.

Build instructions
Fig. 5 provides a workflow on how to assembly the proposed hardware, summarizing the main steps needed for the implementation:

Structures
Start the building process by 3D printing the necessary structures present in Table 5.These structures can be printed using Polylactic Acid (PLA) material, 20 % gyroid infill, and 0.2 mm height (Fig. 6, shows all the printed structures).

Data loggers
The first step to assembling the Data Loggers is connecting the Temperature sensors to the Sensor's PCB.To perform this step, it is necessary first to connect the Temperature sensor's wires to the 3-pin female JST-XH housing.During this step, the usage of a hand crimper tool is recommended.Always remember to assemble the crimped wires in the JST-XH housing in the same order to avoid misconnections.We recommend following the same order in the PCB text layer: VCC, GND, and Signal.After this step, it is necessary to solder the 3-pin male JST-XH housing in the Sensor's PCB to connect the sensor to the PCB.Next, strip the tips of the 3 sets of copper wires and solder them in the Sensor's PCB in the same order as stated in the PCB text layer.The output of this first step can be visualized in Fig. 7.
The next step is to solder the components to the Arduino's shield PCB.To save time, solder the Pin Male Header only to the 3 V3, GNDs, A4, A4, 2, 4, 8, 9, 10, 11, 12, and 13 pads of the PCB.Please note that it is necessary to solder them facing the opposite side of the writings because they will be used to connect to the corresponding terminals in the Arduino Uno.Then use the PCB text layer as a guide for soldering the other components.The connection of the sensors' PCB to the Arduino shield PCB requires more attention.This can be done by simply soldering the wires connecting the two PCBs to the appropriate pads.Another alternative is to use a 3-pin JST-XH package.Note that they must follow the same order: the wire from the VCC in the sensors' board must connect to the VCC pad indicated in the Arduino shield PCB, and the same for the other two (GND and Signal).To build the antenna, strip the 7.8 cm 1 mm copper wire, and make a coil.Next, solder it to the pad above the LoRa.The end of these steps can be visualized in Fig. 8.
Next, place the assembled components into the 3D printed structures.Use the M1.7 screws and the M2 screws to secure the Sensor Shield and the Arduino Uno, respectively.Attach the Arduino Shield PCB to the Arduino Uno by connecting the respective pads from  the Shield to the Arduino.Remember to feed the temperature sensor's wire through the housing cavity before connecting it to the sensor PCB.The end of this step can be seen in Fig. 9. Before uploading the Data Logger's Arduino (.ino) code using the Arduino IDE (which can be downloaded from the internet free of charge), it is necessary to pay attention to four important details: • In line 4 it is necessary to set the id of the data logger.This id will later tell us which device the data comes from.
• In line 5, it is necessary to set the number of sensors being used.
• In line 6, it is necessary to set the interval between readings, in seconds.
• In line 7, it is necessary to set the frequency of the LoRa module you are using.
• In lines 8 and 9, it is necessary to set the calibration values for the sensor reading with the model inclination and coefficient, respectively; • The code to configure the RTC must be uploaded twice: once with line 59 uncommented and once with it commented.
After uploading the code, it is necessary to label the sensors.A tip is to set the interval between seconds to one second for this step.Use ice cubes, a soldering iron, or hot breath to individually cool or heat the temperature sensors, and check the Serial Monitor for the readings.Label the physical sensor with the number whose reading is changing in the Serial Monitor.
If the white LED turns on during uploading or powering up the dataloggers, there is an error in the datalogger.This could be RTC not detected, LoRa board not detected, or the number of sensors found by the logger is different from the number configured in the algorithm.The Serial Monitor will inform you which problem needs attention.To fix these errors, check that these devices are not shorted, are soldered correctly, or are working properly.

Temperature sensor calibration
A necessary step is to calibrate the temperature sensor to ensure consistency and accuracy.To perform it, Koestoer et al. [27] described a method to calibrate the DS18B20 temperature sensor.We have followed the same procedure as previously described by Koestoer et al. [27] but with slight modifications.We have changed the oil using water and a clinical probe thermometer already calibrated to obtain the temperature values.The sensor values were obtained using the serial monitor, and the values from the thermometer were annotated.Later, we have used a simple regression line to correlate the values and obtain a correction factor to be Fig. 6. 3D printed structures used for building the sensor.used in the Arduino code.

Setting databases and API
The first step in setting up the local database is to create a.txt file on the microSD card.Connect the microSD card to a computer and create a new text file with the extension ".txt" in the main folder.Inside the file, text and save a line with the following text "iD, Reading, DateTime".The previous text will be the header for the stored data.
To set up the remote database, it is necessary to configure a remote MongoDB cluster.There are several options for creating the MongoDB cluster, such as Amazon Web Services (AWS), Microsoft Azure, Google Web Services (GWS), and MongoDB Atlas.The researcher must analyze which one best fits the project budget.After selecting the service and setting up the environment, researchers need to create a MongoDB cluster, in this remote cluster, they need to create a database and a collection within it.Note that to access the database from different IP addresses, it is necessary to allow this in the configurations.Store the connection string to access the database under the name of the database and collection.They will be used in the API configuration.
The Python code described in Table 2 is the algorithm that must be deployed to the web service as an API.The web services to which this API can be deployed are the same as those for MongoDB Cluster, with the exception of MongoDB Atlas.To facilitate deployment, we have already created a docker file in the Python code folder and repository, which is necessary to create a container that will run the API.Before uploading, however, some modifications are required.In lines 12, 13, and 14, the text between the quotes must be replaced with the access string, the database name, and the collection name, respectively.After these modifications, the algorithm is ready to be deployed as an API to the Web services.The server used to deploy the API will have a unique domain, this domain will be used in the LILYGO TTGO to send the data to the API and in the digital tool to pull the data from the database.

LILYGO TTGO
In this study, we have provided three different options of codes for the LILYGO TTGO: both remote and local data storage, local data storage only, and remote data storage only.Please, select the one that best fits your project for uploading to the board.Before uploading the LILYGO TTGO receiver code to the board, it is necessary to pay attention to some details: • Finally, change the variables in the secrets.hfile.The variable "ssid" is the name of the WiFi network to which the LILYGO TTGO will connect; the "password" is the password for this network; and "serverUrl" is the URL of the API set previously.Note that the "/store" endpoint must be retained to inform the API algorithm that the data is being sent for storage.
Upload the algorithm to the LILYGO TTGO without the microSD card inserted in the board, otherwise a connection error will occur.Lastly, use the M1.7 screws to fix the LILYGO TTGO in the 3D-printed structure and fit the cover according to the structure format (Fig. 10).

Operation instructions
To start using the data loggers' network, insert the microSD card in the LILYGO TTGO and, using a cable, connect it to a power source, turning it on.Moving to the data loggers' network, place all the temperature sensors in the desired locations.Next, connect the data loggers to the power source through the appropriate cable.It is highly recommended to wait a few moments to connect different data loggers to the power source since the data is instantly sent to the LILYGO TTGO.Connecting two or more data loggers to the power source at the same time can overload the connection, potentially leading to errors.

Digital tool
Using RStudio [28] or another Integrated Development Environment (IDE) that can run R computer language, open the runApp.R file.Please, do not change, move, or delete the other folder files.Next, run the lines 2 to 5 to install the required packages and its dependencies.This step may take time.After the packages are installed, run line 8 to reference the function where the shiny app is.Lastly, modify and run line 8 by inserting the function arguments: • "file.source"argument is the data source: "txt" from the microSD card or "NoSQL" from the remote database.
• If your data is coming from the microSD card, set the "file.path"argument to the path of your.txtfile.• If your data is coming from the remote database, set the "GET.API" argument to the server URL + "/obtain."This server URL is the same one used in the LILYGO TTGO in the variable serverUrl in which you can access your server, just changing the endpoint "/store" to "/obtain".
Please note that in the tool, the "block" is related to the iD of the datalogger set by the researcher while uploading the code to the Arduino.

Sensor calibration
In this study, we used five DS12B20 to obtain the correction factor for all the other sensors used.We used R [26] and the packages metrica [29] and ggplot2 [30] to obtain both the calibration metrics and curve graph.For metrics, the root mean square error (RMSE), mean average error (MAE), and mean average percentage error (MAPE) were calculated to compare values obtained from the sensors against those from the thermometer.Finally, a linear model was fitted to obtain the model inclination and coefficient to be inserted in  4), proving the reliability of this sensor.The model inclination and coefficient obtained were − 0.48 and 1.02, respectively.These are the values to be inserted in lines 8 and 9 of the Arduino code from Section 5.2.Data Loggers.

Validation experiment
To validate the temperature data logger network, a simple germination test was conducted in a growth chamber under controlled conditions.The chamber was maintained at 28 • C for 10 h and 22 • C for 14 h, with 60 % relative air humidity.Five pots (540.74 cm 3 volume, 4.75 cm radius, and 8.5 cm height) were filled with commercial garden substrate, and another five pots of the same volume were filled with soil.The pots were randomly placed within the growth chamber, and two corn seeds were sown in each pot at a depth of 1 cm in each pot.The pots were manually irrigated daily with 40 mL of tap water daily at 11 am, following the manual and data logger measurements.
Two data loggers were used: one with five temperature sensors for the substrate-filled pots and another with five sensors for the soil-filled pots.Each sensor was inserted into a single pot at a depth of 4 cm.Both data loggers were programmed to record temperature measurements every thirty minutes, and a commercial probe thermometer was used to manually measure the temperature of each pot every two hours, from 8 a.m. to 6 p.m. Temperature was manually determined at the same time as the data loggers were collecting soil temperature records.The probe thermometer was inserted into the soil at the same depth as the data logger temperature sensors.The LILYGO TTGO was placed outside the growth chamber to test the ability of the radio signal to transmit data over distance and across physical barriers.The data loggers collected data for 3 days, sufficient time for the corn to emerge under these conditions.Fig. 12 shows the arrangement of the pots, data loggers, and temperature sensors in the growth chamber.This setup allows for comprehensive monitoring and validation of the temperature data logger network under controlled environmental conditions.The comparison of manual probe thermometer readings and data logger measurements helps to verify the accuracy and reliability of the network for future research applications.
The digital interactive decision tool was utilized to monitor the growth chamber remotely and to visualize nighttime temperatures.Fig. 13 displays a screen capture obtained during the validation experiment.The interface includes a header titled "Temperature Sensors Dashboard" and a button to download the data as a CSV format for further analysis and evaluation.Below the header is a section labeled "Last Readings by Block," featuring cards that show the mean of the last reading for each block and the mean-variance.Additionally, there is a bar graph illustrating the last readings of each sensor and two cards displaying the minimum and maximum last readings along with their respective devices.The digital interactive decision tool also features a section for historical temperature curves, which can be displayed by block or by the mean readings of each block.The data can be grouped by hour, day, week, or month for detailed analysis.When the DS18B20 sensor has a reading error, it stores the reading as − 127 (an impossible value for this sensor).The proposed digital tool already deals with this error by removing it from the database.
After three days of data collection, the CSV file downloaded from the digital tool was used for data analysis.The CSV file has the columns "Group", relative to the data logger Id, "DateTime" relative to the date and time (MM/DD/YYYY HH:MM) that the reading was done, "Device" relative to the sensor Id within the data logger, and "Reading", relative to the temperature value (in Celsius).First, a comparison with the probe thermometer data was performed, calculating the RMSE, MAE, and MAPE using the "metrica" package in R [29].A two-sample t-test was then conducted in R using only the data logger measurements to determine if there was a significant temperature difference between the substrate and soil.Finally, a comparative analysis between block 1 and block 2 was plotted using the ggplot2 package in R [30].Since the data is in this format, simple grouping and filtering functions were necessary to manipulate the data logger data and compare it to the ground-truth data.
The results showed an RMSE of 1.65 • C, an MAE of 1.55 • C, and a MAPE of 6 % between manual and data logger measurements (Table 5).These results are most likely due to the combination of two factors: minor timing differences in data collection between the data logger recording and the manual collection and potential heat exchange when opening the growth chamber.For the second point, since the growth chamber had to be kept open for manual temperature collection, the heat exchange between the outside and inside may have affected the readings.Heat exchange when opening and keeping the doors open has been widely discussed in the literature [31][32][33], strengthening this possibility.
The t-test indicated that there was no significant difference in temperature between the soil and the substrate at 5 % probability due to the p-value being equal to 0.4393 (Table 6).The mean temperature obtained between groups 1 (commercial substrate) and 2 (soil) was very similar, with 26.52 and 26.43, respectively.These results showed that the physical properties of the soil between these two do not present any difference in the internal temperature for seedling germination.In Akter et al. [34], different soil textures and different temperatures were tested, and it was observed that the soil temperature varied depending on the texture.Since the substrate and the soil in our study had similar textures, the non-significance of the temperature obtained may be explained by the findings of Akter et al. [34].
Since the temperature inside the growth chamber varied during the night, and this temperature was not recorded due to time constraints and lack of available help, it is vital to verify the behavior of the sensors during this period.Fig. 14 shows the temperature readings for the entire validation period.It can be seen that the data logger readings successfully tracked the temperature changes inside the growth chamber.The distant readings of sensor 2 in Fig. 14a and sensor 3 in Fig. 14b can be either by i) proximity to colder regions within the growth chamber or ii) sensor with slight defect.

Characterization
When analyzing the total cost of the validation, including 10 sensors in two data loggers and one month of web service, the total cost was roughly $102.In contrast, the closest commercial product − a 12-channel data logger with both remote and local storage − costs $280 (not including sensors).For two blocks, the cost would be US$560, not including sensors.Thus, the data logger network presented in this study represents only 18 % of the cost of the closest commercial product.Using only a local database, the validation cost drops to US$97, compared to US$238 for the closest commercial product, or 232 % of the cost of our data loggers.Similar economic advantages when developing low-cost data logging systems were reported by Fuentes et al. [19], developing a low-cost autonomous data logger for photovoltaic systems.The aforementioned authors reported a minimal economy of 300 % over the closest commercial version.When developing a low-cost multi-channel data logger, Saha & Hossain [35] presented hardware costing US$30 (2006 values), which was stated to have a reduced cost compared with commercial versions.The data logger developed by the aforementioned authors only stored data locally and did not have a network, allowing readings from multiple locations.
Regarding energy consumption, since this hardware was designed for indoor usage (greenhouses and growth chambers), therefore locations where power saving is not a problem, we did not assess its practical power consumption.To make users aware of the proposed network power consumption, the theoretical power consumption was calculated using the datasheets of the used hardware.Table 7 shows the results obtained.The LILYGO TTGO has a power consumption varying from 10 to 14 mAh, and the data loggers without the DS18B20 temperature sensors (with Arduino Uno, RFM96 LoRa board) have an initial power consumption of 25.6 and 134 mAh in sleep and active mode, respectively.For each DS18B20 temperature sensor within the data logger, an additional 0.00075 and 1 mAh must be added to the power consumption in sleep and active mode, respectively.
We have encountered six major limitations with this hardware.First, the interference of the LoRa signal, receiving empty measurements from the data loggers.Orfanidis et al. and Polak et al. [36,37] have also investigated similar interference of the LoRa signal, which was mainly attributed to signals from other sources using the same frequency band.Second, the connection of the LILYGO TTGO to the WiFi network.During the validation step, we have noticed that this board connects better to a 2.4 GHz WiFi network.This limitation is because the ESP8266, the embedded component responsible for the WiFi connection in the LILYGO TTGO board, operates at a 2.4 GHz frequency [38].Third, when connecting a new sensor, it is necessary to re-label all sensors.The Arduino recognizes the sensors by their hexadecimal addresses and sorts them out by generating a sequence.If the newly connected sensor has a hexadecimal address smaller than or in the middle of the other addresses, it will take its position in the array, changing the labeled order.Fourth, the projected structure is not weatherproof, which limits it to indoor use.This limitation reduces the usability of the hardware in different studies [26].Fifth, the sensor reliability and durability, long-term duration, should be further evaluated under different conditions.Future studies can focus on moving this sensor to field settings with the goal of testing of environmental factors such as different soil   types, equipment layout, and moisture conditions.A large limitation is adjusting the time gap between readings, which can conflict with the number of sensors within a data logger and the number of data loggers in the network.Suppose the time between readings is too short for the number of sensors in one data logger.In that case, the Arduino will attempt to perform the next reading while still performing the previous, generating reading  problems.The same will occur with numerous data loggers in the network with a short interval between measurements.The last data logger will send information to the LILYGO TTGO simultaneously with the first one, generating problems while storing data.The solution found while performing tests was to empirically set the time intervals considering the desired number of sensors within a data logger and the number of data loggers in a network.Future studies for this hardware should aim at modifications that would allow it to be used under field settings.This would require i) develop a weatherproof structure by using a different material for the 3D printed structure, ii) additional insulation for the sensor inputs to keep water and other contaminants out of the system, iii) accurately measuring the power consumption to design a battery capacity for extended periods of time, and iv) designing alternative methods of powering the device such as solar panels and small wind turbines.An alternative to address the first aim is to use the same method as stated by Afshar & Wood [39] when designing weather resistant 3D printed structures.For the third and fourth objectives, a similar approach was used by Bayhan & Turhan [40], to design a solar-based data logger, which could be used as a model.However, for the fourth goal, a combination of solar and wind power generation could be used, as exemplified by Hossain et al. [41], or the use of small wind turbines only could be explored, as explored by Wang et al. [42].
In summary, a low-cost network of multi-channel data loggers has been developed for indoor temperature measurements.This network is capable of storing data locally, on a microSD card, and remotely in a NoSQL database.The network developed has an initial cost of US$ 72 (2024 values), and its cost comparison with commercial versions decreases as the experimental size increases.A single data logger can receive data from up to 24 temperature sensors, while most commercial versions have a maximum of 12 sensors.In addition, due to the LoRa connection between the data loggers and the central unit (LILYGO TTGO), the loggers can be installed apart from each other without connecting cables.The validation experiment performed in a growth chamber demonstrated the reliability of the network to read and store temperature data locally and remotely, even when placed away from the central station.Lastly, the digital tool allowed the visualization of past readings, successfully splitting the data by the data loggers and temperature sensors, exporting the data in CSV format for further analysis.This hardware has the potential to help researchers, especially (but not limited to) soil temperature experiments in greenhouses or growth chambers.

Declaration of competing interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Fig. 2 .
Fig. 2. Flowchart illustrating the operational processes of the temperature data loggers' network.

Fig. 5 .
Fig. 5. Summarization of required steps to assembly the proposed hardware.

Fig. 7 .
Fig. 7. Connecting the Temperature sensors to the sensor's PCB.All sensors' terminals must be in the same PCB trail.

Fig. 12 .
Fig. 12. Disposition of pots, data loggers, and temperature sensors during the validation.

Fig. 13 .
Fig. 13.Screenshot of the digital tool while performing the validation experiment.

Fig. 14 .
Fig. 14.Historical temperature readings obtained during the validation experiment using the proposed data loggers for commercial substrate (a) and soil (b).

Table 7
Theoretical power consumption for the LILYGO TTGO and the proposed data loggers in sleep and active modes.Hardware Power consumption (mAh) LILYGO TTGO LoRa32 10-14 Data logger with N temperature sensors in sleep mode 25.6 + N * 0.00075 Data logger with N temperature sensors in active mode 134 + N * 1

Table 1
Hardware required to build the network of temperature data loggers.

Table 2
Design file summary.

Table 3
Materials to build the sensor, components, units, cost per unit, total costs (price by July 2024), and sources.

Table 4
Metrics obtained during sensor calibration.

Table 5
RMSE, MAE, and MAPE metrics obtained from the comparison of temperature data obtained by the manual sampling using a probe thermometer and data logger data collections.