2 way communication failure after AEP update to v1.3.2

Home › Forums › Conduit: AEP Model › 2 way communication failure after AEP update to v1.3.2

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • October 14, 2016 at 1:03 pm #15043
    Albert Beukman
    Participant

    Only up-link messages received from my end device. Verified 2-way communication with same end-device operation using different Conduit running v1.2.2.

    Hypothesis 1. Down-link not reaching end device.

    Questions as follows.
    * How can I confirm down-link is reaching the network server / MQTT broker?
    * Are any explicit changes to LoRa Network Server necessary after update?
    * Is this assumption correct: Connection to MQTT server OK as up-links are coming through OK? Is this valid for down-link as well?

    I don’t see any feedback from network server when down-link is published, only Node-Red (lora/*/down debugged), nor do I see the downstream transmission attempt after the first up-link.

    October 17, 2016 at 4:27 pm #15066
    Albert Beukman
    Participant

    Endpoint device using Microchip RN2903.

    Embedded engineer states that when a down-link is pending, network server is not sending ACK to uplink as it did with v1.2.2.

    Microchip feedback:
    Check the Network Server log file on the Conduit and see what it is trying to send out the gateway. If the Network Server is not sending the ACK, that is an error in MultiTech’s new software

    Opened up a support ticket with Multitech.

    October 18, 2016 at 5:09 pm #15091
    Albert Beukman
    Participant

    Resolution on initial hypothesis. Down-link is reaching network server and end-device; Confirmed by embedded engineer. Network server log extract below.

    18:20:32:905|TRACE|MQTT message: lora/<EUI>/down
    18:20:32:906|TRACE|SQL query = SELECT address FROM nodes WHERE deveui = <EUI>;
    18:20:32:907|DEBUG|Mosquitto command received ‘down’
    18:20:32:908|DEBUG|Use port 160
    18:20:32:908|DEBUG|app data size 0
    18:20:32:908|INFO|Queue app data 3 bytes
    18:20:32:908|INFO|Scheduled 4 bytes payload

    Apparent absent up-link confirmation when down-link pending still being investigated.

    October 21, 2016 at 8:38 am #15099
    Steve Kovarik
    Moderator

    Hello Albert

    Are you confirming that this is working OK for you now and the problem has been solved? If so, what fixed it.

    -Best Regards

    November 3, 2016 at 5:05 pm #15338
    Albert Beukman
    Participant

    Thanks for following up Steve;

    Confirmed with embedded engineer that he was waiting for mac_tx_ok after 2nd up-link, but never receiving it. This was preventing the embedded application from continuing normal operation – and consequently creating the impression of a broken 2-way link.

    RN2903 output
    (A) Output where tx confirmed and no downlink pending.

    mac tx cnf 160 0205040302 [len=25]
<20161014120058.632 RX>
ok [len=2]
<20161014120100.102 RX>
mac_tx_ok [len=9]
<20161014120101.194 RX>

    (B) Output where down-link pending

    mac tx cnf 160 0205040302 [len=25]
<20161014120230.628 RX>
ok [len=2]
<20161014120232.133 RX>
mac_rx 160 006900 [len=17]

    Confirmed with Multitech support (from raw data in network server logs) that the up-link confirmation(/ack) was not sent by the network server because said up-link was set as unconfirmed.

    Although inconsequential now, I presume the unconfirmed 2nd up-link was ACK’d by network server in 1.2.2.

    This situation is now handled in the firmware application and 2-way communication works as before.

    Kind regards.

  • Author
    Posts
Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.