Author Topic: Using RFM69 LISTEN MODE and ATC together  (Read 1662 times)

juan3211

  • Newbie
  • *
  • Posts: 15
Using RFM69 LISTEN MODE and ATC together
« on: July 24, 2018, 06:26:12 PM »
@snorp:

Regarding RegRxTimeout2:
0x2B RegRxTimeout2 0x00 Timeout duration between RSSI detection and PayloadReady (DS page 61)
You can monitor the Timeout interrupt that occurs if the RSSI threshold is triggered but no payloadready interrupt is triggered (see page 70 last table row), I think that would be a good indication we're getting noise. I lowered it to 180 and it seems to work fine.
I would like to attempt to integrate your work directly into the RFM69 lib so we could use the ATC as well, otherwise not sure how that tandem could work.

Hi Felix, is there any example about using listen mode and ATC at the same time ?

Regards,

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1856
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #1 on: July 24, 2018, 09:12:46 PM »
Hi Felix, is there any example about using listen mode and ATC at the same time ?

Regards,
I don't know about any specific examples, but, fundamentally, the two modes are used at different points within a node's reporting cycle.  When the node goes to sleep using Listen mode, it is relying on the gateway (or some other node) to wake it up via a burst of signal sent directly to it or broadcast to a set of nodes.  When the node wakes up, it moves out of Listen mode, most likely performs some data sampling, and then sends the sample to the Gateway/other node.  IF the sending node does a sendWithRetry() AND ATC is enabled, the Gateway will ACK with the RSSI received with the node's packet and the ATC code will then tune the send power accordingly. 

Consequently, there is no reason that ATC and Listen Mode cannot be used by a node.  However, as with any node, the sequencing of operations is entirely implemented in code that you write for that node.  The infrastructure is there to support it, but your code needs to follow appropriate behavior.

Tom

juan3211

  • Newbie
  • *
  • Posts: 15
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #2 on: July 25, 2018, 08:19:29 AM »
I don't know about any specific examples, but, fundamentally, the two modes are used at different points within a node's reporting cycle.  When the node goes to sleep using Listen mode, it is relying on the gateway (or some other node) to wake it up via a burst of signal sent directly to it or broadcast to a set of nodes.  When the node wakes up, it moves out of Listen mode, most likely performs some data sampling, and then sends the sample to the Gateway/other node.  IF the sending node does a sendWithRetry() AND ATC is enabled, the Gateway will ACK with the RSSI received with the node's packet and the ATC code will then tune the send power accordingly. 

Consequently, there is no reason that ATC and Listen Mode cannot be used by a node.  However, as with any node, the sequencing of operations is entirely implemented in code that you write for that node.  The infrastructure is there to support it, but your code needs to follow appropriate behavior.

Tom

Thanks @TomWS for this point of view. I have in mind to do a Gateway that is in listen mode and recieves packets from other nodes.

Those other nodes send packet periodically, so Gateway will wake up, do some stuff and sleep again.

What I understood reading the Felix's post of April of 2016

Quote
I would like to attempt to integrate your work directly into the RFM69 lib so we could use the ATC as well, otherwise not sure how that tandem could work.

is that Felix will try to make compatible RFM69_ATC with listenmode, so it could be "transparent" for me.

Nowadays, RFM69_ATC hasn't any function relative with ListenMode.

Thansk a lot for your answer. I will see what I could do, but I am not an expert as you and Felix. I was asking if @Felix has any info in his hard disk   ;D

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1856
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #3 on: July 25, 2018, 11:36:45 AM »
I have in mind to do a Gateway that is in listen mode and recieves packets from other nodes.

Those other nodes send packet periodically, so Gateway will wake up, do some stuff and sleep again.
How is the gateway powered (battery or mains)?  If battery powered then I can understand the need to sleep between packets, if operating off mains then IMO Listen Mode is an unnecessary complication. 

Note that Listen Mode wake, as implemented in the library, relies on a long burst of data from the sender (AKA Waker), not something that would be energy efficient for a node to perform.  The wake function is typically performed by a continuously powered Gateway function.

Tom

juan3211

  • Newbie
  • *
  • Posts: 15
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #4 on: July 25, 2018, 04:13:52 PM »
How is the gateway powered (battery or mains)?  If battery powered then I can understand the need to sleep between packets, if operating off mains then IMO Listen Mode is an unnecessary complication. 

Note that Listen Mode wake, as implemented in the library, relies on a long burst of data from the sender (AKA Waker), not something that would be energy efficient for a node to perform.  The wake function is typically performed by a continuously powered Gateway function.

Tom

Hi, all nodes will be solar panel powered.  Nodes send to gateway packets every 0.25h / 0.5h / 1h (each node has its own frecuency). All nodes sleep between sending anything.

Gateway is also solar panel powered, it need to sleep all of the time and wakes by node's packets. Gateway will read the packed and send it through SIM800L (GPRS) to a web page.

That's why I am thinking in listen mode, and it will be great to have the ATC possibility.

I don't know if I have explained myself better. Thanks Tom again for your efforts.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5718
  • Country: us
    • LowPowerLab
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #5 on: July 25, 2018, 07:50:05 PM »
Gateway is also solar panel powered, it need to sleep all of the time and wakes by node's packets. Gateway will read the packed and send it through SIM800L (GPRS) to a web page.
That's why I am thinking in listen mode, and it will be great to have the ATC possibility.

I would suggest Keeping the Gateway powered in RX mode (just the radio RX, the MCU can sleep and wake upon radio interrupt). That way you need a constant ~15mA. You can buffer the received data, and wake your GPRS module when you need to send it. I suspect that has a "warm" mode where it wont take too long to sync to the local GSM network, and send the data, then back to sleep.
This way, you are ready to go now. You will need a bigger solar panel perhaps. At an average of 15mA + not much more for the GPRS which only wakes occasionally, I think with 2x the panel size on the gateway you will not break the bank. That would also make it easier for your deployed nodes to "catch" the gateway without a lot of retry or the extra wake-bursts of LISTEN-MODE.

FWIW - Native listen mode is still an R&D item on my TODO, right now it's just switchable in the library via a #define ENABLE_LISTENMODE. Maybe one day I will get to it if nobody else does before me...

juan3211

  • Newbie
  • *
  • Posts: 15
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #6 on: July 28, 2018, 03:03:01 AM »
I would suggest Keeping the Gateway powered in RX mode (just the radio RX, the MCU can sleep and wake upon radio interrupt). That way you need a constant ~15mA. You can buffer the received data, and wake your GPRS module when you need to send it. I suspect that has a "warm" mode where it wont take too long to sync to the local GSM network, and send the data, then back to sleep.
This way, you are ready to go now. You will need a bigger solar panel perhaps. At an average of 15mA + not much more for the GPRS which only wakes occasionally, I think with 2x the panel size on the gateway you will not break the bank. That would also make it easier for your deployed nodes to "catch" the gateway without a lot of retry or the extra wake-bursts of LISTEN-MODE.

FWIW - Native listen mode is still an R&D item on my TODO, right now it's just switchable in the library via a #define ENABLE_LISTENMODE. Maybe one day I will get to it if nobody else does before me...

Hi Felix, three days ago I sent you a private message, but I think i didn't do it well.

Anyway.

My "project" is already done with NRF24, but I ended up a bit angry about poor stability and range of those ICs. I want to change it to RFM69. Besides, listen mode is a must in my new project.
I already sleep GSM module all of the time,and my goal is to use listen mode to sleep and use less power as we can.

The project is about several nodes that send information periodically to my gateway. The gateway, when it recieves a message, it can check is someting has an error or not, and it also send periodically that information to a web page. All timing is configured in my web page, and the gateway checks the configuration when it starts and also periodically. It is true that APN configuration is in my sketch. I could add it in a micro sd card, but now it is not my main problem.

In NRF24 I use the ackpayload feature to resend the new timing configuration to my nodes. In RFM69 I will use also the ACK feature to send some information to my nodes when the gateway recieve information from them.

My goal is to work with all nodes powered by solar panels.

We have to options (example with 6 nodes and 1 gateway). Imagine that each node is sending every hour:

1. NOT TO USE LISTEN MODE: our consumption will be: 6 TX nodes sleeping most of the time + 6 TX nodes at 40-60mA sending data for few milisencons + 1 RX gateway at 16mA = 6 x 0 + 6 x 60mAh x 0.00...01 hours + 1 x 16 = 16 mAh. (this calculation is very poor, but it is ok for my example)

2. USE LISTEN MODE: now we have to send burst during about 3 secons, but gateway will be sleeping almost all of the hour: 6 x 0 + 6 x 60mAh x 3s/3600s + 1 x 16 x 0.00...01 hours x 6 times = 0.3 mAh

For me it is much better option 2. Almost I have to try it !!!  ;)

I am not an expert in writing libraries, and my sketchs are usually a litlle mesh  ;D.

I have already cheeck the listen mode example and it works very well. I have been also searching about combining ATC and LISTEN MODE feature, and also to use ACK to send information back to the TX node, and here is where I stop and find your post of 2016.

Quote
FWIW - Native listen mode is still an R&D item on my TODO, right now it's just switchable in the library via a #define ENABLE_LISTENMODE. Maybe one day I will get to it if nobody else does before me...

About this, I understant that you can enable listenmode that way ( I have already check it), but we can enable it with RFM69_ATC.cpp and .h, couldn't we ?

Regards,

NOTE: It is true, that I could use listen mode feature without ATC, and use all TX nodes with maximum power, but for a diy'ers that is not the good way, is it? ;)
« Last Edit: July 28, 2018, 03:09:44 AM by juan3211 »

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1856
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #7 on: July 28, 2018, 09:11:52 AM »
I have already cheeck the listen mode example and it works very well. I have been also searching about combining ATC and LISTEN MODE feature, and also to use ACK to send information back to the TX node, and here is where I stop and find your post of 2016.

About this, I understant that you can enable listenmode that way ( I have already check it), but we can enable it with RFM69_ATC.cpp and .h, couldn't we ?
To use ATC AND Listen Mode Wake in your configuration you would need to:
Nodes:
  • Node wakes up every hour.
  • Node sends 3 second burst to wake up Gateway.
  • Node sends data packet using radio.sendWithRetry().  Note, ATC would need to be enabled.
  • Node gets good result from sendWithRetry() then it knows the gateway got the message AND that ATC is adjusting TX level.  Node can go back to sleep.  If the sendWithRetry() failed AND if reliable communications is necessary, the node will have to repeat the complete cycle from 2 above.  NOTE: do not do this forever, you will drain your batteries.  ALSO NOTE:  The timing of Gateway wake and it going into receiveDone mode is tricky.  If you sendWithRetry BEFORE the gateway wakes up, then the Gateway will miss it.  The longer you delay (to make sure the Gateway gets it) the longer both Node and Gateway need to stay awake.

Gateway:
  • Gateway is in Listen Mode Sleep
  • Gateway wakes up due to burst from Node.
  • Gateway immediately restores normal radio mode and goes into receiveDone() loop for some period of time (see comment above).
  • Gateway receives data packet and immediately ACKs BEFORE doing anything else - this allows the node to go back to sleep.
  • Gateway does something with the data and then goes back to Listen Mode Sleep.

Sounds simple, huh?  Well... it is simple if there is only one Node.  With n Nodes you have each competing to wake up the Gateway and, inevitably, there will be overlap, collisions, and missed packets/wakeups causing lost power and data.

Another approach COULD be:
ALL Nodes use Listen Mode Sleep.
Gateway is TOTALLY sleeping (radio & processor) with an extremely low power timer like TPL5010 or, mister Felix has a nifty TPL5110 breakout that will completely power off the Gateway until every hour - this would consume less than 50nA while sleeping.
When the Gateway wakes up (either due to Wake pin from TPL5010, or repowered due to TPL5110) it broadcasts a Listen Mode Wake up burst to ALL Nodes.
Nodes all wake up and each one, in turn, takes a sample, and then sends it's data to the Gateway using sendWithRetry (ATC enabled of course), and then goes back to Listen Mode Sleep.  NOTE:  In this case, to avoid collisions, the Nodes could delay their TX (sleeping while waiting) until some well defined delay related to their NodeId or something unique. 
This approach will be lower power and should be more reliable.

UPDATE: This proposed approach works well IF all Nodes have the same sample timing.  If individual nodes have unique sample times, then it gets 'interesting'...  But that's another topic.

Just an idea  ;)

Tom
« Last Edit: July 28, 2018, 09:14:07 AM by TomWS »

juan3211

  • Newbie
  • *
  • Posts: 15
Re: Using RFM69 LISTEN MODE and ATC together
« Reply #8 on: July 30, 2018, 06:08:41 PM »
    To use ATC AND Listen Mode Wake in your configuration you would need to:
    Nodes:
    • Node wakes up every hour.
    • Node sends 3 second burst to wake up Gateway.
    • Node sends data packet using radio.sendWithRetry().  Note, ATC would need to be enabled.
    • Node gets good result from sendWithRetry() then it knows the gateway got the message AND that ATC is adjusting TX level.  Node can go back to sleep.  If the sendWithRetry() failed AND if reliable communications is necessary, the node will have to repeat the complete cycle from 2 above.  NOTE: do not do this forever, you will drain your batteries.  ALSO NOTE:  The timing of Gateway wake and it going into receiveDone mode is tricky.  If you sendWithRetry BEFORE the gateway wakes up, then the Gateway will miss it.  The longer you delay (to make sure the Gateway gets it) the longer both Node and Gateway need to stay awake.

    Gateway:
    • Gateway is in Listen Mode Sleep
    • Gateway wakes up due to burst from Node.
    • Gateway immediately restores normal radio mode and goes into receiveDone() loop for some period of time (see comment above).
    • Gateway receives data packet and immediately ACKs BEFORE doing anything else - this allows the node to go back to sleep.
    • Gateway does something with the data and then goes back to Listen Mode Sleep.

    Sounds simple, huh?  Well... it is simple if there is only one Node.  With n Nodes you have each competing to wake up the Gateway and, inevitably, there will be overlap, collisions, and missed packets/wakeups causing lost power and data.

    Another approach COULD be:
    ALL Nodes use Listen Mode Sleep.
    Gateway is TOTALLY sleeping (radio & processor) with an extremely low power timer like TPL5010 or, mister Felix has a nifty TPL5110 breakout that will completely power off the Gateway until every hour - this would consume less than 50nA while sleeping.
    When the Gateway wakes up (either due to Wake pin from TPL5010, or repowered due to TPL5110) it broadcasts a Listen Mode Wake up burst to ALL Nodes.
    Nodes all wake up and each one, in turn, takes a sample, and then sends it's data to the Gateway using sendWithRetry (ATC enabled of course), and then goes back to Listen Mode Sleep.  NOTE:  In this case, to avoid collisions, the Nodes could delay their TX (sleeping while waiting) until some well defined delay related to their NodeId or something unique. 
    This approach will be lower power and should be more reliable.

    UPDATE: This proposed approach works well IF all Nodes have the same sample timing.  If individual nodes have unique sample times, then it gets 'interesting'...  But that's another topic.

    Just an idea  ;)

    Tom

    Thanks Tom !!!! Thanks a lot for your possibilities.

    First of all a question:  why a burst of 3 seconds if default cycle time is 1 second ? It will be good to do a burst of 1 second plus 50 ms of error/offset (I mean 1050 ms) ?

    And about your options, in my original NRF24 project, if the communication fails, TX nodes repeat again after X minutes (where X minutes is usually 25% of cycle time). I mean, there is not any critical information.

    So, I think that your first option will be great (as I understand that complete the RFM69_ATC library with listen mode functionallity is very difficult.

    Only I have the question about the burst time

    I understand also that:
    Quote
    there will be overlap, collisions, and missed packets/wakeups causing lost power and data
    is almost impossible as it is very difficult that two nodes transmit in the same "milisecond". The gateway has to do his job quickly in order to be ready again to listen the next payload. (Also we have to know that RFM69 has a limited input buffer)

    I am used to NRF24 where it is impossible that packets overlaps/collisions. Are you saying that with RFM69 it is possible that two diferent payloads get mixed ?

    Regards,[/list]
    « Last Edit: July 30, 2018, 06:23:23 PM by juan3211 »

    TomWS

    • Global Moderator
    • Hero Member
    • *****
    • Posts: 1856
    Re: Using RFM69 LISTEN MODE and ATC together
    « Reply #9 on: July 30, 2018, 06:57:10 PM »
    Without getting into the specifics of the questions, some fundamental points.  The most battery efficient Listen Mode Sleep cycle is the maximum time slot, which is approximately 2.8 seconds (very brief RX and then ~2.8 second sleep).   If you use this slot timing, then you need a 3 second burst to guarantee that you'll wake up the listening node. 

    FWIW, I didn't like Listen Mode when I first read about it but others did some good work to demonstrate its usefulness and I tried it and the Listen Mode code in the Library was a derivative result of that.  Subsequently, however, I and others discovered hang up states that occurred that didn't seem to have a universally reliable solution.  Net is that I no longer use Listen Mode Wake - ever.  I have totally converted to external hardware timer which ALWAYS works and is very low power.  I have set up most motes to work on a 10 minute cycle which seems to be a good compromise between data sample resolution and battery life.  Given this, it takes no more than 10 minutes to reach any mote in my network if I want to send a command (like turn on a sprinkler valve or upload new code) and that works well for me.  Hence, no need tor Listen Mode Wake, in my world.

    Note: When I turn ON a sprinkler valve, I can comfortably wait for the 10 minute cycle to start the irrigation.  Once the valve is open, however, I switch to a fast, Listen Mode Timer that yields a 14 second (5 x 2.8 second) cycle so that I can turn OFF a valve in a hurry if need be.

    Tom

    juan3211

    • Newbie
    • *
    • Posts: 15
    Re: Using RFM69 LISTEN MODE and ATC together
    « Reply #10 on: August 01, 2018, 07:32:10 AM »
    Hi Tom,

    Three more comments to "close my project" in my brain. Thanks in advance again.

    FIRST
    Quote
    Subsequently, however, I and others discovered hang up states that occurred that didn't seem to have a universally reliable solution

    In my actual project (NRF24), if a TX node detects that it has done 3 tries to send a packet t the RX node without success (without getting the ackpayload) it resets itself and the NRF24 (by re-configuring it. I don't find necessary to reset it "electricaly")

    Also, RX node takes care about the last good data from each TX node. If RX node detects that it hasn't recieved anything from any TX node in the last 4 x cycle time (each node with its cycle time) it will reset itself (also by software (watchdog or reconfiguring the NRF24)). I mean, if RX node "detects" that it hasn't recieved anything ... it thinks that it is the guilty node, so it resets itself.

    Does it possible to reconfigure RFM69 by software?, will I need to use mandatorily reset pin? , or will I need full power off / power on the RFM69 ?
    Or is it better to implement a listen mode in your sketch by radio.sleep not to get "these hang up states" ? It will be easier to use library's listen mode and reset the RFM69 if it can be reset by "software"

    SECOND
    Quote
    I have totally converted to external hardware timer which ALWAYS works and is very low power. I have set up most motes to work on a 10 minute cycle which seems to be a good compromise between data sample resolution and battery life

    I think that I have understood you, but just in case .... I think that the way that you have described needs a gateway that it is always connected to power. I mean, to connect to your nodes, it has to send a "10 minutes burst", does it? Or, probably, does the node the responsible of getting data from the gateway, so it is the gateway that it is always listening ? Both ways, I think that you need a gateway that is always consuming power (if it is in RX mode, it will consume about 15-16mA). Or do I missunderstand you ? How do you send data from nodes to the gateway ?

    Quote
    Note: When I turn ON a sprinkler valve, I can comfortably wait for the 10 minute cycle to start the irrigation.  Once the valve is open, however, I switch to a fast, Listen Mode Timer that yields a 14 second (5 x 2.8 second) cycle so that I can turn OFF a valve in a hurry if need be.
    good way to do it !!!!

    THIRD
    And finally, about cycle time.

    Quote
    The most battery efficient Listen Mode Sleep cycle is the maximum time slot, which is approximately 2.8 seconds (very brief RX and then ~2.8 second sleep).

    Project: 4 TX nodes that send data every 60 minutes, 1 RX gateway in listen mode during X seconds cycle time
    • TX power for 1 hour:
    • TX time: 4 nodes x X seconds send burst x 50mA / 3600
    • Sleeping: 4 nodes x (3600 - X) x 5uA / 3600

    • RX power for 1 hour: (3600 / X) is total cycles in 1 hour
    • RX time: [0.000256 seconds * 16mA / 3600] * (3600 / X)
    • Idle time: [(X - 0.000256) seconds * 6uA / 3600] * (3600 / X)

    • Total with X = 3 seconds  : 0.1666666 + 0.0199833 + 0.0013653 + 0.0059994 = 0.1940146 mAh
    • Total with X = 1 second   : 0.0555555 + 0.0199944 + 0.0040960 + 0.0179984 = 0.0976443 mAh
    • Total with X = 0.1 seconds: 0.0055555 + 0.0199994 + 0.0409600 + 0.0059846 = 0.0724995 mAh

    I can't see in a project where all nodes (RX and TXs) are powered with solar panels why 3 seconds is better than 1 second.
    I see that with less cycle time your RX consumption will be bigger, but your TX consumption will be less.
    This calculation depends on how many TX nodes you have got, don't it?
    And your cycle time depends on how many TX nodes you have, the response-time that you need and where do you need low battery power (TX node, RX node or both).
    Anyway, this power consumption is much much less than with NRF24 as its gateway needs to be constantly in RX mode, so you spend continuosly 12mA

    Tom, please, tell me your opinion of these comments, thanks.

    juan3211

    • Newbie
    • *
    • Posts: 15
    Re: Using RFM69 LISTEN MODE and ATC together
    « Reply #11 on: August 12, 2018, 05:23:27 AM »
    Hi, may be Tom is on holidays  ;D

    Has anybody an opinion about my comments?

    Regars,

    TomWS

    • Global Moderator
    • Hero Member
    • *****
    • Posts: 1856
    Re: Using RFM69 LISTEN MODE and ATC together
    « Reply #12 on: August 12, 2018, 07:41:57 AM »
    Does it possible to reconfigure RFM69 by software?, will I need to use mandatorily reset pin? , or will I need full power off / power on the RFM69 ?
    Or is it better to implement a listen mode in your sketch by radio.sleep not to get "these hang up states" ? It will be easier to use library's listen mode and reset the RFM69 if it can be reset by "software"
    No, the RFM69, if it hangs in this locked up state transitioning from Listen to synchronous mode, requires a hardware reset to unlock it.  We have not found a software reconfiguration sequence that works 100% of the time.  And one fail will drain your battery.
    Quote

    SECOND
    I think that I have understood you, but just in case .... I think that the way that you have described needs a gateway that it is always connected to power. I mean, to connect to your nodes, it has to send a "10 minutes burst", does it? Or, probably, does the node the responsible of getting data from the gateway, so it is the gateway that it is always listening ? Both ways, I think that you need a gateway that is always consuming power (if it is in RX mode, it will consume about 15-16mA). Or do I missunderstand you ? How do you send data from nodes to the gateway ?
    My Gateways are always powered from mains with battery backup so they will stay powered for at least a day.   When I used Listen Mode Sleep, which I don't any more, the nodes would be sleeping in listen mode, the gateway would broadcast a 3 second wakeup burst every 10 minutes, all of the sleeping nodes would wake up from this burst, do their sampling, and, each, in turn, would send their samples back to the gateway with sendWithRetry().  This improved the reliability of the data transfer, but also gave the Gateway a chance to send a command to the node in the return ACK (like stay awake for an OTA update, or open a valve, for instance).  The Gateway is always in RX mode otherwise.

    As I said, I don't do this any more.  I use the HW timer to wake up the nodes and send the samples back to the GW based on their own timing needs.
    Quote
    ...
    I can't see in a project where all nodes (RX and TXs) are powered with solar panels why 3 seconds is better than 1 second.
    The 3 seconds is determined by the Listen Mode cycle time.  As I said earlier, the most energy efficient Listen Mode cycle has 2.8second interval with a very brief RX time (64uS IIRC).  Any device trying to wake up a sleeping node has no idea WHERE the sleep node's cycle is in its timing and, therefore, MUST send enough of a burst to guarantee that it overlaps the overall 2.8 cycle time to successfully trigger the RX event.

    juan3211

    • Newbie
    • *
    • Posts: 15
    Re: Using RFM69 LISTEN MODE and ATC together
    « Reply #13 on: August 12, 2018, 05:49:18 PM »
    Tom, thanks a lot again for your help and effort. I will try to fight a little bit and report to the forum back.

    Thanks.  ;)