I tried earlier today to connect a RAK4631 with RUI3 (V3.5.4, same as you) to my US915 Chirpstack server (on a VPN in Germany) and I didn’t have any serious problems, beside of 1 or two failed retries.
It worked with both AT command and API call to join.
Your problem is really strange.
Our R&D team is out on Chinese New Year holidays already, so I will not get any help from them for a week.
Would you be willing to run a test against my US915 server?
I can definitely do that, yes! I have a gateway here that I can set up to point to whatever endpoint you think would work. However, I don’t think we will see different results as I don’t see any messages ever hitting the gateway at all.
@beegee and @carlrowan I think I figured it out. Here’s what happened:
I was doing some further testing this morning. I flashed RUI 3.4.2 to the device using nrfconnect. Here’s the output from AT+VER:
AT+VER=3.4.2-rui3_22q1_update.112
Once the device restarted, I ran the same AT commands, and the device was able to join the network:
Next, I reset the device with ATZ, and asked it to join again. This time, it failed to join with the same error message, +EVT:JOIN_FAILED_TX_TIMEOUT
If I first run ATR to restore factory settings, then ATZ to restart the MCU, then flash 3.4.2-rui3_22q1_update.112 to the device using nrfconnect and then finally run the join sequence AT commands, it will usually join, and be able to join again after powering the device off and then back on.
This was encouraging, so I ran a few additional tests. The first one was to load the default 3.5.3 firmware using nrfconnect. Then, I configured the device to join using the AT commands. The device failed to join. I powered the device off, and then back on, and waited a few minutes before issuing the join command. This time, it worked. Curious. I played around a little with waiting different intervals before issuing the LoRaWAN AT commands to join the network, and found after 30-60 seconds it would work consistently. This is the same amount of time that the BLE radio is on when the device first starts up, as confirmed by using a Bluetooth scanner. I added the following two lines of code to the setup() function of the test sketch:
// turn off BLE UART
api.ble.uart.stop();
// turn off BLE advertising
api.ble.advertise.stop();
With these two lines included in the code, the LoRaWAN join and subsequent message sends work exactly as expected.
It looks like the LoRaWAN radio can’t be used until the Bluetooth is shut off. Is there some kind of software interlock to prevent the two radios from being used at the same time? Or, since the R&D team said that this could be interrupt related, could the BLE radio be driving some interrupts that knock out the LoRaWAN radio?
Hi Nathan,
I am not disabling BLE on my device and don’t have this problem. The BLE and LoRa drivers are independent and there should be no interlock between the two.
The RAK4630 is on a custom PCB? If yes, can you show me the power-supply connections of the RAK4630 module?
On our WisBlock RAK4631 Core module the power supply is like this:
There could be the problem here.
The RAK4630 is internally designed to use VBAT_NRF to generate its own GPIO supply. Therefor VBAT_NRF should be higher than 3.3V. As you can see in the schematic part I posted, we have VBAT_NRF connected to VBAT which is between 3.7V and 4.2V.
I am not sure whether this could cause a supply problem while BLE is active that could influence the SX1262 transceiver.
I have no setup to test your supply configuration, but I will forward this to our R&D team. They are in Chinese New Year, so an answer might not be back before beginning of February.
On your custom PCB, do you have an option to connect VBAT_NRF to another voltage than the 3.3V?
Hi @beegee!
We do have that option. We are actually making a new PCB revision right now to deal with a couple other issues that came up during testing. I’m passing this info along to our PCB designer right now.
I’ll let you know what he says, surely other people building products based on the 4630 might find this useful!
– Nathan
Hi Nathan,
Usually we use the Breakout Boards for the WisDuo modules as reference schematics.
Unfortunately for the RAK4630 we never made such Breakout Board.
I will check with our Documentation team if we can add a reference schematic with these details.
A reference schematic would be very helpful. I have found something a little confusing here. In the RAK4631 power supply schematic section you shared, the notes say that VBAT_SX and VBAT_NRF should both be supplied 3.7 to 4.2V from the battery or USB.
However, the 4630 documentation says that VBAT_SX should be supplied 3.3V normally, 3.7V max. The 3.7-4.2 range in the schematic segment you shared would seem to be out of spec, based on the documentation. The same docs say that VBAT_NRF should be supplied between 2.5 and 5.5V, so 3.3 from the regulated supply should be just fine. Our power supply circuit can supply up to 500mA at 3.3V
What am I missing here? Do you have any insight into that discrepancy? We referred to the RAK documentation when designing the board.
Since I’m designing a custom board with RAK4630, I’m watching this thread closely…
In my case I’ll be powering the board directly from a LiFePo4 battery (3.6v when charged) I’ve not planned to have a regulator circuit (only the LiFePo4 battery charger IC)
Is it safe to power RAK4630 at 3.6V on all VDD_XX pins? as Nathan said probably there’s a discrepancy between your schematic and recommended operating conditions.
Regards
@nmcminn
The error is in the documentation. In our WisBlock Base Boards VBAT is directly connected to the rechargeable battery which has 3.7 to 4.2 V, depending on its charging status.
@javier.nr
I never tried to run the RAK4630 from 3.6V. It is close to the upper max specs for VDD of the SX1262 (3.9V) and of the nRF52 (3.9V). A spike on the voltage could cause damage.
Beside of that, I expect the same problems if all supply pins are tied to the same voltage.
The nRF52 in the RAK4630 is designed to to use the DC/DC option. I couldn’t find the details in the datasheet, but you are not the first customers who have problems when VBAT is the same level as the 3.3V input.
Hello bernd!
LiFePo4 chemical will have 3.6v at maximum when fully charged, so based on max spec probably it’s okay as the battery will never reach 3.9v?
As DC/DC option is probably something inside nrf52? Can be changed on user side? Sorry to ask, never worked with Nordic Chip and I want to make sure the board will work with supply at the same voltage on all VDD_XX pins (if I can, I want to avoid voltage regulator)
Thanks for your attention
@nmcminn
I double checked documentation and schematics.
VBAT_SX is tied to 3.3V, not to VBAT and the documentation is correct, max is 3.7V.
VBAT_NRF allows up to 5.5V and is tied to VBAT.
No mistake in the documentation.
@javier.nr
It cannot be changed to LDO as there is a coil for the DC/DC under the metal hood that would need to be removed.
Hello Bernd,
Now I understand what you mean, and also I’ve found here the schematic
So probably the coil to remove is L10, since it couldn’t be removed I will change my plans to include a 3v3 low dropout regulator. Any candidate/suggestion for this LDO (I mean very low quiescent current)?
In summary:
Many thanks for your attention, and excuse me @nmcminn for hijacking your thread, as you said:
It was super useful to me 
PS. Next RAK4630 revision can include a solder bridge underside to bypass L10? 
LDO is not the best solution when you want lowest quiescent current.
In a new design where we will have supply from 3.6V LiSOCl2 batteries only we use the RT6160 converter ==> https://www.richtek.com/Products/Switching%20Regulators/Buck-Boost%20Converter/RT6160A?sc_lang=en&specid=RT6160A
Wow @beegee superb support! Many thanks!
I was checking RT9080 and SGM6036 also, will study your part also.
new devices! great! 
…
Hi @beegee,
Were they able to solve the problem of +EVT:JOIN_FAILED_TX_TIMEOUT?
I have the same issue but in the RAK3172 module. I have a post with more details RAK3172 Radio Tx Problem.
I hope you can help me.
This thread is related to power supply mainly. The join fail was related to usage of BLE at the same time, the RAK3172 doesn’t have BLE, so it is not related to your problem.
Hi @beegee,
I believe there is a mistake in the documentation.
In the RAK4630’s datasheet we have:
In the RAK4631’s datasheet we have:
Both says a voltage for VBAT_NRF between 2.5V-5.5V is recommended, but here you say:
So, for the RAK4630 VBAT_NRF is recommended to be higher than 3.3V, and not higher than 2.5V as the documentation says.
Is that correct?
It is not an error.
VBAT_NRF should be higher than VDD_NRF, so you have to compare the minimum of VDD_NRF min with VBAT_NRF min.
