mDot with public networks

Home › Forums › mDot/xDot › mDot with public networks

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • October 24, 2015 at 5:11 am #9696
    Andrew Lindsay
    Participant

    Hi,

    I’m trying to get an mDot working with my Conduit that has been configured as a public gateway forwarding LoRaWAN packets to The Things Network. I have gone through the libmDot functions to identify those used for public and those used for private networks. I have the following function calls:`setPublicNetwork(true)
    setJoinMode(MANUAL)
    setAck(1)
    setNetworkAddress( 4 bytes that I believe to be unique address for this node)
    setNetworkSessionKey( 16 bytes )
    setDataSessionKey( 16 bytes )`

    I see a message on the usb serial output that it is joining the network and then successfully joined but I dont see any packets forwarded via the packet forwarder log. The values used for Network session key and data session key are the ones shown on the TTN wiki and when read using the get functions are the same.

    I also see CRC errors being received by the packet forwarder and not forwarded on.

    I know the gateway is communicating with The Things Network as I can see it using the API and using tcpdump on the Conduit I can see the UDP traffic between the two including the status updates.

    I did try allowing CRC failed packets through and have seen some node activity but the address of the node was 00000000 and not the value I was expecting to see.

    Any ideas as to what I’m doing wrong or what I’ve missed?

    Thanks

    Andrew

    October 24, 2015 at 8:45 am #9698
    Jason Reiss
    Keymaster

    Andrew,

    When in MANUAL join mode, the call to join will not send a message out since it has the address and keys that would have been assigned and generated in the join request/accept messages.

    What settings are you using for the packet forwarder config?
    Have you configured the “synch_word” to be 52 for public network?

    October 24, 2015 at 10:18 am #9703
    Andrew Lindsay
    Participant

    Jason,

    “synch_word” is 52. I have seen a single message get through ok, but that appears to be the only one after running this for a few days. Compared to using a local private address where all packets were being received.

    thanks

    Andrew

    October 24, 2015 at 11:08 am #9704
    Jason Reiss
    Keymaster

    Can you try the private network setup again?

    Or you can try to connect to TTN with the AT Command firmware.

    AT+PN=1
    AT+NJM=0
    AT+NA=
    AT+DSK=
    AT+NSK=
    AT+ACK=1
    AT&W
    ATZ
    AT+SEND=data

    October 25, 2015 at 10:40 am #9709
    Andrew Lindsay
    Participant

    For some reason it is getting timeouts while waiting for the ACK response. So looks like either the Conduit is not handling the packets properly or its detecting errors and not forwarding the packet.

    Andrew

    October 26, 2015 at 8:30 am #9710
    Brandon Bayer
    Blocked

    Andrew,

    TTN doesn’t currently support ACKs (according to Johan), so you’ll want to disable that for now.

    Also, TTN has a back-end issue where all received packets don’t show up through the API. Quoting Johan from the TTN forum thread:

    Now, we have a storage issue on our back-end. Turns out that not all data is being routed correctly and stored as it should.

    So you’ll only want to rely on the packet forwarder logs for verifying packets are being forwarded to TTN. Here’s an example where the forwarder receives 1 valid packet and 1 ghost packet from noise. You can see in the UPSTREAM log that 1 packet was CRC_OK and was forwarded to TTN:

    
lgw_receive:1428: FIFO content: Pkts: 1 6c 0 Stat: 5 Size: 12
lgw_receive:1443: [6 17]  //<--- VALID PACKET
Note: LoRa packet
lgw_receive:1428: FIFO content: Pkts: 1 8e 0 Stat: 7 Size: 7f
lgw_receive:1443: [5 17]  //<--- GHOST PACKET FROM NOISE
Note: LoRa packet

WARNING: [down] ignoring invalid packet

##### 2015-10-26 13:36:57 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 50.00%, CRC_FAIL: 50.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (18 bytes)
# PUSH_DATA datagrams sent: 1 (234 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 2 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####

    -Brandon

    October 26, 2015 at 5:39 pm #9717
    Andrew Lindsay
    Participant

    Hi Brandon,

    Thanks for the info. I’ll try this again without ACKs and wait for TTN to get their back-end updated as part of their development process.

    Cheers

    Andrew

    November 18, 2015 at 4:12 pm #10050
    Jim Maricondo
    Participant

    I’m having trouble getting my mDot EVB to connect to the public Senet network. How can I troubleshoot this? It was working back in July when I went to the MultiTech/Senet/Semtech workshop but now it doesn’t. Not sure if it is an issue with Senet, or I changed something by accident that broke it, or if the network reception is just too poor in my office.

    I am using the MTDOT_Senet_Demo_23-July project from class, and it just gets an error -4 when it tries to join the network. I have replicated this using AT commands as follows.

    How can I troubleshoot this further?

    at+njm=1
at+fsb=0
at+pn=1
at+ni=0,xxxxxxxxxxxxxxxx
at+nk=0,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
at+txdr=10
at+rxdr=10
at+txp=20
at+join
Join Error - Failed to join network
ERROR

    NI is Senet’s App EUI.
    NK is the App Key given by Senet after registering my mDot’s EUI Device ID.

    at&v
Device ID:..yyy
Frequency Band:..FB_915
Frequency Sub Band:.0
Public Network:..on
Start Up Mode:..COMMAND
Network Address:.00000000
Network ID:.. xxxxxxxxxxxxxxxx
Network ID Passphrase:.
Network Key:.. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Network Key Passphrase:.
Network Session Key:.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Data Session Key:.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00
Network Join Mode:.OTA
Network Join Retries:.2
Join Byte Order:.LSB
Link Check Threshold:.off
Link Check Count:.off
Error Correction:.1 bytes
ACK Retries:..off
Encryption:..on
CRC:...on
Adaptive Data Rate:.off
Command Echo:..on
Verbose Response:.off
Tx Frequency:..0
Tx Data Rate:..SF_10
Tx Power:..20
Tx Wait:..on
Tx Inverted Signal:.off
Rx Frequency:..903700000
Rx Data Rate:..SF_10
Rx Inverted Signal:.on
Rx Output Style:.HEXADECIMAL
Debug Baud Rate:.115200
Serial Baud Rate:.115200
Wake Mode:..INTERVAL
Wake Interval:..10 s
Wake Delay:..100 ms
Wake Timeout:..20 ms
Log Level:..0

OK
    November 18, 2015 at 4:30 pm #10052
    Jason Reiss
    Keymaster

    What frequencies are used by the gateway.

    Try AT+FSB=1 to use only the first 8 channels of US915

    With AT+FSB=0 the mDot will use 64 channels and choose randomly between them.

    The AT+RXDR command is not needed. The lora mac layer will choose the correct datarate depending on AT+TXDR setting and Rx window.

    November 18, 2015 at 4:39 pm #10053
    Jim Maricondo
    Participant

    Thanks.

    Actually in the MTDOT_Senet_Demo project we got they setFrequencySubBand(0) so I assume that is what Senet requires.

    In summary, theoretically this should work, right? Guess I need to try it in other locations to see if it is just a signal issue, right?

    at&f
at+njm=1
at+fsb=0
at+pn=1
at+ni=0,[senet app EUI]
at+nk=0,[device app key from senet]
at+txdr=10
at+txp=20
AT&W
ATZ
AT+JOIN
  • Author
    Posts
Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.