Send ADR via node-red

Home Forums Conduit: AEP Model Send ADR via node-red

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #19835
    Lawrence Griffiths
    Participant

    ARD works well in most cases but I need to have means of node-red Application setting the Date rate of end-node one to help with collisions, the other when ADR seems undecided about Lowering the Data rate of a poor performing end node.

    Any way I can do this?

    BTW I came across this in LoRaWAN spec says “The application layer should always try to minimize the aggregated air time used given the network conditions.” Any one know what they mean by this?

    Thanks
    Lawrence

    #19837
    Jason Reiss
    Keymaster

    An ADR command can be sent from the application using port 0 if ADR is enabled on the end-point. Otherwise application messages could be used.

    The context of this is when the network/device cannot use ADR. The application should use the best datarate to minimize time-on-air rather then the datarate with the greatest reach.

    #19839
    Lawrence Griffiths
    Participant

    Jason thanks is it as simple as sending the following from a function node to lora-out node

    var msg = {
    “payload”: 0x50ff0001,
    “eui”: “00:11:22:33:44:55:66:88”,
    “ack”: true,
    “port”: 0
    };

    // MAC LinkADRReq cmd
    // 50ff0001
    03 LinkADRReq Mac cmd 03
    5 DataRate ms nibble of DataRate_TXPower
    0 TXPower ls nibble of DataRate_TXPower
    ff00 ChMask
    01 Redundancy

    I copied 50ff0001 from AEP logs and used to understand the mac command. One thing that I noticed if my understanding is correct the TX power setting is 0 which in EU section of LoRaWAN Regional Parameters 20 dBm I thought 14 dBm was mx power for EU?

    #19841
    Jason Reiss
    Keymaster

    Content looks good, but add the 03 command type as the first byte.
    The payload data type should be a string or buffer.

    +14 dBm is max for all but 869.4-869.65 MHz band
    The MAC layer in mDot will lower according to used frequency.

    #19847
    Ajay K
    Participant

    Hi Lawrence,

    I get the part of the lowering the data rate, but how do you figure out which node you need to target from node-red? Are you parsing the lora uplink packets to see what data rate it is operating at and deciding based on that?

    Thanks,
    Ajay

    #19848
    Lawrence Griffiths
    Participant

    Ajay, when we think we are having collisions ADR has both end-nodes on same SF so my understanding is (with in power limits) two end-nodes on TX on same channel same time if the both have dif SF they will both be processed.

    Also we have a situation where RF environment changes and has caused well performing nodes to fall off net occasionally coming back online. ADR needs to at least 20 packets to access a change in DR. So when we see a nodes who RSSI has a big delta we want to take action then.

    #19849
    Lawrence Griffiths
    Participant

    Jason have tried and not got the outcome I hoped for
    Looks like the PORT is set to 1 from last block

    17:6:25:715|DEBUG|ED:0e-7e-34-64-33-30-67-44|PACKET-TX|ADDR: 00000001 PORT: 1 ACK: 0 FCNT: 00000005
    

    // MAC TX followed by Node-RED mac

    16:58:58:443|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 600100000005010003520700017bce238a
    17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 6001000000000500018a8e0a31f16a39f031
    

    var macBuf = new Buffer(‘0340070001′,’hex’);
    var msg = {
    “payload”: macBuf,
    “eui”: “0e:7e:34:64:33:30:67:44”,
    “ack”: false,
    “port”: 0
    };
    `
    // ADR from network server – works

     
    16:58:57:709|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Use RX1 TOA:56 ms
    16:58:57:715|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-RX|JSON: {"chan":0,"codr":"4/5","data":"QAEAAACCCAADBxQpdEA7z/Ew","datr":"SF7BW125","freq":868.10000000000002,"lsnr":9.8000000000000007,"modu":"LORA","rfch":0,"rssi":-33,"size":18,"stat":1,"time":"2017-07-05T16:58:57.678346Z","tmst":3861837027}
    16:58:58:439|INFO|GW:00:80:00:00:00:00:9a:26|FRAME-TX|IP: 127.0.0.1:47267 CH: LC1 NODE: 00:00:00:01 FCNT: 00000002 REPEAT: 0
    16:58:58:443|INFO|ED:0e-7e-34-64-33-30-67-44|MAC-COMMAND|ADR CMD 0352070001
    16:58:58:443|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Q-SIZE: 0 PKT-SIZE: 528 PKT-ROOM: 237
    16:58:58:443|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 600100000005010003520700017bce238a
    16:58:58:444|DEBUG|GW:00:80:00:00:00:00:9a:26|PACKET-TX|RX1 OFFSET: 1000000
    16:58:58:477|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|JSON: {"txpk":{"appeui":"00-00-01-00-00-aa-aa-aa","codr":"4/5","data":"YAEAAAAFAQADUgcAAXvOI4o","datr":"SF7BW125","deveui":"0e-7e-34-64-33-30-67-44","freq":868.10000000000002,"ipol":true,"modu":"LORA","ncrc":true,"powe":11,"rfch":0,"size":17,"tmst":3862837027}}
    16:58:58:484|DEBUG|GW:00:80:00:00:00:00:9a:26|DUTY-CYCLE|BAND: 1 DUTY: 34883
    16:58:58:484|INFO|Update DC Band: 1 Duration: 51 time-on-air available: 34832 ms
    

    Failed form Node-RED

    lora/0e:7e:34:64:33:30:67:44/down : [msg.payload] : string
    {"data":"A0AHAAE=","ack":false,"port":"0"}
    
    17:6:25:671|INFO|GW:00:80:00:00:00:00:9a:26|FRAME-TX|IP: 127.0.0.1:47267 CH: LC1 NODE: 00:00:00:01 FCNT: 00000006 REPEAT: 0
    17:6:25:715|INFO|ED:0e-7e-34-64-33-30-67-44|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 5 PKT-ROOM: 242
    17:6:25:715|DEBUG|ED:0e-7e-34-64-33-30-67-44|PACKET-TX|ADDR: 00000001 PORT: 1 ACK: 0 FCNT: 00000005
    17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|DATA: 6001000000000500018a8e0a31f16a39f031
    17:6:25:716|DEBUG|GW:00:80:00:00:00:00:9a:26|PACKET-TX|RX1 OFFSET: 1000000
    17:6:25:718|DEBUG|GW:00:80:00:00:00:00:9a:26|FRAME-TX|JSON: {"txpk":{"appeui":"00-00-01-00-00-aa-aa-aa","codr":"4/5","data":"YAEAAAAABQABio4KMfFqOfAx","datr":"SF7BW125","deveui":"0e-7e-34-64-33-30-67-44","freq":868.10000000000002,"ipol":true,"modu":"LORA","ncrc":true,"powe":11,"rfch":0,"size":18,"tmst":15101763}}
    17:6:25:719|DEBUG|GW:00:80:00:00:00:00:9a:26|DUTY-CYCLE|BAND: 1 DUTY: 36000
    17:6:25:722|INFO|Update DC Band: 1 Duration: 51 time-on-air available: 35949 ms
    
    #19856
    Jason Reiss
    Keymaster

    Looks like port as string “0” is not being parsed correctly. It should be an integer in JSON. Not sure if this is node-red or the lora-out nodes doing.

    17:6:25:715|DEBUG|ED:0e-7e-34-64-33-30-67-44|PACKET-TX|ADDR: 00000001 PORT: 1 ACK: 0 FCNT: 00000005

    #19857
    Lawrence Griffiths
    Participant

    Jason you can’t overwrite the lora-out node port setting from input msg. You can only set it from the node options. I take a look at the nodejs and see what that yields. But feel like we are in Bug territory .

    Do think this NR/out as it passed the downlink msg a JSON to MQTT which assume feeds the lora network server.

    lora/0e:7e:34:64:33:30:67:44/down : [msg.payload] : string
    {“data”:”A0AHAAE=”,”ack”:false,”port”:”0″}


    var msg = { data: new Buffer(payload).toString("base64"), ack: ack_config, port: port_config };
    client.publish('lora/' + eui + '/down', JSON.stringify(msg));

    #19859
    Jason Reiss
    Keymaster

    lora-out node is a light wrapper over MQTT

    MQTT Node
    msg.topic = “lora//down”;
    msg.payload = ‘{“data”:”A0AHAAE=”,”port”:0}’;

    Command line

    mosquitto_pub -t lora//down -m ‘{“data”:”A0AHAAE=”,”port”:0}’

    UDP is also an option.

    UDP:1786
    # nc -u localhost 1786

    lora/0e:7e:34:64:33:30:67:44/down {“data”:”A0AHAAE=”,”ack”:false,”port”:0}

    #19860
    Lawrence Griffiths
    Participant

    That worked
    msg.topic = “lora/devEUI/down”;
    msg.payload = ‘{“data”:”A0AHAAE=”,”port”:0}’;

    Think the issue in lora-out node not doing type testing on port no.
    Will mod and test think there should be something like port_config = parseInt(port_config, 10);

    Thanks for your help Jason

    #19861
    Jason Reiss
    Keymaster

    Thanks to you. I will log an incident to get this updated in AEP.

    #19862
    Lawrence Griffiths
    Participant

    Let me test the change first I do tomorrow as it’s 10pm hear in UK.. thta’s me for the night

    #19866
    Lawrence Griffiths
    Participant

    Jason it looks like parseInt(port_config, 10); fixed that issue in lora.js`

    node.on('input', function(msg) {
    var eui = msg.eui || config.eui;
    var payload = msg.payload || config.payload;
    var ack_config = msg.ack || config.ack;
    var port_config = msg.port || config.port;
    port_config = parseInt(port_config, 10);

    But there is another bug you can’t override the node port setting from msg.port also if you set the node config port drop down to blank you get null in port no

    {"data":"A0AHAAE=","ack":false,"port":null}

    Could you pls raise ticket for both of these thanks.
    Lawrence

    #19871
    Ajay K
    Participant

    Thanks a Lawrence your earlier response. I still don’t understand how you would find out when to send, when one of the nodes is not able to communicate with the conduit, since in class A you can’t even send a packet to the mdot, without mdot successfully uplinking packet. Can MAC commands be sent without such restrictions.

    In my case most of the nodes seem to be falling under the second scenario you have mentioned i.e.

    Also we have a situation where RF environment changes and has caused well performing nodes to fall off net occasionally coming back online. ADR needs to at least 20 packets to access a change in DR. So when we see a nodes who RSSI has a big delta we want to take action then.

    What did you mean by “when we see a nodes whose RSSI has a big delta”?

    Thanks,
    Ajay

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