Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - martin7743

Pages: [1]
1
General Project/Programming Guidance / Re: Getting values from BLE
« on: January 20, 2018, 10:51:58 AM »
I do not know the tool you are using, but if you are awaiting a 4 byte float value, your 4 byte hex values "00 80 ee 43" with the most promising endian variant gives me a decimal value of 477.
It's not your mentioned 487, but take a hex to float converter and check again if that's the miracle behind your problem.

Best regards,
Martin

2
Hi Nelson,

thanks for your reply!
Your example works and I realized that my current measurment setup was the cause for the confusing behaviour I wrote in the last posts. I was not aware, that the "SimbleeCOM.begin()" is drawing a current of approx. 16mA! My shunt resistor was too high which caused undervoltage. So I have to apologize for the wrong and missleading current measurements and conclusions in the last posts!

But my initial question is still valid.
I have now tested SimbleeCOM and it seems that it is a must, to have SimbleeCOM.begin() called and it is not possible to have a working SimbleeCOM_onReceive() callback during Simblee_ULPDelay(). Which by the way would reduce the current only from 16mA to 13mA.

So my new formulation of the question:
Is it possible to have a listening SimbleeCOM callback with current draw <<1mA ?
If not with your current api, maybe with some low level "hacks"?

Best regards,
Martin

3
Some additional information to my measurements above:
- I have removed the power hungry ADP160 regulator from the Sparkfun breakoutboard before. So the current measurements should be identical to the bare simblee chip. (eveything works fine with BLE)

- Arduino version 1.8.2
- Simblee version 1.1.2

I am still curious. Can anyone confirm that SimbleeCOM consumes power if a receiving callback is present, even if stopped with SimbleeCOM.end()? So no coin cell operation possible on the receiver side?
Is there a workaround or fix with low level functions?

Thanks in advance,
Martin

4
I did some current measurements to see if ULPDelay() is maybe stopping the SimbleeCom activities.
But now I am really confused!
I used the "Simblee COM Receiver"-sketch as posted and modified some lines.

These are my results:

- SimbleeCom.begin() with delay() loop: ~3.7mA
- delay() loop alone: ~ 4.2mA
- SimbleeCom.begin() with Simblee_ULPDelay() loop: ~3.7mA
- Simblee_ULPDelay() loop alone: ~5µA

So, during ULPDelay the same current is drawn as with delay(), but the callback does not work in the case of ULPDelay() but works with delay().
But there is more:

- if SimbleeCom.end() is called, the current consumption stays unchanged!
  So once called, you come never back to power saving ULPDelay()!
- all these measurements were done with the "void SimbleeCOM_onReceive" Callback present in the sketch. If this callback code is removed,    Simblee_ULPDelay() seems to work!

So this is a serious limitation for all battery powered applications. Instead of consuming 5µA most of the time, nearly 4mA are drawn!
Can anyone confirm this?
I cannot believe, that this is the desired behaviour of the SimbleeCOM.
So any help/input/ideas are welcome!  :D


5
Sure, here is the sending part:

Code: [Select]
#include<SimbleeCOM.h>

char payload[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };

void setup()
{
 SimbleeCOM.mode = LOW_LATENCY;
}

void loop()
{
 SimbleeCOM.begin();
 SimbleeCOM.send(payload, sizeof(payload));
 SimbleeCOM.end();
 Simblee_ULPDelay(1000); 
}

6
Hi Wayne,

thanks for your answer!
But I think this is the way how these Radio Callbacks should work! By interrupting the main loop.
If I use a regular "delay(1000)" everything works. But this does not help in powersaving.

If I am doing this Simblee_ULPDelay - "power saving trick" with the SimbleeBLE callback functions, everything works as supposed.

So "SimbleeBLE_onReceive(char *data, int len)" callback works during Simblee_ULPDelay and "SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi)" callback does not work.

Best regards,
Martin
 

7
I am using 2 Simblee devices (sparkfun breakoutboards) and want to establish a power efficient wireless communication via SimbleeCOM between them.
Therefore I used the 2 standard sample sketches for sending and receiving via SimbleeCOM.
The first device ist continuously sending every second and the other devices continuously receiving.
Everything works but is using a lot of power.
So a modified the sending part by changing the loop to: 
Code: [Select]
void loop()
{
 SimbleeCOM.begin();
 SimbleeCOM.send(payload, sizeof(payload));
 SimbleeCOM.end();
 Simblee_ULPDelay(1000); 
}

Everything still works fine!

But if trying a similar power saving trick with the receiving part, the SimbleeCOM_onReceive callback is never called.
(see the complete receiving sketch below)

Code: [Select]
#include<SimbleeCOM.h>

void setup()
{
 pinMode(2, OUTPUT); //this is the red LED (sparkfun simblee breakoutboard)
 SimbleeCOM.mode = LOW_LATENCY;
 SimbleeCOM.begin();
}

void loop()
{
  Simblee_ULPDelay(1000); //without this line everything works
}

void SimbleeCOM_onReceive(unsigned int esn, const char *payload, int len, int rssi)
{
 digitalWrite(2, HIGH);
}

So I am asking, is this normal desired behaviour or a bug or am I doing something wrong?

Best regards,
Martin

8
Support / Re: Simblee supply issues?
« on: September 14, 2017, 06:43:40 AM »
Hi,

I have just encountered the same problem.
Suddenly the stock count at mouser went from 2800 or so to 0! From one day to the other.
Digi-Key 0 too, since end of August.
RS-Online 0.

There must be a bigger problem!
Maybe a product recall?

Has anyone more info?

Hopefully Simblee is not discontinued!

Best regards,
Martin

9
Hi,

even if "RFduino_ULPDelay( INFINITE )" is called and Connection Interval is set to 1000ms (and connection established), every 4 seconds some extra current (red dots in diagram) is drawn.
Does anyone know the reason therefore and does someone have an idea what I can do against it?



Code: [Select]
//24.07.2016
//Arduino 1.5.8
//RFDuino-Lib v 2.2.4
//RFduino is comsuming some additional power every 4 seconds (no matter if advertising or connected)

#include <RFduinoBLE.h>

void RFduinoBLE_onConnect() //callback if connection starts; set connection intervall here; (is called only once, at beginning of connection)
{   
  RFduinoBLE.updateConnInterval(1000, 1000); //ms (min, max)  [7.5-4000ms in 1.25ms steps] //default [20ms] (16,24)?;   
}

void setup()
{
  RFduinoBLE.advertisementInterval = 1000; //ms (default: 80) (Range: 20-10240 in 0.625ms steps)   
  RFduinoBLE.begin();   
  //RFduinoBLE.end();
}

void loop()
{       
  //android app "BLE Device Scan - BluetoothLeGatt" connects with RFduino; (Android 4.4.2)
  RFduino_ULPDelay( INFINITE ); //ms  //ulp would draw <5µA if BLE advertising (started with RFduinoBLE.begin()
                                      // has been stopped before (with RFduinoBLE.end())
}

Some diagram related infos:
The white numbers are voltage measurements in [mV] at a 100 Ohm shunt. So a value of 33mV for example means 330µA current.
The black [µA] value is the long term current average.
The non uniform peak height is due to aliasing effects of this undersampled measurement. If measured with 1000 Samples/s, these 1s connection peaks have more or less the same height (and higher peak levels).

Best regards,
Martin

Pages: [1]