The gateway sends BeaconFreqReq requests

When I use Class A, I send a message to the gateway. The gateway sends a BeaconFreqReq request.

Device Debugging Information:

SRV_MAC_BEACON_FREQ_REQ
MOTE_MAC_BEACON_FREQ_ANS

Is your device correctly configured in the console? You didn’t accidentally check the class B checkbox?

1 Like
  • Is that the option you’re talking about? Is that the option you’re talking about? If I didn’t choose it, there’s also a BeaconFreqReq request.

1667902072552

Those to options should not be selected if your node is class A

In fact, I canceled both CLASS B and CLASS C, but it’s still BeaconFreqReq request from the console. I found the record of August, but there was no such request.I don’t know if it’s this, but I feel like my End-Device is not working properly.

This is the configuration in my console. I’m canceling CLASS B and CLASS C, and in fact, the node will receive SRV_MAC_BEACON_FREQ_REQ when it sends.

image

b5449329b33dbc296406504b4959e57

image

What is the setup on your node? Class A, B or C?

Class A

Did you force the node to rejoin (OTAA) or reset LoRaWAN session (ABP)? (For the latter, delete the node and newly adding is the easiest solution)

1 Like

I use OTAA to join the gateway.

Power the node down and then wait 15 sec, then switch it back on.

Do you then get the same messages?

After the device is powered off, add the device to the gateway again. The device will still receive the device after uplink.

image

e2b78e1d8928066c1b9ed5c33a5297d

Depends on the node some devices e.g. the Tabs/Browan devices have supercaps to even out the battery hit from any TX so you either have to wait for many minutes/hours for discharge depending on Tx rate, or discharge with 75-120ohm resistor! :wink:

Dont believe the OP has yet told us anything about the device or its firmware so all guess work right now! :wink:

Once you’ve mastered scrolling up & down source code at speed, you’ll be able to automagically spot these things.

It’s LoRaMac-node and it’s the last case statement in ProcessMacCommands - I’d be tempted to suggest that some re-arrangement of the brackets has occurred and it is being tripped by mistake.

True but that is a challenge with the posting of images vs formatted </> code! :wink: Even a statement to say ‘its LoRaMAC-node’ (version?) would help point volunteers in right direction unless - like some who have read in detail and swallowed whole & applied near photo memory! :wink: - know well and in detail.

Power down means if you have supercaps, they have to be full discharged for 15sec plus, otherwise the device is not powered down.

You have X-ray vision :joy: :joy: :joy:

Which you may not know if you havent taken the node apart…which some of us might do :blush: :grin: Tell a ‘user’ to power down and they will take it that you mean pull the power cord, remove usb power, pull batteries etc…or even just switch off using i/O button/switch (many may not realise that these days even that may be electronic switch vs physical power disconnect, with system internals remaining potentially powered…) Classic helpline, ‘have you tried powering off and on again’! :rofl:

Given the firmware, it’s likely to be a bit more bespoke.

But once it has its power cycled, it will definitely connect via OTABP to the gateway …

Yes, this is the statement in ProcessMacCommand. All I did was add a printed message.

Even if I lose power for a few minutes, I need to re-use OTAA to join the gateway. The effect is the same. I’m not an expert on this, but I saw from LoRaWAN 1.0.3 that this statement belongs to Class B and is sent by the gateway to the node. So I’m confused.