Hi.
I own a RAK7204. I am familiar with the concept.
While the unit is not joined, it sends out a protocol by RF which does not include sensor values. My question here is, what are these bits and bytes?
For example (all hex):
0 ;4 ;72 ;68 ;f8 ;ff ;9 ;1f ;ac ; 74 ;6d ;4 ;fe ;ff ;9 ;1f ;ac ; c ;b9 ;4e ;a6 ;30 ;b3
Block in bold is the EUI of the sensor. Ok so far.
Last 6 bytes at the end I have no clue what is their meaning.
First block is some LoRaWan status bits and bytes and again half of the EUI. Why?
When powering the RAK7204 this message is sent three times. Only
the last block of 6 bytes changes.
I could not find any information on this and I am a very curious person by nature.
bye
Michael.
PS: Received these with a Semtech LoRa Concentrator and the UDP Semtech Packet Forwarder. As said I am curious.
Hello @covenant1969 , welcome to the forum.
The RAK7204 is sending out the Join Request to the LoRaWAN server. You need to register your device in the application of the LoRaWAN server.
Once your application in the LoRaWAN server knows the device, it will answer the Join Request with a Join Accept message. Only after that the RAK7204 can send sensor data.
The bytes in the packet that you see are the DevEUI, the AppEUI and the AppKey of the RAK7204. You can get these information from the device with the AT command at+get_config=lora:status.
We have a Quick Start Guide in our Documentation center that helps you step by step through the process.
Thanks for that.
I made steps forward with this.
Simple question. How can I check with RAK7204 and the help of AT commands if any JOIN ACCEPT meesages have been received? So far my gateway is getting JOIN ACCEPT by UDP (Semtech) but it seems they do not reach RAK7204.
Any kind of debug level AT command would be good.
By Terminal (USB/COM) the RAK7204 just says Join Retry 1-6, then he is going to sleep again. No message like received something, but does not work out…
Or an AT command like “I got this, but it failed…” would be great.
bye
Michael.
The device will return a JOIN success or JOIN error as you can see in the documentation of the at+join command.
Or you can use the at+get_config=lora:status command which will tell you if the device has joined or not:
It does not report JOIN SUCCESS or JOIN ERROR. Just that I can see him trying. 7204 is sending out 6 JOIN REQUEST with 1s intervall. Then going to sleep.
I am using PicoGW_packet_forwarder. There I can see the RXPK JOIN REQUEST. I am also transmitting as PULL RESP JOIN ACCEPT Message as an answer to PULL DATA. But nothing of this seems to reach the 7204.
{“rxpk”:[{“tmst”:549013169,“chan”:0,“rfch”:1,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9.2,“rssi”:-38,“size”:23,“data”:“AARyaPj/CR+sdG0E/v8JH6xW9DPAtzw=”}]}
{“txpk”:{“imme”:true,“tmst”:558013169,“datr”:“SF7BW125”,“codr”:“4/5”,“freq”:868.100000,“ipol”:true,“rfch”:0,“powe”:15,“ncrc”:true,“modu”:“LORA”,“fdev”:0,“size”:32,“data”:“IFfapyadMNfVk9ruqKN372jTC6L0BSpg71FWhNEuISI=”}}
That was my question. If at least something or anything would reach the 7204 by Radio, then it should at least say either success or error? Correct?
Bye
Michael.
Hello,
solved the issues so far.
Everything is about timing (1/2/5/6s after Request) and frequency selection when sending the Join Accept.
For readers. Above txpk (join accept) is anyway wrong. Join Accept messages are either 17 or 33 bytes long. So do not use that as an example.
Unfortunately I played around with my 7204 a lot. That one is now sending Join requests in second intervalls and all the time. That also blocks the COM/USB Console totally. Is there a hardware factory reset method using the jumpers?
Bye
Michael.