But by nobody here - you first posted after you’d purchased the wrong Arduino and we’ve done our best.
It’s not clear what your motivation is here so it’s very hard to see where we go next. If trying out LoRaWAN is just for curiosity, then I think we’re done, because we really need you to have access to gateway logs.
I bought them and I don’t feel like I lost something because it’s really cheap and I can reuse them for other things, but learned a lot. Someone here said why to buy a Ferrari if you just want to test one ride. Unsupported hardware worked well for other guys. Imagine now how you will feel when you buy super featured board and then you see in the console no JointAccept and you can’t explain why because you need to add extra fees for new gateway to see logs. Strange.
We can solve any problem. The main problem is in understanding. We don’t know if no JoinAccept is generated when the node is unreachable or low memory or wrong pin mapping or bytes order etc etc The beginners like me will see how difficult it’s debugging first node when you don’t have a own gateway. This is a lesson to learn.
I’m surrounded by gateways with full access to their logs and test equipment and I do this for a living… and even with all of those things in my favor, it’s still hard.
So yes, take unsupported hardware, no access to raw gateway view or even certainty that one is in range, and on top of that user unfamiliarity, and it’s going to be worse.
If you want to solve this, find out what actual bytes the node transmitted, decode those with the online LoRaWAN decoder and see if they’re right.
For receive, as we discussed earlier, use the logic analyzer to see if it’s actually trying at the right time.
I bought them and I don’t feel like I lost something because it’s really cheap and I can reuse them for other things, but learned a lot. Someone here said why to buy a Ferrari if you just want to test one ride. Unsupported hardware worked well for other guys. Imagine now how you will feel when you buy super featured board and then you see in the console no JointAccept and you can’t explain why because you need to add extra fees for new gateway to see logs. Strange.
We can solve any problem. The main problem is in understanding. We don’t know if no JoinAccept is generated when the node is unreachable or low memory or wrong pin mapping or bytes order etc etc I would like to see something simpler The beginners like me will see how difficult it’s debugging first node when you don’t have a own gateway. This is a lesson to learn.
I don’t know how to do that without my own gateway or a spectrum analyzer.
I used a logic analyzer. Connected it to SPI to see communication between arduino and rfm. I set up sending packet each 10 seconds for testing and I did saw each 10 seconds some activity. I could not decode what commands are passing between. Need to learn deeper this type of communication
Print out a hexdump of the raw packet bytes
You want to look only at a single cycle of transmit and receive, and as explained in the post recommending this, look for the specific pieces of SPI bus and DIO activity happening at the right times. Even if you don’t decode the SPI you need to see activity happening in the right place.
Given you’re not reverse engineering something, you could also just blip another GPIO at key times in sequence of the attempt, which was actually the first part of that recommendation from earlier…
FWIW, having somewhat lost the will to live, I got the breadboard mashup that’s pictured above out of its draw and created a new ABP sketch and it’s sending away nicely and received a downlink. Using https://github.com/matthijskooijman/arduino-lmic/tree/1.5.0+arduino-3
I’ll try an OTAA sketch in the morning.
This is another version. This one is
name=LMIC-Arduino
version=1.5.0+arduino-3
author=IBM
I have tested earlier with this version
name=IBM LMIC framework
version=1.5.1
author=IBM
Now I tested at the window with version=1.5.0+arduino-3 - nothing for me.
Starting
RXMODE_RSSI
457: engineUpdate, opmode=0x808
1505: TXMODE, freq=867500000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
67967: RXMODE_SINGLE, freq=867500000, SF=7, BW=125, CR=4/5, IH=0
I suppose you have your own gateway. Have you tested how many meters from the house your device can reach the gateway?
It would be great if you could be specific about the repository and git hash you are using when you mention these. The “name” in the code is almost meaningless.
Also, debug prints may break timing. So a good strategy is to load up with extra debug output, raw packet dump, etc and make sure the code is doing what it is supposed to be doing; then disable all of that and check the timing with a scope or logic analyzer.
This one. It’s the same maintainer, only versions are different.
https://github.com/matthijskooijman/arduino-lmic
I just compared library.properties and I observed a difference. version=1.5.1 and version=1.5.0+arduino-3 is different. Can you see it? Links to all used libraries are provided in this thread, if you read from beginning. What git hash do you want and for what purpose?
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