I have a setup consisting of a Dragino LoRa HAT on a Raspberry PI 3b+, and two Arudino MKR WAN 1300 devices. After installing and running the dual_chan_pkt_fwd software, the gateway was successfully registered and connected to TTN. Sending messages from the Arduinos are the problem. Running the example scripts for the MKR WAN devices, with the data rate set to 5(SF7), allowed me to send data to TTN through the Dragino HAT. This is a single channel Gateway. So the messages were all sent on SF7. However, the data passed through the hat is often corrupted. My devices are the only LoRa devices in the area, and there is no obstructions between the devices. Even sending âHelloâ to TTN returned strange values in the payload. However, it would work in irregular intervals.
After looking deeper into the issue, I tried communicating on the simple LoRa network, without any LoRaWAN stuff, just using the arduino-LoRa library on SF7 and BW125. I noticed that the Arduinos could chat easily between each other. But they struggled to communicate with the Dragino device. This is the output of RPI receiving data from the arduino. The sent message is âhelloâ plus a counter. Capture|405x229
This made me conclude that the issue lies with the Dragino LoRa hat or the RPi. However, I am unsure how to fix this issue. All devices are communicating at 868.1MHz at SF7. Has anyone experienced anything similar to this and would be able to offer advice?
Please message me privately or contribute to the topic if you can offer any input.
your questions are not TTN related, I suggest to ask this at a dragino forum. did you search this board, there seems to be always problems with Dragino hats
make sure your gateway receiving frequency is the same as your node Tx frequency.
If you didnât changed the code from your nodes they transmit on 8 frequencies while your âgatewayâ listens on a single one, that means your missing a lot of packets.
If your node is to close to your gateway its possible to receive some âhalfâ packets from another channel, so always keep min 10 meters in between.
Hi.
This board does give a lot of problems. But it seemed to work for some people. Would setting the SPI frequency set the tx frequency? I did set the Spreading Factor. But I understand what you mean with the hopping. I think that might be the problem.
Thank you. Would you know how to switch off the frequency hopping on the MKRWAN 1300 by any chance? I am able to set the frequency to 868Mhz when I start LoRa service using LoRa.begin(868E6)
no, you cannot. How far is the node from the gateway? Because since I see at least two consecutive messages in your log, which in theory are on two different frequencies, likely you are too close.
And do a restart, sometimes the gateway software has issues.
What makes you say that? Frequency/Channel selection is definitely controllable; this is not a fixed-function device, itâs a microcontroller running an Arduino sketch. Further even a proper fixed-function node has its channel list controllable via MAC commands.
In terms of the issue listed here, itâs nearly as likely to be a software coherency bug like a race condition or reading the contents of a buffer that is not actually valid, as it is an actual radio problem.
This test likely does not give any insight into the original problem involving different software.
Of course everything based on software can be reprogrammed to do something that was not foreseen initially, however the MKR WAN library at present does not allow to disable frequency hopping (on 3 channels by the way). I suspect this is related to the fact that is a LoRaWAN certified device, to ensure standard compliance. Of course you can modify the library code, but is not like messing with LMIC directly inside the Arduino IDEâŚ
(EDIT: I started with LoRaWAN in the very same situation: 2 MKR WAN + 1 Dragino LoRa Hat on RPi, for a single channel gateway. Still using MKR WAN, no more single channel ).
Since there it iterates over 3 channels. Can I send the same message across all three channels?
This sounds like a dirty work around. But it might be the easiest solution for now. The devices are close to each other, in the same room. So I will move them today. Just have to setup a static IP on the RPi before I move it to control it on a different WiFi network.
I just moved the gateway away from my node. But now my node is sending messages to gateways that are a little further away.
I am also able to see the different transmission frequencies that the node is transmitting on. So it seems that the issue is indeed the frequency hopping of the Arduino node. Is this a firmware fix?
I wouldnât mind trying to fix this problem on a firmware level. But I have no idea where to start, and would appreciate some guidance.
Your node is always sending messages to all gateways within radio reach. That is as intended and nothing to worry about. If there are full gateways within reach of your node I would just shutdown the 1 channel âgatewayâ and use the traffic as forwarded by those gateways in stead of changing the firmware to something that is not LoRaWAN compliant (just like the 1 channel âgatewaysâ are non compliant).
if it is not too far now, messages should be received also by your gateway (the node does not send to something, it just sends around). So check on your gateway if the packets are received correctly now that is not too close, to verify if still there is the corruption problem.
Frequency hopping is not a problem: it is a mandatory feature according to standards, and the MKR WAN is LoRaWAN certified. Solutions:
You may look for the Murata firmware code (is available on github), understand what should be changed, find the right IDE, understand how to upload firmware on the chip, et voilĂ .
Or you may spend 20 euros for a non-certified board based on LMIC (e.g.Lora32u4 or similar) and make it function in a non-standard compliant way just by calling a function.
Or, finally, if you do not want to buy a gateway, you may just exploit surrounding gateways, since this is one of the beauties of TTN.
This is the output of the receiving script on the RPI. It is an screenshot from the 
).