ramses_rf transmits too many packets per unit time

[brucemiranda]

When the offical Honeywell HGI80 is used as the serial device, ramses_cc or ramses_rf are stressing it too much and the HGI80 hits a max duty cycle and shuts down. This is an inbuilt function designed to stop RF jamming.

ramses_cc and ramses_rf need to respect the etiquette of RF communications and be a bit less chatty. The HGI80 has to be the gold standard.

Currently using ramses_cc 0.41.7 with a manually adjusted ramses_rf 0.31.13

[zxdavb]

IMO, there is no evidence that ramses_rf is exceeding the HGI80 duty cycle. This is on the basis of personal testing, and user feedback in the various forums.

The last reports of such were from around 2019-2020.

In this case, my understand from other channels is that @brucemiranda has identified another cause for his symptoms.

However, it remains possible to exceed the HGI80 duty cycle if ramses_rf is abused by the user, e.g. multiple back-to-back restarts of HA with the cache disabled.

[brucemiranda]

ramses_cc should slow down it's queries made

[zxdavb]

All the HGI80 (868.3 MHz) docs I've seen do not specify its duty cycle, but my understanding from the ETSI EN300.220-2 standard is that anything in band M (868.0-868.6 MHz), the duty cycle limit should be 1%.

Reference: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/

I appreciate that ramses_rf is very chatty, but this is a trade-off between a lower duty cycle and having convergent data...

A lot of work has gone into reducing the Tx rate as much as possible, and ramses_rf imposes a duty cycle of 1% per 60s in any case.

There are opportunities for further gains in the future (i.e. eavesdropping 3220 packets between the controller and the OTB in preference to sending periodic 3220|RQ|OTBs - this is planned.

[zxdavb]

ramses_cc should slow down it's queries made

It would be useful to hear people's thoughts on why they believe the rate is excessive?

What Tx rate would be acceptable?