Auto Addressing not working when Master power on after slaves

[maxidroms83]

I user pure example from repo
https://github.com/gioblu/PJON/tree/master/examples/ARDUINO/Network/SoftwareBitBang/MasterSlaveAutoAddressing

It works good when I connect slave device in line when master is powered.

But if I will reboot master arduino, the list_ids ignored and not assign any addresses.

The portion of the code is not showing any devices.
for(uint8_t i = 0; i < PJON_MAX_DEVICES; i++) { if(bus.ids[i].state) { Serial.print("Device id: "); Serial.print(i + 1); // Shifted by one to avoid PJON_BROADCAST Serial.print(" Device rid: "); Serial.print(bus.ids[i].rid); Serial.print(" | "); } }

[gioblu]

Ciao @maxidroms83 I have run a test now with 2 Duemilanove is working fine, If I reset master it receives soon after a 205 request by slave including the id assigned by master before its reset.
Which devices are you using for this test?
Try adding a 1M pull-down resistor.

[maxidroms83]

Hi @gioblu
I used MEGA2560 r3 as master and Uno r3 as slave.

Here is their code and some logs:

I've attached the code for master and slave I used.
I feed power master from USB, and slave from master via 5v out to Vin pin.
I tried with 1M and 4.7 M pull-down resistor.

Archive.zip

here is some logs when I inserted UBS cable to my laptop:

Master initialized
Header: 111 Length: 1 Receiver id: 254 Sender id: 255 Request: U RID: 1354766041 Packet: 85 Packets in buffer: 0
Slave answer received.

---

Header: 111 Length: 1 Receiver id: 254 Sender id: 255 Request: U RID: 1354766041 Packet: 85 Packets in buffer: 0
Slave answer received.

---

Header: 111 Length: 1 Receiver id: 254 Sender id: 255 Request: U RID: 1354766041 Packet: 85 Packets in buffer: 0
Slave answer received.
Header: 111 Length: 1 Receiver id: 254 Sender id: 255 Request: U RID: 1354766041 Packet: 85 Packets in buffer: 0
Slave answer received.

---

Here is I push reset button on slave

Header: 110111 Length: 5 Receiver id: 254 Sender id: 255 Request: ⸮ RID: 1528794506 Packet: 200 91 31 141 138 Packets in buffer: 1
Header: 110111 Length: 6 Receiver id: 254 Sender id: 1 Request: ⸮ RID: 1528794506 Packet: 201 91 31 141 138 1 Packets in buffer: 0
Header: 111 Length: 1 Receiver id: 254 Sender id: 1 Request: U RID: 1797229962 Packet: 85 Packets in buffer: 0
Slave answer received.
Device id: 1 Device rid: 1528794506 | ***
Header: 111 Length: 1 Receiver id: 254 Sender id: 1 Request: U RID: 1797229962 Packet: 85 Packets in buffer: 0
Slave answer received.

---

As you can see, no device detected until I reset slave. But even if no device detected the broadcast events working just perfect.

[gioblu]

Ciao @maxidroms83 I have tested with a mega 2560 R3 as master, I do not have a UNO to test with in this moment, but with Duemilanove works fine.

Maybe is the power supply the problem, if you supply 5v to VIN I am not sure the voltage regulator will be able to generate 5v in VIN, try to supply with 5v pin to 5v pin.

[maxidroms83]

I will try power up them separately.
I also have the same problem with MEGA2560 -> Trinket 5V.

I am not arguing with guru's developed this amazing library, but I think if your protocol working to receive broadcast messages and send response - successful, but Auto Address is not working during arduino initialization, then this is not power supply problem.

The question mostly is: why if master send BROADCAST and Salve respond to PJON_MASTER_ID with PJON_NOT_ASSIGNED id like this:
Header: 111 Length: 1 Receiver id: 254 Sender id: 255 ......

why master do not handle this and do not assigning Dynamic Id after first message received from slave with PJON_NOT_ASSIGNED address ?

[gioblu]

Ciao @maxidroms83 thank you for your compliments, about the "guru" title I think I still need many years of dedication. Speaking about the issue, I have read back your answer, the motivation why it behaves as you describe in the case of PJON_NOT_ASSIGNED device on master PJON_ID_LIST request is the condition at line 297 in PJONSlave.h

You are right, in this particular case as the code is now, slave will not list their id if not assigned. For this reason master does not detect them and they remain not listed.

[gioblu]

Ciao @maxidroms83 I am testing a change that seems fixing the issue (from line 296 PJONSlave.h):

if(this->data[overhead - CRC_overhead] == PJON_ID_LIST)
  if(this->_device_id != PJON_NOT_ASSIGNED) {
    if(
      (uint32_t)(PJON_MICROS() - _last_request_time) >
      (PJON_ADDRESSING_TIMEOUT * 1.125)
    ) {
      _last_request_time = PJON_MICROS();
      response[0] = PJON_ID_REFRESH;
      response[5] = this->_device_id;
      this->send(
        PJON_MASTER_ID,
        this->bus_id,
        response,
        6,
        this->config | PJON_ACK_REQ_BIT | required_config
      );
    }
  } else if(
    (uint32_t)(PJON_MICROS() - _last_request_time) >
    (PJON_ADDRESSING_TIMEOUT * 1.125)
  ) {
    _last_request_time = PJON_MICROS();
    acquire_id();
  }

Thank you for reporting this.

[maxidroms83]

Thank You! Testing now..

[gioblu]

Thank you @maxidroms83 for support, testing and fast response.

[maxidroms83]

Hi @gioblu ,
I finished testing this case around and multiple times. Looks like the original problem was resolved.

But there is another case.

I looked at the PJONSlave.h. I understand what you proposed.
Here is what's happening.
First of all I tested with separate power supply - all working is fine! I think the problem is, when 2 arduinos powered at exactly the same moment - some glitch happening during the initialization:

1. Both arduinos initializing.
2. Master send list_ids when slave not initialized yet.
3. I opening Serial Monitor to see the logs (do it very quick after powering arduinos)
4. Reset happening (Sketch always restarting when I open serial monitor)
5. In loop() is ee empty device list but broadcast to slave and reply to master looks like this:

Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

6. Even I restart master with reset button it's not help.
7. I continue to receive broadcast to slave messages and reply back from slave but address will never assigned.

And this case was fixed by your change. Now, if i change step #3 to "Wait for 30 sec, while you make sure communication between master and slave is working. Open Serial Monitor then. Sketch will be restarted and slaves will never be assigned the new address".

Messages will be always look like:

Master initialized
Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255
Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

Header: 100111 Length: 3 Receiver id: 254 Sender id: 255 RID: 892704692 Message: 255

Here is most recent files to test and wiring pic.
Archive2.zip

[gioblu]

Ciao @maxidroms83, so testing here with the original sketch present in master I cannot reproduce the second issue you describe, commenting line 179 and 180 of PJONSlave and running the example make possible to reproduce the issue you initially described (slave remains PJON_NOT_ASSIGNED because acquire_id is not called, master sends PJON_ID_LIST, no answer), adding the change I have sent you this problem seems fixed. I see you have added a cyclical packet sending using send, that could influence the test. Is the same happening running simply the unchanged example?

[maxidroms83]

Nope, the unchanged example works perfectly.
If your suggestion is correct - I need delay for 5-10 sec for "handshaking" before start sending any data

[gioblu]

CIao @maxidroms83 sorry but I yersterday night fall asleep, was really late.
It may be because underlivered packets are making the buffer full after reset.

For sure is a good idea to give some time to master to handshake with other slaves before starting operating with cyclical sendngs

[gioblu]

Ah, @maxidroms83 I forgot, if you need to send cyclically use send_repeatedly instead of send.
If you call send cyclically without being sure older packets have been delivered you could accumulate packets and potentially fill the packets buffer. Maybe that is the reason of behavior 2. Soon will follow fix to your initial report. Thank you again.

[gioblu]

Fix added, thank you again I will close for now here, feel free to open back if something is not clear.
Happy tinkering.

[maxidroms83]

Hi @gioblu ,
Sorry, I was out of town. I ended with some timeouts before start sending informations and it works very well. So, thank you very much for this great Job!