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.
@jmarcelino That did the trick! I reset both boards after connecting the grounds together and was able to successfully start the concentrator.
Thanks for the help!
If anyone else follows the diagram posted above and the install script from the ic880a tutorial, the change for the reset pin is located here https://github.com/ttn-zh/ic880a-gateway/blob/spi/start.sh#L4 and should be updated to 7 or your setup if it is different from the diagram.
Not having any luck here… keep running into the dreaded:
ERROR: Version of calibration firmware not expected, actual:226 expected:2
ERROR: [main] failed to start the concentrator
if I enable debug I see this:
Note: SPI burst write success
Note: SPI read success
Note: SPI write success
Note: SPI read success
Note: SPI write success
Note: SPI write success
Note: SPI read success
Note: SPI write success
Note: SPI write success
Note: SPI write success
Note: SPI read success
ERROR: Version of calibration firmware not expected, actual:226 expected:2
ERROR: [main] failed to start the concentrator
I’m using an Odroid C1 which has a 40pin rPi header and I’m using GPIO 102(40-18) which I verified does toggle when the start.sh script uses 102 instead of 25 for the pin number.
I’ve also tried 500000 SPI speed, 50000 speed, and even 1000000 besides the default 800KHz SPI speed. It does look like SPI is working(see above debug msg) but since I have my boards connected with 6" jumper wires I was concerned.
The latest thing I tried was pulling the concentrator 5v wires from the 40 pin and providing 5v/gnd from an external power supply. It’s not even pulling 100mA so I can’t see how that would help since the ODroid is powered from a wall wart 5v 2A…
my global_config and local_conf are from my working Multitech MTAC system so I know they work with that concentrator and 915MHz.
Any suggestions?
You need to change the global_conf.json, for RisingHF the clock source should be set to 1. For MTAC it is set to 0.
UPDATE: its’ working… I forgot to look for background poly_pkt_fwd processes in the background and stop them. Once done, and with the clk set 1, it’s up and running. Don’t know how I missed this last time I checked using clk=1 but there it is.
UPDATE: it’s working and far more reliably now that I moved the SPI clock jumper out of the ribbon cable of the other signals. I also say only 400mA used so moved 5V and gnd back being sourced from the 40pin header(5V=40-4 GND=40-6 ).
We tried the Pibow Coupé case on one of our Raspberry Pi + RisingHF boards w/ the official adapter and hey it works pretty well!
@jmarcelino, Looks good but I’m going to dig into KiCAD and generate an adapter for either connectors or direct solder of one or both concentrator and/or controller and should cost ~$5 from DirtyPCBs. Once I moved my SPI clock line my octopus setup has been running all day without a single restart of the packet forwarder process. And soon it’ll be 10m in the air powered via Adafruit Power over Ethernet hack/connectors.
Friends, i need some guidance.
I have risinghf RHF2S001 and i was trying to install the standard loriot connection. I have followed all the instruction, different power supply for concentrator and combining the ground.
[2017-03-29 15:59:18.707][INFO ] Starting LoRa Concentrator
[2017-03-29 15:59:19.424][ERROR] lgw_start failed
[2017-03-29 15:59:19.424][ERROR] You might be running an incompatible version of the binary
STOP
[2017-03-29 15:59:19.425][LOG ] Concentrator stopped
I have spent a lot time but could not make it work but failed.where as lora_pkt_fwd command works.
The other image (commandline/shell) type provided by risinghf works but i need a regular desktop interface. I but i am keen on setting TTN setup.
Can i install TTN version of lora_gateway and packet_forwarder and make it work with risinghf gateway. I could see additional commands/packages in TTN repository(https://github.com/TheThingsNetwork/lora_gateway) and https://github.com/TheThingsNetwork/packet_forwarder).
Could anyone help…
You can do the setup from https://github.com/ttn-zh/ic880a-gateway/tree/spi then edit /opt/ttn-gateway/bin/start.sh
Change the line which says
SX1301_RESET_BCM_PIN=25
to
SX1301_RESET_BCM_PIN=7