mDot with public networks
- This topic has 9 replies, 4 voices, and was last updated 8 years, 10 months ago by Jim Maricondo.
-
AuthorPosts
-
October 24, 2015 at 5:11 am #9696Andrew LindsayParticipant
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 #9698Jason ReissKeymasterAndrew,
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 #9703Andrew LindsayParticipantJason,
“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 #9704Jason ReissKeymasterCan 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=dataOctober 25, 2015 at 10:40 am #9709Andrew LindsayParticipantFor 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 #9710Brandon BayerBlockedAndrew,
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 #9717Andrew LindsayParticipantHi 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 #10050Jim MaricondoParticipantI’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 #10052Jason ReissKeymasterWhat 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 #10053Jim MaricondoParticipantThanks.
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
- This reply was modified 8 years, 10 months ago by Jim Maricondo.
- This reply was modified 8 years, 10 months ago by Jim Maricondo.
- This reply was modified 8 years, 10 months ago by Jim Maricondo.
- This reply was modified 8 years, 10 months ago by Jim Maricondo.
- This reply was modified 8 years, 10 months ago by Jim Maricondo.
-
AuthorPosts
- You must be logged in to reply to this topic.