The code I'm running at the moment is just
setup()
{
Serial.println("SET CONTROL CONFIG 103d");
}
loop()
{
Serial.println("SLEEP");
}
but I've also tried the SLEEP command in the setup, and putting this code in the ArduinoBT bootloader. I left the Arduino with sleep enabled running for several hours and it made no difference to the consumption, also "SET CONTROL CONFIG 102d" doesn't make any change. Perhaps I'm issuing the commands in data mode? I understand that data mode is when there is a Bluetooth connection and command is when there isn't a connection but I might be mistaken.
Sorry I've taken so long had my exams and holidays.
My code eventually evolved to be something like this:
int input = 0;
int resetPin = 7;
int ledPin = 13;
void setup()
{
pinMode(resetPin, OUTPUT);
Serial.begin(115200);
Serial.println("SET CONTROL ESCAPE 43 00 0");
Serial.println("SET CONTROL CONFIG 103D");
digitalWrite(ledPin, HIGH);
}
void loop()
{
if (!input)
{
delay(2000);
Serial.print("+++");
delay(2000);
Serial.println("TEST DEEPSLEEP");
delay(10000);
Serial.print("+++");
delay(2000);
input = 1;
digitalWrite(ledPin, LOW);
}
Which doesn't work (YAY!)
I then found some code here which had successful iWRAP communication, I modified it to include the iWRAP I wanted, started with "INFO" and found out the version of iWRAP (WRAP THOR AI 2.2.0 build 60) obtained the correct datasheet found that deepsleep was feature of the module and that you could test it using the "TEST DEEPSLEEP" command. I used that command and the board slept! I think... the current sat at around 36mA which is higher than normal unconnected use but the board was incommunicable. The test returned an OK so I'm confident that I can make the board sleep now. Unfortunately issuing the "SLEEP" command doesn't seem to do anything atm, though I don't know if my initial setup commands are being issued yet.
Anyhoo here is the (barely) modified code I'm using now. Basically run it then enter "&" into the serial monitor and it goes to command mode and issues the commands you put in the code, enter "@" and it tells you the response to those commands.
#include <EEPROM.h>
int ledPin = 13; // LED connected to digital pin 13
int resetPin = 7; // BT module uses pin 7 for reset
char inByte = 0; // incoming serial byte
int infoSize = 0 ;
void setup() // run once, when the sketch starts
{
pinMode(ledPin, OUTPUT); // sets the digital pin as output
pinMode(resetPin, OUTPUT);
Serial.begin(115200); // start serial at 115200 kbs
Serial.println("SET CONTROL ESCAPE 43 00 0");
Serial.println("SET CONTROL CONFIG 103D");
}
void loop()
{
// if we get a valid byte, read analog ins:
if (Serial.available() > 0) {
inByte = getbyte(); // get incoming byte
if (inByte == '&' ) { // look for a &
Serial.print("Got an & ");
infoSize = getInfo();
Serial.println("Done");
}
else if (inByte == '@' ) { // look for a 0
digitalWrite(ledPin, LOW); // set led LOW
Serial.print("Get string: ");
for(int i=0;i<infoSize;i++)
{
Serial.print(EEPROM.read(i));
}
Serial.println();
Serial.print("Cleared string size: ");
Serial.println(infoSize);
}
}
}
int getInfo()
{
int j=0;
digitalWrite(ledPin, HIGH); // set led HIGH
delay(2000);
Serial.print("+++");
delay(2000);
Serial.println("SLEEP"); //THIS IS WHERE YOU ENTER THE COMMANDS
//"INFO" and "TEST DEEPSLEEP" are both successful
//"SLEEP" isn't successful yet
for (int i=0; i <= 10; i++){
delay(1000);
while (Serial.available() > 0 && j <512) {
inByte = getbyte(); // get incoming byte
EEPROM.write(j, inByte);
j++;
}
delay(1000);
}
delay(2000);
Serial.print("+++");
delay(2000);
digitalWrite(ledPin, LOW); // set led low
return j;
}
char getbyte()
{
while (Serial.available() == 0) { //look for aviable data
// do nothing, wait for incoming data
}
return Serial.read(); //return data if aviable
}
Yay epic edit!
Thanks so much for your help, it's been invaluable to my journey :)
The advertisement packet your beacons send can contain custom data. However the space is very limited, around 31 bytes. About 16bytes of it goes to the 128bit "service UUID" of your beacon. The structure of the packet is defined by the bluetooth spec and it does have some overhead, so I'm not sure how much is actually available for the custom data.
The service UUID is an identifier which your iphone app will search for. The idea that each service has a unique identifier, so if an app wants to find heart rate monitors, it will scan for the heart rate monitor uuid. In iOS you can even do a wildcard scan, and it will return any ble advertisements it can find, regardless of the services it has. It is however recommended by Apple guidelines that you specify the service UUID.
There is no requirement for pairing in order to receive the advertisment packets from the beacon. There is also no theoretical limit that would prevent that the beacons couldn't be found, given an infinite amount of time.
I haven't heard anyone putting 500 advertising BLE beacons in the range of an iPhone to see how many it can detect. With 500 beacons advertising simultaneously there will be a lot of collisions between packets. This could theoretically be calculated with knowing the advertisement interval.
The iPhone scan window (how long the channels are actively listened to) and scan interval (how often the scanning window is entered) cannot be adjusted, isn't documented and cannot be relied to remain the same between versions. This means that there isn't a way to really calculate how the advertisements will be found.
There's some recommendations published by Apple about advertising: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Oh, and by default iOS will filter the results so you get one notification per scan session, per beacon. You can set the "allow duplicates" option in the scan to get multiple notifications per scan session for each beacon if this is needed, but again, apple doesn't recommend it.
If you end up testing this with 500 beacons, or even > 10, I thin a lot of people would be interested in your results. I personally would also appreciate hearing about your experiences.
Best Answer
Take a look at my answer here about low power radios:
Low-power wireless module strategy
The core problem is that BOTH receive and transmit typically take on the order of 10mA to 30mA for integrated radios.
Therefore to get average power down you must use some kind of radio duty ratioing technique (there are many). As an example, ContikiMAC can route traffic in a sleepy router network with about 400uA average.
I'm not too familiar with BTLE but your numbers are no too surprising to me. I've seen demos of BTLE devices that use a coin-cell and have a run-time around 1 week. This would match the numbers you are seeing.