mDot Device Class C work flow

Home Forums mDot/xDot mDot Device Class C work flow

Tagged: , ,

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #15433
    Serkan
    Participant

    We are using mDot and Conduit products.
    mDot has firmaware version 2.0.
    We set device class C with command AT+DC=C

    Question 1. We need to send packet from Conduit to all mDot end point products. (not to one EUI) All devices in that network. Can we do it?

    Question 2. We able to receive packets from Conduit when we send a packet from end point. I read that Device Class A works like that. But we want to change it to device class C, and we want to send commands to all devices. do we need to AT+PING or AT+SEND fixed intervals to AT+RECV? Or can we just use AT+RECV to check any packets received?

    Best regards

    #15435
    Jason Reiss
    Keymaster

    Multicast is not explicitly supported.

    The packet will be received by all Class C devices. But it will be filtered by the network address.

    AT+SEND is only needed for Class A device to receive.
    In Class C AT+RECV will show the last received packet.
    However there is not a notification of packet received with the AT Firmware. The AT+DLC can be monitored to see the Frame Counter of the last packet.

    A custom firmware using the library can register an event class to handle packets when they are received. It can also receive packets that have been filtered out by the network address, however they will still be encrypted.

    #15436
    Serkan
    Participant

    Hi Jason,

    Awesome, same network, all of our devices can receive packets that we sent from server.

    We can check downlink frame counter with AT+DLC. It’s OK for our situation. We don’t need any events or triggers.

    Q1: We are using, Conduit AEP, Node-Red. Devices in admin panel shows Device Class A, but we changed it to device C in mDot, do we need to register again that devices?

    Q2: In Node-Red, Lora Out Node could not send a payload with a function node. In function node we return new { Payload : “test data” } format. But not sent. If we connect Lora in to Lora Out, when we AT+SEND we can get Echo of that message. I need to create proper new MSG format. How can i do it?

    Thank you for fast response.

    #15437
    Jason Reiss
    Keymaster

    If you direct the output of the lora-in node to a debug node and configure the debug node to show the complete object you will see a correctly formatted packet that is sent as an echo.

    Only the eui and data/payload are required for downlink.

    A class C device needs to be configured on the network server independently. There is currently not a message the device can send to signal that it is Class C.

    LoRa Network Server

    #15448
    Serkan
    Participant

    Thank you.

    Class C problem solved.

    But you said that “if we send msg without EUI, all devices in same network will receive that message.”

    So, in new msg format i need EUI and Payload . What should i set EUI to send all devices. iş there a format like 00:00:00 or do i need to leave it empty?

    { EUI : "", Payload : "test" }

    and when i debug complete msg object there are lots of fields. Should i use that fields? Channel number, band, timestamp etc.
    i am only interested in Payload and not to giving EUI filtering.

    Best regards

    #15453
    Jason Reiss
    Keymaster

    I would be interested to see where you are quoting from. That behavior is not supported. A msg will always need an eui to identify the destination.

    Multicast is not explicitly supported.

    The packet will be received by all Class C devices. But it will be filtered by the network address.

    For multicast to work all devices would need to share a network address and set of session key to verify and decrypt the payload.
    The mechanism to share the address and keys does not exist.

    #15695
    Pascal
    Participant

    Hi

    We are using, Conduit AEP, Node-Red. Devices in admin panel shows Device Class A, but we changed it to device C in mDot, do we need to register again that devices?

    Could you please explain where you have an “admin panel” to see the devices ?

    Is it in the conduit web page or in the node-red (I cannot find it)

    Thanks
    Regards

    #16268
    Mark Makarychev
    Participant

    Pascal, I believe he is talking about the page that is located on the conduit web page (Status & Logs -> Statistics -> LoRa [tab]).

    I found this topic while searching for an explanation as to why in Class C I’m only getting packages after TX, and I also found that on the LoRa server all the devices are marked as Class A. After reading this became a bit disappointed:

    There is currently not a message the device can send to signal that it is Class C.

    Is this going to be added sometime in the near future? Because changing 100+ mDots from Class A to Class C by hand on the LoRa server sounds like a dreadful task…

    #19153
    Momo Smith
    Participant

    Hi guys, i follow your topic and i hope you can help me.
    I try to configure a node MTDOT868 in Class C and a multitech Conduit.

    With the conduit, i don’t have a problem. I’m sure to send a message with a payload and a correct EUI.
    However, for the mtdot868, i have join my reseau and i have configure node in class C.
    Now, i try to understanding why i don’t receive a message in my node.
    I use a console (putty) for read information. I can see configuration information but no data sended by a conduit.

    First question :
    Why in the class_c_exemple.cpp, there is a fonction send ? Why send a message by a node before to see a message from the conduit.

    Second question :
    Is there a complet code in class c who working ? and where i find it ?

    Thanks in advance

    #19175
    Mark Makarychev
    Participant

    Momo, for class C to work, you need to also tell the gateway(*) that node ‘X’ is a class C device. In the class_c_example.cpp there is a send function to send data to the gateway, but this does not mean that the node receives data only after sending. If you initialized the mDot as class C, it will be continuously listening for packages from the gateway – not just after sending (as a class A device would).

    (*) Now: how to set up a node as class C on the gateway:
    1. Connect to the gateway whichever way is easier for you. I usually just connect through the microUSB port on the back and connect to the gateway through putty (COM device).
    2. Type: lora-query -n to list all the connected nodes. Find your class C node in the list and remember what number it is (00000000X).
    3. Then type lora-query –u 00000000X class C to set node X as a class C device. When both the node is initialized as Class C and the gateway knows that this node is Class C, you should be able to receive packets from the gateway right away.
    4. Type /etc/init.d/lora-network-server restart to restart the gateway and save the new configuration.

    #19214
    Momo Smith
    Participant

    Hi Mark,
    I have configure my server today.
    My program working now. Thank you.

    #19223
    Momo Smith
    Participant

    Hello friends,

    Now, my node is in class C. I can see each data in a console. I would like to retreive data for send it with a UART connexion. I read a differents functions in file mDot.h. There is just one function to receive named recv(). In comment, it’s note “send() must be called before recv()”
    So, my question is :
    What is the good fonction i need to use for receive each datas in real time without use send() before ?

    Thank

    #19228
    Mike Fiore
    Blocked

    Momo,

    You should use the event framework to print your RX data on the debug port. See mDotEvent.h in the Dot Library.

    Cheers,
    Mike

    #20772
    Mark Makarychev
    Participant

    Hello,
    Has this been added yet?

    There is currently not a message the device can send to signal that it is Class C.

    If not, in what version is it expected/planned to be added?

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