RAK2247 how to change default SPI port to another in Raspberry Pi 4?

Issue: Hello,
I want to connect my RAK2247 to the SPI6 port of my Raspberry Pi 4 (witch has 6 SPI ports) using ChirpStack for example. Is there a solution to configure this choise of SPI, In which file in ChirpStack directory for example should I access to change this configuration?
I know that SPI is composed of MISO, MOSI, CLK and CS but I am trying to choose the SPI6 (GPIO’s : 18, 19, 20 and 21) to communicate with my RAK2247 LoRaWan Getaway.
Thank you

Setup: Raspberry Pi 4

Server: ChirpStack

How to configure RAK2247 hardware SPI connection to the SPI6 of the Raspberry Pi 4 (change SPI GPIO’s for ChirpStack server).

Hello @Said_2022

I’m not sure I understand what you need. Are you using Chirpstack only as a LoRaWAN Network Server or are you using Chirpstack Concentratord? If the later you should probably head over to their documentation site (Introduction - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server) or their forum (https://forum.chirpstack.io/).

If you are using Chirpstack as a server, I don’t see why you need to use a different SPI bus. What is the reason for that?

In case you still want to do it, steps would be:

Hello @xoseperez
Thank you for the detailled response. It exactely what I need to do. I made an adapter interface for RAK2247 and I connected it on the SPI6 of the raspberry pi 4, that’s why I try to configure the SPI6 (dev/spidev6.0).

It’s ok for the “1. Enable SPI 6 bus overlay (add dtoverlay=spi6-1cs to the /boot/config.txt file”

Now I using rak_common_for_gateway, can you tel me how to configure or set RADIO_DEV environment variable to /dev/spidev6.0? because the installed in my linux Raspberry Pi, I am tried “Edit packet-forwarder config” but it not contained RADIO_DEV variable.

Thank you

Sorry, my fault, the variable is named LORAGW_SPI. Check the commit here to support this option only 15 days ago: Option to set a different device port and speed for SX1301/8 SPI conc… · RAKWireless/rak_common_for_gateway@3d6e44d · GitHub

I would first try definiing it in the /etc/environment file:


When the system boots and the gateway service starts it should see the variable and set the device port accordingly… But as I said I have not tested it so you might need to do some R&D here…

Thank-you for your prompt response,
Sorry but I don’t inderstand how modify or in what file the LORAGW_SPI variable ? in environment variable ?

Yes, you should set the LORAGW_SPI as a system variable. You can do so by adding the line in my answer before to the /etc/environment file.

Another option would be to edit the /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh file to add LORAGW_SPI=/dev/spidev6.0 before the ./lora_pkt_fwd in the last line.

Thank you,
The /etc/environment file is empty ! I edited /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh file.
I think I have a another problem with the reset pin, it connected to the GPIO25 in my interface and configured at gpio17 in strt.sh : SX1301_RESET_BCM_PIN=17, so I can change it to 25 here ?

Yes, change the reset GPIO there.
It’s not unusual that the environment file is empty, but it’s of to add it on the start.sh file.

I have already “Not data available” in dashboard after changes and reboot. Is there a way to test if the SPi communication is correctely established between Raspberry anr RAK2247SPI?
Thank you

I tested my board (interface for RAK connected to SPI6 of Raspberry Pi 4) with RAK2287 and it’s work with modification of : “com_path”: “/dev/spidev0.0”, to “com_path”: “/dev/spidev6.0”, in the packet forwarder config json file located in /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd. This file begin by this lines :
“SX130x_conf”: {
“com_type”: “SPI”,
“com_path”: “/dev/spidev0.0”,
“lorawan_public”: true,
“clksrc”: 0,
“antenna_gain”: 0, /* antenna gain, in dBi /
“full_duplex”: false,
“fine_timestamp”: {
“enable”: false,
“mode”: “all_sf” /
high_capacity or all_sf */
“radio_0”: {

But I dont locate this line in the RAK2247 packet forwarder json file. The two firmware are different.
How I can add “com_path”: “/dev/spidev0.0” to the packet forwarder ?

The file begin by this lines:
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 1,
“antenna_gain”: 0,
“radio_0”: {

Hi @Said_2022 for SX1301(RAK2247), the communication path is predefined in the loragw_spi.native.c (lora_gateway/loragw_spi.native.c at master · Lora-net/lora_gateway · GitHub)
You need to change it in the file and compile it again.

Thank you,
Can you tel me how to compile this Lora_gateway ? I dont find installation method in the Git.

The same way you use till now. Change the SPI path in the file and run the install sh script. The script will recompile all needed files.

It looks like if a recent checkout of rak_common_for_gateway is used then the commit mentioned above introducting the LORAGW_SPI environment variable was supposed to be effective for RAK2247 (SX1301) builds also.

A build directly from the semtech (Lora-net) repo rather than rak_common_for_gateway would not have that RAK customization.

The following command could help figure out how a given packet forwarder build is actually setup:
strings path/to/packet_forwarder_binary | grep -i "LORAGW_SPI\|spidev"

This should find the hardcoded /dev/spidev0 or or spidev6, and if the LORAGW_SPI and/or LORAGW_SPI_SPEED environment variables are being checked.

Recompiling from source is of course the correct solution for changing the fixed SPI device. Though as a last-ditch option one can use a binary-capable editor to simply change spidev0 to spidev6 in the compiled binary, being very careful that it’s an exact replacement operation (check that the file length in bytes is the same before and after). A serious downside of editing binaries is that if you don’t leave notes that this is what you have done, any future recompilation is likely to cause a “why doesn’t this work???” mystery.

I already tried to change SPI0 to SPI6 by LORAGW_SPI command environment variables but not work, it looks like the Raspberry is pointing to SPI0 already after this command. I will try the last proposition of @Velev and return here for result.