I noticed that I’m using the wrong frequency.
I change 902 Mhz to 868.1 Mhz. but now I have errors.
Rpi 3b is gateway, rpi 3a is node.
How i can debug the flags?
Trace back through the code generating the messages.
Print out what is actually read from the chip, compare it to the data sheet
Consult with the author of the raspberry pi port you are using.
Hi @SzymonJk ,
Have you solved the issue? I have almost identical issue. It actually end with this data:
sudo ./thethingsnetwork-send-v1
FAILURE
radio.c:664
Best regards
This may well indicate and SPI wiring issue.
The mention of FSK mode in the earlier posting also suggest misconfiguration, while LoRa chips do support FSK modes, TTN doesn’t generally utilize such.
@cslorabox thanks for answer.
I think I found an issue, maybe not exactly for thethingsnetwork-send-v1 but for other code which didn’t worked for me. I have set reset PIN to 0 and now it at least starts.
The last issue I have the code I am testing https://github.com/computenodes/dragino always waits for connecting to LoRa gateway which is next to it and other board connects without any issue. I am now wondering if LoRa protocol or smth hasn’t changed.
I managed to get mine to work, but not the correct way… I have left it in the to hard basket for now as getting it to work by implementing the correct frequency plan the ‘correct way’ was my stumbling block. Are you planning on using it as a node or as a single channel gateway?
@ccall48 I was looking to try both. I have another board - node from pi supply (RAK811) and I want to exchange some test messages between both boards.
RAK2245 works well on a pi for a no frills TTN gateway, just connect an external antenna if you want decent field range from your nodes.
I haven’t tried the RAK811, but it seems like there is some support for it on GitHub, looks inexpensive enough to have a play with if you have got the time.
I played with that same dragino pihat for weeks to get it to work on au915, but it involved crude hacks to the lmic frequency codes which is no recommended/frowned upon.
@ccall48 could you share those hacks. I would need it for EU 868.1 freq and as this is my only one second board I need to to try to exchange some messages between them… Already lost almost a week with no luck.
It should work with the EU868 by default, I had to change out the code to make it work with AU915.
Do you have a community gateway in range you can check to see if the device is sending data?
Yes, actually because I wasn’t able to make it run. I build my own gateway.
The issue now is that the other pi supply node conncets to the gateway with no issues, whereas dragino is not connecting at all.
I tried to run the above (I have added the link) python code and it stucks on ‘waiting’, doesn’t seem to be connecting with the gateway or/and TTN.
Would you mind to test and run the code?
Thanks,
Radoslaw
1 Like
Start at the top of this thread. It might help point you in the right direction, as your device should work on EU868 without hardly any changes to the default coding.
Nothing has changed.
But also, there’s really no such specific thing as “connecting” in this context.
You can complete an OTAA join-accept loop.
You can send an ordinary packet (either after OTAA or simply ABP setup) and have it received and decoded.
But there is no literal specific meaning of being connected.
If one node is taking longer to get started but eventually does, that often points to illicit re-use of the join nonce (if it’s the join accept that is taking a while) or illicit rollback of the frame counter, as within a given set of credentials from ABP or assigned by OTAA, any decrease in the frame counter is viewed as an attempted attack by someone who recorded old packets and is trying to play them back. Packets won’t be decoded until the frame counter reaches a larger value than previously used, or until you reset that on the server.
@cslorabox just re tested everything and I have checked the gateway traffic and there is nothing. No join. No messages.
This python code when is ‘waiting’ is checking if device address was assigned, but it is always 0 (make sense as it didn’t correctly joined).
So my assumption is that either code is wrong or device is not able to see the gateway next to it…
Mode ← STDBY
Mode ← TX
Waiting
2019-12-28 - Dragino - 155 - DEBUG - TX Complete
Mode ← STDBY
Mode ← RXCONT
Waiting
Waiting
Waiting
Waiting
…
Just waits there nothing happens.
1 Like
Start by moving the node at least 10 feet from the gateway. If a node is sitting too close to a gateway its transmissions are much too strong to be received correctly.
@kersing unfortunately this did not help.
I went through thethingsnetwork-send-v1 source code and the above python code.
Error with thethingsnetwork-send-v1 is that dragino returns version 0, whereas with python code the issue is that is waiting (as mention in above post). I have tried to check if something could be wrong with the code but it just looks correct.
Any other tips you might have to fix it?
Thanks
There definitely needs to be “gateway traffic” - if the network isn’t hearing the node attempt to join, no join accept will be generated.
You need to figure out why the node isn’t being received when another apparently is.
Perhaps it is transmitting on the wrong frequencies, or perhaps the hardware has become damaged.
So my assumption is that either code is wrong or device is not able to see the gateway next to it…
Mode ← STDBY
Mode ← TX
Waiting
2019-12-28 - Dragino - 155 - DEBUG - TX Complete
Mode ← STDBY
Mode ← RXCONT
Waiting
Waiting
Waiting
Waiting
…
Just waits there nothing happens.
Blockquote
Same issue for me…
LoRaWan nodes primarily transmit, and rarely receive anything.
First you need to check and make sure that the node transmission was received. Being too close to the gateway is known to cause mixups.
Additionally, there’s very little evidence that there presently exists any software which can make a bare-radio pi-based node actually work correctly. Few node applications would be compatible with using a pi, so it’s not really a configuration that gets much work from people able to debug such a thing and get it to work correctly.
The switchover to TTN v3 makes correct handling of downlinks absolutely mandatory for all nodes - as a result, it’s likely the death of various “not quite complete” node softwares.