Transmission delay does not change

I am using a few PR52-33P with a MQTT gateway.
In order to test range, I changed the default delay to 1, so that the sensors would transmit almost continously.
However, I noticed that the nodes no longer act as relays. They are either in direct range of the gateway or they do not communicate at all, even if they have another node in range of the gateway, 50 meters away from them in direct line of sight. The mesh functionality is not working.
I considered that maybe the mesh does not work when they are transmitting continuously. So, I tried to change the delay to a number larger than 1. I tried 2, I tried 4, I tried the default 10, I even tried 30, but to no avail. The nodes go on transmitting almost continuously. At best, they transmit every 5 seconds. I followed the configuration instructions described in

I ran all the steps until I obtained the status in the devices tab. The status always lists an “undefined” error.
So, my questions are:
1-Is the fact that the nodes are not acting as a mesh related to the delay of the transmission?
2-Why can’t I change the node’s delay to a different value?

node wont act as relays because they sleep right after sending the packet.
if you want to use them as relays them disable th e sleep mode.
for that

  1. remove radio module
  2. connect tp pc using usb modem
  3. use xctu to disable sleep mode of th radio


But if I disable the sleep mode, won’t the battery be gone in a very short while? I thought that the nodes could act as relays by synchronising their sleep periods, and waking up all at the same time, to both transmit and relay other nodes’ messages. If I disable the sleep mode, what will be the expected duration of the batteries?

You are correct about battery life. they will be gone in no time. that why we recommend external powered devices for such use case

I am terribly disappointed with your response.
Your technical description borders on false advertising, as you claim that your nodes last for 10 years, they have ranges of 2 km, and that they perform mesh network services. You fail to mention that you can’t have both at the same time, and that the range is 10 x lower in an urban environment.
You never say that in order to have a mesh the nodes have to be always awake, and that will deplete the batteries.
In fact, these devices have proven to be an outright disappointment in every aspect, from the cheap switch that breaks at the first use, to the performances which are far, far away from the advertised.

if you use the batteries at high current consumption they will drain quicker. its true for all batteries and all products.
here is a video which clearly explain how it works

I know that if I turn sleep off, the batteries will go away soon (how soon, by the way?). Of course. But in good communications protocols, all the nodes go to sleep synchronously, then they all wake up at the same time, they relay each other’s messages, and they go back to sleep. That’s how DigiMesh is supposed to be implemented. And that’s the view that one takes from reading your misleading brochures.
Why can’t you program the nodes to wake up once an hour, and then relay each other’s messages for, say 10 seconds, and then go back to sleep?

Oh, and by the way, your video extols the virtue of the mesh network, and the autonomy of 10 years. But never did I hear you say that it is either one or the other. That you cannot have a mesh network and a 10 year autonomy. That makes ALL the difference.