Hello, i have rpi 3a+ and have a problem to configure a node.
I use this instruction:
Use LoRa GPS HAT and RPi 3 as LoRa End Device
http://wiki.dragino.com/index.php?title=Connect_to_TTN
What is wrong?
Ctrl-Z is suspend, use Ctrl-C to kill something. Suspending an instance may have left it in the background fighting the new one for ownership of the radio.
You need to debug the flags issue; and figure out why FSK was involved at all.
The LMiC stack which you seem to be using some variation of will not stage new data for sending if it still has a send / receive cycle in progress; youâll need to understand what is going on overall.
Note that a piâs full multitasking OS makes it a somewhat awkward choice for an end-device; people do it, but youâll probably need to open the receive window a bit early to account for less reliable timing; fortunately the pi burns enough power that leaving the radio receiving longer than usual shouldnât be noticed.
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.