I made three nodes per Charles’ boards and and sketch from another member ENVNODE. Two work fine. The third shows up on my gateway but has never been seen on the application data console. The rfm95w was previously used on TTN as a single channel gateway setup. Could that be my problem? If the radio serial number is the problem is there a work around?
There is no such thing. (At least, it’s not transmitted in the LoRaWAN message, hence unknown to TTN.)
If you’re referring to a DevEUI (globally unique identifier) then you should probably make sure it’s not known to TTN from some earlier tests. But if it were, I’d assume TTN would deny you registering the device with the existing EUI to TTN Console.
Does it show in the Traffic page of the gateway in TTN Console? I’d look at the wiring.
The wiring is right. It transmits at the set interval and shows up on my gateway traffic. The problem is the device address on the gateway traffic does not match the device address entered in the sketch. I’m seeing the relevant temp., pressure, and humidity information on the serial monitor when the node is connected to the pc. If more information is needed to help me figure this out let me know.
You’re right about the wiring; if you see packets then that’s probably okay.
Please make sure you got the terminology right. As you’re referring to a Join Request, I assumed this is an OTAA node. A Join Request uses the DevEUI, not a Device Address (DevAddr, which is calculated from a Join Accept).
If you’re looking in the local gateway log (rather than TTN Console) then I guess you compared with a node that does work, so I guess you know how to decipher the log then. But just to be sure: beware that many details are in reverse order in a LoRaWAN packet. (You could use an online decoder when unsure.)
If you’re seeing a Join Request with the wrong DevEUI in the Gateway Traffic in TTN Console (see No Join Response from TTN for expected screenshots of gateway and application), then the node must be configured wrongly.
This node is using ABP. Also I am viewing the gateway traffic on TTN console, not the local gateway page in a browser. So, the devaddr that is entered in the sketch should be the same as what shows on the gateway traffic page? The devaddr entered in the sketch is 8 bit numeric. The devaddr on the gateway is 8 bit alfa numeric. On the gateway traffic page it says the network is “Experimental Nodes” on my other node traffic it says “The Things Network” Also this non working node says it has 6 brokers. My working nodes report 1 broker. Just throwing this stuff out there that I have noticed that is different so maybe someone can spot something wrong.
Yes.
A DevAddr as generated by TTN should start with 26 or 27 (hexadecimal). (As an aside: these are not a secret; anyone can pick them up from the radio transmission.)
Then you’re erroneously using a DevAddr that starts with 00, 01, 02 or 03, or you entered it in the wrong order. You should use the DevAddr as issued by TTN, and choose the right option: Hex, lsb or msb? (Check the 2 working nodes).
The DevAddr"26021622" is the one issued by TTN and it is in the sketch This is what shows in the gateway traffic " 018D0EF6" The network Session Key and the App Session key are both entered msb.
If you’re sure you’re looking at traffic from your node (and not someone else’s node*) then I’m out of ideas.
*) Is the message length the expected size?
Yes it’s my node for sure. The message is 19 bytes just like the other two weather nodes. I have parts ordered to populate two more boards. Will have to wait and see how that goes. Thanks for the help.
Hehe, easy after all:
You’ve forgotten to prefix the DevAdr with 0x to denote hexadecimal. Now the code thinks 26021622 is just a decimal value, which in hexadecimal happens to be 0x018D0EF6. So, you’ll need to use:
static const u4_t DEVADDR = 0x26021622;
Lessons learned: use the right terminology and show some code…
1 Like
So much to learn! Yes that was it. A measly little 0x. Sure am happy you found that, otherwise there would have been the same problem with the new nodes that are under construction. Now I just need to figure out why the payload fields are empty. Thanks, Jim
…well, hexadecimal values using the characters 0…9, A…F, chances would have been good that another DevAddr would have included at least one non-digit, in which case the compiler would have complained about the value not being decimal.