Well, I was following the EFM32 implementation from Dramco, but the RTC did not work for me, since my device is EFM32PG, @nestorayuso helped me (which is on other post), it seemed to work for the ABP but not for OTAA.
I have attached my updated version (this is for EFM32PG series 1 with RTCC - 32bit).
For the LoRa initialization and OTAA, I was also following Dramco again - in the file deep_sleep_app.c, it uses the code for setting up RX2, (nothing that I thought may help for OTAA). Am just learning as it comes, My apologies again
For RX2, some observations:
assigning {869525000, DR_3} : OTAA does not break. And for several restarts of the node, the JoinRequest and JoinAccept cycle used randomly 868100000, 868300000, 868500000 - this is just to try out if OTAA breaks or not. I haven’t checked for subsequent downlinks yet, which will be my next steps, sending some data to the node.
And with no assigning, let it be as default. OTAA works and then the JR and JA cycles randomly used 868500000, 868100000, 868300000
And the time stamps for JR sent and JA recceived show 4 seconds of time difference for several restarts. The node uses the RX1.
Just a thought, when will node use RX2? How many retries the node will make in OTAA mode, if the join request not successful in the first try?
I also observe a similar behaviour when iam using LoRaMac Node with SAML21 + SX1276
My observations -
1.Continuous join accept request on the TTN Network Gateway .No data is being send
2. After debugging i see in the function OnTxNextPacketTimerEvent()
if( mibReq.Param.NetworkActivation == ACTIVATION_TYPE_NONE ) stands true and a continuous join can be seen in the TTN application and gateway
3.It seems though the join is accepted by the gateway somehow the end device is not able to recognize it
Any hint on what went wrong…
Iam newbie i have recently started exploring the code .Please bear with my silly qa
I believe your GW does send ACK to your node, but the node is not able to receive since the RTC is not working as expected. You may need to calibrate. I believe it is the wake-up time of the micro which need to be taken into account, EFM32 micros have wakeup time in terms of uSec
You may try this: by commenting out the code line TimerLowPowerHandler() in Main.c or RtcEnterLowPowerStopMode() in the Timer.c so as not to let the node go to sleep, so that the node responds in the receive window time slots, just to test if the node works (meaning join the network and send data).
