All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
After reviewing your paper, following the average evaluation of the reviewers, I have decided to accept your paper for publication.
Dear author, although most of the comments from reviewer 1 and 3 were addressed, reviewer 2 still has some concerns about your improvements. Address all their comments carefully if you want to proceed with the process.
ok
ok
ok
ok
As previously written, the article describes a technical solution for a common problem in smart farms, although it uses and describes commercial hardware modules and free software. Thus, there is no new technique, hypothesis or study.
Even though the author affirms it is a development of a scientific tool, there are several other similar tools on the market, with same low cost and different technologies. The paper do not show how significant are these changes regards the other products in the market.
The author did cite PeerJ Criteria, but I would also like to remember "PeerJ Computer Science judges articles on scientific validity and suitability to join the scholarly literature".
The author did some minor improvements but did not address the main problem in the paper as it is a scientific paper.
As stated before, there is no relevant and meaningful scientific contribution. It is a technical solution for a problem. The author did not made the suggested modifications.
There is no finding in the paper, although it is an excellent description of a technical
solution with free software and accessible hardware.
There are several ways to deal with a technical solution with a scientific approach.
After a quick search, there are several examples below of open solutions. It also shows that this solution could have been compared with several others and it hasn't. In addition, most of these solutions have more than 5 years, are common and thus, there is no scientific validity.
"Open source hardware to monitor environmental parameters in precision agriculture" - https://doi.org/10.1016/j.biosystemseng.2015.07.005
"Irrig‐OH: An Open‐Hardware Device for Soil Water Potential Monitoring and Irrigation Management" - https://doi.org/10.1002/ird.1989
"Open Hardware: A Role to Play in Wireless Sensor Networks?" - https://doi.org/10.3390/s150306818
"SEnviro: A Sensorized Platform Proposal Using Open Hardware and Open Standards" - https://doi.org/10.3390/s150305555
If there is no interest in adapting to a review paper, the contribution could be handled in several other ways. But the author did not address this situation accordingly.
No comment
No comment
No comment
I have read through the author’s responses to the reviewers and the revised version of the manuscript. I feel that my original comments have been addressed appropriately, and that the author’s responses to the other reviewers’ comments were appropriate. Overall the manuscript has been improved, and should be a useful contribution to the literature.
This work is interesting and novel but requires improvements to justify publication. Address each reviewer comment carefully, particularly those comments from Reviewer 2.
[# PeerJ Staff Note: It is PeerJ policy that additional references suggested during the peer-review process should only be included if the authors are in agreement that they are relevant and useful #]
[# PeerJ Staff Note: Please ensure that all review comments are addressed in a rebuttal letter and any edits or clarifications mentioned in the letter are also inserted into the revised manuscript where appropriate. It is a common mistake to address reviewer questions in the rebuttal letter but not in the revised manuscript. If a reviewer raised a question then your readers will probably have the same question so you should ensure that the manuscript can stand alone without the rebuttal letter. Directions on how to prepare a rebuttal letter can be found at: https://peerj.com/benefits/academic-rebuttal-letters/ #]
The article should include a section named Background to demonstrate how the work fits into the broader field of knowledge.
Relevant prior literature must be referenced, for example:
Mulla, D. J. (2013). Twenty five years of remote sensing in precision agriculture: Key advances and remaining knowledge gaps. Biosystems engineering, 114(4), 358-371.
Saura, J. R., Reyes-Menendez, A., & Palos-Sanchez, P. (2019). Mapping multispectral Digital Images using a Cloud Computing software: applications from UAV images. Heliyon, 5(2), e01277.
Seelan, S. K., Laguette, S., Casady, G. M., & Seielstad, G. A. (2003). Remote sensing applications for precision agriculture: A learning community approach. Remote sensing of environment, 88(1-2), 157-169.
The research work is clearly defined. It is relevant and meaningful.
The investigation was conducted rigorously but the author should improve the conclusion.
1) The paper has several strong points, as it has a good literature review and is very didactic about the proposed system implementation. However, there is one major problem as there is no scientific contribution.
The article describes a technical solution for a common problem in smart farms, although it uses and describes commercial hardware modules and free software. Thus, there is no new technique, hypothesis or study.
This is notable in the text, as there is no problem stated, no highlights of the paper scientific contribution and its main objective.
2) The introduction does provide sufficient background and include several relevant references. It is one of the strongest points of the paper. Most of references are from the past 5 years and there is an excellent review of them. However, I would recommend avoiding some parts as L49-53 (perishable food) and L60-64 (factories examples), they are a bit off the paper main topic. An explanation of smart farms and its context would be great before L65. In addition, the introduction seems to be missing an ending paragraph to conclude the idea and relate to the paper’s main topic.
3) English language and style are fine, with just a few minor spell checks required. However, some paragraphs are fragmented, thus the text needs a small revision (For example, L46-47).
4) Most of figures are good with enough information. One exception is the text in figures 6, 7, 8 and 11, which is not legible in the pdf.
It is an interesting topic and matches the paper scope. Although it isn’t an easy implementation and requires a lot of study and tests, there is no relevant and meaningful scientific contribution. It is a technical solution for a problem.
A solution would be to make a comparison study with other solutions and actually test its performance or propose a new structure in communication. There are several solutions for this application with better technologies, using Zigbee and Lora networks (for example). However, it would still be hard to find a scientific gap for the study.
My suggestion for the author is to change the paper scope/type to a literature review. The paper review is excellent and updated. There aren’t many reviews about these systems lately and would be great with your example of implementation with MeteoMex.
For this, only a few things have to change. For example, an expansion of the literature review as a “first part”, an example of sensor module construction with MeteoMex for a second part and some “study cases” as a third part.
There is no finding in the paper, although it is an excellent description of a technical solution with free software and accessible hardware.
I believe the paper is not suitable for publication as it is now. However, I suggest to turn it to a literature review paper as I described in 2.
No comment
No comment
No comment
The MeteoMex project appears to be a fairly complete set of design files and software examples necessary for making a functional sensor reporting device. I have raised some issues in the specific comments below that I feel would make the manuscript more readable and useful to the interested reader. While the files are made available on Github (a commercial site with an uncertain long-term existence), I would recommend that you also create a permanent archived copy of the existing repository on a long-term archiving site such as zenodo.org, which provides free archiving. It’s certainly appropriate to provide updated files on Github on an ongoing basis.
The introduction could be more concise, as the listing of the various challenges of food production, storage, wastewater treatment, etc. seem to go on for a long time before the crux of the project is reached, which is a system to help monitor various aspects of these various industries and environments.
Line 19 Abstract: “analog, digital and I2C sensors” should be reworded, since in this context I2C is a digital protocol and a sensor using the I2C protocol is not different from the generic term “digital sensor”.
Line 46-47: This is a sentence fragment
Line 57-58: This sentence doesn’t seem relevant to the thrust of the paper. It could be removed.
Line 73: agriculture 4.0 is used here without a useful definition. The only definition I find appears at the end of the paper at line 380.
Line 86: AA battery does not need periods after each A.
Line 88-90: It’s not immediately clear what the purpose or service provided by Blynk, ThingSpeak, MQTT is, for a reader not already familiar with those services. This sentence should be split into two, and the role of these services should be more clearly explained. The MQTT acronym should be defined.
Line 90-91: This sentence conveys no useful information and could be cut to make the introduction more concise.
Line 93-94: This sentence gives a brief description of the attributes of the MeteoMex project, but no description of the specific capabilities (i.e. what can/could it measure, how frequently, what kind of power requirements). Those capabilities are described in more detail in section 2, but a brief rundown should be provided in the introduction.
Figure 1: Which part the term “shield” is referring to in the caption isn’t self-evident until the reader has read the text and figured out that the PCB referred to in the caption is the shield. I would suggest changing the initial sentence of the caption to read “A) circuit and B) PCB “shield”.”
Line 99: The units of the board dimensions are given as mm squared, but the number provided are the linear dimensions (mm), so the mm2 label should be changed to mm.
Line 120-121: The DeepSleep mode is mentioned a few times in the manuscript, but it is never properly explained what this mode does. The sentence on Line 121 confuses me, since the way it is written makes it sound like the jumper needs to be closed manually in order to wake the device, and that this would need to be closed by the user each time they wanted to wake the device. But normally I would assume that a deep sleep mode would have some facility to automatically wake itself, either on a regular time interval or because of some external sensor interrupt being triggered, rather than the user needed to physically close a jumper. If the deep sleep mode works normally, this sentence should be reworded to say something like “For enabling the DeepSleep mode, the jumper J1 must be closed.”
Line 124: The manufacturer (Maxim) for the DS18B20 should be listed.
Line 127: From what I read, the maximum input voltage for the analog input on the Wemos is 3.2V, so it might be worth mentioning that analog sensors that use a 5V supply must still limit their output range from 0 to 3.2V to avoid damaging the analog channel on the microcontroller.
Line 131: The manufacturer and part number for the turbidity sensor should be provided.
Line 132: The manufacturer for the JSN-SR04T sensor should be provided.
Line 158: change “why” to “so”
Line 164-165: Awkward phrasing for the sentence beginning “Programming a DeepSleep/WakeUp…”
Line 166: What is an accumulator in this context? A battery?
Line 239: Using a neural network to estimate solar irradiance from temperature humidity and pressure seems overly complicated and not relevant to this project. A lux or PAR sensor (though PAR sensors are expensive) could give similar information on irradiance and also interface to the MeteoMex.
Lines 247-253: The process of calibrating a soil moisture sensor is glossed over here. Please provide a reference to give a more detailed description of a proper calibration routine.
Line 254-256: After giving the soil temperature in Celsius, the units change to Kelvin for the subsequent temperature values. Why not continue using Celsius, especially if they are interchangeable with respect to numeric value?
Line 260: I assume the temperature peak was at 12 pm, not am.
Line 261: The phrasing of this sentence is awkward. It would read better as “… point is only exposed to direct sunlight for a short period of the day.”
Line 270: “economical” instead of “economic”
Lines 272-281: I’m not sure that the example of monitoring air temperature a server room merits a separate section and figure here. Monitoring air temperature was adequately covered in section 3.3. I think most of section 3.4 could be cut to help make the paper more concise, and a mention of the server room air temperature results could be made in a sentence in the paragraph on lines 265-269 where another air temperature monitoring usage is described.
Line 329: change “importing” to “important”
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.