OK. Do you have the correct permissions on the /dev/spi device? Have you tried running test_loragw_reg with sudo?
Yeah, same thing:
pi@raspberrypi:~/risinghf/lora_gateway/libloragw $ sudo ./test_loragw_reg
Beginning of test for loragw_reg.c
ERROR: CONCENTRATOR UNCONNECTED
IMPLICIT_PAYLOAD_LENGHT = 0 (should be 197)
FRAME_SYNCH_PEAK2_POS = 0 (should be 11)
PREAMBLE_SYMB1_NB = 0 (should be 49253)
ADJUST_MODEM_START_OFFSET_SF12_RDX4 = 0 (should be 3173)
IF_FREQ_1 = 0 (should be -1947)
End of test for loragw_reg.c
pi@raspberrypi:~/risinghf/lora_gateway/libloragw $ sudo ./test_loragw_spi
Beginning of test for loragw_spi.c
data received (simple read): 0
End of test for loragw_spi.c
For the SPI, I used the command
$ echo -e “\ndtoverlay=spi-bcm2708\ndtparam=spi=on\n” >> /boot/config.txt
seems to be working
pi@raspberrypi:~/risinghf/lora_gateway/libloragw $ ls /dev/spi*
/dev/spidev0.0 /dev/spidev0.1
Did you double checked Reset Pin of the SX1301 ?
I’m saying because sometime the reset line of chip are a bit confusing,
- asserting a reset on SX1301 ( 0 => 1 => 0) usually works fine (saved me lot of time)
- if reset pin is high (active reset) the chip can answer to SPI command but not ALL, that’s confusing because chip seems to works for some commands but not all since it’s in reset mode, so be sure this line is set to 0 when you want chip to works as expected.
Just saw your reset line is connected to SPI CE1, I would avoid this one, already saw SPI reconfigure these pins (or even some devices) so try to use an unused GPIO just to see if it works better, worth trying …
I just checked the voltage at RESET pin on the RisingHF board (pin 14) and it is low (0.5V).
I haven´t tested a different pin yet on RPI, I´ll try it.
Hi,
As we know that the RHF0M301 uses similar hardware as in IMST ic880a.
I would like to confirm that I was able to get my RHF0M301 up and running by following this
IMST ic880a Instruction at TTN Official Github page.
However, please make sure that you have the correct RESET line. For example, if you are using the official RisingHF Raspberry Pi backplane, then you need to specify the reset line to pin 7 (Note: 7 is the RPi hardware pin for physical pin 26).
To specify the reset pin, just change the default start command from:
$ <packet-forwarder-binary> start
to:
$ <packet-forwarder-binary> start --reset-pin 7
Also, I have made an eagle library and backplane for the RHF0M301 board if you are interested.
2 Likes
Hello folks !
I’m working on RHF0M301 gateway with raspberry pi 3 and also i have registered my gateway on TTN , an arduino node is sending data to the gateway. The packets are received by the gateway and displayed on the pi’s console . But the problem is that these packets are not forwarded to the TTN router .
this is the packet forwarder i’m using
this is how my global_conf.json looks like. i have used the server address and port as mentioned in the “settings” in the gateway registration page .
“gateway_conf”: {
“gateway_ID”: “b28affa1234badef”,
/* change with default server address/ports, or overwrite in local_conf.json /
“server_address”: “asia-se.thethings.network”,
“serv_port_up”: 1901,
“serv_port_down”: 1901,
/ adjust the following parameters for your network /
“keepalive_interval”: 10,
“stat_interval”: 30,
“push_timeout_ms”: 100,
/ forward only valid packets */
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: false
}
this is the proof that im receiving LoRa packets at the gateway
Can anybody figure out what’s wrong?
Any feedback is welcome , Thank you
I hope you mean the information is in local_conf.json, not global_conf.json?
To connect to TTN you need to change the serv_port_up and serv_port_down to 1700. To make sure your gateway is using the correct frequencies, get the global_conf.json from the TTN github repository.
1 Like
Thank you kersing for your feedback , its the global_conf.json itself and believe me it had worked for me few months a go ! and i’m configuring json files according to this 
i’m trying to connect to ttn-router-eu and port number is 1901. is this ok?
Please read my previous message. The port to use is 1700, not 1901. Your global_conf.json should be downloaded from the TTN github site (see my previous message for the link) and the gateway specific parameters like ID should be in the local_conf.json.
Or as @Epyon suggested, use the official TTN packet forwarder or the use resin.io with these sources.
thank you kersing , it worked !!!. i was confused with 1901 port as mentioned in the “settings” -.>“router” .
Can anyone tell me as why they have mentioned 1901 port ?
Thank you in advance!!
Hi Guys
I am experimenting with lorawan so i decide to buy the developer kit in risighf, My gateway recive the packets and they show in the ttn website but i lose more than 50% of the packets, and the node is very close from the gateway no more than 2 meters, Do you have any suggestion ?
I am using the RHF76-052 configurated in 915 Mhz for a node and for gateway RHF0M301
less then 2 meters is to close !
Just curious why it needs to be further away from the gateway. From my experience with RF system, the closer will have higher chances of receiving the signal. Is this case doesn’t apply for LoRa?
LoRaWAN receivers are very sensitive, especially when coupled with an antenna that has some gain. If you place a node next to a gateway you are overloading the receiver, which will result in many CRC fails for your and other nodes. You don’t place a FM radio right next to a 100kW transmitter, right? Datasheets such as the one from IMST stipulate you should keep at least 2m distance between a node and a gateway to prevent errors or even damage to the gateway. The same goes for node-to-node distance.
Also, in RF it is generally recommended to keep a distance of one to multiple times the wavelength between sender and receiver.
This is associated with the radio Near Field (Fresnel) and Far Field (Fraunhoffer). See https://en.wikipedia.org/wiki/Near_and_far_field . Most radio systems, including LoRa, modulate and use the far field. If you locate transmitter and receiver in the near field they might or might not work and may produce strange results. LoRaWAN in EU at 868MHz uses a wavelength of 33cm. There is no hard near/far boundary but it’s best to keep at least 4 wavelengths between transmitter and receiver. For workshop commissioning I use 2m, i.e. 6x wavelength as my reference test point. As a point of interest some radio systems specifically use the near field, e.g. RFID, bank cards, etc. in order to limit the range and provide power. They are called Near Field Communications systems.
I had the same problems. It was a huge headache, but eventually I figured it out, and I made an instructable for it: http://www.instructables.com/id/LoRaWAN-Gateway-Seeeduino-Motes/
I also talk about this in this thread: Seeeduino US working
And I’ve uploaded the correct end-device Arduino code for using a hybrid gateway here: https://github.com/brady-aiello/Seeeduino_LoRaWAN_for_hybrid_gateways
Long story short: It drops the packets because it’s not listening on those channels. The code that Seeeduino gives us assumes that we are using a full gateway (which listens on all 64 channels), when it reality, our Rising HF gateway is only listening (and transmitting) on 8 channels. So we just need to make sure that the gateway and the nodes are using the same 8 channels.
1 Like
I too have purchased on of the Rising HF 2S001 Discovery Kits. They now are now shipped with an RPi model 3 which gives them more grunt. RHF bundles an FTDI adaptor so you can communicate via a USB port for initial configuration.
The kit is very well put together and easy to get running. Mine is now feeding to TTN with some test nodes.
It is important to note that the 8 channel limitation referred to by Brady is a factor of the Semtech Gateway chipset and effects ALL gateways. To make a 64 channel Gateway, you would need 8 of the modules. And very few people have tackled that task to date. From a practical view, that means the capacity of a Gateway drops to 1/8th of the claimed figure.
So, I’ve set up the risinghf hardware and ssh into it. I cloned ttn’s ic880a and run install.sh
what’s next? I am rather lost as to what the proper steps are in installing and then testing the connection and functioning of the gateway. Many wikis skip steps, so any help is appreciated. Thank you all.