LoRawan Class C multicast.

[Antonio Muñoz]

Hi.
I am working with an conduit AEP and it would be very useful to be able to send data in class c in multicast for all the devices.
It’s possible ?

Thank you very much in advance.
regards.

[Jason Reiss]

It is possible but not easy.

To send a multicast all receiving device must have the same session keys and counters.

A fake ABP device can be added to the network server. Then the dev addr and session keys can be sent from the application to all receiving end devices. After which downlinks sent to the fake ABP multicast eui will be received be all devices.

The mDot/xDot libraries have functions to setup multicast sessions.

[Antonio Muñoz]

Thanks Jason.
I’ll try.
regards

[Antonio Muñoz]

Hi Jason.
I have created a new node:

lora-query -x device add ‘{“deveui”:”00-11-22-33-44-55-66-77″,”class”:”C”}’

lora-query -x session add ‘{“deveui”:”00-11-22-33-44-55-66-77″,”dev_addr”:”11111111″,”appeui”:”22-22-22-22-22-22-22-22″,”joineui”:”00-11-22-33-44-55-66-77″,”net_id”:”008000″,”app_senc_key”:”00112233445566778899aabbccddeeff”,”fnwk_sint_key”:”00112233445566778899aabbccddeeff”}’

After I transmit a data packet to an existing node, it is transmitted correctly.

But when I try to transmit to the new created node, the message is not transmitted
I show you the lora-network-server.log of both messages

Good message:

10:33:19:436|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTgwICBTTlI6IDkuMiAgQ0g6IDUgBQ==”,”ack”:false,”port”:81}
10:33:19:441|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:66
10:33:19:453|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
10:33:19:463|DEBUG| Device::ScheduleSendApplication Class: 2
10:33:19:463|DEBUG| getTimeOnAirMs SF: 12 BW: 125 PL: 8 SZ: 28 TOA: 1482
10:33:19:464|TRACE| Schedule DC band: 2 available: 360000 duration: 1532 freq: 869525000
10:33:19:464|DEBUG| Schedule Class C downlink packet
10:33:19:762|INFO| GW:00-80-00-00-00-00-aa-85|FRAME-TX|IP: 127.0.0.1:53760 CH: LC6 DEV: 00-6a-ff-cd FCNT: 00000009 REPEAT: 0
10:33:19:769|INFO| ED:00-04-a3-0b-00-1e-a5-a0|SCHED-TX|Q-SIZE: 1 PKT-ROOM: 51
10:33:19:770|DEBUG| getTimeOnAirMs SF: 12 BW: 125 PL: 8 SZ: 37 TOA: 1810
10:33:19:770|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|PACKET-TX|ADDR: 006affcd PORT: 81 ACK: 0 FCNT: 00000009
10:33:19:771|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-TX|DATA: 60cdff6a0000090051dfae52bfc0538a48b179828d977989b916ad22696a76d47385b11d3fc30a00fc
10:33:19:772|DEBUG| GW:00-80-00-00-00-00-aa-85|PACKET-TX|RX2 OFFSET: 7000000
10:33:19:786|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-TX|JSON: {“txpk”:{“appeui”:”54-45-4c-4c-49-4e-4b-00″,”codr”:”4/5″,”data”:”YM3/agAACQBR365Sv8BTikixeYKNl3mJuRatImlqdtRzhbEdP8MKAPw=”,”datr”:”SF12BW125″,”deveui”:”00-04-a3-0b-00-1e-a5-a0″,”freq”:869.52499999999998,”gweui”:”00-80-00-00-00-00-aa-85″,”imme”:true,”ipol”:true,”modu”:”LORA”,”ncrc”:true,”powe”:0,”rfch”:0,”size”:41,”twnd”:2}}
10:33:19:787|DEBUG| GW:00-80-00-00-00-00-aa-85|DUTY-CYCLE|BAND: 2 DUTY: 360000
10:33:19:787|DEBUG| getTimeOnAirMs SF: 12 BW: 0 PL: 8 SZ: 41 TOA: 2138
10:33:19:788|INFO| Update DC Band: 2 Duration: 2138 time-on-air available: 357862 ms
10:33:19:788|INFO| GW:00-80-00-00-00-00-aa-85|UDP-TX|JSON-SIZE:326
10:33:19:789|TRACE| TX-MSG|127.0.0.1:53760 330 bytes
10:33:19:807|DEBUG| DeviceTransmitController::TransmitFrame ID: 66
10:33:21:984|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01948104
10:33:21:985|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760
10:33:32:185|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 0103d504
10:33:32:186|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760

Message from the manually created node:

10:33:40:908|DEBUG| ED:00-11-22-33-44-55-66-77|DOWNLINK|Queue {“data”:”IFJTU0k6LTgwICBTTlI6IDkuMiAgQ0g6IDUgBQ==”,”ack”:false,”port”:81}
10:33:40:924|WARNING| ED:00-11-22-33-44-55-66-77|QUEUE|Created downlink record ID:67
10:33:40:924|INFO| ED:00-11-22-33-44-55-66-77|QUEUE-TX|DATA SIZE: 28
10:33:42:384|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01692504
10:33:42:385|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760
10:33:52:584|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01481004
10:33:52:585|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760

This message does not progress, but I do not know why.

[Jason Reiss]

Now set the session uplink counter to 1.

lora-query -x device <DEVEUI> update ulc 1

This should allow the downlinks to be sent.
Normally the network server will wait for one uplink from an end device before scheduling downlinks.

[Antonio Muñoz]

Thank you very much Jason again
I will try

Regards

[Antonio Muñoz]

Hi Jason.
I have tried and it works perfectly.
I already receive the data in the multicast motes in class C.

Thanks again.

• This reply was modified 6 years ago by Antonio Muñoz.

[Antonio Muñoz]

Hello again.
Now I have a similar problem and when I try to transmit a data packet to a specific node, the packet is received by the lora-network-server, but it does not progress, it’s like the problem I had yesterday with the node created for multicast, I have tried with the previous solution:

lora-query -x device update <dev_eui> ulc 1

but the message has not progressed yet.
It only happens with a certain node.
This is what I see in the lora-network-server.log

8:48:35:646|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:48:35:679|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:295
8:48:35:680|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:48:38:726|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 01c23104
8:48:38:726|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524
8:48:41:917|TRACE| TX-ACK|127.0.0.1:35478 4 bytes 01d95501
8:48:41:918|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PUSH-DATA|127.0.0.1:35478
8:48:41:919|INFO| GW:00-80-00-00-00-00-aa-85|FRAME-RX|Parsing 1 packets
8:48:41:919|WARNING| GW:00-80-00-00-00-00-aa-85|FRAME-RX|CRC-ERROR

8:54:21:386|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:54:21:435|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:296
8:54:21:436|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:54:25:526|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 0104f604
8:54:25:526|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524

8:55:35:513|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:55:35:533|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:297
8:55:35:545|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:55:36:727|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 01483c04
8:55:36:728|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524

I tried to make a new login ota, but it has not helped.
What is the solution ?

Thanks.

[Antonio Muñoz]

After a time without transmitting any message, I have tried again and the conduit has sent one by one all the messages that had had to send previously.
I do not understand why the messages did not come out.

[Antonio Muñoz]

Hello Jason again.
Regarding the subject of this post, I am having problems with the new firmware version AEP 5.2.1.
Specifically, I do the same procedure as with previous versions (1.6.4) to transmit packets to a large number of nodes simultaneously. But with this firmware version the packets are not transmitted. Do you know what the reason may be?

Thank you so much and Happy New Year.

• This reply was modified 3 years, 3 months ago by Antonio Muñoz.

[Jason Reiss]

The previous procedure was a work around to get multicast to work.

When creating the multicast session provide this field.
“multicast”: “C”

[Antonio Muñoz]

I have tested it and it works fine.
There is a document where these details are described, to be able to consult it in the future without having to ask the forums.
Thank you very much again.

[Jason Reiss]

I see it referenced in the release notes for mPower 5.1.5
https://www.multitech.com/documents/publications/sales-flyers/PCN%2003092020-001_mPower%20Software%20Release%205.1.5.pdf

I agree an official mPower developers guide document would be a great addition to the available resource.

[Antonio Muñoz]

Hi Jason. Thanks for your answer.
Currently I have another problem that I do not know how to solve. To access with winscp I must first access with a telnet session and configure a password for root (“sudo passwd root”). This way I can access all folders with winscp. However this is not permanent, when I restart the conduit, I have to do the same operation to be able to access with winscp. Is there a solution to make the root password permanent?
Thanks again and best regards.

[Antonio Muñoz]

Hi Jason, I know how to do it. I have created a script that I run from node red with the following line:

echo -e “mypassword \ nmypassword” | passwd root
This way when I want to log in with winscp, I can do it as root.

Cheers

[Author]

Posts