Sorry, deleted that, it was to establish exactly what you were using, didn’t realize they were different repos.
I tested different versions of LMIC. I think the issue is not in the code and not in the hardware.
I think that is mistaken, unless you’re not within range of a gateway
Yes, I have several, but for the sake of choice, we’ll go with the RAK7246 Developer gateway - Pi based - so it’s easier to see what’s happening and make changes. Costs $99.
Range is a tricky topic as it can be changed just by weather alone.
As I’ve had to move house over summer I don’t have a proper external antenna and I’m in a metropolitan area so I’d expect there to be differences. But I have got ~1km from spots just above the house, a few hundred meters from down the road about 25m below the house and 6km if I go up the nearest big hill.
In the rural area I had a moderate external antenna I could get 5km from a hill top with line of sight and 100m if I was behind the old mill house further down the hill from my office with no line of sight. Both used a Pro Mini device with helical antenna - which is the very worst of antenna’s AFAIK, but I’m not an RF engineer so I’ll let someone else comment.
Longest connection I’ve had with LoRa to LoRa using a mag-mount antenna at the base station and the transmitter having just a short wire antenna with tin foil ground plane (high altitude balloon) was +100km.
So as you can see, it’s complicated.
Overall, despite any paranoia on your part, you can put some considerable trust in the TTNMapper.
Thanks for your distance experience. I have some ideas.
Back to the last abp example sketch, it’s strange that in the code it sends each 60 seconds “hello world”, but in the console I see only one packet queued, like cycle stopped after 1 sending and waiting for response from TTN. I don’t see “EV_TXCOMPLETE” . But with previous library, I saw each 60 seconds new sendings. Is this normal?
No, that’s not normal, it means the LMIC has crashed.
So as I get older the more I doubt myself, so I’ve also checked the OTAA script over lunch as well as the ABP last night and that is working for me as well. Both uplinks and downlinks. I’ve tried it with my RAK7246 & a TTIG.
Right now, I am what you call the previous library
which is the only library I’ve recommended. Specifically, I’m using this branch:
Yes you recommended the only library but different versions, look:
This post → Here the version is 1.5.1 GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives.
Another post → Here the version is 1.5.0+arduino-3 GitHub - matthijskooijman/arduino-lmic at 1.5.0+arduino-3
To avoid confusion, I’ve tested with both versions.
version is 1.5.1 I see EV_TXCOMPLETE
version is 1.5.0+arduino-3 I don’t see EV_TXCOMPLETE
If you said “it means the LMIC has crashed.”, then I switch back to version 1.5.1
Whatever. I’ve retested my bread board setup with the version I last used, which is 1.5.0+arduino3, as there is only so much time I can put in to the forum, and it all worked fine.
Maybe you could look at the TTN community gateways and see if you can contact an owner for help.
Or migrate to the AdaFruit Feather M0 with RFM95.
Or post it to me and I’ll have a look.
433 have no frequency plan and 915 would be illegal.
TTN uses the frequency plan setup in the ABP sketch just fine.
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
Realistically speaking, please either:
- Switch to a feather and use MCCI LMiC with exactly the same setup as MCCI does, current git checkout, extra jumper wire on DIO as documented, etc
or
- Use exactly the same versions on the ATmega328p that Nick is using and then actually debug why your setup is not working.
Randomly jumping around and guessing what messages mean isn’t going to get you anywhere.
Pick a path and get down to the facts.
Useful information for young debuggers:
If you don’t see EV_TXCOMPLETE -> Check DIO1 pin. In my case, RFM95 pin DIO1 lost connection with arduino pin 3.
When I walked outside hoping I will be heard by one public gateway with the node in my backpack, the wires were moving and DIO1 wire was broked inside the insulation. After a careful inspection I discovered this. Changing DIO1 wire resolved the problem with absence of EV_TXCOMPLETE message in the console. Now I can continue debugging with the last version you recommended 1.5.0+arduino3
Thank you for posting this - I know you checked the connections previously, I haven’t been caught out like this in a few years, but after 40 years, I know that I will miss something like this again!
Fingers crossed you get an uplink - you can use your phone to check in real time.
While walking out taday I oserved for the first time frames up.
And from my phone I expanded data field:
But now, the data field is empty, I can’t analyze nothing.
Why data is deleted so fast from TTN? Is good I took a screenshot with my phone.
I tried to decode the payload with an online decoder too see if is hello world message, but no successful. Or data is not correct, or I did something wrong.
But this is another problem. Now I know, from my house it will never work, I’m not in area.
Thanks all for help.
That decoder needs the full LoRaWAN message, as seen on the gateway. That includes about 13 additional bytes for things like some header, the DevAddr and a MIC.
Your application’s Data page in TTN Console sees the application payload. For that, TTN does not know how it’s encoded by your device. But surely 0x48656C6C6F2C20776F726C6421 is Hello, world!
.
(Next step: don’t send text.)
It’s true! I thought I need a decoder, but is a simple hex
Hurray! Champagne all round!
Only on the console page, that’s normal, it’s only a debug facility.
Turn on the Data Storage integration - that will keep all data for up to 7 days:
https://www.thethingsnetwork.org/docs/applications/storage/
And, as there are still some gaps to fill in your knowledge, a quick review of the following would help:
https://www.thethingsnetwork.org/docs/lorawan/
The devices section of: https://www.thethingsnetwork.org/docs/devices/
The gateways section of: https://www.thethingsnetwork.org/docs/gateways/
The network section of: https://www.thethingsnetwork.org/docs/network/
The applications and API sections of: https://www.thethingsnetwork.org/docs/applications/
Thank you