Communication between two arduinos in forest

Hello,

I have some experience with arduino but not working with it very often so please excuse my inaccuracies and english.

I'd like to make weather station at our cottage. I'd like to receive data every hour to some iot hub to work with them.
Problem is that there is no GSM network, closest place where i can at least make a phone call is about 300 meters through (most of the time really wet) forest with 60 meters elevation.
So my idea is to have weather station near cottage which would send data to upper station that would send them via GSM. But I'm not sure how to transfer data between those two. Is it possible via radio communication? I guess the terrain will affect range a lot. Also i wouldn't like to replace batteries more than once a month.

I will be really grateful for every answers. Thanks!

There are a number of radio options. The forest may well defeat the shorter range ones though. LoRa is probably your best bet.

vote for LORA.
there was already a similar topic some months ago: Arduino Forum

I can recommend these "ready to go" modules: Lora Radio Node - battery-powered, programmable as ProMini in the Arduino IDE, 3.3V/8MHz,

Definetly LoRa, here is the report on the testing I did in a wet and dry forest.

The sensor transmitter is no problem in itself, that could last for years on battery using a bare bones Arduino.

The issue is the remote receiver, that passes on the data via GSM.

The receiver needs to be powered to work of course, and a SX127x LoRa setup would take around 12mA, and a SX126x around 6mA, so batteries would not last long, a set of AAs would last around 10 or 20 days.

However if the sensor sender at the cottage can be connected to mains power, or a much larger battery, then you can set it up so that the remote receiver is in deep sleep most of the time with the receiver off, then wakes up and listens for say one second a minute. The transmitter at the cottage just keeps sending the sensor packet until it gets an acknowledge. Sure it might take on average 30 seconds to complete the data send, but the 10 day battery life of the remote is now extended to circa 600days.

I have trialed exactly this code for my LoRa library as a way of significantly saving the amount of power a GPS tracker uses. Why send the tracker location if there is no receiver nearby ? So the tracker goes to deep sleep most of the time and wakes up periodically to see if anyone is nearby listening.

During the day, I charge the battery of my out in the yard weather station using a solar cell.

I really appreciate your answers guys. I forgot to mention that cottage has no electricity. But i really like the deep sleep and solar panel ideas. I could probably synchronize time when transmitter will wake up and send data and receiver would wake up too and listen at the same time. For one minute or so. Thanks!

My weather station, ESP32, deep sleeps for 5 minutes per cycle. The battery is a 3300mAh. The location of the weather station does not receive any direct sunlight. With a 12V 20W solar cell, the battery is, typically, charged by 0900. I disconnected the solar cell, the weather station ran for 4 nights and 4 days before I plugged in the solar cell for charging.

I use MQTT on 4 ESP32's doing different tasks weather station, humidity control, HVAC control, plant lighting to pass info around.

I'm using 3.7 LION packs, around 2000mAh, small 5V panels (80x80mm), and CN3065 modules for charging. The modules are sending every 5 minutes, flicker a LED just for fun, go only into deepsleep if the voltage falls below 4.0 V (in 8 sec steps as its the maximum on the AVR I found so far). No problems in the last 10 months.

Another module reads a water 12V pressure/transducer using a step up converter, has an LCD incl. backlight. Same story, on good days the LCD is always on. If it's "low" on battery, it switches of the backlight, the step up converter and goes into deepsleep. So not really the "low power" solution, but as long it's running even in winter during bad weather periods, why not.