Install libftdi:
This library is required for enabling the ftdi drivers to talk to the SPI component in the . The installation process is simple and can be done according to the following steps：

sudo apt-get install libftdi-dev

Install libmpsse:
Go to download folder of your RAK831 gateway repor under the ../libmpsse/src directory.Execute the following command.

sudo ./configure --disable-python

And then compile

make

Static and dynamic libraries compiled code is put into /usr/local/lib
Header file is put into /usr/local/include

sudo make install

Build the library
Unpack the RAK831 LoRa Gateway project and go to lora_gateway directory. then build the library and examples.

make all

Some tests:
After completing the above work, you can start the Lora Gateway tests. It is necessary to confirm whether the Liunx system recognizes the FT2232HL module and whether the wiring is connected. So first we need to test the SPI communication.

SPI test
Go to the ../lora_gateway/libloragw directory. Execute the following command.

sudo ./test_loragw_reg

The output should show that the register get a non zero value which matches the values that is in the (should be ***) section in each line.

RX test
In the ../lora_gateway/libloragw directory, execute the following command to test the module receive
function.

sudo ./test_loragw_rx 868.1 868.5

Note: here change the radio0 and radio1 frequency to the frequency of your rak831 device. This should show a steady stream f bytes being sent out from the concentrator.

@Twenyong thank you for your post!
I changed the question because I have figured out my last problem. But after adding lora_pkt+fwd under respository RAK831_LoraGateway, i cant build it using make. It seem like its lack of library.cfg, what should I do?
Sorry for the convenient, I'm newbie in Lora.

You can find the error logs here. Please note that I cloned the whole packet_forwarder directory from https://github.com/Lora-net/packet_forwarder.git, because when I added just folder lora_pkt_fwd, make command couldn't find out file libraries.cfg

Thank you @OlivierG
I've tried your code but it seems to me that I got the same results as following @Twenyong without installing packet_forwarder? How can I check it please?

Secondly, (if anyone can help) when I tried function test_loragw_rx, I always received problem with CRC, package damaged. I thought that it's due to missing a sender so I set up a sender with module Heltec Wifi Lora 32, and sender code from https://www.alictronix.com/archives/860 with frequency modified, but the concentrator still received damaged packet? Am I wrong at something?

Build the RAK stack: The log you sent is not from RAK's code...so it is not obvious to help you in building it

Heltec Wifi Lora 32 is just a LoRa sender, so, if you want to use it as a sensor (why not . ), you have to set up the Heltec device with LMIC stack (see arduino lmic at [https://github.com/matthijskooijman/](link url))

I set up the whole pack (Heltec -> RAK831 <-> TTN) and it works
Regards
Olivier

The RAK831 module does work correctly with the RAK stack, so going with @OlivierG comments, I would definitely suggest to first get your RAK stack compiled and executed.

Second, the CRC check failure is ok, as it happens when there is no sender to send a lora packet. However when testing the initial config, your spi_test and rx_test shouldn't throw "concentrator failure" during execution. So i would request you to build the RAK stack first and see if the above two commands work and show you a correct output

BTW, I would like to understand if there is any particular requirement for running the RAK831 via FTDI instead of full speed SPI? If its an industrial use case, I would recommend getting a industrial chipset variants of the imx6 or from broadcom and run it on the board directly via SPI. Since the FTDI support is getting deprecated with the semtech gateway version code v3.2.0. Hence any changes to the sx1301 or future chipset revision will not have full support for the FTDI based development. Just a suggestion from my end.

Official semtech repo notes:

v3.2.0

Added support for SX1301AP2 reference design (with FPGA and additional SX127x). When a FPGA is detected at startup, the HAL automatically adapts SPI communication requests (using SPI header or not).
Added util_spectral_scan diagnostic tool to scan the spectral band in background, where the LoRa gateway operates. (can only be used with SX1301AP2 or similar design). By default it uses the same SPI device as the one used by the HAL, but it can be changed depending on the hardware architecture on which it is used by updating the SPI_DEV_PATH constant defined in file util_spectral_scan/src/loragw_fpga_spi.c. Note: when using same SPI device from 2 applications, we rely on the host SPI driver and OS to properly handle concurrent SPI requests. It has been tested on Raspberry Pi / Raspbian with spi_bcm2708 driver.* Removed SPI FTDI support due to lack of performances to properly handle heavy packet traffic. Only native SPI usage is recommended.
HAL: added a check that SX1301 firmwares have been properly loaded at startup.

Look like it's a problem because I lack of experience with Linux, as a permanent windows user. I think I have succeed to build it, but I still don't know how can I execute it? Does it mean running the rx_test?

@OlivierG I will use it as a sensor, I used to play a lot with arduinos but for now I just send some random number

But it seems just to be used for RPi because I can't connect to TTN. Then I came back to the option of adding this floder https://github.com/Lora-net/packet_forwarder/tree/master/lora_pkt_fwd under RAK831_LoRaGateway repo with the same error log, like in the very long comment of mine before. @OlivierG are you sure that I should not clone the packet_forwarder? In addition, do you think my laptop installed both windows and ubuntu makes this problem?

Hi @KhaiNguyen
Step by step, little by little
Just one question: on the Heltec Lora module, are you using the default LoRa sender ? ... if "yes", the global behavior is the one expected. The Heltec send Lora frame, not LoRaWan.
TTN expects LoRaWan frames, with all the needed settings (e.g.: APP EUI, DEV EUI, ... )
So, now, let the gateway "as is"
(on the RPI, if you look at syslog :sudo tail -f /var/log/syslog
you should see log like this one: