RAK811 at 3'd-party module (PiSupply Micro:Bit LoRa Node)

I bought such module (https://learn.pi-supply.com/make/getting-started-with-the-microbit-lora-node/). The module works fine with default settings (maybe), but here, in Russia, we should to use RU868 Frequency Plan - slightly same than EU868 Band but with different channels defining. For this reason my LoRaGateway (RAK7243) doesn’t see this node - at TTN console “newer seen” status always appears.

At first, I had soldered the UART connection directly to RAK module and saw the correct answers at RAK_SERIAL_PORT_TOOL console:
at+version
OK2.0.3.0

2d, at console window I entered next set of commands:
at+set_config=ch_list:0,on,868900000,0,5
at+set_config=ch_list:1,on,869100000,0,5
at+set_config=ch_list:2,on,864100000,0,5
at+set_config=ch_list:3,on,864300000,0,5
at+set_config=ch_list:4,on,864500000,0,5
at+set_config=ch_list:5,on,864700000,0,5

After that the response form module for command ‘at+get_config=ch_list’ is:
OK0,on,868900000,0,5;1,on,869100000,0,5;2,on,864100000,0,5;3,on,864300000,0,5;4,on,864500000,0,5;5,on,864700000,0,5;6,off;7,off;8,off;9,off;10,off;11,off;12,off;13,off;14,off;15,off

i.e. the RU868 Frequency Plan was correctly defined.

3d, all other registers look like normal:
at+band
OKEU868
at+get_config=ch_mask
OK0,003f
at+mode
OK0
at+abp_info
OK0,<dev_addr>,<nwks_key>,<apps_key> (checked with TTN console many times, bit-per-bit, exactly correct)

Anyway, “never seen” at TTN console.

Do you have any ideas?

Hi @b_calabasov
Did you try OTAA?

Hi,
The current PiSupply’s BSP release for MakeCode doesn’t support OTAA join method. Only the ABP method is supported now for this device.

Hi @b_calabasov,

I’m sorry, but the current firmware is based on LoRaWAN 1.0.2, and there is no RU region in this specification by defualt. I don’t know whether it is useful to modify based on EU868.
I think maybe you can add RU region to the source code of RAK811. The RAK811’s firmware you are using is fully open source, so you can customize it freely.

Hi Fomi,
Were the root of problem can be? The RU868 band is placed inside EU868 - RU band is smaller than EU. I just change frequency plan for some present channels, nothing else.

Why ‘at+join=abp’ returns ‘OK’ instead error if node isn’t joined? (‘never seen’ at console).

BR,

Hi Fomi,
I faced with very strange situation. TTN ignore ‘unconfirmed’ messages.
If I use
at+send=0,1,016700d202650080
nothing happens. I mean, no any information appear at TTN console.
But in case if I use response request in sending message,
at+send=1,1,016700d202650080
TTN shows device info console


But in the RAK_SERIAL_PORT_TOOL in response message the event code is 6 = STATUS_RX2_TIMEOUT
TTN4

FW is 2.0.3.4

Hi, @b_calabasov
I think that the RAK811 module never receive data from TTN console.I mean you maybe use ABP mode joined TTN console and send data.Receive windows of The RAK811 mismatching with GateWay about frequency.You could try this AT command modify the RX2 frequency to default frequency 869100000 and default datarate DR0 for RU864 region:at+set_config=rx2:0:869100000

1 Like

Dear all,
Today I’ve found the root of my problem: RAK811 module ignores the ‘ch_list’ settings for joining procedure.

Let see the screenshots.
My device has the dev_eui 0007D3175E3ED295. As you can see, I setup only two channels for connections - 868,1 & 869,1 - the same with my BS settings
RAK811-1
But OTAA process always finishes with event ‘6’ - “STATUS_RX2_TIMEOUT”

At the same time I launched another one LoRa server (EU868, stand-alone, not connected to TTN) with console and found that device send JoinRequest through the default EU868 channels

Is anybody knows how to change the JoinFrequencies in this module?

P.S. Yes, OTAA already implemented for PiSupply Micro:bit LoRa Node

Hi @b_calabasov,

The join frequencies are determined by the LoRa Allieance, those are not supposed or allowed to be changed. They are the frequencies of the 3 mandatory channels for the EU868 band. This is why there is no mechanic to change those as this will not be LoRaWAN anymore.

Regards
Vladislav

Hi Vladislav,
Ok, Thanks! Now it’s totally clear about OTAA Join procedure.
But anyway, on the ABP method the “ch_list” setting ignored too.
Very rarely I see at my TTN console some payloads from my node but passed through some neighbor (not mine!) Base Station with wrong frequency plan.
Today, for example


Gateway ID b827ebffff12b0a5 - isn’t mine!

Hi @b_calabasov,
Do you ha e ADR on?

Regards
Vladislav

Hi Vladislav,
What do you mean?

Today I’ve set up second PacketForwarder - with EU868 plan. Instead of “ch_list” settings, RAK811 always use default EU868 frequencies in ABP mode too - through 2-d gateway.

Hi @b_calabasov,

I mean is Adaptive Data Rate turned on?

Regards

Hi,
Yes, ADR is ON.
BR