Is this enough to prove that my modules are not fried?
LoRa Sender
Sending packet: 0
Sending packet: 1
Sending packet: 2
LoRa Receiver
Received packet 'hello 0' with RSSI -46
Received packet 'hello 1' with RSSI -51
Received packet 'hello 2' with RSSI -51
Received packet 'hello 3' with RSSI -51What is the conclusion? Without having your own gateway, it’s almost impossible to start with LoRaWan. Living in a big city, public gateways around you will not help.
Don’t suggest to buy one or to DIY one. Look at the prices, it’s madness. For “hello world” it doesn’t worth it.
I don’t need proof!
So, if YOU are happy the modules are OK, can you do an ABP uplink please and look at the TTN console.
If nothing appears, then you need to get nearer a gateway.
Based on the efforts you put into this thread I assume that your intentions include more than only creating a Hello World application.
I understand your frustration for not getting things to work, but having access to a gateway (e.g. your own gateway) can really help in the debugging process.
I would agree 100%, given the sheer volume of effort put into this (on your own part too) you really need a basic end to end setup to help diagnose and work on solutions - your working blind without being 110% you have a gateway very close - all this diagnosis is pointless if you can’t reach a gateway, although again your device logs looks clean now at least
Working on lorawan/TTN devices I would suggest yes you should have a gateway setup, they are not expensive either
“Without having your own gateway, it’s almost impossible to start with LoRaWan.” - if your a serious device/code developer this makes no sense sorry, otherwise you have to hope someone else pays for a gateway near you.
We know you have a scope, so you must be working in electronics at some level. It’s all about investment in your future - the $100 invested in a basic Pi based gateway could turn in to €20,000 extra income when you apply for your next job …
I work with what I have at the moment. When I bought my modules, I have been informed about ability to work with public gateways and Huge lorawan range compared to wifi and bluetooth. I’ve crossed this city so many times that I’m sure I have been in the range. Take a look at ttnmapper over Paris. Do you think this information is all fake? Even if positioning on the map is not 100% accurate, I’ve been all the city around, it’s impossible to not catch 868mhz here. I don’t believe lorawan is like bluetooth when you need to be in the house with the device near you.
You are absolutely correct.
Except you have made a device from parts and whilst the LoRa to LoRa works, if we could see what the gateway says it has received, we may have the Eureka! moment that enables us to get you going.
This is a very common problem when people make devices themselves and it is usually something very small that is stopping things from working.
Yes, a scope and a logic analyzer is a good investment. It will help me in any electronics project. But lorawan gw will only serve me some days and if I will decide that lorawan is not for me, I will sell my gw on Ebay if I’m lucky. You will not believe but I don’t have internet connection in my house. I use 4g in my phone. Another problem is to share my 4g , using a 4g router (that I don’t have) and interconnect it with the gateway. Internet connection problem is easy as 123 for me. Maybe I will buy one gateway if I will find one second hand cheaper, not because I’m poor but because it doesn’t worth, like I said earlier, for the first test.
While being in range is certainly the issue, and knowing for a fact that you are in range of a gateway that is actually active would be hugely helpful, it’s not actually the main reason this was brought up.
Rather, you’re stuck looking in the application data view of TTN, and if you see nothing, we have no way of knowing if your node didn’t transmit, or if it transmitted something which didn’t decode as a valid LoRaWAN message from your device.
In contrast, when you own/control the gateway, you can see the raw messages it picks up, and examine those yourself and say “oh, I see an attempt here, but it’s not quite right because…” and then try to address what you have seen is wrong with the packet. And for downlink, you can not only see that the gateway transmitted, if necessary you can put one scope probe on the gateway’s transmit LED and the other on the node and actually see if the receive window lined up with the downlink’s transmission.
When I bought my modules, I have been informed about ability to work with public gateways and Huge lorawan range compared to wifi and bluetooth.
These things are somewhat aspirational. If your node is known to work correctly and if there is a maintained gateway in range, then indeed, you don’t need your own. But both of those can practically speaking be big “if’s”.
And while you bought your first setup based only on published guidance, you bought your second ATmega328p solution even after warnings here that it was not a sound choice. Could Nick get it to work after a fashion? Yes. Will you? Unknown, but add using unsupported hardware to not having a gateway and you have two very large challenges added to what is already even in the ideal case a challenging system.
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?