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.
Great news. I spoke with RisingHF, and they have a new version of firmware for the RHF76-052AM. Iâve updated the library and sample app, and it seems to be working 100%. Pointers to the update method is in the readme in the git archive.
2 Likes
After upgrading the firmware, I am receiving a â+JOIN: No band in <x>msâ message that starts at close to 30000ms and counts down before it is allowed to try to connect again. Then it will try 2 times before starting the 30s count down again⌠I am receiving some of the OTAA activation packets in TTN console but the RHF76-052AM never successfully joins the network. I am using all of your code from the github repo btw. Have you seen this?
Yes I have, and I reported it to risinghf. No useful response other than this is the result of the maximum allowable time to try JOINing a network timing out. The part that makes it weird is that I often see it when I first turn on a board, and thus by definition it cannot have spent too much time trying.
I hate to ask, but did you make sure to update the keys in the source code?
Do you have any other nodes (non-risinghf) to test out the gateway?
Are you seeing the JOIN accept messages in the traffic log?
Thanks for your help in this thread!
I agree that it cannot have spent too much time trying because I begin getting this âerrorâ immediately after every 2 failed activation attempts.
Just for a little back story, I downgraded the firmware back to what it was and I am able to connect via OTAA after 2-20 attempts but I also have a decent amount of data loss (50%) sometimes while I also receive nearly 100% at other times. Not sure if this is the node or the gateway because, unfortunately, I donât have another node to test with right now, but have some on order.
Haha, I did update the keys.
With the upgraded firmware, I would see some activation packets received by TTN but the node would never get an acknowledgement and actually connect. With the old firmware, since it is able to try continuously it will connect but I wouldnât say it is consistent or reliable by any means.
Is this experience common with LoRa in general, or just the RisingHF products?
LoRaWan 1.0.1 defines:
The JoinReq message transmit duty-cycle should never exceed 0.1%
(For LoRaWAN 1.1 it might be more complicated: âThe intervals between transmissions of Join-Requests SHALL respect the condition described in chapter 7.â)
A LoRaWAN 1.0 Join Request message is 23 bytes. In SF7 with a 0.1% duty cycle, this means it can only try in the same subband every 61.9 seconds. So, even though the device will already have waited 6 seconds for a Join Accept response (it will have listened in both RX1 and RX2, without receiving anything): 30,000 ms between tries even seems too low to me, assuming joining even starts at SF7.
That said: in an ideal situation it should obviously join near instantly (Join Request sent after powering up, and Join Accept transmitted in RX1, 5 seconds after the Join Request was sent).
Itâs not clear to me:
- Does the device even try to join before seeing the first
+JOIN: No band in <x>msmessage? - Is that first try even received by a gateway? (Even if received by another gateway, TTN Console should show an activation message in the âDataâ tab of the device.)
- Does the gatewayâs âTrafficâ page in TTN Console show a Join Accept downlink? (TTN might be commanding a different gateway to send the Join Accept.)
- Does TTN Console show the device is âactivatedâ? (If TTN responded with a Join Accept, it will show the device as being âactivatedâ, even though it cannot be sure the device even received the message.)
How do you issue the AT commands? Iâm confused about what I have to do to configure the board before using a terminal emulator. My commands are coming in, because the RX light is flashing when I type. But I donât get any output.
(This is because Iâm also having a hard time getting the Seeeduino to reliably communicate to TTN. It sends a couple messages, then stops.)
@brady_aiello Upload this code to the Seeeduino and then you should be able to open the Arduino Studio Serial Monitor and input the AT commands. Also, you may be aware but, the provided LoRa library will take care of calling the AT commands for you.
void setup()
{
Serial1.begin(9600);
SerialUSB.begin(115200);
}
void loop()
{
while(Serial1.available())
{
SerialUSB.write(Serial1.read());
}
while(SerialUSB.available())
{
Serial1.write(SerialUSB.read());
}
}
Thanks for the clarification @arjanvanb. It seems the the node is not actually sending +JOIN requests to the gateway consistently. Once the gateway actually receives the request, it joins rather quickly.
The TTN page shows an activation packet once the gateway actually receives and is able to forward the JOIN packet properly but about 50% of the time the acknowledgment is not received by the node (even though the gateway receives it).
I am not sure where to look in the TTN console to know if it is âActivatedâ. There is a green dot by the Status in the device Overview page and a counter showing the time since the last received packet.
This Seeeduino lora node just seems to be very inconsistent. I have a few additional lora shields/radios on the way that I will try to connect with and see if I have better luck.
Iâve had much better luck with other LoRa node modules, but this is the first modem module Iâve tried.
The reason for the bad packet rate on the old firmware is that itâs trying to use all 72 channels, not just the 8 + 1 used in 915Hybrid.
2 Likes
I got the Seeeduino working perfect every time by adding this line:
lora.setDataRate(DR0, US915HYBRID);
This code calls:
sendCommand("AT+DR=US915HYBRID\r\n");
to tell the module to just use the bottom 8 channels.
@toddkrein is rightâif youâre using a gateway with 8 channels, it canât support full LoRaWAN,which specifies 64 (72 total). It needs to operate in âHybridâ mode. Here is a section from the RHF76-052 AT Command sheet:
As you see, you need to use hybrid mode for hybrid gateways. I wish I had figured this out a long time ago. But hey, now we know!
2 Likes
Glad to see that the data is working. Are you seeing problems with the Join as we have?
No @toddkrein , I havenât had trouble joining, BUT I have only joined with ABP. I havenât tried OTAA yet, but I will soon. Iâve included my code in the âSeeeduino US workingâ post I made.
Hi Todd, I donât see where you are explicitly turning off the non-hybrid channels in code. Could you please explain?
You would only need to explicitly turn them off if you used the âUS915â mode. If you select the âUS915HYBRIDâ it automagically removes the extra channels. You can check it with the AT+CH command.
Cool. Thanks. And it looks like youâre not setting the lower 8 channels at all. Is this also done automagically by just setting it to âUS915HYBRIDâ mode?
So just setting it to US915HYBRID mode doesnât work with the Rising HF gateway, because the gatewayâs default config starts the channels at 903.9 MHz and the Seeeduino hybrid mode starts them at 902.3 MHz. Itâs not quite aligned, which is why I had to set them manually.
Does anyone have a copy of the latest firmware for the RHF76-052AM?