Just got my BlueDuino and started playing around with it. Soldered the pins in place, plugged in the USB wire, and uploaded the serial sample sketch. Amazing. It works.
Found one problem with the wiki instructions though. Regarding AT+SDUR, the AT command wiki says:
“AT+SDUR[param1] Scan duration in seconds AT+SDUR1 OK+Set:1”
First of all, you should probably add a note that the default is 4 seconds.
More importantly, you should add note:
“Run AT+RESET to make the command affected”
oops, that’s not very good English. 
How about this instead:
“Run AT+RESET to activate the new duration timing”
In other words, simply using AT+SDUR command does not actually change the duration. Even though “AT+SDUR?” will return the duration that you just adjusted to, it’s not actually in effect until you reset the module.
I’ve just added the line to the wiki.
Thank you very much for your mention. 
Quick question: When I set the AT+SDUR to 1 second, does that mean the scan interval and scan window are both set to 1 second? (assuming I am using AT+SCAN2 for scanning)
It just mean scan interval is set to 1 second. The scan window is default value and I haven’t found it at TI’s document.
Do you need a shorter scan interval?
No, I’m just trying to get very reliable scans, 1 per second.
I currently have an iBeacon set to advertise once per second.
And now I have set the BlueDuino to AT-SDUR1 (i.e. 1 second scan duration).
So, in theory, the iBeacon is advertising once per second, and the BlueDuino is scanning for one second, sooooo it should capture every single advertisement from the iBeacon and I should get 1 scan result per second, but…
When I run a simple sketch, I get too much variability in the scan results. For example, here’s what I get in the serial monitor (the RSSI number is incorrect; just ignore it):
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 965
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1010
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1976
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1011
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1012
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 964
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 3947
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1976
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1010
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 962
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1977
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1011
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1014
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 964
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 2986
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1012
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1972
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 962
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1014
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 2986
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1984
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 963
The RSSI of the target bluetooth LE 4.0 fob is: 2
Milliseconds elapsed since last string: 1011
You can see from the bolded numbers above that I am getting slow scans every few seconds. Not sure why though.
I am currently trying a different approach where the sketch writes AT+SCAN2 then reads results for 1 second, then writes AT+SCAN0 (stops scanning), then loops back to write AT+SCAN2 again, etc etc. It seems to be getting better results, but still not all 1 second scans.
So I am still brainstorming how to get 100% reliable 1 second scans. That’s why I asked the question about scan interval and scan window.
Please try to change the advertising interval to shorter. For example: 500ms or less. The beacon will advertise at three channels. BlueDuino may miss the advertising data.
Haha, yes, I know that will help. But I am developing a consumer product and want the iBeacon to last as long as possible without needing a battery change. So, I need to stay at 1 advertisement per second.
Your point about three channels is interesting though. I will think about it some more. Thanks!
Resurrecting a bit of an old thread here:
Firstly, to clarify some terms:
Scan interval: how often the controller should scan.
Scan window: for each scanning interval, it defines how long the device scans"
According to my understanding, the above “Scan Window” and “Scan Interval” are the official BLE 4.0 terms. “Scan Window” is what your company calls “Scan Duration”. Correct me if I am wrong about that.
I know the Scan Window (Scan Duration) is adjustable using the AT+SDUR command.
Were you ever able to find out what the chip’s default value is for the Scan Interval?
The official BLE guidelines say that Scan Window and Scan Interval should be set to the SAME number in order to have CONTINUOUS scanning. So that’s what I would like to do. Since you currently do not have an AT command to adjust Scan Interval, I am hoping to set the Scan Window (Duration) to whatever the Scan Interval default value is.
Thanks!
I have searched and searched on the internet for this answer, but still have not found it. It seems there is no default values for Scan Interval and Scan Window for the CC2540 chip. From what I can figure out, the values for these must be written into code/software somewhere. Perhaps this is located in your firmware? Or maybe I am using the wrong word?
Could we search for TGAP_GEN_DISC_SCAN_WIND in the firmware?
Thanks!
The Scan Interval and Scan Window are default values in firmware. We didn’t change it. The AT+SDUR means scan duration. it means the module will keep scan 1000ms and stop if Scan duration = 1000ms.
“it means the module will keep scan 1000ms and stop if Scan duration = 1000ms”
But doesn’t that mean the exact same thing as the definition of Scan Window?
Oh wait, I think I know what you mean. It sounds like Scan Duration is turning on the CC2540 chip for 1000ms (for example), but during that 1000ms, the chip is basing Scan Window and Scan Interval on the defaults in the chip firmware.
Right?
By the way, I did find one reference in a webpage about a module called BLE112 that also uses the CC2540 chip. There they mentioned that the defaults for Scan Window and Scan Interval are both 125ms.
Not sure if that is accurate for every module (including BlueDuino) that uses the CC2540 chip though.
I think I need to start playing around with AT+SDUR less than 1000ms to see if that improves my scan performance.
Sorry to keep bugging you about this. I’m wondering if the default values might be somewhere in these files:
What do you think?
You can download bel-stack from TI. There’s nothing about default value.
Yeah, I searched for about three hours yesterday. Many people on the internet were asking the same question, but nobody had the answer. As you say, it seems that there it no specific default. It must be specifically programmed. So I wonder who wrote and loaded the program that is running on your CC2540 chip? Someone on this earth must know the answer, right?!? Haha!
Anyway, I have given up trying to figure it out. Will focus on lowering the AT+SDUR to see how that might help.
Thanks!
You can ask a question at TI’s Bluetooth Low Energy forum about this.
How about this instead: