Some Clarification of Automatic Power Control (RFM69_ATC)

[jrdoner]

Suppose that I am building a star network, where all remote units talk to a master station, but not to each other.  I want the Master Station to adjust the power levels of the remotes, but I want the master to remain at a fixed preset power level.   Do I initialize all but the Master as RFM69_ATC, and intialize the Master as just RFM69, or if not, what?

Tanks in advance for your help.

[TomWS]

Suppose that I am building a star network, where all remote units talk to a master station, but not to each other.  I want the Master Station to adjust the power levels of the remotes, but I want the master to remain at a fixed preset power level.   Do I initialize all but the Master as RFM69_ATC, and intialize the Master as just RFM69, or if not, what?

Tanks in advance for your help.

You would initialize all to use RFM69_ATC because the control requires both ends of a connection to be aware of the ATC feedback request.  On the 'Master' end, you would NOT set radio.enableAutoPower(TARGET_RSSI); or you would set it, but with a value of zero.  Either way, the 'Master' endpoint would simply have the code to respond to the other endpoints with the reflected RSSI value.  The Master end wouldn't adjust its own transmit level and would transmit at whatever level you initially set.

Don't hesitate to ask if you have any further questions,
Tom

[jrdoner]

Ok,

Thanks for the quick, very clear reply.

[Jferns]

Regarding RFM69_ATC  I  have seen that when the node power is reduced and then if gateway goes out of range  then nodes are not  increasing power to find the gateway. Power increase or decrease is only  occurring if  gateway responds with Acks. I have seen deadlocks occur as  gateway may sometimes never receive low power  transmits.

This issue is easy to reproduce.

For testing I added a function locally to the library to increase  transmit power if gateway is not responding with ACK and  could avoid these deadlocks.

[TomWS]

Regarding RFM69_ATC  I  have seen that when the node power is reduced and then if gateway goes out of range  then nodes are not  increasing power to find the gateway. Power increase or decrease is only  occurring if  gateway responds with Acks. I have seen deadlocks occur as  gateway may sometimes never receive low power  transmits.

This issue is easy to reproduce.

For testing I added a function locally to the library to increase  transmit power if gateway is not responding with ACK and  could avoid these deadlocks.

"then if gateway goes out of range" - Why would this happen?  Is your node moving with respect to the Gateway?  The ATC library assumes stationary nodes and also assumes that the 'target' value is not so low as to be past the edge of a reliable connection.  Given that adjustment is only made when an Ack is received and the starting point is a strong transmit level, I'm not seeing how this case can happen.  Please explain.

Tom

[Jferns]

Hi Tom,

I agree node used in my testing was not stationary.

Let's assume a node initially is in range and transmits to gateway, gateway Acks and node reduces power. This goes on till target Rssi is reached. Now if node is moved to a different place/room and if the reduced power is not sufficient to reach the gateway a deadlock occurs. From this new location node can only reach gateway with increased power or node restart.

---JFerns

[TomWS]

Hi Tom,

I agree node used in my testing was not stationary.

Let's assume a node initially is in range and transmits to gateway, gateway Acks and node reduces power. This goes on till target Rssi is reached. Now if node is moved to a different place/room and if the reduced power is not sufficient to reach the gateway a deadlock occurs. From this new location node can only reach gateway with increased power or node restart.

---JFerns

Ok, I agree that's the result of your scenario, but that is not the intent of the ATC library.  Its purposefully slow response and no change on missing ACK are done to accommodate slowly varying conditions (and busy gateways) for stationary nodes.  For your scenario, it might makes sense to do what you are suggesting in your receive code, although I would probably adjust transmit level upward only after 'n' missed ACKs, it's an implementation choice.  If the node is relatively fast moving then I suggest that you stick with the standard RFM69 library for that node.

Tom

[Kilo95]

How long does it take for the node  to start dialing down the power?

[Felix]

As soon as you start transmitting. It starts at full power and dials down (-1 on output power) with each sent packet until it settles to the given RSSI.

[Kilo95]

Ok. I must not have something set properly. I'm at -53 to -54. And they're only about 30 feet apart. I'll have to check

[TomWS]

Ok. I must not have something set properly. I'm at -53 to -54. And they're only about 30 feet apart. I'll have to check

What's your target RSSI?  -53 to -54 is relatively strong signal and might be the lowest you can get at that distance.

Tom

[Felix]

If you keep them close, then they will dial down to minimum, yet you will still get a relatively strong signal, which makes perfect sense. If these radios can do 200km with high altitude balloons, then I sure expect a pretty strong signal at minimum output power at 30ft.

[Kilo95]

I set the target to -69. I watched on the serial monitor and it doesn't dial down. I put the #include rfm69_atc.h and put the radio.autopower(-69); after setup() on the node but can't get it to dial down. Also placed rfm69_atc.h in pigateway node. Also substituted rfm69_atc radio for rfm69 radio. I downloaded latest libs from GitHub. I figured it'd drop a little more than -53 or -54 at 30 feet. Maybe I'm wrong

[Felix]

So it starts at ~ -54 and stays there the entire time?

[Kilo95]

Yep.