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.

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: 

1. 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.

2. 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. 

3. 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.

4. 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.

5. Information on the number and duration of any transmission gaps would improve transparency and allow readers to better assess system robustness.

6. A time series showing battery voltage or power availability, particularly during periods of low solar insolation or adverse weather, would enhance the technical evaluation.

7. 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.

8. The authors should clarify how frequently the Rock REMOTE Mini was active compared to time spent in sleep mode.

9. It should be specified whether telemetry was strictly schedduled at fixed intervals or triggered by specific events or thresholds.

10. 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.

11. 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.

12. The authors are encouraged to discuss how daily or near-real-time telemetry improvs the interpretation of firn temperature evolution.

13. It would be useful to explain how rapid data access reduces scientific risks such as sensor burial, melt event, or abrupt thermal changes.

14. 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.