Guy

Forum Replies Created

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • in reply to: OTAA sessions and Conduit restart #27723
    Guy
    Participant

    Ok, that is confusing.

    I have just been using OTA and did not realise the difference in how you configure OTA versus ABP devices. So I guess I must have done it correctly.

    You say that they joined ok though ?

    You could try getting one device working reliably on your desk first and then run around and get the others working.

    in reply to: OTAA sessions and Conduit restart #27627
    Guy
    Participant

    Hi Jason

    Thanks, that was the issue. I was pulling the plug to simulate a power failure but had not had the device running long enough since the join for the DB to backup.

    I assume that whilst the device was in the whitelist the latest network keys had not yet been saved so the messages were rejected.

    in reply to: OTAA sessions and Conduit restart #27621
    Guy
    Participant

    Hi Michael
    thanks, but I have added the devices on the WebUI so they are in the database

    in reply to: DeviceTimeReq LoraWAN 1.0.3 #27455
    Guy
    Participant

    Thanks Jason. I managed to get this to work.

    Just to close the loop for those who may run into this issue:

    I had a mismatch on the DownlinkDwellTime settings on the MultiTech Conduit versus my LoraWAN stack (STM/Semtech). So I was not processing any downlinks at all, Mac commands included.

    The Actility stack can start with DwellTime 1 on AS923 (default for Semtech stack) and then sets it to 0 with a MAC command on the first downlink. This gets the device in a better config for packet size.

    The Conduit requires that the LoRaWAN settings match the stack and does not attempt to change it.

    So I needed to change the AS923 regional parameters settings in the Semtech stack to DwellTime = 0 and set the Conduit accordingly.

    • This reply was modified 5 years, 1 month ago by Guy.
Viewing 4 posts - 1 through 4 (of 4 total)