Skip to content

Conversation

@nicolsc
Copy link
Contributor

@nicolsc nicolsc commented May 17, 2017

This uses a different SPI transaction (0x0B), and allows to send empty frames for basic applications such as buttons, door opening systems, ...
Added a simple example called SendBoolean

@facchinm : Let me know if I need to structure this differently to fit with the lib architecture :)

nicolsc added 2 commits May 17, 2017 14:37
This uses a different SPI transaction (`0x0B`), and allows to send empty frames for basic applications such as buttons, door opening systems, ...
Added a simple example called _SendBoolean_

Let me know if I need to structure this differently to fit with the lib architecture :)
@facchinm
Copy link
Contributor

Hi Nicolas 😉 !
I'd prefer not to add additional APIs to the library, since we went through a super long review process with @sandeepmistry and we decided to expose only Stream APIs and hide the send details as private. I'd love lo merge the example if modified into something like

#include <SigFox.h>
#define VALUE_TO_SEND 1
#define DEBUG 1
void setup() {

  if (DEBUG){
    Serial.begin(9600);
    while (!Serial) {};
  }

  if (!SigFox.begin()) {
    if (DEBUG){
      Serial.println("Sigfox module unavailable !");
    }
    return;
  }
  if (DEBUG){
    SigFox.debug();
    Serial.println("ID  = " + SigFox.ID());
  }
  delay(100);
  int ret = sendBit(VALUE_TO_SEND);
  if (DEBUG){
    Serial.print("Status : ");
    Serial.println(ret);
  }
}

void loop(){}

int sendBit(bool value) {
    SigFox.beginPacket();
    SigFox.write(value);
    return SigFox.endPacket();
}

What do you think about it?

@nicolsc
Copy link
Contributor Author

nicolsc commented May 18, 2017

The point of this single bit message is to send empty messages (bit switch in the protocol headers), instead of using a full byte of payload.
The goal is to offer the ability to push the 'low energy' approach to its max: smaller messages = smaller emission time = smaller consumption

Would it be OK to add a private method size_t SIGFOXClass::write(bool val), that would rely on 0x0B instead of 0x07+ 0x0D ?

@facchinm
Copy link
Contributor

Oh, I totally missed it, sorry, I was only looking at the "boilerplate" code and missed the different "opcode". I'll write down a stub tomorrow but sing 0xB under the hood is totally feasible 😉

@facchinm
Copy link
Contributor

facchinm commented May 18, 2017

Could we use something like this?

diff --git a/src/SigFox.cpp b/src/SigFox.cpp
index 5cf54b5..7c2d21d 100644
--- a/src/SigFox.cpp
+++ b/src/SigFox.cpp
@@ -130,7 +130,13 @@ int SIGFOXClass::send(unsigned char mess[], int len, bool rx)
   if (len > 12) len = 12;
   int i = 0;
 
+  if (rx == false && len == 1 && mess[0] < 2) {
+    //we can use send_bit command
+    return sendBit(mess[0]);
+  }
+
  spi_port.transfer(0x07);
   spi_port.transfer(len);
   spi_port.transfer(mess, len);
   spi_port.endTransaction();

and make sendBit private

EDIT: the datasheet states

Send Single Bit
This command sends a data bit (0=0x00/1=0x01) within a SIGFOX™
 RF frame as specified by SIGFOX.
An event on the EVENT signal is generated when finished. This command will only be used during testing
of the system and not during regular operation in a SIGFOX network.

is it true? Can we use it in "production"?

@nicolsc
Copy link
Contributor Author

nicolsc commented May 18, 2017

No problem in using it, especially in a development kit. I'll try to know why there this is indication in Atmel's spec sheet

Regarding your code sample, when sending a single bit, you don't need to send the message length with 0x07 .
All you need is

+  spi_port.beginTransaction(SPICONFIG);
+
+  spi_port.transfer(0x0B);
+  spi_port.transfer(value ? 1 : 0);
+  spi_port.endTransaction();

@facchinm
Copy link
Contributor

Manually merged with #2

@facchinm facchinm closed this May 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants