Good afternoon,
My problem solved with bypassing fuse. But I didn’t understand why it happened roughly at the time there was a change for the V2 gateways as you mentioned?
Thanks,
Are you asking if the change of servers somehow managed to influence the fuse in your device?
A possible theory: may-be the join on SF12 combined with the sensor probe just overloaded the fuse when communication on SF7 leaves a little spare energy in a capacitor?
1 Like
Hi all,
I’m also new on this, and was trying with CubeCell AB01, AB02S and wireless stick pro and all same problem: accpet join-request and Forward join-accept message.
I’m using TTN, with Indoor gateway from TTN on 915Mhz.
First I noticed the RSSI was quite low (-120 around) and the baords were beside each other.
After lots of try and error i finally got it working: it was the channel mask!
instead of this:
uint16_t userChannelsMask[6]={ 0x00FF,0x0000,0x0000,0x0000,0x0000,0x0000 };
i used this:
uint16_t userChannelsMask[6]={ 0xFF00,0x0000,0x0000,0x0000,0x0000,0x0000 };
I’m using TTN and configured like this:
- i created the device manually
- generated the device if and app id on TTN (and copied to my firmware)
- joinId and appEUI all zeroes
- Frequency 915 Mhz FS2 (if not FS2 it doesnt work)
- Lorawan v1.0.2, params revision B
And i used the example Lorawan.ino (or Lorawan_OLED)
1st thing is move them apart - as forum search would have revealed to you we recommend min 3m seperation ideally 5-10 with an absorber such a a wall inbetween to bring signals to manageable levels OTHERWISE THEY ARE SHOUTING AT EACH OTHER! with consequent channel bleed over saturation and distortion which often then stops/hinders the join process… what you may be seeing is the figure for one of the adjacent channels where the signal is bleeding to rather than a clean signal on the ‘real’ channel…
Yep! Again per the documentation and per registration process - ’ as used for TTN’! 
Good to hear you got it working - now seperate them for increased reliability - ideally look for RSSI < -40 → -115, pref <-55 → …
1 Like
Actually i was getting -120 when i was using the wrong frequency (915 FS1) and wrong channel mask (0x00FF). Now it is <10dbm
way too high….get separation….
Also seeing this with a Dragino lt-22222-l (latest firmware 1.6, EU_863_870, registered via device repository). I don’t run my own gateway, node was connected and sending data for about 24hours at some point (rssi around -120dB), after that entered this loop. Can this be due to bad signal strength? (am a total noob on lora, is it supposed to send join-requests again if that’s the case? Also, I still see these looping messages, so some transmission is still successful, right?). Finally shut down the node for some time (would that actually make a difference or not?), now it’s operational again.
How can I find out more? Serial connection to node and going in debug mode? Don’t really mind an unreliable connection (only monitoring cistern water level) but interested to learn more.
Hello I have a problem with an end device it starts sending data but after a while it starts looping from “Accept join-request” and “Forward join-accept message”
What could be the issue?
Hello, could someone help tell the solution to this. The lsn50v2 was connecting just fine then all of a sudden it begun goinig in this continuous loop of accept join-request and forward join-accept message.
Do not duplicate post.