Hi,
RAK3172 V4.0.6
AT+CAD=1
How does this work?
When using AT+PSEND=… does the radio check for Channel activity?
What message do we get if there activity or no activity?
Does it wait for no activity before sending out packet?
How long long does it listen for?
If there is activity do I need to do another AT+PSEND?
Is this something that I need do just before AT+PSEND, then turn off after AT+PSEND is done? The purpose of AT+CAD=1 is to minimize collisions.
Thank you.
Frank.
If you activate CAD with AT+CAD=1, the device will check for channel activity every time you use AT+PSEND.
If CAD detects a channel activity, it retries CAD until there is no channel activity, then it sends the packet.
I run a test and here is the log output.
To know the result of CAD, I mixed AT commands with a custom firmware that has CAD result callback.
Test environment:
Two RAK3172
Device 1 P2P settings SF12, BW31.25, CR 4/8, payload length 239 bytes → time on air = 44.6s
Device 2 P2P settings SF12, BW31.25, CR 4/8, payload length 64 bytes → time on air = 14.1s
Both DUT receive AT+PSEND commands over UART every 3 seconds
I removed AT_BUSY_ERRORS from the log, as the script I used doesn’t wait for TX finished, it just continues to submit AT+PSEND (not the recommended behaviour, but I didn’t spend too much time on the test script)
Log from device (2) shows it waits until device (1) has finished transmission, then it sends its packet
13:09:50.724 --> P2P CAD reports activity
13:09:53.834 --> P2P CAD reports activity
13:09:58.683 --> P2P CAD reports activity
13:09:59.868 --> P2P CAD reports activity
13:10:03.130 --> P2P CAD reports activity
13:10:06.214 --> P2P CAD reports activity
13:10:09.204 --> P2P CAD reports activity
13:10:12.252 --> P2P CAD reports activity
13:10:15.448 --> P2P CAD reports activity
13:10:18.437 --> P2P CAD reports activity
13:10:21.588 --> P2P CAD reports activity
13:10:24.651 --> P2P CAD reports activity
13:10:27.696 --> P2P CAD reports activity
13:10:30.823 --> P2P CAD reports activity
13:10:33.898 --> P2P CAD reports activity
13:10:37.002 --> P2P CAD reports activity
13:10:40.088 --> P2P CAD reports activity
13:10:43.197 --> P2P CAD reports activity
13:10:46.193 --> P2P CAD reports activity
13:10:49.302 --> P2P CAD reports activity
13:10:52.412 --> P2P CAD reports activity
13:10:55.472 --> P2P CAD reports activity
13:10:58.562 --> P2P CAD reports activity
13:11:01.641 --> P2P CAD reports activity
13:11:04.737 --> P2P CAD reports activity
13:11:07.796 --> P2P CAD reports activity
13:11:10.891 --> P2P CAD reports activity
13:11:13.938 --> P2P CAD reports activity
13:11:17.079 --> P2P CAD reports activity
13:11:20.139 --> P2P CAD reports activity
13:11:23.210 --> P2P CAD reports activity
13:11:26.311 --> P2P CAD reports activity
13:11:29.396 --> P2P CAD reports activity
13:11:32.465 --> P2P CAD reports activity
13:11:35.547 --> P2P CAD reports activity
13:11:38.598 --> P2P CAD reports no activity
13:11:38.598 --> OK
13:12:23.223 --> +EVT:TXP2P DONE
With the above settings, I see that CAD is active for ~3 seconds.
You do not need to deactivate CAD after PSEND, it will be only active after you used PSEND
Thanks Bernd,
This is a great explanation on how AT+CAD works,
How long does CAD listen for before the AT+PSEND is sent. I’m trying to determine the potential delay before AT_PSEND is sent. How long does AT+CAD listen for to determine there is no carrier?
Hi Frank,
I am discussing the CAD retries with the R&D team. It seems to try without limitation until it gets a channel free result.
As you can see in my log, it was already trying 3 minutes to get channel free result. That is not a good solution for a battery powered device.
Even my test was with an excessive long time-on-air value, it could happen in “normal” environments if there are many active devices.
Hi Bernd,
Today I measured the delay incurred by the AT+CAD=1.
With AT+CAD=0 (default) the delay from AT+PSEND= (end) to OK is 2.1 to 5.6 ms .
With AT+CAD=1 the delay is from 36.0 ms to 39.81 ms,
Thus AT+CAD=1 adds ~32 ms of delay (no carrier detected).
The AT+CAD=1 searches for ~32 ms for a carrier, minimum
I further assume that if a carrier is detected AT+CAD=1 will delay the OK until the carrier disappears., plus any additional delays?
Yes if there is a lot of air traffic then AT+CAD=1 could be waiting quite a while.
I would suggest then that AT+CAD=1 might have a timeout. If we assume a worst case situation BW=31.25, packet 253 , CR=4/8, SF=12 the air time could be 48s !!!. Then delay would need to be up to 48000ms Thus the range could be 0 to 65534 in ms, or just over 1 minute. But in reality I think this situation will be be rare, but possible.
I agree with the timeout, I already requested for this from the R&D team.
It is a little bit tricky with the timeout and the CAD search timing. If you know the max payload and transmission parameters of all other nodes, you can calculate it. But in scenarios where different payload sizes are used you can only guess.
In my Arduino (none RUI3) P2P codes I rather choose a short CAD detection time and repeat CAD check if channel activity was detected.
But RUI3 doesn’t give me that option (yet).
Bernd,
Looks like when CAD detects a carrier it reports AT_BUSY_ERROR. Is this correct? That’s what I’m seeing on the scope. At the 32ms mark where OK appears in CAD mode I get an AT_BUSY_ERROR. That means you need to send out another PSEND. This is not good.
It’s better if CAD just waits until the carrier is gone, then sends an OK. The way it’s setup now requires a lot of overhead to manage. You really don’t need that AT_BUSY_ERROR message. A timeout is better way to do it without the AT_BUSY_ERROR.
Yes, I agree. Opened already a ticket with our R&D team for it with your very helpful feedback.
Hi,
I am currently using another module that does CAD and it simply returns “busy” if it detects activity. I can then decide when I want to send again. This is probably the behaviour that I would prefer.
I suppose this is not currently possible? Or has it changed since this post was made?
Correct, it is not possible to just start CAD and check the result. It is combined with a packet transmission.
I realize I wasn’t very clear… It is when we try to send a message that either sends it and return ‘ok’, or if it detects activity it doesn’t send and returns ‘busy’. Either case we get a reply back quickly.
Is there any plans to change the behavior or add a timeout of some sort?
/Henrik
