Has anyone here tried the RisingHF gateway boards?
I only asked them about the 868Mhz - which are available at around €150 - but they also list a 900-930Mhz version, the RHF0M301V1A-920
More info at http://www.risinghf.com/product/rhf0m301/?lang=en and you might also want a RHF4T002 Raspberry Pi adapter.
Where did you find the €150 price?
Somehow, the link to AliExpress in the top left corner of www.risinghf.com gets me to an empty store. In Google, I found a February 2016 direct link to the gateway on AliExpress, which directs me to their Dutch site, showing $220. For that, @kersing noticed that it shows zero transactions in the past 6 months, but yet also shows some orders from June. And clicking “Store: RUIXING Electronic” in the top left of that AliExpress page gets me the empty store again. Confusing…
I contacted RisingHF directly: sales at risinghf.com
Got a reply from Frances Liu:
RHF0M301 gateway concentrator: USD160/pcs
Discovery IoT kit RHF2S001: USD385/SET
Temperature&humidity sensor node RHF1S001: USD45/PCS
The quotation above is for samples, and delivery terms is FOB Shenzhen, Pls take note!
This was less than a month ago.
I reached out as well to ask about the 915 Mhz version (RHF0M301V1A-920), and Frances Liu responded that the unit will start shipping next week (8 Sept 2016). I asked him to send me an invoice and he did. It is USD$160 + shipping (DHL USD$27). Payment is via PayPal. I am going to be ordering one today!
Great, I got the same information.
I was also asking about the Raspberry Pi interface board, the “go between” PCB that connects the Pi directly to the gateway board. He said while they didn’t plan it as a separate product but it could be added on request with gateway board orders for an extra $40.
We bought the Discovery IoT. The price was about the same like you posted. They have gw module that can be reconfigured for both 868 or 915. They also hv 433, but different hw.
I spent some time yesterday doing some LoraWan work, trying to get my gateway set up and have a our sensor post info to The Things Network. I had some successes, but have not gotten a message to appear in The Things Network. Here is what I did:
Following the Wiki for RisingHQ for the gateway, I set up the GPIO pins to the raspberry PI 3 as documented. I used an external power supply for the gateway (as recommended), and an LED turned on to show the gateway was powered. I enabled the SPI interface on the PI. I had some issues with the open source projects that risingHQ until I discovered that there is a 3.2.1 version of lora_gateway and a v2.2.0 version of the packet_forwarder project. I check out the latest for that version and the commands seemed to line up.
The wiki instructions show how to connect to the loriot system, but I kept getting a “lgw_start failed” message:
https://bitbucket.org/snippets/tperfitt/ko7Gj
I gave up on this path after a bit since it doesn’t appear that I need that service running to connect to TTN.
The concentrator (gateway radio board) appears to be detected:
https://bitbucket.org/snippets/tperfitt/aoqGn
I then moved on to configuring the packet forwarder. I configured the frequencies, gps location, and server name in the config files:
https://bitbucket.org/snippets/tperfitt/XgEr4
and then started up the packet forwarder:
https://bitbucket.org/snippets/tperfitt/7oqb9
That seemed to work well, so I registered gateway at TTN network and it updates on their system:
On my way!
I then focused on getting a node to send data. Our sensor has a mode to talk directly to the radio (Microchip 2903) so i gave the command to do that and then I turned on the LoraWan capability:
mac resume
{“debug”,“ok”}
ok
That worked well. I then added a device in the TTN:

I used the ABP since it there was some info on the TTN about how OTAA is not support in the “old” API. Since it was unclear what API I was using, i decided to stick with the ABP mode. I sent the commands to set the keys and connect:
mac set nwkskey FCADD3CFD57FB3E8A10E3953F6F81221
mac set appskey 9EB41E44218BBB8D20257DEE5943EA61
mac set appeui 70B3D57ED000102C
mac set devaddr EA4ED7D5
and then I attempted to join:
mac join abp
ok
accepted
Looking good!
However, when I look at the output for the gateway, there is no change in the output, and when I did a network packet trace, there is no info being sent to TTN. In this article:
https://www.thethingsnetwork.org/forum/t/connecting-to-ttn-using-rn2483/1975
it shows some info similar to what I am seeing but doesn’t resolve the issue. I try to send a random TX:
mac tx uncnf 1 3132333435
ok
mac_tx_ok
But still no activity on the network and nothing shows up in the device on TTN.
I tried the util_pkt_logger in lora_gateway/util_pkt_logger but it does not show any output :
https://bitbucket.org/snippets/tperfitt/qo7bA
So it appears that the gateway is connected to TTN, and the node seems operational, but the gateway radio is not receiving any transmitted packets. I am a bit unclear if the global_conf json configures the radio or if it is simply to report to the server (TTN).
Any anyone have any ideas why the concentrator is no hearing the 2903 and anything I can do to test?
tim
Hi Tim, there’s a lot to digest but at a glance I’d suggest it’s because the Microchip module is using the full 64(+8) channel plan of the US LoRaWAN spec while the gateway - like most currently available - is only 8 channels
You have to disable most of the channels on the RN2903 and keep only the ones specified for the gateway. See http://www.microchip.com/forums/m926581.aspx for a code snippet to do that.
By the way I’m using @gonzalocasas fantastic setup on my RisingHF gateway. Just had to change the reset pin number in start.sh to match my setup.
Probably the best to use since it has all the right versions of the packet forwarder and is very well tested with TTN. It is EU focused (as far as I know) so you’ll need to change the configuration to use the US frequency plan and correct TTN server.
I got it working. The hint from @jmarcelino was needed but I also needed to figure out the correct frequencies that were at play for the config file.
Here is the tool to give out the commands to turn on just 8 channels (but in ruby):
fsb=1
chLow = (fsb -1) * 8;
chHigh = chLow + 7
ch500 = fsb + 63(0…72).each do |i|
if ( i == ch500 || chLow <= i && i <= chHigh) then
puts “mac set ch status #{i} on”
else
puts “mac set ch status #{i} off”
end
end
Using the output from the failed output from the loriat tool:
RADIO: radio 0 enabled, SX1257, center frequency 902600000, RSSI offset -166.0, TX enabled
RADIO: radio 1 enabled, SX1257, center frequency 903400000, RSSI offset -166.0, TX disabled
INFO: LoRa Multi-SF channel 0 >> Radio 0, IF -300000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 1 >> Radio 0, IF -100000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 2 >> Radio 0, IF 100000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 3 >> Radio 0, IF 300000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 4 >> Radio 1, IF -300000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 5 >> Radio 1, IF -100000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 6 >> Radio 1, IF 100000 Hz, 125 kHz BW Enabled
INFO: LoRa Multi-SF channel 7 >> Radio 1, IF 300000 Hz, 125 kHz BW Enabled
INFO: Lora std channel> radio 0, IF 400000 Hz, 500000 Hz bw, SF 8
INFO: FSK channel> radio 0, IF 0 Hz, 250000 Hz bw, 50000 bps datarate
I edited the global config file for 868 Mhz and updated it with these values, and it seems to work.
{
"SX1301_conf": {
"lorawan_public": true,
"clksrc": 1, /* radio_1 provides clock to concentrator */
"radio_0": {
"enable": true,
"type": "SX1257",
"freq": 902600000,
"rssi_offset": -166.0,
"tx_enable": true
},
"radio_1": {
"enable": true,
"type": "SX1257",
"freq": 903400000,
"rssi_offset": -166.0,
"tx_enable": false
},
"chan_multiSF_0": {
/* Lora MAC channel, 125kHz, all SF, 868.1 MHz */
"enable": true,
"radio": 0,
"if": -300000
},
"chan_multiSF_1": {
/* Lora MAC channel, 125kHz, all SF, 868.3 MHz */
"enable": true,
"radio": 0,
"if": -100000
},
"chan_multiSF_2": {
/* Lora MAC channel, 125kHz, all SF, 868.5 MHz */
"enable": true,
"radio": 0,
"if": 100000
},
"chan_multiSF_3": {
/* Lora MAC channel, 125kHz, all SF, 867.1 MHz */
"enable": true,
"radio": 0,
"if": 300000
},
"chan_multiSF_4": {
/* Lora MAC channel, 125kHz, all SF, 867.3 MHz */
"enable": true,
"radio": 1,
"if": -300000
},
"chan_multiSF_5": {
/* Lora MAC channel, 125kHz, all SF, 867.5 MHz */
"enable": true,
"radio": -100000,
"if": 1
},
"chan_multiSF_6": {
/* Lora MAC channel, 125kHz, all SF, 867.7 MHz */
"enable": true,
"radio": 1,
"if": 100000
},
"chan_multiSF_7": {
/* Lora MAC channel, 125kHz, all SF, 867.9 MHz */
"enable": true,
"radio": 1,
"if": 300000
},
"chan_Lora_std": {
"bandwidth" : 250000,
"enable" : true,
"if" : 400000,
"radio" : 0,
"spread_factor" : 8
},
"chan_FSK": {
"bandwidth" : 250000,
"datarate" : 100000,
"enable" : false,
"if" : 0,
"radio" : 0
},
"tx_lut_0": {
/* TX gain table, index 0 */
"pa_gain": 0,
"mix_gain": 8,
"rf_power": -6,
"dig_gain": 0
},
"tx_lut_1": {
/* TX gain table, index 1 */
"pa_gain": 0,
"mix_gain": 10,
"rf_power": -3,
"dig_gain": 0
},
"tx_lut_2": {
/* TX gain table, index 2 */
"pa_gain": 0,
"mix_gain": 12,
"rf_power": 0,
"dig_gain": 0
},
"tx_lut_3": {
/* TX gain table, index 3 */
"pa_gain": 1,
"mix_gain": 8,
"rf_power": 3,
"dig_gain": 0
},
"tx_lut_4": {
/* TX gain table, index 4 */
"pa_gain": 1,
"mix_gain": 10,
"rf_power": 6,
"dig_gain": 0
},
"tx_lut_5": {
/* TX gain table, index 5 */
"pa_gain": 1,
"mix_gain": 12,
"rf_power": 10,
"dig_gain": 0
},
"tx_lut_6": {
/* TX gain table, index 6 */
"pa_gain": 1,
"mix_gain": 13,
"rf_power": 11,
"dig_gain": 0
},
"tx_lut_7": {
/* TX gain table, index 7 */
"pa_gain": 2,
"mix_gain": 9,
"rf_power": 12,
"dig_gain": 0
},
"tx_lut_8": {
/* TX gain table, index 8 */
"pa_gain": 1,
"mix_gain": 15,
"rf_power": 13,
"dig_gain": 0
},
"tx_lut_9": {
/* TX gain table, index 9 */
"pa_gain": 2,
"mix_gain": 10,
"rf_power": 14,
"dig_gain": 0
},
"tx_lut_10": {
/* TX gain table, index 10 */
"pa_gain": 2,
"mix_gain": 11,
"rf_power": 16,
"dig_gain": 0
},
"tx_lut_11": {
/* TX gain table, index 11 */
"pa_gain": 3,
"mix_gain": 9,
"rf_power": 20,
"dig_gain": 0
},
"tx_lut_12": {
/* TX gain table, index 12 */
"pa_gain": 3,
"mix_gain": 10,
"rf_power": 23,
"dig_gain": 0
},
"tx_lut_13": {
/* TX gain table, index 13 */
"pa_gain": 3,
"mix_gain": 11,
"rf_power": 25,
"dig_gain": 0
},
"tx_lut_14": {
/* TX gain table, index 14 */
"pa_gain": 3,
"mix_gain": 12,
"rf_power": 26,
"dig_gain": 0
},
"tx_lut_15": {
/* TX gain table, index 15 */
"pa_gain": 3,
"mix_gain": 14,
"rf_power": 27,
"dig_gain": 0
}
},
"gateway_conf": {
"gateway_ID": "4C5892C755B4DF50",
/* change with default server address/ports, or overwrite in local_conf.json */
"server_address": "router.us.thethings.network",
"serv_port_up": 1700,
"serv_port_down": 1700,
/* 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": true,
/* GPS configuration */
"fake_gps": true,
"ref_latitude": 41.751866,
"ref_longitude": -88.125221,
"ref_altitude": 100
}
}
Why not download the TTN configuration file from the TTN github repository? That way you are using the same frequencies other gateways connected to TTN use as well.
Good idea. Now that I have it up and running I’ll migrate over to those frequencies. I didn’t know where the “standard” set lived, but I’ll do that next.
I just got notified by RisingHF that they are now FCC certified for the RHF0M301 gateway module. I’m going to do some more testing with it this week. We are also finalizing our own node that uses the TN2903 chipset that should be able to integrate with any gateway. More info here:
http://www.proxidyne.com/project/proxidyne-iot-starter-kit/
We are using RN2903 to communicate using peer to peer mode using our own protocol, but also have a mode where you can set the LoRaWAN settings on the RN2903 and pass data directly. It should work great with the RisingHF gateway and then get data via TTN.
tim
The build process isn’t very different from the ic880a, here are suggested connections:
(you can play with where to connect the reset pin)
The rest of the stack is exactly the same.
Hey @jmarcelino!
I just got my rising HF board and have been trying to get it setup but have been running into a few issues.
Here is a look at the output after running start.sh.
I’ve already …
In an earlier comment (Has anyone tried the RisingHF gateway boards? - #9 by jmarcelino) you mentioned that you had to reset the pin number in start.sh but I don’t see any reference to that inside the file. Am I missing something? Is there a reason the reset from the RisingHF board can’t map to pin 22 as in the example for the ic880a?
Thanks in advance!
UPDATE: I am using a Pi Zero
UPDATE: 1/19/2017
Today I came across this repo that mentions having to toggle the reset pin of different board, with risinghf being one of them. Looks like the pin matches the diagram posted above.
gpio -1 mode 26 out
gpio -1 write 26 0
sleep 0.1
gpio -1 write 26 1
sleep 0.1
gpio -1 write 26 0
sleep 0.1
ttn-resin-gateway-rpi/run.sh at master · rayozzie/ttn-resin-gateway-rpi · GitHub
Still no luck though.
UPDATE: 1/21/2017
Made some progress last night. I realized that packet_forwarder and lora_gateway libraries that are cloned during the ic880a install script clone the repos from TTN’s github account.
Both are a few versions behind in comparison to most recent releases by LoraNet or RisingHF.
Although I haven’t dug too deep into the file changes between 3.1.0 and 3.2.0, I can confirm that 3.2.0 is the first release version of lora_gateway that allows me to test registration and spi successfully on the RisingHF board.
On the latest version, I can successfully test registration and see that the concentrator is connected.
End of register verification IMPLICIT_PAYLOAD_LENGHT = 197 (should be 197) FRAME_SYNCH_PEAK2_POS = 11 (should be 11) PREAMBLE_SYMB1_NB = 49253 (should be 49253) ADJUST_MODEM_START_OFFSET_SF12_RDX4 = 3173 (should be 3173) IF_FREQ_1 = -1947 (should be -1947) End of test for loragw_reg.c
After I tried running a tx test. Here is the output when when I try and run the tx test with the following command:
sudo ./util_tx_test -f 915.0 -r 1257
`Sending -1 LoRa packets on 915000000 Hz (BW 125 kHz, SF 10, CR 1, 16 bytes payload, 8 symbols preamble) at 14 dBm, with 1000 ms between each
ERROR: Failed to load fw 1
ERROR: failed to start the concentrator
As of version 4.0.0 a script called reset_lgw.sh was added that allows you to reset
the concentrator through the HOST GPIO pin. The default in GPIO 7, which appears line up correctly with the diagram provided above that maps the reset pin on the concentrator to Pi’s pin 26 (CE1/GPIO7)
I tried using this before calling any scripts that I assume are trying to start the concentrator but still had no luck.
Getting close! 
Thanks for the report. It’s interesting that your RisingHF board only works with the 3.2.0 packet forawarder while mine (and at least two others, including people in US) work fine with the older ‘official’ TTN version.
I wonder if there’s been a new revision of the SX1301 chip which requires the new forwarder?
So you can just run test_loragw_reg but not test_loragw_hal ?
Just checking but since you’re powering the concentrator board externally are you connecting both the Pi and the RisingHF grounds together as needed?
@jmarcelino
Sorry for the confusion. Part of the problem was a complete oversight on my part since I was not cloning the install and setup script from the spi branch.
@kersing Pointed out that newer versions, like the one I was referring to earlier dropped support for USB, which explains why those were working for me.
Trying to see if I can get further now. Will report back with new finding.