I have a problem that gateway received join request and sent join accept, but on the node, nothing happens.
For OTAA, do you need to supply the App Session Key and Network Session Key? I don’t see them in the TTN Console for the device.
Nevermind, I got it. App EUI and App Key for OTAA.
This can’t possibly work. Where are you passing your AppEUI?
Using latest 2.1.15 firmware (that I knew of from this thread), my sketch is not working anymore. Especially that triggers an error when setting channels:
+MODE: LWOTAA
+DR: EU868
+DR: DR5
+DR: EU868 DR5 SF7 BW125K
+ADR: ON
+CH: 0,868100000,DR0:DR5
+CH: 1,868300000,DR0:DR5
+CH: 2,868500000,DR0:DR5
+CH: 3,867100000,DR0:DR5
+CH: 4,867300000,DR0:DR5
+CH: 5,867500000,DR0:DR5
+CH: 6,867700000,DR0:DR5
+RXWIN1: ERROR(-1)
+RXWIN2: 869500000,DR3
+POWER: 14
>>> SETUP DONE
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
>>> JOIN ERROR
+JOIN: No band in 115215ms
Here is the code I use to connect:
lora.setDeciveMode(LWOTAA);
lora.setDataRate(DR5, EU868);
lora.setAdaptiveDataRate(true);
lora.setChannel(0, 868.1);
lora.setChannel(1, 868.3);
lora.setChannel(2, 868.5);
lora.setChannel(3, 867.1);
lora.setChannel(4, 867.3);
lora.setChannel(5, 867.5);
lora.setChannel(6, 867.7);
lora.setReceiceWindowFirst(1);
lora.setReceiceWindowSecond(869.5, DR3);
Any idea how to fix that?
Thanks for your help.
Hi, I would remove the Adaptive Data Rate line, because we already set a preferred data rate. I would also set the first Receive window with the specific frequency and data rate, like this:
lora.setReceiceWindowFirst(0, 868.1);
The method signature is this:
void LoRaWanClass::setReceiceWindowFirst(unsigned char channel, float frequency)
For me, I have OTAA working, with US frequencies, but a join at the moment takes about 3-4 attempts. ABP is much faster, but it’s discouraged for security concerns and the inability to reassign addresses and network keys and app keys on the fly.
Feel free to reference my work here. I’ve included frequencies and data rates for all countries TTN is available in.
I hope this helps.
Hello all,
For your information, latest firmware version, 2.1.16 dated from 2017-12-03, is available from Seeed github repo
Hello,
I had the same issue on the Seeeduino LoRaWAN board with firmware 2.1.15, OTAA and a raspberry pi gateway.
I solved it by setting the timeout parameter of the setOTAAJoin function:
lora.setOTAAJoin(JOIN,60).
Hope this could help!
In the other hand, I tried to upgrade the firmware to 2.1.16 with minicom (i’m on linux mint 18.3), using ymodem, but every time the board tells me: firmware upgrade failed! I’ve followed the procedure: plug usb then press DFU and wait in minicom for the “CCCC” characters.
Did anyone managed to upgrade to 2.1.16 using minicom?
I have upgraded the firmware with minicom. That part worked for me. But this version seems to have the AU channel plan completely screwed up.
Has anybody got this thing to work on AU915? I have never been able to get this thing to join.
OMFG, I hate this POS board.
I’ve made the mistake of coming back to work on it again, after a many-month layoff, and nothing is working. The boards seem to randomly reset, even a new one out of the box. When I use transferPacket, I get the initial “+MSG: Start”, and nothing else. Until it resets itself. I’ve tried typing in the command by hand, and get the same result. It’s running 2.1.15. I’m running Arduino 1.8.1.
I thought maybe that TTN had changed something, and went to load the latest firmware (2.1.18), but I can’t get the board to go into upgrade mode. I get nada.
To check my sanity, we’re supposed to use:
#include <Arduino.h>
void setup()
{
//Serial1.begin(9600);
SerialDBG.begin(115200);
SerialUSB.begin(115200);
}
void loop()
{
while(SerialDBG.available())
{
SerialUSB.write(SerialDBG.read());
}
while(SerialUSB.available())
{
SerialDBG.write(SerialUSB.read());
}
}
right?
I’ve tried this on three different boards, so it’s not a HW issue…
OK, figured out the Software update problem - We use “putty” at work, and it doesn’t play well with “extraputty”. Argh… there’s five hours of my life I won’t get back…
… But it does look like 2.1.18 fixes whatever the problem was.
1 Like
This timeout parameter works on my Node 
TY jturello
Anyone trying to get these modules working with the AU915 band and OTAA must update to firmware version V2.1.19 (25 May 2018) This can be downloaded from RisingHF’s wiki page once you have a login.
If you don’t upgrade, you will be able to send a join request to a gateway, the gateway will acknowledge with a join accept, but the RHF76-052 will never receive the join accept and fail. ABP will work if you never need to use the downlink.
There was a AU915 downlink issue fixed in V2.1.17 and also a DR6 issue fixed in V2.1.19.
As we use sub-band 2 in Australia, simply delete channels that are not used with AT+CH=‘Channel to Del’, 0.
In most cases this is 0 to 7, 16 to 64, 66 to 71. It should then work first go!
1 Like
Could you post the firmware file somewhere for people without RisingHF wiki login?
Is there a changelog from 2.1.16 to this one?
Thanks!
Hi !
Is it possible to share the firmware release 2.1.19 or later I am stuck with 2.1.15 and having issues in joining to network, Thanks in advance
1 Like
This code I customized and I am sharing works perfectly for me.
I’m using version 2.1.16
I use the default libraries of seeeduino.
#include <TheThingsNetwork.h>
#include <LoRaWan.h>
#include “DHT.h”
#define DHTPIN 8
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);
unsigned char data[4];
char buffer[256];
void setup(void)
{
dht.begin();
SerialUSB.begin(115200);
while(!SerialUSB);
lora.init();
memset(buffer, 0, 256);
lora.getVersion(buffer, 256, 1);
SerialUSB.print(buffer);
memset(buffer, 0, 256);
lora.getId(buffer, 256, 1);
SerialUSB.print(buffer);
lora.setId("XXXXXXXX", "XXXXXXXXXXX","XXXXXXXXXXX" );
lora.setKey(NULL, NULL, "XXXXXXXXXXXXXXXXXXXXXXXXXXXX");
lora.setDeciveMode(LWOTAA);
lora.setDataRate(DR5, EU868);
lora.setAdaptiveDataRate(true);
lora.setChannel(0, 868.1);
lora.setChannel(1, 868.3);
lora.setChannel(2, 868.5);
lora.setChannel(3, 867.1);
lora.setChannel(4, 867.3);
lora.setChannel(5, 867.5);
lora.setChannel(6, 867.7);
lora.setReceiceWindowFirst(1, 868.3);
lora.setReceiceWindowSecond(869.525, DR0);
lora.setPower(14);
while(!lora.setOTAAJoin(JOIN));
}
void loop(void)
{
bool result = false;
delay(2000);
SerialUSB.println("-- LOOP");
uint32_t humidity = dht.readHumidity(false) * 100;
// float t = dht.readTemperature(false);
uint32_t temperature = dht.readTemperature(false) * 100;
byte payload[4];
payload[0] = highByte(temperature);
payload[1] = lowByte(temperature);
payload[2] = highByte(humidity);
payload[3] = lowByte(humidity);
SerialUSB.print("Temperatura: ");
SerialUSB.println(temperature);
SerialUSB.print("Umidade: ");
SerialUSB.println(humidity);
// SerialUSB.print("Temperatura: " + String(temperature));
// SerialUSB.print("Umidade: " + String(humidity));
//byte payload[4];
//data[0] = highByte(t);
//data[0] = lowByte(t);
//data[2] = highByte(h);
// data[1] = lowByte(h);
// data[1] = h;
// data[2] = t;
result = lora.transferPacket(payload, 4, 10);
//result = lora.transferPacket("Marcelo Balisteri!", 10);
if(result)
{
short length;
short rssi;
memset(buffer, 0, 256);
length = lora.receivePacket(buffer, 256, &rssi);
if(length)
{
SerialUSB.print("Length is: ");
SerialUSB.println(length);
SerialUSB.print("RSSI is: ");
SerialUSB.println(rssi);
SerialUSB.print("Data is: ");
for(unsigned char i = 0; i < length; i ++)
{
SerialUSB.print("0x");
SerialUSB.print(buffer[i], HEX);
SerialUSB.print(" ");
}
SerialUSB.println();
}
}
delay(5000);
}
This is the TTN decoder Temp and Hum
// Decodificação do payload no tttn
function Decoder(bytes, port) {
var humidity = (bytes[0]<< 8) | bytes[1];
var temperature = (bytes[2] <<8) | bytes[3];
return {
humidity: Umidade,
temperature: Temperatura
}
}
Hi, have you managed to solve the problem of unsuccessful update the firmware? I also encountered the same problem. I followed the steps in Seeeduino wiki and firmware version 2.1.19.
I’m in Malaysia, asia region with frequency band AS920-923. My current firmware version is 2.0.10. On my first attempt, using extraputty to connect to the seeeduino lorawan board w/gps, the small window of the transferring file via Ymodem -> send have no progress as the packet# shown 0/58. After that, the small window disappeared and I assumed failed then proceed to the next attempt. But now the small window cannot read the file of the firmware with error file not found.
Hope get some insight to solve the problem. Anyone is welcome.
2 Likes
Hi, I have another question. I referred to the sample code, Seeeduino_LoRaWAN_for_hybrid_gateways provided by @brady_aiello. I get the following output in Arduino serial monitor:
+RESET: OK
+ID: DevAddr, XX:XX:XX:XX (My DevAddr from AT+ID in serial monitor)
+ID: DevEui, XX:XX:XX:XX:XX:XX:XX:XX (My DevEui from AT+ID in serial monitor)
+ID: AppEui, XX:XX:XX:XX:XX:XX:XX:XX (From the console of ttn)
+ID: DevEui, XX:XX:XX:XX:XX:XX:XX:XX (My DevEui from AT+ID in serial monitor)
+ID: AppEui, XX:XX:XX:XX:+KEY: APPKEY XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
//Both AppEui and AppKey are from the console of ttn
+MODE: LWOTAA
+DR: US915HYBRID
+DR: DR0
+DR: US915HYBRID DR0 SF10 BW125K
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+CH: ERROR(-2)
+RXWIN1: 0,923200000
+RXWIN2: 923300000,DR8
+LW: DC, OFF, 0
+LW: ERROR(-2)
+POWER: 10
+JOIN: Start
+JOIN: NORMAL
+JOIN: LoRaWAN modem is busy
+JOIN: Join failed
+JOIN: Done
+MSGHEX: Please join network first
+JOIN: Start
+JOIN: NORMAL
+MSGHEX: LoRaWAN modem is busy
+JOIN: Join failed
+JOIN: Done
I found that the are setting the DevEui and AppEui 2 times according to the output. (I wonder why?) But it not able to set the DevAddr to the one generated from the console of ttn, is set according to the one get from AT command, AT+ID. Therefore, the are different DevAddr between the console of ttn and the AT+ID command from the serial monitor. I’m not able to change the DevAddr from the console.
There are also error in setting the 8 channels for AS1 region. Also, the join is failed.
Any idea?
Hello,
I had some problems with both OTAA and ABP with this module(firmware 2.1.15). So I decided to upgrade the firmware to version 2.1.19. But after the upgrade the modlule is locked in DFU mode, and I cannot return it to normal mode. Did anyone have this issue and solved is?
Thanks for all replies.