Microchip SAMR34 Joining Denied

End Devices (Nodes) SAMR34
14

I have raised a case with Microchip about this, and this is what they said. I’ve also got a project from someone else which was based on an earlier code base.

I’ve unforutnatly not been within easy range of a gateway so, its made progress slow, but am goign to do some more work on this today, and all things being equal my RAK831 will arrive tommorrow.

Can you please confirm if your network server and gateway are same node or different nodes? Also can you confirm if you saw JOIN request at Gateway or Network Server? This would help in understanding the issue better. Normally the JOIN request is transparent to the gateway and it should just relay it to the Network Server.

The JOIN Request carries a MIC (Message Integrity Check) which is calculated using the APP Key. If the Network Server does not have the same APP Key, MIC check on Network Server will fail and it will send a Join Failure. To debug this further, we would need to know MIC check passed or failed on Network Server. Please advise if it is possible to get these logs.

If MIC check passed on Network Server, then it should send a Join response with success. If MIC check failed, then it should send a Join response with failure. Can you check if Network Server is generating the response?

If it is generating the response, then we would need to review the RX1 and RX2 settings at the device side to ensure they match the network expectations.

Hope that helps. Please let us know once you have this information.

15

I have been looking at the code trying to see if there is anything more useful to be obtained than the “joining denied” message.

16

so, i had an interesting time today; Im in New Zealand and we use AU-915Mhz. I was unable to get the SAM R34 to connect via a RAK831 gateway![gw|690x305] . The gateway is known to be good and works with other devices. Interesting on AU-915 the device just wouldn’t connect. There was no join message on the gateway either.

I tryed connecting via differnet bands, ( with the gateway still set to 915 ) as i know it will ‘receive’ other bands, and the SAMR34 transits a join request when its configured to EU-868. The join gets all the way back to the TTN application and is accepted, but the gateway trys to connect to the device on the 915 band. ( which it should do )…

My suspicion is that there is a problem with the Microchip supplied code for the AU-915Mhz band… And i’ll raise this with microchip now.

This of course does not explain the OP’s question, as he is in Europe.

gw

17

That’s weird. I have a rak831 gateway, and while it’s possible to configure it to use 868MHz, it has to be configured to do so. It’s not something that it just does. In the us, I have to set a channel mask or select a subband (the second one) to get my nodes transmitting and listening on the right 8 channels of the 72 channel possibilities. Is there anything like that in AU_915? The RAK831 has two “radios” and each one covers four of the channels by configuring a center frequency and three IF offsets from that frequency for each “radio”. I don’t see how it could just receive on an entirely different band unless one radio was configured for 915 and the other for 868. I suppose that could be done, but it wouldn’t work well with most nodes. Is AU_915 your normal home band?

1 Like
18

yes, AU_915 is band we use here in NZ for The things network ( though the commerical networks are using some different bands )

i have no knowledge of how the gateway is configured… However devices that are running 915Mhz have no problem connecting to it… ANd it seems to listen to 868

My own gateway arrives tommorrow, so hopefully i’ll get a bit more insight.

19

I did some looking and AU is very much like US in that there are 8 subbands of (8+1) channels. Most gateways, like RAK831, can only deal with 1 subband. In the US, we use the second subband for TTN. I think I said before, that I have to make sure my nodes (and gateway) are set to use this properly. On my RAK wisnode, I have to use a channel mask to mask out the frequencies (channels) that don’t apply, otherwise it will attempt to use them. On some LMIC stacks (and lopy I believe) you have to call enable_channel() and disable_channel() functions during setup() for each individual channel. I have also seen a function called enable_subband() that makes this easier, since it’s only one function call instead of dozens. Perhaps you are in need of doing something like this. It is also my understanding that Australia (and perhaps New Zealand?) also have two other Asian bands in operation making things even more confusing.

When you receive your RAK831, be sure that the global_conf.json file is correct for your region. You will also, likely, need to find the reset script and set the appropriate gpio pin (Broadcom GPIO7) which is pin 11 in wiringPi (python). Apparently the ic880 boards that folks used to use a lot we’re on a different pin (GPIO 17), so you’ll find examples that might lead you astray.

I suggest trying to get everything working with ABP activation as that is one less problem to fight. ABP will work without needing the gateway to send you a confirmation that may or may not be on a frequency your node expects and may or may not be transmitted during the same window of time your node is listening. :wink:

20

Yes, Spark ( the telco ) has deployed AS-923, and Kotahi net, has used the Indian one. TTN has chosen to use AU-915. All the bands are open and unlinceced, and can all be used. So your pick of what you want to do.

The gateway i’ve been using seems to work with other devices, so its a bit strange what is goign on. Microchip are working on this…

21

Got my gateway yesterday and have set up for AU-915Mhz… I dont’ get a join with it either.

:frowning:

22

But now you have log files to look at. Is anything showing up at ttn console page for your gateway? Secondly, you should see rxpk messages in raspberry pi system log. When the ttn recognizes the join request, you’ll see a txpk message on your pi, even if your node doesn’t see it. Iow, you have more visibility of what might be going wrong. Once you are sending the correct ID and key information, you should see data traffic on the ttn console device page. If it’s an option, I would suggest working towards getting ABP working first.

Edit: make sure you have five or ten feet of distance between the node and the gateway. BTW, you are seeing your gateway as being connected on the ttn page, right? And you should see the “last seen” updating every 30 or 60 seconds, regardless of what you are doing with your node. Be aware that the traffic view in the ttn console is browser cached, meaning you only see what happens when that page is already open in your browser. Once you hit refresh to reload the page, it’s all cleared out. Switching between gateway and application on the console clears the browser cache too. You might want to add an application integration to permanently store some of the data. It’s really easy.

Edit 2:. You want a data storage integration.

23

So, i did a bit more looking at this… using the AU_global_conf.json file on the RAK831 resulted in nothing being seen by the gateway. ( trying to join using the SAMR34 using 915 or 868 )

I swapped to the EU_global_conf.json file, and when i try to join using 868 I get some activity in theTTN console.

Capture

joining on AU915 doe’snt craete any join attempts.

The gateway is some 10meters away, and yes the gateway is being seen…

I have been looking at the syslogs as well. When configured for AU-915, i dont’ see anything being received… Using the EU-868 Config i see this; ( as well as in teh console )

pi@ttn-gateway:/var/log $ tail -1000 syslog | grep pk
Feb  5 12:07:43 ttn-gateway ttn-gateway[539]: INFO: Received pkt from mote: D0016F90 (fcnt=46037)
Feb  5 12:07:43 ttn-gateway ttn-gateway[539]: JSON up: {"rxpk":[{"tmst":170199772,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":9.2,"rssi":-103,"size":23,"data":"AJBvAdB+1bNwMNYBGBklBACNFWC73A0="}]}
Feb  5 12:07:43 ttn-gateway ttn-gateway[539]: JSON down: {"txpk":{"imme":false,"tmst":176199772,"freq":923.3,"rfch":0,"powe":20,"modu":"LORA","datr":"SF12BW500","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"IPuvvHfSHYTYjuMt/9qW1dQ="}}
Feb  5 12:11:15 ttn-gateway ttn-gateway[539]: INFO: Received pkt from mote: D0016F90 (fcnt=46037)
Feb  5 12:11:15 ttn-gateway ttn-gateway[539]: JSON up: {"rxpk":[{"tmst":448884852,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":9.0,"rssi":-105,"size":23,"data":"AJBvAdB+1bNwMNYBGBklBAD/b6CJAA4="}]}
Feb  5 12:11:15 ttn-gateway ttn-gateway[539]: JSON down: {"txpk":{"imme":false,"tmst":454884852,"freq":923.3,"rfch":0,"powe":20,"modu":"LORA","datr":"SF12BW500","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"IG0NKWKiFx6/qHr/k2W4DJI="}}

It appears that perhaps somethign else is in play to get the gateway configured to use the EU-868 band. ( I’m just trying to get it working as a starting point )

I’m perplexed as to why it does not see any packets when its set up for AU-915. I’m guessing the problem may lie with the SamR34. This is a very similar behaviour to what i saw on a known working system.

24

Are you changing the region on the node when you also change the global_conf.json file? If not, then that explains a lot about why the gateway doesn’t respond when configured for the AU region. It’s only going to listen to the frequencies specified in the json file. In EU, it’s my understanding that the gateway responds on the same frequency that it received, in other words EU frequencies are bi-directional. In AU and US, there are uplink only frequencies and downlink only frequencies, 8 of each per subband. It sounds like your node may be configured for the EU region, assuming that you aren’t changing it when you switch your json files on the gateway. In US and AU there are also 8 subbands, unlike EU. You have to ensure that your gateway and your node are using the same subband. This is often done by setting a channel mask in the node to stop it from trying to use frequencies that the gateway isn’t listening on. I don’t know anything about your node, does it use AT commands for configuration, or are you compiling and uploading firmware to it?

Edit, I just saw your log messages. Your gateway is transmitting on 9xxMHz because the ttn network told it to. You can’t change that, it’s based on your gateway registration in ttn. You are only going to get this to work by using the correct json file for your region. Your node is apparently configured for EU region, and that is most definitely your problem. ABP would let you get packets to your application, but you will never be able to get confirmation or downlink messages, which is absolutely required to accomplish your OTAA.

25

Yes, of course. I was carefully matching the Device and the gateway. Thanks for the hint about it being TTN sending the instruction on which frequency to transmit on. I reconfigured everythign to be EU-868 ( including the gateway ) and it joined and i was able to send data. Of course i shoud’tn really be using EU-868 here, but for a few minutes its not goign to be a big problem. ( i’m out in the sticks with a very low gain antenna :slight_smile:

Capture
Capture1717×402 44.4 KB

It would seem, that there is a problem somewhere with how the SAMR34 is setup with its AU915, or perhaps the RAK831 is not a good choice for AU915 either.

26

It would appear that when the node is configured for your region, it isn’t setting something correctly. Are there any firmware updates available for it? I think it’s a pretty safe bet that the rak831 is working as it should.

27

Im starting to wonder if the RAK831 is sutiable for use with the AU915 band, since it only covers 8 frequencys.

28

i have had some discussions with microchip today… Out of the box the device is trying to join on channels that the RAK831 is not listening to…

Yes, this is what we were also reviewing. The configuration file shared by you is only enabling 8 channels while our default setting are as per Lorawan specifications (which says 64 channels for 125 KHz and 8 channels for 500 KHz). Device can send a join request randomly on any of the 72 channels.

I will need to check with the software team on how to make the settings for 8 channels on the device. Once I have the update, we will let you know.

29

On the other hand: a device should not join too often (possibly only once in its lifetime), and the procedure to join is well documented. For 1.0.2:

If using the over-the-air activation procedure, the end-device should broadcast the JoinReq message alternatively on a random 125 kHz channel amongst the 64 channels defined using DR0 and a random 500 kHz channel amongst the 8 channels defined using DR6. The end device should change channel for every transmission.

Unfortunately, the AU915 specifications are a bad copy-paste from the US915 documentation (sometimes even still referring to the US tables), but for US915 this explanation is a bit more extended:

For rapid network acquisition in mixed channel plan environments, it is further recommended that the device follow a channel selection sequence (still random) which efficiently probes the groups of nine (8 + 1) channels which are typically implemented by smaller gateways (channel groups 0-7+64, 8-15+65, etc.).

So yes, joining might take some time, but due to using DR0 (best range) chances are good that when a randomly selected channel is indeed supported by the network, the Join Request will be received.

Next, while 1.0.2 does not support a CFList in the OTAA Join Accept yet, the initial ADR will tell the device which channels to use. (In 1.1 TTN will include the network settings in the Join Accept, like it already does for EU868.)

30

Good luck trying to find an affordable gateway that can listen to 72 channels simultaneously. There is an “official” subband for AU that is used by TTN, just like the US. Your problem is not the RAK831, it is with your node. There should be a channel mask implemented in its firmware, then it’s a simple matter to make it work. By default,my Rak Wisnode would do the same thing, but setting a channel mask makes it transmit only on the subband my Rak831 is configured to use.

31

Page 19 of this document clearly explains the subband issue and what to do to set it when you compile the firmware.

http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-R34-MLS-Getting-Started-Guide-User-Guide-DS50002812A.pdf#page=19

  1. Gateways usually support only 8+1 channels and a set of 8+1 channels is called as SUBBAND.

    The NA/AU Regional band has 64+8 channels. Therefore there are eight SUBBAND’s in the case of NA/AU region. The application by default is configured to work in SUBBAND 1.

    Change the SUBBAND value according to the gateway/NS configuration. If the gateway supports 64+8 channels then the SUBBAND definition must be commented.

1 Like
32

This two year old post indicates that, like the US, TTN in Australia uses subband 2. If you define (#define SUBBAND 2) this in the config file and compile the firmware, you should be on your way to a working situation.

https://www.thethingsnetwork.org/forum/t/australian-channels-for-ttn-is-there-a-standard/4056/4

33

Thanks so much for pointing this out to me. I had gone down a rabbit hole by following the guide that is published on TTN, rather than the Microchip doc… It got me mostly working but not entirely working. I’ve modifyed the sub-band, put my gateway back to AU-915, (both changing the global_conf.json and the frequency plan on TTN console ), and now when the device trys to join i see a packet at the gateway and an entry in the traffic page on the ttn console. For some reason TTN is still sending the reply with a EU868 band, even though i’ve set it to use 915.

I tryed deleting the gateway and re-adding it, but it still trys to use 868. there might still be some kind of timeout going on.

EDIT: Yes, it seems if you make a frequency plan change it takes some time for it to update. Was about 10 minutes in my case.

The good news is that now i seem to have a working solution! Thanks so much for your help!