timeouts over and over again

[ivannunyadambiz]

Setup: pozyx shield on an arduino mega2560 and a pozyx anchor 3m away in direct line of sight.

Code:

#include <Pozyx.h>
#include <Pozyx_definitions.h>
#include <Wire.h>

uint8_t counter = 0, calibration, status, listsize;
bool justforfun = false;
uint16_t anchors[10];

void setup()
{
  Serial.begin(115200);

  Pozyx.begin(); // we don't care about return codes here.
  Pozyx.clearDevices();

  Serial.println("MAAAARCOOOOOO...");

  Pozyx.doDiscovery(POZYX_DISCOVERY_ALL_DEVICES, 5, 10);
  Pozyx.getDeviceListSize(&listsize);

  if(listsize != 0) Serial.println("I hear someone shouting polo...");
  else              Serial.println("Nope. All by myself here...");

  Pozyx.getDeviceIds(anchors, listsize);

  Serial.print("His name is ");
  Serial.println(anchors[0], HEX);
  Serial.println();

  delay(1000);
}

void loop()
{
  counter++;

  status = Pozyx.getCalibrationStatus(&calibration, anchors[0]);
  if(status != POZYX_SUCCESS)
  {
    Serial.print("\nERROR: getCalibrationStatus: ");
    Serial.println(status);
    Serial.println(Pozyx.getSystemError());
    Serial.print("I crashed after reading CalibrationStatus from ");
    Serial.print(anchors[0], HEX);
    Serial.print(" ");
    Serial.print(counter - 1);
    Serial.println(" times");
    delay(100);
    abort();
  }
  else
  {
    if(justforfun ^= 1) Serial.print("TICK\t");
    else                Serial.print("TOCK\t");
    Serial.println(calibration, BIN);
  }
  delay(200); // this just HAS to be enough...
}

I get like 1 in 10 runs to manage 100 data exchanges without failing. I'm not saying I cannot implement my own packet loss/timeout handling, but the shield certainly has more mips to spare than the atmega...

[samuelvdv]

Hi, a basic re-transmission protocol was implemented on the board but eventually we did not enable it for the release because we wanted real-time behavior. For example, in the orientation 3D sketch where the motion data is read remotely in real-time. A delay due to signal re-transmission would be undesirable. however, perhaps we could include a register in one of the next firmware updates to configure the re-transmission this way people can choose between real-time behavior and reliability. Thanks for the suggestion.