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:
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.
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.
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.
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.
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.
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?
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.
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.
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…