RAK4260 Node EU868 Downlink reliability

Is anyone testing the 4260 module on the EU868 band? I’m really struggling with downlink reliability issues, especially in CNF confirmed mode. Uplink seems fine, but downlink data frequently but randomly fails. I did have an RSSI issue due to the software not turning on power to the RF switch, but despite fixing this the problem remains. Anyone else seen this?

I’m thinking that this is timing problem… With one GW I receive the Join Accepts and Downlinks very well. With other, with other Network Server I cannot receive anything (therefore the GW receive the uplink and send the answer). I’m currently trying to find some way to test the timing precision of the SW Timer of LoRaWAN stack…

2 Likes

FYI I’m using a RAK4427 concentrator with RPi3 running RAK’s pkt forwarder to TTN server.

@fishbeetle @RicSToz, For your information, I’m on AU915 and using a RAK2245 + RasPiZero as a gateway with a modified legacy (UDP) packet forwarder to TTN server running SPI at 2MHz instead of 8MHz. Not seeing this issue at all. Strange!

Is it possible the 2247 spi should also be run at a reduced rate? Hard to see why this would only affect downlink packets.

1 Like

The RAK2245 has level shifters as it can connect at 3.3V or 1.8Volt. They have a frequency limit requiring the 2245 to run SPI at 2MHz. I see no reason to reduce the SPI speed on a 2247.
I raised this to provide more information. If it turns out to be a timing issue, then this may help identify which part of the timing is causing the issue.

1 Like

Hello All!
In the last days I watch that the node was not understanding the LinkADRReq commands from Network Server too(the LinkADRAns indicates that the channel mask is OK, Power is OK but the Data Rate NOK). Tired of this, I take my SAMR34 Xplained board and test with the Microchip Example Code…Success. Thinking this, I simply take this code, modified the RF_SWITCH and TXCO pins and burned with Atmel ICE in the RAK… Success… the node is now understandying the ADR command correctly and is accepting the first Join Accept message. Now, the only problem is that the uplink signal seems to be more poor. Should I be forgetting something?

Right in the bull’s-eye!
PA13 should be forced to “false”

Hello my friends!

Other issue solved… the downlink problem is caused by the incorrect level on BAND_SEL (PA13). This pin is responsible to select the correct I/O of RF_SWITCH (RFI or PA_BOOST). I think that now is solved… let’s see!

Good work Ricardo, I’m away on vacation at the moment so can’t try to emulate your success. Can you please be more specific on exactly what’s needed to fix the downlink issue?
Thanks again.

Hi @RicSToz, did you find your solution solve the problem?

Could you help me understand how this works as my investigation shows something slightly different.

RF Switch – SAMR34 connections
1 - Vdd to RF Switch is supplied from PA28
2 - The following table is the switching logic levels (obtained from the RF Switch data sheet) with RAK connections added
3- SAMR34 connections V1 (BandSel) is PA13 on RAK4260 and V2 is TxRx

J1 – Tx, PA Boost Optional high-power PA output, all frequency bands – V1 = 0, V2 = 1
J3 – Tx, RFO-HF RF output for band 1 – V1 = 1, V2 = 1
J2 – Rx, RFI-HF RF input for band 1 – V1 = 1, V2 = 0

I also checked the RAK4260 and the Microchip Xplainer board use the same inputs on the RF switch so the software logic should be the same. Therefore I would expect the same result on the Xplainer Board and the RAK4260. I am interested in your findings as you clearly saw a different result.

RF Switch control pins
1 - BandSelect – PA13 on both the Xplainer board and the RAK4260
2 - TxRx – same dedicated pin on SAMR34 used on the Xplainer board and RAK4260
3 - Vdd on the Xplainer board this was fed from Vddana which is always on, on the RAK4260 is fed from PA28

Since the only difference between the Xplainer Board and the RAK4260 is the Vdd, I had assumed the primary cause is likely to the control of the Vdd and therefore the software controlling pin PA28

I did not find this happening on 915MHz as I think the power being supplied to V2 on the RF Switch which is used to connect J1 (PA Boost) to the antenna is able to leak inside the RF Switch and provide phantom power to Vdd

I am very interested in your findings, hope you can help me understand.

1 Like

Hello @Tony_Smith

My main finding is that the BAND_SEL line have to be correctly switched according the following table:

image
V2 is the dedicated pin TXRX of SAMR34. V1 is BAND_SEL (PA13 in the case of RAK4260). In the code that I was editing the BAND_SEL pin was incorrectly sourced. This cause that in downlink proccess, the RFI circuit was not used, causing poor downlink sensibility. After this modification, I was able to receive data normally.

Hope this help you

Hi @Richardo,

I can see we agree on the state of V1 when the SAMR34 is receiving. You table shows V1 should be a 1 when the SAMR34 is receiving (RFC to J2) RFI-HF.

In you post

I can see you are suggesting V1 which is controlled by PA13 should be a Zero.

I am a little confused, should it be True or False?

Also, did you solve a receiver problem when testing on 915MHz or on 868MHz?

Regards, Tony

Yes, a little bit of confusion caused by “real-time posting” and “emotion works”. I was forcing false to make uplinks … then I see that the RSSI dowlink was bad and I realized that PA13 should be switched according to transmission or reception and not just false.

1 Like

Great to hear you got it working.

Hi Ricardo,
Do you have any idea what the difference is between the RAK software example and the Microchip software example codes that results in the improved handling of the LinkADR Req & Ans process?

Hi @fishbeetle
I think that the RAK code was modified and not fully tested. I found some errors in the switching of SKY RF Switch that impact directly in the downlink capabilities. Now, my device is working fine with good Uplink and Downlink RSSi levels and virtually zero packet loss.

FYI My down-link reliability issues now seem to have largely melted away with constant tweeking and chipping away at contributing factors. I’ve documented my progress here: http://www.marvellconsultants.com/LoRaNode/ I hope others will find it useful.

1 Like