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.
Quote from: jrdoner on November 30, 2015, 09:24:15 PM
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
Ok,
Thanks for the quick, very clear reply.
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.
Quote from: Jferns on December 05, 2015, 12:14:38 AM
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
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
Quote from: Jferns on December 05, 2015, 09:19:02 AM
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
How long does it take for the node to start dialing down the power?
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.
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
Quote from: Kilo95 on February 01, 2016, 06:32:07 PM
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
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.
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
So it starts at ~ -54 and stays there the entire time?
Yep.
Can you try the Node and Gateway examples from here (https://github.com/LowPowerLab/RFM69/tree/master/Examples), they are tested to work with ATC.
Quote from: Kilo95 on February 01, 2016, 09:30:52 PM
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
At 30 feet, it's unlikely to be able to drop the transmit power low enough to get -69 RSSI on the receive end; -54 seems reasonable to me. The most telling parameter is radio._transmitLevel, if this is at the minimum then that's perfect - you're not wasting any power in the connection. Print out that value as you start up the connection and you can watch it track to its final value.
Tom
Ok. I didn't do anything different. Checked this morning and it's tuned down to -61. I might swap out to a half wave antenna for kicks and giggles. I know it should make more difference on the gateway moteino. Thanks for the suggestions
to get ATC to work, do i need to add #define ENABLE_ATC to the sketch, or just the radio.sendwithretry, enableautopower(RSSI), and the ATC radio command?
See this node example (https://github.com/LowPowerLab/RFM69/blob/master/Examples/MotionMote/MotionMote.ino) for how ATC is used.
Quote from: Kilo95 on March 16, 2016, 01:48:07 PM
to get ATC to work, do i need to add #define ENABLE_ATC to the sketch, or just the radio.sendwithretry, enableautopower(RSSI), and the ATC radio command?
Did you monitor radio._transmitLevel as I had suggested earlier? THAT will tell you directly what the ATC is doing.
Tom
im using the weathershield node sketch. I assume I should put it in this section?
-------------
radio.encrypt(ENCRYPTKEY);
sprintf(buffer, "WeatherMote - transmitting at: %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
---------------
Would this be the correct command?
sprintf(buffer, radio._transmitLevel);
ok, so i looked back into one of tom's other posts and tried to add the command to get my radio tx level. using the serial monitor in arduino, it showed tx level of 31 and RSSI 0 but it only showed that once. i'm attaching my WS sketch and PiGateway sketch. maybe someone has the time to tell me what i'm doing wrong. thanks!
i've been trying this to no avail. made more changes to WS sketch and it still shows the tx level is 31 and my RSSI as0. it never tunes it down. below is the WS sketch. you can disregard the WS sketch in the previous post. Any suggestions?
This is what i get in the Arduino serial monitor:
My TX level:31, my RSSI:0
BAT:4.86v F:7151 H:41 P:29.20 (packet length:29)
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
WAKEUP
My TX level:31, my RSSI:0
BAT:4.86v F:7183 H:41 P:29.20 (packet length:29)
WAKEUP
Sorry for all the posts. Looks like 2 of 3 nodes (possibly the third) are tuning down. Just would like to know how to check the tx power of the nodes. (Got one node tuned down to -80)😁
Quote from: Kilo95 on March 22, 2016, 08:12:15 AM
Sorry for all the posts. Looks like 2 of 3 nodes (possibly the third) are tuning down. Just would like to know how to check the tx power of the nodes. (Got one node tuned down to -80)😁
Uncomment the Serial.println statements in the RFM69_ATC.cpp interruptHook() (https://github.com/LowPowerLab/RFM69/blob/master/RFM69_ATC.cpp#L151).
That will print the transmit level each time it tunes up/down.
Great thanks
Quote from: Kilo95 on March 21, 2016, 08:58:30 PM
<snip>
My TX level:31, my RSSI:0
BAT:4.86v F:7183 H:41 P:29.20 (packet length:29)
WAKEUP
First, don't follow Felix's last suggestion, printing within an interrupt handler is a very bad idea. I'm not sure why that code didn't get removed.
Secondly, where you are printing the TX level is fine, what is wrong is that your RSSI data returned by getAckRssi() is returning a 0 value, meaning that your far end is NOT sending the received RSSI, therefore no ATC will take place. Are you using the ATC library on the far end as well?
Tom
Yes. I am using the ATC lib on the gateway moteino also. A couple of posts back, I attached my pigateway.ino. Only change is I disabled radio.enableautopower on the gateway and used the radiohighpower function right now. That's only on the gateway. The nodes are autopower
Quote from: Kilo95 on March 22, 2016, 09:47:52 AM
Yes. I am using the ATC lib on the gateway moteino also. A couple of posts back, I attached my pigateway.ino. Only change is I disabled radio.enableautopower on the gateway and used the radiohighpower function right now. That's only on the gateway. The nodes are autopower
Are you able to print 'DEBUG' statements on the gateway? Make sure that it is successfully Acking each of the nodes and, on the nodes, check the radio.sendWithRetry() return values to make sure you're receiving the ACK.
Basically, if ATC is loaded, enableAutopower is called, and you get successful ACKs from the other end, then the library will try to adjust the TX levels.
Tom
Would you mind telling me how to print the debug statements on the gateway? Much appreciated
I assumed gateway.sys.log. It shows ack-sent on all nodes. It does appear that one node I reset last night did possibly tune itself down. (At least the rssi dropped from -50 to about -60 on a stationary node)
All the serial data coming from the gateway Moteino or MightyHat is logged in the gateway.sys.log by this function:
global.processSerialData = function (data) {
. . .
console.log('>: ' + data)
Look for lines in the log file that start with ">: some data".
However this only shows data that is written from the gateway with Serial.write commands. You won't see any serial data from your nodes.
In addition, there's nothing wrong with debugging with Serial.write, even inside interrupts. Although interrupts should be as fast as possible without any bloated unnecessary code. Don't let them uncommented for long term use though, indeed that is not a good idea, but it's OK for short term debugging.
I'll give that a shot Felix and see what the node to power is
Quote from: Felix on March 23, 2016, 10:27:03 AM
In addition, there's nothing wrong with debugging with Serial.write, even inside interrupts. Although interrupts should be as fast as possible without any bloated unnecessary code. Don't let them uncommented for long term use though, indeed that is not a good idea, but it's OK for short term debugging.
Agreed, which it why the print was there in the first place, I just didn't like leaving the impression of this being a proper general practice. Thanks for the clarification.
Tom
Tried to uncomment the two serial.print lines in RFM69_ATC.cpp interruptHook(). When I did and I recompiled my WS node sketch, I got errors. I'll have to try it again in the next couple of days (got a sick child right now so my time is limited). thanks for your help