Microchip SAMR34 Joining Denied

(Joystick) #1

HI,

I’m bringing up SAM R34 Xplained Pro Evaluation Kit board to TTN.
I’m using Atmel Studio 7 as explained in https://www.thethingsnetwork.org/labs/story/connecting-the-microchip-atsamr34-xplained-pro-kit-with-lorawan-to-the-things-network

DevEUI read from board, AppEUI and AppKey are put in place into conf_app.h
App builds and uploads to the board without any errors but on terminal I have:

Join Parameters

DevEUI : 0x000425191801d6d6

AppEUI : 0x70b3d57ed001744f

AppKey : 0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Join Request Sent for EU868

Joining Denied

  1. Send Join Request
  2. Send Data
  3. Sleep
  4. Main Menu

Enter your choice:

I’m in Amsterdam Noord, very close to couple of TTN gateways.

I tried several projects and changing DATARATE and managed to get device “seen” on TTN console but no join.

Please advise what troubleshooting techniques are available.

Thank you,
Alex

UPDATE:

  • Created a new device in TTN Application
  • Generated DevEUI
  • Disabled EDBG_READ_EUI in Atmel Studio project
  • Put all 3 params into demo projects
  • Tested 2 demo projects (from workshop and vanilla one)
  • On TTN console I can see “last seen 3 sec ago” after join attempt
  • No join actually happening

I also installed Gemtek MiniHub gateway, it is online on TTN and works great, showing hundreds transmitted tx/rx messages.

Will try to escalate to Microchip Team.

Best wishes,
Alex

(Afremont) #2

As a first guess, you may have the endianness wrong. I think this is fairly common. You did add your application and device, right?

Edit: deveui and appeui have to be in lsb order. Appkey is in msb order.

(Mrpackethead) #3

I have been experiencing the same issue… See my TTN device window and the details that the R34 Xplained is trying to use…

Capture

This is defination that is in conf_app.h

/* OTAA Join Parameters */

#define DEMO_APPLICATION_EUI { 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x01, 0x6F, 0x90 }
#define DEMO_APPLICATION_KEY { 0xE8, 0x70, 0xFE, 0x5F, 0x99, 0x31, 0x3B, 0x36, 0xE8, 0xC5, 0xEF, 0x1C, 0x57, 0x4A, 0x87, 0x61 }

The device ID is defined by the Debugger, so i’m sure that its right? Are you suggesting that my EUI might be in the wrong order
I

(Afremont) #4

Yes, I believe your appeui is reversed. If you click on the <> and then click on the next button (arrows) until it says lsb, you will see how it should be defined.

(Mrpackethead) #5

In the instructions here, it does say specifically to use MSB.

https://www.thethingsnetwork.org/labs/story/connecting-the-microchip-atsamr34-xplained-pro-kit-with-lorawan-to-the-things-network_

Capture

(Joystick) #6

Hello guys, thank you fo joining,

Yes, endiannes is MSB and correct.
And i made myself such board working during workshop.

What I’m thinking of is:

If this board (DevEUI) was already registered on TTN with another user would it join or not into my application?

Thanks again,
Alex

(Mrpackethead) #7

Did you use the same software you are using today.

(Joystick) #8

Yes, same atmel studio, same project as workshop. Just another board.

Then I started new project as per manual to get better feeling of how things work.

What’s the proper way to debug join failures?

Thank you,
Alex

(Afremont) #9

Perhaps it is only Arduino with LMIC that requires the lsb order.

(Joystick) #10

Maybe you probably know if there are tools like wireshark available for Atmel boards / LoRa ?

I should be most probably able to read SPI data exchange between MCU and SX?

Thank you,
Alex

(Afremont) #11

I’m not sure I understand, but if you’re asking for a way to accomplish what you describe, here is an inexpensive way to do that:

(Joystick) #12

Thanks - looks interesting.

I was actually hoping three are some software tools which can help debut the join issue.
Anyway, I just set up a Gemtek gateway at home and will try SAM R34 again.

Then another gateway.
Thanks again for help.

Best regards,
Alex

(Afremont) #13

It’s an inexpensive way to find out what is really being transferred over SPI. I’m sure the Sigrok/Pulseview folks would be quite appreciative of someone writing a protocol decoder for LoRa comms between the processor and radio module that can be “stacked” on top of the SPI decoder. Pulseview is a truly incredible tool.

(Mrpackethead) #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.

(Mrpackethead) #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.

(Mrpackethead) #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

(Afremont) #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?

(Mrpackethead) #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.

(Afremont) #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:

(Mrpackethead) #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…