That would have been under TTN V2, 2021 we migrated to TTS(CE) aka TTN V3 with 'final V2 sunset Dec’21 - much closer to full LoRaWAN complance and hence much more picky and choosey wrt node behaviour, use lates MCCI lib if you can or look at LMIC-Node
Thankyou… but for some reason, i have to stick with arduino 33 ble sense and i guess that’s not supported by lmic node.
So i’m using MCCI LMIC…
Which version/library specifically? (Link to source)
latest version
And do you have access to the TTN Console view of that GW to see what it hears from your node? Or can someone who does have access tell you/grab data? Aso what are you seeing in the node local console output?
If struggling with reception can you take node closer to the GW?
I don’t have access to the gateway console. However, right now i’m very close (on the face) of the gateway!
I have rechecked my pin connection and frequency settings too.
I’m using Lorawan version 1.0.3 and regional version A. is it true for sx1276? Any idea? as i couldn’t find this data on any datasheet and one tutorial on youtube used these settings for sx1276. So i’m following the same…
My serial monitor shows display like this:
21:26:25.624 → 20350149: EV_TXSTART
21:26:25.624 → Packet queued
21:26:27.714 → 20481622: EV_TXCOMPLETE (includes waiting for RX windows)
21:26:57.406 → 22356953: EV_TXSTART
21:26:57.406 → Packet queued
21:26:59.496 → 22488402: EV_TXCOMPLETE (includes waiting for RX windows)
I’m using example ttn-abp and just altered the session keys and the pin map for DIO0 and DIO1.
And have selected sx1276 radio 1
and EU 863 plan… in the config files!
Also as i can see that gateway on Heat map of ttn… I saw that it last heard at around 4:30 pm and i was trying to send data after 5pm. So i think it’s not even listening.
That’s a clue…
Pardon? Are you saying that gateways clock off at the end of the day???
Well… i meann that if it were listening to my data it should have heard something after 5pm too. Not talking about any clocking off…
How on earth would LoRaWAN work if gateways stopped listening?
By using ABP you don’t get any form of feedback as to if you got the keys the right way round etc.
At least with OTAA you can get to a Join Request / Join Accept even if your device doesn’t hear the Join Accept. Then you know you aren’t in range. Or the gateway is selectively deaf. Or playing Bon Jovi really loud and not able to hear very well.
What is the distance between your node and the gateway?
I’m on the same floor… same hallway! should be only few meters… few steps
I’ve tried OTAA just now…
22:28:16.409 → 36676005: EV_TXSTART
22:28:22.782 → 37079192: EV_JOIN_TXCOMPLETE: no JoinAccept
22:31:47.878 → 50021406: EV_TXSTART
22:31:54.279 → 50424611: EV_JOIN_TXCOMPLETE: no JoinAccept
With OTAA it’s working now…
however it’s caught in a loop
accept join request and forward join accept message!
Too close is also a problem but a few walls will sort that. Why not go and ask for collaborator view rights to the gateway so you can see what it is hearing.
This seems to be contradictory - it sends a join request, it hears a join accept, it gets on with sending uplinks.
Perhaps you could clarify what you mean and tell us exactly what you see in the console and on the serial debug.
And please format any serial output using the toolbar.
The console looks like this… However, i’ll again work with it tomorrow and will update!!
Which most of the time means the device isn’t hearing the join accept - either because it has marginal reception (the gateway can hear as it has a good well positioned antenna) or because the device is too close to the gateway (>5m + brick wall as minimum separation).
Having the reported RSSI / SNR from the Join Request would be very useful to clarify.