New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LoRaWAN] Single channel gateway issue #26
Comments
Ok I think I defeated the beast xD So I used my mDot-868 to check if the problem comes from the gateway or the node. So, I decided to work on ABP mode first to eliminate downlink as a potential error source. So first I observed the same troubles. But quickly I noticed something as mDot output more debug information, and espacially frequency used : frequencies are rolling. I don't know in details LoRaWAN protocol so I think its normal to reduce dutycycle. But with a mono-canal gateway it becomes a problem ... So I configured my mdot to only use 868.1 MHz and bingo, I received almost all packet (sometimes one is lost but I think it's the gateway that is used by another node). So on my Murata ABZ board I used this code :
I don't know if I did the right way (I think some code is not need, advices are welcome :) )but at least it works. Is there any way to get the frequency used for current transmit ? Regards |
Sorry to be so slow. Seems you figured it out.
There is no way to get the next frequency (or the current one). Normally
you have 3 base frequencies in LoRaWAN and the node picks one randomly that
is available (might be restricted due to duty cycling).
The APIs like LoRaWAN.getDataRate() are returning info about the NEXT
transmission, where things might change due to ADR.
In general, I'd recommend actually reading the spec before guessing ...
https://www.lora-alliance.org/resource-hub
…On Wed, Jul 25, 2018 at 4:40 AM, battosai30 ***@***.***> wrote:
Ok I think I defeated the beast xD
So I used my mDot-868 to check if the problem comes from the gateway or
the node. So, I decided to work on ABP mode first to eliminate downlink as
a potential error source.
So first I observed the same troubles. But quickly I noticed something as
mDot output more debug information, and espacially frequency used :
frequencies are rolling. I don't know in details LoRaWAN protocol so I
think its normal to reduce dutycycle. But with a mono-canal gateway it
becomes a problem ... So I configured my mdot to only use 868.1 MHz and
bingo, I received almost all packet (sometimes one is lost but I think it's
the gateway that is used by another node). So on my Murata ABZ board I used
this code :
#include "LoRaWAN.h"
const char *devAddr = "******";
const char *nwkSKey = "******";
const char *appSKey = "******";
void setup( void )
{
Serial.begin(9600);
while(!Serial);
LoRaWAN.begin(EU868);
LoRaWAN.disableChannel(0);
LoRaWAN.disableChannel(1);
LoRaWAN.disableChannel(2);
LoRaWAN.disableChannel(3);
LoRaWAN.addChannel(0, 868100000, 0, 7);
LoRaWAN.enableChannel(0);
LoRaWAN.setAntennaGain(2.0);
LoRaWAN.setDataRate(5);
LoRaWAN.setTxPower(14);
LoRaWAN.joinABP(devAddr, nwkSKey, appSKey);
Serial.println("JOIN( )");
}
void loop( void )
{
if (LoRaWAN.joined() && !LoRaWAN.busy())
{
Serial.print("TRANSMIT( ");
Serial.print("TimeOnAir: ");
Serial.print(LoRaWAN.getTimeOnAir());
Serial.print(", NextTxTime: ");
Serial.print(LoRaWAN.getNextTxTime());
Serial.print(", MaxPayloadSize: ");
Serial.print(LoRaWAN.getMaxPayloadSize());
Serial.print(", DR: ");
Serial.print(LoRaWAN.getDataRate());
Serial.print(", TxPower: ");
Serial.print(LoRaWAN.getTxPower(), 1);
Serial.print("dbm, UpLinkCounter: ");
Serial.print(LoRaWAN.getUpLinkCounter());
Serial.print(", DownLinkCounter: ");
Serial.print(LoRaWAN.getDownLinkCounter());
Serial.println(" )");
LoRaWAN.beginPacket();
LoRaWAN.write(0xef);
LoRaWAN.write(0xbe);
LoRaWAN.write(0xad);
LoRaWAN.write(0xde);
LoRaWAN.endPacket();
}
delay(10000);
}
I don't know if I did the right way (I think some code is not need,
advices are welcome :) )but at least it works.
Is there any way to get the frequency used for current transmit ?
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AG4QfFKS2P3TGejcsOCf6aDSkDqxndOpks5uKEs7gaJpZM4Vcl4g>
.
|
One day is not at all what I would call slow xD you're framework is so reliable and clean, I gained so much time that I would forgive you anything now !
I will take the time to read it well now that I have tested a lot of things and have a clearer view on LoRaWAN. Just one last point : I did not find where I could activate ack request ? |
ACK is enabled/disable per packet ...
endPacket(bool confirm = false);
…On Wed, Jul 25, 2018 at 7:18 AM, battosai30 ***@***.***> wrote:
Sorry to be so slow. Seems you figured it out.
One day is not at all what I would call slow xD
In general, I'd recommend actually reading the spec before guessing ...
https://www.lora-alliance.org/resource-hub
I will take the time to read it well now that I have tested a lot of
things and have a clearer view on LoRaWAN.
Just one last point : I did not find where I could activate ack request ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AG4QfI7ujVFRmpAElAS_8a0ppP0qQ6umks5uKHARgaJpZM4Vcl4g>
.
|
So simple ... And if endPacket(true) is used, I just have to do something like this ?
|
You don't have to check ... But then you don't know whether it succeeded
or not ...
…On Wed, Jul 25, 2018 at 9:46 AM, battosai30 ***@***.***> wrote:
So simple ... And if endPacket(true) is used, I just have to do something
like this ?
while (LoRaWAN.busy())
{
}
if (LoRaWAN.confirmed())
{
debug.println("ACK");
}
else
{
debug.println("NACK");
}
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AG4QfMYKAjC_eJl93REfVybG7SfvhC8Hks5uKJK9gaJpZM4Vcl4g>
.
|
Ok so what could I do in ABP mode to check at least that a gateway is in the range ? At least I would check the link during start up |
Link check does not need to be answered right away. A confirmed
transmission does.
…On Thu, Jul 26, 2018 at 1:33 AM, battosai30 ***@***.***> wrote:
Ok so what could I do in ABP mode to check at least that a gateway is in
the range ? At least I would check the link during start up
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AG4QfOAE9IaJhaEDDBmULGu74ziJ56NZks5uKXDXgaJpZM4Vcl4g>
.
|
Hi,
I tried two single channel gateway and having troubles with both, but no problem on a "real" gateway (Rpi+ic-880).
I tried OTAA and ABP.
OTAA : the node doesn't not seems to receive the JOIN_ACCEPT message. I tried a lot of config, the join resquest is well received (I have to fix DR to 5) the gateway seems to send well the join accept but the node seems to receive nothing.
ABP : it works but only ~1msg/5 succesfully arrived on server :s
As the issue appears on two different gateways (one is esp32 + sx1276 board, the other is a Dragino LG01) I think it's not coming from the gateway firmwares or it's a protocol issue I missed something configuring node and/or gateway.
So if you have any suggestion :)
The text was updated successfully, but these errors were encountered: