Feature-wise there isn’t any difference. The RAK831 is a bit more compact, but both run on the same platform (e.g. RasPi) and with the same packet forwarders.
At €105 + €9 shipping the RAK831 is still cheaper than the iC880A at €119 + €35 shipping. However because the RAK831 comes from outside the EU you do run the risk of having to pay an additional 21% + clearance costs if your package gets intercepted by customs. I wouldn’t be surprised if IMST set the price of €119 with that in mind.
The prices shown at the IMST webshop are NET prices, they will charge you the same VAT you would pay ordering something from China. Therefore the price you pay is (Eur 119 + Eur 35) + 19% VAT, provided you are not ordering as an entity having a European VAT registration.
See http://shop.imst.de/terms-and-conditions:
All prices published in the IMST Online-Shop are net prices, as our offer is generally not directed to (private persons) consumers. In addition, gross prices and the statutory VAT (currently 19%, Germany) is shown separately on the invoice
Perhaps wait a couple of days until https://webshop.ideetron.nl/ lowers prices as well and order from them, their shipping is usually cheaper…
Ha I wondered about that, because their new shop front-end said ‘Prices plus VAT’. Thanks for clearing that up. The RAK831 remains the cheapest by far then.
Sure, you are welcome.
How does the RAK831 board perform?
Is there any technical difference between this board (and iC880A) and much more expensive commercial gateways?
Performance wise no, see this discussion. All concentrator boards and gateways use the same Semtech provided chips and the same Semtech provided reference design.
On every photo of the RAK831 board I see two strips on the side.
They look like leftovers from the PCB production process that have yet to be removed.
Is that correct or do the strips serve any special purpose I am not aware of?
no, just break it off
Few days ago I have installed first gw with RAK831 pictures
I have good coverage and all seems quite nice. I did that minimum rssi is for now in few day test is -115dBm.
I did test other gateways and know that my other gateways are receiving messages with lower rssi, so im not sure if RA831 can perform maybe better with some fix?
Did someone notice something like that?
Are those gateways using the same antenna, same RF connector, same RF cable, same length of RF cable and the same position with respect to the nodes, and are the weather conditions the same? If not, you are comparing apples to oranges 
.
I noticed that my RAK831 GW does report about 15 -20 dBm worse RSSI compared with my iC880A based GW. measured with exactly the same roof mounted Antenna and the same 4m cable.
Setup was few nodes with distances between 20-500m with same SF every 5 minutes.
Measurement during few hour with RAK831, then I connected the IC880A instead of the RAK831 and measured another few hours.
I’m not comparing.
Just saying that my RAK831 does not report smaller RSSI then -115dBm.
It could be just RSSI no. I did not noticed that distance is lower (as far as I can tell driving around city).
So your IC880A does not report RSSI smaller than -95dBm to -100dBm under same circumstances where your RAK831 reports -115dBm?
Just interested: what RF cable type are you using?
Could it be that the IC880A and the RAK831 have different LNA gains or filter losses but that you use the same (for example IC880A ) configuration for both concentrators?
Somehow the control software and drivers should know the hardware specific filter losses and LNA gain to report an accurate received power level. I can imagine that there is a hardware specific gain calibration for both the receive and transmit path stored somewhere.
I received with RAK 831 @ - 123 db according to the console.
* searching for the screenshot
couldn’t find it off course but made a new one just now … -121 db very good
and that’s with an indoor GP antenna
I have a new RAK831 ( 915 Mhz model ) concentrator that is attached
to a Rpi board using “Kilobyte’s” RAK831 Raspberry Pi Breakout/Backplane.
I had set this up on my bench and used the ttn-zh installer to configure the
gateway. I am using the antenna that came with the RAK831 for now. I fired
up the gateway and ran a few tests using my RN2903’s ( of which I have
a few) I ran tests using OTAA and ABP and sure enough my packets showed
up on TTN ! 
The gateway starts up fine, I can see the logs and there doesn’t seem to be
any issues at all. However, if the RN2903 is more than about a meter away
from the gateway, the gateway never sees any RF packets … (Yes the
rn2903 has disabled (turned off) channels not used by the gateway subband 7)
for ch in range(0,72):
self.write_command('mac set ch status %d %s'%(ch,
'on' if ch in range(49,51+1) else 'off'))
I know the RN2903’s are working ok as I have used them in P2P mode sending
packets over 1KM in distance. I also double checked the antenna on the RAK831
and it seemed fine. I then tested the RAK831 using private packets (0x12) and
sure enough it saw every packet and displayed them correctly. So the RAK831
can hear the RN2903 sending private packets (0x12) at distance. However, when
I configure it to use type 0x34 for TNN the gateway never sees any packets. The
log simply shows
ttn-gateway[992]: # RF packets received by concentrator: 0
ttn-gateway[992]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Now, when I move the RN2903 very close to the gateway and send a message
the gateway gets it and processes it just fine. In fact the gateway forwards it almost
immediately. I can see this in the tcpdump
15:59:15.026733 IP ttn-gateway.cayugalake.net.34100 > 13.66.213.36.1700: UDP, length 235
E… 9@.@.l1…
m.B.$.4…g…’…yy.{“rxpk”:[{“tmst”:2581612820,“time”:“2017-11-09T20:59:15.026490Z”,“chan”:2,“rfch”:0,“freq”:904.300000,“stat”:1,“modu”:“LORA”,“datr”:"
SF10BW125",“codr”:“4/5”,“lsnr”:-12.8,“rssi”:-109,“size”:15,“data”:“QMwcAiYACAABvEdHk6e5”}]}
So I’m stumped … I can’t figure out what’s going on with my RAK831.
So basically I have a setup which works 100% as long as the RN2903 clients are within a
meter of the gateway 
The gateway is configured using the global_conf.json from the TTN site. I’m guessing I
have a config problem somehow. I’m not all that sure how to configure the RN2903
channels for Canada 915 Mhz.
Perhaps someone can help me ensure my global_conf.json and my RN2903’s are
configured properly …
Here is my global_config.json
{
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 1,
“clksrc_desc”: “radio_1 provides clock to concentrator”,
“antenna_gain”: 0,
“antenna_gain_desc”: “antenna gain, in dBi”,
“radio_0”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 904300000,
“rssi_offset”: -166.0,
“tx_enable”: true,
“tx_freq_min”: 923000000,
“tx_freq_max”: 928000000
},
“radio_1”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 905000000,
“rssi_offset”: -166.0,
“tx_enable”: false
},
“chan_multiSF_0”: {
“desc”: “Lora MAC, 125kHz, all SF, 903.9 MHz”,
“enable”: true,
“radio”: 0,
“if”: -400000
},
“chan_multiSF_1”: {
“desc”: “Lora MAC, 125kHz, all SF, 904.1 MHz”,
“enable”: true,
“radio”: 0,
“if”: -200000
},
“chan_multiSF_2”: {
“desc”: “Lora MAC, 125kHz, all SF, 904.3 MHz”,
“enable”: true,
“radio”: 0,
“if”: 0
},
“chan_multiSF_3”: {
“desc”: “Lora MAC, 125kHz, all SF, 904.5 MHz”,
“enable”: true,
“radio”: 0,
“if”: 200000
},
“chan_multiSF_4”: {
“desc”: “Lora MAC, 125kHz, all SF, 904.7 MHz”,
“enable”: true,
“radio”: 1,
“if”: -300000
},
“chan_multiSF_5”: {
“desc”: “Lora MAC, 125kHz, all SF, 904.9 MHz”,
“enable”: true,
“radio”: 1,
“if”: -100000
},
“chan_multiSF_6”: {
“desc”: “Lora MAC, 125kHz, all SF, 905.1 MHz”,
“enable”: true,
“radio”: 1,
“if”: 100000
},
“chan_multiSF_7”: {
“desc”: “Lora MAC, 125kHz, all SF, 905.3 MHz”,
“enable”: true,
“radio”: 1,
“if”: 300000
},
“chan_Lora_std”: {
“desc”: “Lora MAC, 500kHz, SF8, 904.6 MHz”,
“enable”: true,
“radio”: 0,
“if”: 300000,
“bandwidth”: 500000,
“spread_factor”: 8
},
“chan_FSK”: {
“desc”: “FSK disabled”,
“enable”: false
},
“tx_lut_0”: {
“desc”: “TX gain table, index 0”,
“pa_gain”: 0,
“mix_gain”: 8,
“rf_power”: -6,
“dig_gain”: 0
},
“tx_lut_1”: {
“desc”: “TX gain table, index 1”,
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: -3,
“dig_gain”: 0
},
“tx_lut_2”: {
“desc”: “TX gain table, index 2”,
“pa_gain”: 0,
“mix_gain”: 12,
“rf_power”: 0,
“dig_gain”: 0
},
“tx_lut_3”: {
“desc”: “TX gain table, index 3”,
“pa_gain”: 1,
“mix_gain”: 8,
“rf_power”: 3,
“dig_gain”: 0
},
“tx_lut_4”: {
“desc”: “TX gain table, index 4”,
“pa_gain”: 1,
“mix_gain”: 10,
“rf_power”: 6,
“dig_gain”: 0
},
“tx_lut_5”: {
“desc”: “TX gain table, index 5”,
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 10,
“dig_gain”: 0
},
“tx_lut_6”: {
“desc”: “TX gain table, index 6”,
“pa_gain”: 1,
“mix_gain”: 13,
“rf_power”: 11,
“dig_gain”: 0
},
“tx_lut_7”: {
“desc”: “TX gain table, index 7”,
“pa_gain”: 2,
“mix_gain”: 9,
“rf_power”: 12,
“dig_gain”: 0
},
“tx_lut_8”: {
“desc”: “TX gain table, index 8”,
“pa_gain”: 1,
“mix_gain”: 15,
“rf_power”: 13,
“dig_gain”: 0
},
“tx_lut_9”: {
“desc”: “TX gain table, index 9”,
“pa_gain”: 2,
“mix_gain”: 10,
“rf_power”: 14,
“dig_gain”: 0
},
“tx_lut_10”: {
“desc”: “TX gain table, index 10”,
“pa_gain”: 2,
“mix_gain”: 11,
“rf_power”: 16,
“dig_gain”: 0
},
“tx_lut_11”: {
“desc”: “TX gain table, index 11”,
“pa_gain”: 3,
“mix_gain”: 9,
“rf_power”: 20,
“dig_gain”: 0
},
“tx_lut_12”: {
“desc”: “TX gain table, index 12”,
“pa_gain”: 3,
“mix_gain”: 10,
“rf_power”: 23,
“dig_gain”: 0
},
“tx_lut_13”: {
“desc”: “TX gain table, index 13”,
“pa_gain”: 3,
“mix_gain”: 11,
“rf_power”: 25,
“dig_gain”: 0
},
“tx_lut_14”: {
“desc”: “TX gain table, index 14”,
“pa_gain”: 3,
“mix_gain”: 12,
“rf_power”: 26,
“dig_gain”: 0
},
“tx_lut_15”: {
“desc”: “TX gain table, index 15”,
“pa_gain”: 3,
“mix_gain”: 14,
“rf_power”: 27,
“dig_gain”: 0
}
},
“gateway_conf”: {
“server_address”: “router.us.thethings.network”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“servers”: [ {
“server_address”: “router.us.thethings.network”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“serv_enabled”: true
} ]
}
}
GIsn’t the TTN config for subband 1? So I’m surprised it picks up any transmission at all. Only explanation I can think of would be the tiny distance overloads some circuit making it receive transmissions at different frequencies.
Could it be that you received the wrong board? Or that you have a board with the wrong band pass filters mounted?
Are these the proper freq for sub-band 1 ?
Ch - Freq
8 - 903.9
9 - 904.1
10 - 904.3
11 - 904.5
12 - 904.7
13 - 904.9
14 - 905.1
15 - 905.3
I believe my code for the RN2903 should enable these
for ch in range(0,72): # sub band 1
self.write_command('mac set ch status %d %s'%(ch,
'on' if ch in range(8,15+1) else 'off'))
…