Binary downlinks

[sslupsky]

I believe there is an outstanding issue with binary downlinks. As reported in #33, the module firmware does not handle sending a binary zero because the underlying AT command firmware uses a printf style format (%s) to send the data from the module. The referenced issue indicates a change was merged to support ASCII HEX, not binary. Thus, by using the format() method, you can inform the module firmware to send the data to the SAMD21 as ASCII HEX (not binary). This workaround is fine for situations where you can control how the data is sent. In the case where you do not, and the binary data could contain zeros, the downlink will not reach the SAMD21.

I had a look at (fairly recent version) v1.2.2 of the ST modem firmware stack and the problem still exists there so it has not been resolved.

What is required is a vcom function to write a byte to the UART. Does anyone know if such a function exists in the ST IDE? Perhaps we can cherry pick this function into the ST module firmware stack and then add a function to send the binary data?

[ruipalma]

If the interface is an AT command set, it must be ASCII and the binary data must be in ASCII HEX.
In AT command set, byte 13 (CR) is used to end a command, byte 127 (Del) is used to delete char, and so on. It's a industry standard interactive interface, so you must manipulate data accordingly.

[sslupsky]

Actually, there are many examples online where binary data is sent using AT commands. What is required is an AT command that sends the binary data payload, not ASCII HEX.

[ruipalma]

I believe that, it will however be something different from the “Hayes” standard as it uses text strings by definition.
In LoRaWAN every byte counts so I only work with binary data, using functions similar to this ones to send it, they work great so I don't even think about the fact that SAMD <-> Murata communication is in text format.

bool sendPacket(uint8_t *packet, uint8_t size, uint8_t port)
{
    char str[(size*2)+1];
    str[(size*2)]=0;
    for (uint8_t i = 0; i < size; i++) {
      str[(i*2)]=String(packet[i] >> 4, HEX)[0];
      str[(i*2)+1]=String(packet[i] & 0xF, HEX)[0];
    }
    int err;
    modem.setPort(port);
    modem.beginPacket();
    modem.print(str);
    err = modem.endPacket();  
    return err > 0 ? true : false;
}

And this one to process received data:

uint8_t dehex(char c) {
  return c<'A'? c & 0xF : 9 + (c & 0xF);
}

uint8_t queryModem(uint8_t *rx_buf, uint8_t bufferSize)
{
    int rx=0;
    String rcv;
    rcv.reserve(bufferSize*2);

    if (!modem.available())
      return 0;

    while (modem.available()) {
      rcv += (char)modem.read();
      rx++;
      if (rx==bufferSize*2) break;
    }

    memset(rx_buf,0,bufferSize);

    for (int i=0; i < rcv.length(); i+=2) {
      rx_buf[i/2] = dehex(rcv[i])<<4 | dehex(rcv[i+1]);
    }

    return rx;
}

I clean this functions from the application code, i don't have opportunity to test them after the clean, i hope it runs ok.
Maybe the API can have a sendBinary(uint8_t *buffer, int size) and a receiveBinary(uint8_t *buffer, int size) as a workaround.

[sslupsky]

Yes, I agree, something like that. MKRWAN.h can handle the binary stream.

With regard the power consumption, reducing the amount of data helps reduce power. I suppose downlink messages are very infrequent. A firmware update could be a large downlink though.

I am not so familiar with FUOTA yet. Where does the FUOTA image go? Does FUOTA support updating the module and the host MCU?

[ruipalma]

I'm not familiar to FUOTA also.
AFAIK the image goes to a reserved flash space, so half of the flash must be reserved.
I will like OTA fw updates over LoRaWAN but the data rate are too slow. It will take many many hours per device and will completely saturate the gateway during that time.
My current firmware weights 53Kb, its a lot of messages, i never send more than 32bytes, but i have captured packets with 100+ bytes.
Maybe with multicast messages it will not be impossible.