Infinite collision about pjon HOT 7 CLOSED

We could try something like nick gammon in his rs485 example did: http://www.gammon.com.au/forum/?id=11428

from pjon.

@gioblu Would this implement what you suggested?

int response = bus.send(address, message, 2);

while (1) { 
    if (response == NAK || response == FAIL) {
        delay(random(0, 20));
    }
    bus.update();
}

from pjon.

Ciao @thomsna. Yes, here it is what I am locally testing:

uint16_t PJON::send_string(uint8_t id, char *string, uint8_t length) {
  if(!*string) return FAIL;
  if(!this->can_start()) return BUSY;

  uint8_t CRC = 0;
  pinModeFast(_input_pin, OUTPUT);

  this->send_byte(id);
  CRC ^= id;
  this->send_byte(length + 3);
  CRC ^= length + 3;

  for(uint8_t i = 0; i < length; i++) {
    this->send_byte(string[i]);
    CRC ^= string[i];
  }

  this->send_byte(CRC);
  digitalWriteFast(_input_pin, LOW);

  if(id == BROADCAST) return ACK;

  uint32_t time = micros();
  uint16_t response = FAIL;

  /* Receive byte for an initial BIT_SPACER bit + standard bit total duration.
     (freak condition used to avoid micros() overflow bug) */
  while(response == FAIL && !((uint32_t)(micros() - time) >= BIT_SPACER + BIT_WIDTH))
    response = this->receive_byte();

  if(response == ACK) return response;

  /* Random delay if NAK, corrupted ACK/NAK or collision */
  if(response != FAIL)
    delayMicroseconds(random(0, COLLISION_MAX_DELAY));

  if(response == NAK) return response;

  return FAIL;
};

With this approach, modifying a little the send_string function you are now catching NAKand also other response values like a damaged ACK/NAK or simply a collision with another transmission.

I think FAIL should not be considered as a sure collision, but more likely absence of communication, so I think should be treated differently.

from pjon.

Nice to see an improvement is in the pipeline for this matter :)
I guess the key here is this line: delayMicroseconds(random(0, COLLISION_MAX_DELAY));
where (0, COLLISION_MAX_DELAY) is the window defined by quadratic backoff.

from pjon.

Ciao @thomsna I am not sure to have understood your point.

By my side, I think COLLISION_MAX_DELAY should not be shorter than the average oscillation in code execution (temperature, ceramic resonator, different board layout i.e. vias length to clock) but should be as short as possible to reduce bandwidth and computation time loss.

from pjon.

so you let me stumble in this issue: delayMicroseconds(random(0, COLLISION_MAX_DELAY)), minimum should not be zero but this value we should still determine/estimate to go over oscillation.

from pjon.

Ciao @thomsna today I met with Mauro personally and we have built a network sharing our hardware:

• 15 Arduino Nano
• 1 Arduino mega
• 1 ESP8266 and
• 1 ATtiny85

With a true multimaster setup (so with bidirectional flux of packets to many devices) and with the new 2.0 version works flawlessly (O_ o we are shocked works really amazingly)!!

The added delays reduced enormously the chance of a collision. We still are considering to setup a test to measure the effective quantity of collisions (if they still occur), probably using a sketch and scoping the channel in parallel with an oscilloscope.

Soon will follow video / gif of the experiment :)

from pjon.