the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 27 Nov 2025
Design and implementation of a robust data logging and satellite telemetry system for remote research
Abstract. Scientific research frequently requires data acquisition and transmission from remote environments, requiring robust, autonomous solutions capable of operating in extreme environmental conditions with minimal maintenance. This study presents the design and implementation of a data logging and telemetry system deployed in the Western Cwm of Mount Everest, Nepal, to transmit several meteorological parameters from an automatic weather station and firn layer temperatures obtained from a suite of borehole thermistors. Drawing on recent advances in satellite Internet of Things (IoT) connectivity, we present the successful integration and deployment of Campbell Scientific data loggers with Ground Control’s compact satellite-enabled RockREMOTE Mini, which uses the Iridium Certus 100 networks and is powered by Iridium’s 9770 modem. The complete system, which operated at 6,660 m a.s.l, in an extremely cold climate with a limited sky-view factor due to the steep surrounding terrain, provided continual monitoring of ice temperatures and meteorological conditions transmitted every 24 hours, from May 4 to August 10, 2025. Data integrity and transmission reliability were consistently maintained despite the harsh weather conditions and limited power availability. This integrated system established a robust methodological framework for other researchers working in remote locations, demonstrating the potential for sustained and high temporal resolution measurements of environmental conditions in locations where traditional communication infrastructure is unavailable.
Competing interests: My co-author, Michael Mitrev, is employed by Ground Control, who design and distribute the RockREMOTE series of products.
Publisher's note: Copernicus Publications remains neutral with regard to jurisdictional claims made in the text, published maps, institutional affiliations, or any other geographical representation in this paper. While Copernicus Publications makes every effort to include appropriate place names, the final responsibility lies with the authors. Views expressed in the text are those of the authors and do not necessarily reflect the views of the publisher.-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(1610 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1610 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2025-4346', Anonymous Referee #1, 28 Dec 2025
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-RC1-supplement.pdfCitation: https://doi.org/
10.5194/egusphere-2025-4346-RC1 -
AC1: 'Reply on RC1', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC1-supplement.pdf
-
AC1: 'Reply on RC1', Sunil N. Oulkar, 07 Feb 2026
-
RC2: 'Comment on egusphere-2025-4346', James Veale, 06 Jan 2026
General Comments
This contribution presents a methodological framework for the integration of satellite communication with data acquisition in remote environment. It provides detail of a system using specific hardware and satellite technologies. The methodology is well described, and a strong assessment of the system’s performance is given.
Although the work as described is constrained to specific hardware, communications, and data processing workflows, the community would benefit from its publication – particularly due to the level of detail provided as supplementary material, which aims to enable further adoption of this remote monitoring approach. The inclusion of discussion of alternative microcontrollers and satellite communication systems is good, but could be expanded upon. I would additionally like to see discussion on alternatives to the presented ETL (data extraction, transformation, and loading) pipeline.
I recommend the publication of this contribution, subject to minor revisions and some expanded discussion to address the points listed below. I hope these comments will aid in its successful publication.
Specific Comments
L.144: In discussion of the RockREMOTE power consumption, a figure is given for the idle wattage (300mW). It would be worth also providing the value for the transmission wattage (~7250mW?).
Fig. 4: I understand this figure has been simplified to fit within the manuscript, could a more detailed workflow be given in an Appendix? The figure may also benefit from improved clarity if it adhered to ISO 5807 – but this is not a strictly necessary improvement.
L.203: The performance of the dynamic power control described here should be assessed in the Discussion section
L.257: I would appreciate discussion of why Cloudloop was chosen. Is it locked in by the choice of hardware?
L.275: Similarly, discussion on alternative ETL pipelines would be beneficial. It is outside of my expertise to comment on the suitability of the pipeline presented, but could Cloudloop handle much of the pipeline natively? Also what about cloud native solutions? What about the limitations of relying on cloud services? These kinds of questions could be addressed.
L.289: Some of the inherent limitations of using Excel for data transformation are alluded to here, as are some better alternative tools. I would recommend a programming approach over Excel more strongly than it is in the manuscript.
L.312: It is said that the measurements ceased due to structural collapse of the setup, how is this known/inferred? Is it suggested by data from the AWS?
L.318: Inclusion of specific data on transmission reliability is excellent. Looking at the battery voltages in Fig. 5, I can see that the few days where repeat attempts were required were not due to power supply and so must be an issue with satellite availability. It may be worth making it clear here that it was this that the retry protocol successfully dealt with. Additionally, as you’ve talked about the applicability of this system to polar environments, discussion of how you expect performance to differ in the polar regions (if at all) given the differences in satellite availability and terrain or sky-view may be good.
L.331: Given that the experimental setup is no longer functioning, do you have any modelling on the difference expected during the winter that could be included or referred to? On this note, analysis of the energy data collected could be presented in more detail than Fig 5 – a daily energy budget with variance for example.
Fig.9: The figure shows that three transmitters were used, one per instrument. It might be worth discussing the benefits of this architecture over the alternative of a single transmitter for all three data loggers. Or indeed the same for the choice of separate data loggers for the AWS and thermistors.
L.371: Discussion of the benefits of remote data acquisition in this paragraph is very good. Could situations where it is less suitable be discussed? (However, I do struggle to think of examples myself, other than in the case of sites which are regularly visited for other purposes already.)
L.431: The proposed future work is excellent. Developing standardised deployment protocols will allow researchers to do similar work with less help from engineers/programmers - lowering the barrier to entry for projects lacking technical expertise.
L.435: Including code and detailed instructions for the data extraction workflow is excellent and benefits the contribution significantly.
Technical Corrections
No technical corrections noted.
Citation: https://doi.org/10.5194/egusphere-2025-4346-RC2 -
AC2: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC2-supplement.pdf
-
AC4: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC4 -
AC5: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC5
-
AC2: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
-
RC3: 'Comment on egusphere-2025-4346', Pratik Kad, 07 Jan 2026
The manuscript presents a well-executed design and deployment of an integrated data logging and satellite telemetry system at the Western Cwm of Mount Everest ( at 6,660 m a s l) and addresses an important observational gap in high-mountain research. I have the following comments and suggestions:
-
The study is timely and technically robust, but the novelty of the approach relative to existing automatic weather station telemetry deployments should be articulated more clearly.
-
Satellite telemetry has previously been used in high-altitude and polar environments, and the authors should explicitly clarify what differentiates this system from earlier Iridium-based or ARGOS-based implementations. This would be helpful to readers.
-
Short comparative discussion Or table, summarising improvements relative to previous systems in terms of power consumptieon, data throughput, latency, cost efficiency, or transmission reliability would substantially strengthen the manuscript.
-
The statement that data integrity andd transmission reliability were consistently maintained remains largely qualitative and should be supported by quantitative evidence. The authors are encouraged to report the percentage of successful daily data transmissions achieved during the deployment period.
-
Information on the number and duration of any transmission gaps would improve transparency and allow readers to better assess system robustness.
-
A time series showing battery voltage or power availability, particularly during periods of low solar insolation or adverse weather, would enhance the technical evaluation.
-
If available, statistics on data packet loss, retransmissions, or failed communication attempts should be included. Also, power availability is a critical constraint in high-altitude environments.. yet the current description of power management remains relatively general.
-
The authors should clarify how frequently the Rock REMOTE Mini was active compared to time spent in sleep mode.
-
It should be specified whether telemetry was strictly schedduled at fixed intervals or triggered by specific events or thresholds.
-
Additional information on system behaviour during extended cloudy periods, snowfall events, or prolonged low insolation would be valuable.. given the importance of surface energy balance in high-mountain environment, a clearer link between environmental conditions and power system performance would strengthen the manuscript.
-
The introduction provides a solid overveiew of cryospheric relevance but could better connect telemetry developments to specific scientific questions in mountain climate and glacier research.
-
The authors are encouraged to discuss how daily or near-real-time telemetry improvs the interpretation of firn temperature evolution.
-
It would be useful to explain how rapid data access reduces scientific risks such as sensor burial, melt event, or abrupt thermal changes.
-
The stated operational period from 4 May to 10 August 2025 is clear, but a brief explanation of why the system was not operated through winter would improve context. Alos, It should be clarified whether winter operation was limited by powor availability, logistical constraints, environmental risks, or project scope.
Citation: https://doi.org/10.5194/egusphere-2025-4346-RC3 -
AC3: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC3-supplement.pdf
-
AC6: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC6
-
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2025-4346', Anonymous Referee #1, 28 Dec 2025
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-RC1-supplement.pdf
-
AC1: 'Reply on RC1', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC1-supplement.pdf
-
AC1: 'Reply on RC1', Sunil N. Oulkar, 07 Feb 2026
-
RC2: 'Comment on egusphere-2025-4346', James Veale, 06 Jan 2026
General Comments
This contribution presents a methodological framework for the integration of satellite communication with data acquisition in remote environment. It provides detail of a system using specific hardware and satellite technologies. The methodology is well described, and a strong assessment of the system’s performance is given.
Although the work as described is constrained to specific hardware, communications, and data processing workflows, the community would benefit from its publication – particularly due to the level of detail provided as supplementary material, which aims to enable further adoption of this remote monitoring approach. The inclusion of discussion of alternative microcontrollers and satellite communication systems is good, but could be expanded upon. I would additionally like to see discussion on alternatives to the presented ETL (data extraction, transformation, and loading) pipeline.
I recommend the publication of this contribution, subject to minor revisions and some expanded discussion to address the points listed below. I hope these comments will aid in its successful publication.
Specific Comments
L.144: In discussion of the RockREMOTE power consumption, a figure is given for the idle wattage (300mW). It would be worth also providing the value for the transmission wattage (~7250mW?).
Fig. 4: I understand this figure has been simplified to fit within the manuscript, could a more detailed workflow be given in an Appendix? The figure may also benefit from improved clarity if it adhered to ISO 5807 – but this is not a strictly necessary improvement.
L.203: The performance of the dynamic power control described here should be assessed in the Discussion section
L.257: I would appreciate discussion of why Cloudloop was chosen. Is it locked in by the choice of hardware?
L.275: Similarly, discussion on alternative ETL pipelines would be beneficial. It is outside of my expertise to comment on the suitability of the pipeline presented, but could Cloudloop handle much of the pipeline natively? Also what about cloud native solutions? What about the limitations of relying on cloud services? These kinds of questions could be addressed.
L.289: Some of the inherent limitations of using Excel for data transformation are alluded to here, as are some better alternative tools. I would recommend a programming approach over Excel more strongly than it is in the manuscript.
L.312: It is said that the measurements ceased due to structural collapse of the setup, how is this known/inferred? Is it suggested by data from the AWS?
L.318: Inclusion of specific data on transmission reliability is excellent. Looking at the battery voltages in Fig. 5, I can see that the few days where repeat attempts were required were not due to power supply and so must be an issue with satellite availability. It may be worth making it clear here that it was this that the retry protocol successfully dealt with. Additionally, as you’ve talked about the applicability of this system to polar environments, discussion of how you expect performance to differ in the polar regions (if at all) given the differences in satellite availability and terrain or sky-view may be good.
L.331: Given that the experimental setup is no longer functioning, do you have any modelling on the difference expected during the winter that could be included or referred to? On this note, analysis of the energy data collected could be presented in more detail than Fig 5 – a daily energy budget with variance for example.
Fig.9: The figure shows that three transmitters were used, one per instrument. It might be worth discussing the benefits of this architecture over the alternative of a single transmitter for all three data loggers. Or indeed the same for the choice of separate data loggers for the AWS and thermistors.
L.371: Discussion of the benefits of remote data acquisition in this paragraph is very good. Could situations where it is less suitable be discussed? (However, I do struggle to think of examples myself, other than in the case of sites which are regularly visited for other purposes already.)
L.431: The proposed future work is excellent. Developing standardised deployment protocols will allow researchers to do similar work with less help from engineers/programmers - lowering the barrier to entry for projects lacking technical expertise.
L.435: Including code and detailed instructions for the data extraction workflow is excellent and benefits the contribution significantly.
Technical Corrections
No technical corrections noted.
Citation: https://doi.org/10.5194/egusphere-2025-4346-RC2 -
AC2: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC2-supplement.pdf
-
AC4: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC4 -
AC5: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC5
-
AC2: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
-
RC3: 'Comment on egusphere-2025-4346', Pratik Kad, 07 Jan 2026
The manuscript presents a well-executed design and deployment of an integrated data logging and satellite telemetry system at the Western Cwm of Mount Everest ( at 6,660 m a s l) and addresses an important observational gap in high-mountain research. I have the following comments and suggestions:
-
The study is timely and technically robust, but the novelty of the approach relative to existing automatic weather station telemetry deployments should be articulated more clearly.
-
Satellite telemetry has previously been used in high-altitude and polar environments, and the authors should explicitly clarify what differentiates this system from earlier Iridium-based or ARGOS-based implementations. This would be helpful to readers.
-
Short comparative discussion Or table, summarising improvements relative to previous systems in terms of power consumptieon, data throughput, latency, cost efficiency, or transmission reliability would substantially strengthen the manuscript.
-
The statement that data integrity andd transmission reliability were consistently maintained remains largely qualitative and should be supported by quantitative evidence. The authors are encouraged to report the percentage of successful daily data transmissions achieved during the deployment period.
-
Information on the number and duration of any transmission gaps would improve transparency and allow readers to better assess system robustness.
-
A time series showing battery voltage or power availability, particularly during periods of low solar insolation or adverse weather, would enhance the technical evaluation.
-
If available, statistics on data packet loss, retransmissions, or failed communication attempts should be included. Also, power availability is a critical constraint in high-altitude environments.. yet the current description of power management remains relatively general.
-
The authors should clarify how frequently the Rock REMOTE Mini was active compared to time spent in sleep mode.
-
It should be specified whether telemetry was strictly schedduled at fixed intervals or triggered by specific events or thresholds.
-
Additional information on system behaviour during extended cloudy periods, snowfall events, or prolonged low insolation would be valuable.. given the importance of surface energy balance in high-mountain environment, a clearer link between environmental conditions and power system performance would strengthen the manuscript.
-
The introduction provides a solid overveiew of cryospheric relevance but could better connect telemetry developments to specific scientific questions in mountain climate and glacier research.
-
The authors are encouraged to discuss how daily or near-real-time telemetry improvs the interpretation of firn temperature evolution.
-
It would be useful to explain how rapid data access reduces scientific risks such as sensor burial, melt event, or abrupt thermal changes.
-
The stated operational period from 4 May to 10 August 2025 is clear, but a brief explanation of why the system was not operated through winter would improve context. Alos, It should be clarified whether winter operation was limited by powor availability, logistical constraints, environmental risks, or project scope.
Citation: https://doi.org/10.5194/egusphere-2025-4346-RC3 -
AC3: 'Reply on RC2', Sunil N. Oulkar, 07 Feb 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2025/egusphere-2025-4346/egusphere-2025-4346-AC3-supplement.pdf
-
AC6: 'Reply on RC3', Sunil N. Oulkar, 07 Feb 2026
Publisher’s note: the content of this comment was removed on 9 February 2026 since the comment was posted by mistake.
Citation: https://doi.org/10.5194/egusphere-2025-4346-AC6
-
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 375 | 244 | 37 | 656 | 25 | 25 |
- HTML: 375
- PDF: 244
- XML: 37
- Total: 656
- BibTeX: 25
- EndNote: 25
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Sunil N. Oulkar
Matthew W. Peacey
Michael Mitrev
Duncan J. Quincey
Bryn Hubbard
Tom Matthews
Ankita S. Oulkar
Katie E. Miles
Ann V. Rowan
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(1610 KB) - Metadata XML