Rhf76-052am - getting it working with OTAA


(Toddkrein) #21

OK, I was nudged to try and learn Git. You can see my code here:


(Toddkrein) #22

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.


(Toddkrein) #23

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.


(Iotatwtamu) #24

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?


(Toddkrein) #25

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?


(Iotatwtamu) #26

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?


(Arjan) #27

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>ms message?
  • 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.)

(Brady Aiello) #28

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.)


(Iotatwtamu) #29

@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());
    }
}

(Iotatwtamu) #30

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.


(Toddkrein) #31

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.


(Brady Aiello) #32

Thanks @iotatwtamu! Got it working perfect!


(Brady Aiello) #33

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!


Seeeduino US working
(Toddkrein) #34

Glad to see that the data is working. Are you seeing problems with the Join as we have?


(Brady Aiello) #35

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.


(Brady Aiello) #36

Hi Todd, I don’t see where you are explicitly turning off the non-hybrid channels in code. Could you please explain?


(Toddkrein) #37

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.


(Brady Aiello) #38

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?


(Brady Aiello) #39

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.


(Andrewgreen) #40

Does anyone have a copy of the latest firmware for the RHF76-052AM?