I have based my tests on the rather poorly documented OTAA example which does not work. I have also contacted RisingHF to see if I can get some proper documentation.
A copy of the AT command set can be found here
1 Like
OK so I have managed to get OTAA kind of working. I say kind of because its random when it works and fails. This leads me to believe there is a timing related issue somewhere … the trick is to figure out where!!
Is OTAA generally something reliable or does it typically require several retries to succeed ?
Thanks,
Serge
For those interested this is what seems to be working for me
#include <LoRaWan.h>
char buffer[256];
void setup(void)
{
SerialUSB.begin(115200);
while(!SerialUSB);
lora.init();
lora.setKey(NULL, NULL, ".......8204A501331D6........");
lora.setDeciveMode(LWOTAA);
lora.setDataRate(DR0, 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);
lora.setPower(20);
while(!lora.setOTAAJoin(JOIN));
}
void loop(void)
{
bool result = false;
result = lora.transferPacket("Hello World!", 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);
}
3 Likes
Dear ssozonoff, I still having some troubles with the ABP connection of my SEEEDuino. In the sketch I replaced the KEYs with those providerd by TTN and set the Channels to the Australian Frequencies LoRaWan (I am in Australia right now). In the serial monitor it seems to work properly but nothing appears in TTN console. Since you said that in your case the ABP works fine, have you got some suggestions to improve my ABP sketch? Furthermore, did you find a guide (or something that describe the commands) for the LoRaWAN SEEEDstudio library?
Thank you very much
Gianluca
Hi,
It sounds like you have done everything correctly. I would double check the App Key and EUI’s.
Are you using your own Lorawan GW/Packet Forwarder? If so what do the logs say.
Further up in the thread I posted a link to the manual with the AT Commands. This information combined with looking at the source files of the Lorawan library for the Seeeduino (LoRaWAN.cpp) should give you a better idea of the commands available and the ones being used. This is as much information as I have been able to find so far.
I would double check the App Key and EUI’s.
Or, if one has access to the gateway’s log (like simply in the gateway’s “traffic” page in TTN Console) then even when the keys are wrong, one should see packets coming in. (One will even see non-TTN traffic there.) In the same “traffic” page one can also see outgoing Join Accept messages if the keys were accepted.
I have been doing some low power measuring and for the moment the best result I have so far is 1.25MmA draw. According to the Seeed guys it should be possible to do better than this. I have already removed to power LED and the only thing I am unsure of is if the GPS is also being put into stand-by mode. I have contacted them about this.
I looked at the schema and it does seem that there is a pin from the MCU connected to a Standby pin of the GPS module… Will have to experiment some more.
A month ago I succeeded to get the GPS version of this LoRaWAN module running (ABP) on TTN.
But not without a lot of dufficulties.
One was that the API has got a new version and was not available on Internet, fortunately some one from RHF.
In that way I discovered that one important library routine in the Seeeduino library was missing and I had to add this myself (I informed Seeeduino about that).
This is about setting the public network key.
void LoRaWanClass::setPubNetwKey(int PubNetwKey)
{
char cmd[64];
if(PubNetwKey)
{
if (PubNetwKey == 1) {
sendCommand("AT+LW=NET, ON\r\n");
} else {
sendCommand("AT+LW=NET, OFF\r\n");
}
#if _DEBUG_SERIAL_
loraDebugPrint(DEFAULT_DEBUGTIME);
#endif
delay(DEFAULT_TIMEWAIT);
}
}
OK so with several peripherals connected I2C etc… I am now at a sleep current of 200uA. Its not yet 90uA but I imagine that it coud be achievable. For my application 200uA sleep current is enough so will not be spending more time on this.
1 Like
So I haven’t managed to get this board working in either OTAA or ABP mode. Not sure whether the problem is with my gateway or the board. In OTAA it just says join failed, and then in ABP it says the message length is incorrect. I’ve entered all of the my application and device paramters using lora.setKey() and lora.setId()
I was thinking about going through and rewriting the library to see if I can get it to work that way. It’s fairly simple (just sending and receiving serial commands to the RHF76 module).
I’m a little confused about jvn’s post. I can see that the function he added sends this string "AT+LW=NET, ON\r\n", yet I don’t see that command anywhere in the datasheet for the module. Is this a command that only works in some secret updated firmware version of the RHF76?
I have not had any problems and have not needed to add any code or anything. Both OTAA and ABP mode work fine.
Okay thanks, maybe it’s my gateway. I added the new multi protocol forwarder to it recently.
To ZaneL, If someone knows how how to attach a file I could send you the latest version (3.1) of the PS01509 LoRaWAN AT Command Specification.
@jvn That would be helpful! I think you can just click the “Upload” button after you click reply and upload the file?
So my problem is that I’m not really sure what settings I need to use for the United States. For example the header file lists these possible settings…
******************************************************************
Type DataRate Configuration BitRate| TxPower Configuration
US915 0 SF10/125 kHz 980 | 0 30dBm
1 SF9 /125 kHz 1760 | 1 28dBm
2 SF8 /125 kHz 3125 | 2 26dBm
3 SF7 /125 kHz 5470 | 3 24dBm
4 SF8 /500 kHz 12500 | 4 22dBm
5:7 RFU | 5 20dBm
8 SF12/500 kHz 980 | 6 18dBm
9 SF11/500 kHz 1760 | 7 16dBm
10 SF10/500 kHz 3900 | 8 14dBm
11 SF9 /500 kHz 7000 | 9 12dBm
12 SF8 /500 kHz 12500 | 10 10dBm
13 SF7 /500 kHz 21900 | 11:15 RFU
14:15 RFU |
*******************************************************************
So in my code I did the following, based on the settings from here:
lora.setChannel(0, 903.9);
lora.setChannel(1, 904.1);
lora.setChannel(2, 904.3);
lora.setChannel(3, 904.5);
lora.setChannel(4, 904.7);
lora.setChannel(5, 904.9);
lora.setChannel(6, 905.3);
There are also these settings and I’m not sure which to choose.
lora.setDataRate(DR0, US915);
lora.setAdaptiveDataRate(true);
lora.setReceiceWindowFirst(1);
lora.setReceiceWindowSecond(905.6, DR0);
lora.setPower(20)
Specifically I don’t know what data rate to choose, and which frequency and data rate to choose for the second rx window. All of the info I can find only specifies these settings for the EU region.
Zane, I’ve got my RHF76-052 working OK. Not great, and not nearly as good as my ST Micro board, but I may be able to help you out a little. The first thing I did was a factory reset on the device, and then when I set the data rates to US915, all of the RXWIN1, DR, and CH entries were correct.
For each run, do the software (not factory) reset, and set the data rate to DRO, US915.
Turn on ADR.
Set the mode to LWOTAA
Next, you turn on the RXWIN1
RXWIN2 should be 923.3, DR8. (See section 2.2.7 of the LoRaWAN spec)
Power should be set to 14.
After that, I was able to connect to TTN, but it generally takes 15 - 25 join attempts before it actually works.
If you want to PM me, I can send you my updated LoRa libraries and the Arduino sketch.
OK, I was nudged to try and learn Git. You can see my code here:
The folks from RisingHF pointed out that we’re running a 915Hybrid rather than a true 915, and so we need to turn off the non-hybrid streams. Do that with the AT+CH=<X>,0 where X is the channel number. Should go from 8 to 71.
I’ve updated my git repository with a bunch of the fixes.
At this point, I get 100% of the messages, but the Join still takes a long time.