LoRa Stack 4.40 and AS923 Dwell Problem

Home › Forums › Lora Network Server › LoRa Stack 4.40 and AS923 Dwell Problem

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • February 28, 2018 at 11:21 am #22713
    Amir Ronen
    Participant

    Hi
    I updated to LoRa Stack 4.4.0,working with STArm CPU.
    i am using multitech AEP MTCDT-H5-210A Firmware 1.4.3
    LoRa setup is on AS923 with Both Dwell times OFF.
    on the end unit LoRa stack, They have added a check on the RxDone function for a legal max payload received from the server.
    Since the default for AS923 is dwell on the commands from the server are
    discarded! the unit receives 33 bytes but the max payload is 11.
    i think that because the server works with Dwell off it sends long commands after the first message that includes new RF channels and the TX Parameters Setup request (that includes the dwell off set).but the Max pay load query returns max of 11 bytes because the dwell is still on!
    I changed the AS923 region AS923_DEFAULT_DOWNLINK_DWELL_TIME to 0
    And the problem was solved!. so i don’t know if the server supposed to communicate with the unit as if dwell is on – even if it is configured to dwell off,just because the unit start with dwell on as default, or the end units should not assume that the down link is on upon startup (and let the server set it…)
    Thank you
    Amir

    February 28, 2018 at 11:30 am #22714
    Jason Reiss
    Keymaster

    33 bytes it the join accept message.

    The network server will send down the dwelltime params in the first few downlinks if dwelltime is enabled or one downlink if it is not enabled at the server. The network server will not know if the end-device is defaulted to dwelltime on to send a join accept without the CFList.

    It may be assumed a device will join with the dwelltime disabled.

    Have you raised the issue with the main source project?
    https://github.com/Lora-net/LoRaMac-node

    February 28, 2018 at 11:52 am #22717
    Amir Ronen
    Participant

    Thank you for the quick response
    I will try to raise the question at semtech support.
    However, the max payload check is not done on the join response.
    The CF List might be too long to send on the join response alone, so it is continued on the first message response with SRV_MAC_NEW_CHANNEL_REQ commands, together with the TX params command,and this is where it fails.
    BR
    AR

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