@wdebbaut:
Did you try using uppercase for the id in the API URL:
https://www.thethingsnetwork.org/api/v0/gateways/B827EBFFFF909FFF/
instead of
https://www.thethingsnetwork.org/api/v0/gateways/b827ebffff909fff/
I had the same issue using lowercase, but trying uppercase fixed it.
I hope it helps and excuse me if you already received replies/solutions - I do not see replies on this forum, just trying to help:)
tnx for your reply Milen, in the meantime we have a multichannel gateway to experiment with - the Lorrier device LR2 - because the single channel is not really compatible with the project we are working on. This LR2 is in fact a combination of the IMST Lora concentrator iC880A, a Beaglebone Green as MCU and Mikrotik board as IP interface.
We modified the Dragino board into a lora node and in this way we are able to send the messages from this node via the multichannel gateway up to the WirelessThings, aka TTN backend with no problems. We even succeeded in sending the payload up to 30km !
Wish you all the very best with you endeavors in this exciting field of RF and IP.
Wim.
For those of you using @Thomas’ single channel packet gateway and looking for a way to automate the deployment, I’ve merged several of the pull requests and added debian packaging files to create a .deb package.
My fork of the code can be found at https://github.com/proffalken/single_chan_pkt_fwd and I’d welcome someone testing that it works because my Dragino LoraShield is still in the post!
Contributions/comments/etc. always accepted 
where did you buy that shield from?
@exquisitus - I got it from Ebay: http://www.ebay.co.uk/itm/272267571206?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
I purchased it after talking with a few people in the Slack channels
Optimization in the CAD procedure for MultiSF (Application Note from Semtech):
The use of a spread spectrum modulation technique presents challenges in determining whether the channel is already in use by a signal that may be below the noise floor of the receiver. The use of the RSSI in this situation would clearly be impracticable. To this end, the channel activity detector is used to detect the presence of a LoRa preamble signal. The CAD behavior is similar to a standard preamble detection used widely with other RF modulations to detect if a message is being sent.
As the LoRa signal can be below the noise floor, there is a non negligible statistical probability that the LoRa CAD detector may trig on RF noise and thus create a false detection. To drastically reduce false detection while using the CAD, it is advised to perform a second CAD after a first valid CAD detected.
The process to perform a double CAD is described below:
Dual CAD state diagram
It is essential to clear the interrupts generated by the radio to ensure good operation of the process. Using this method, the ratio of false detection goes from 1% to virtually 0%.
That sounds okay if one wants to implement listen-before-talk. But if one wants to detect uplink or downlink data, wouldn’t one miss the actual data when doing another CAD rather than starting to listen for the data?
Hi all,
I have a single_chan_pkt_fwd on my RPi and reveiving meaasges from my arduino node but i don’t see the messages on TTN. I understood that the IP for croft.thethings.girovito.nl (54.72.145.119) is no longer valid so i tried:
Regards, Walter de Gier
Hey everyone,
How is it possible that my gateway is visible here:
https://staging.thethingsnetwork.org/gatewaystatus/ and active,
but in console it is not activated and it says that it has never been seen?
Any help, thanks!
The ESP8266 LoRaWanGateway can now be configured to only listen to a single spreading factor (SF) on a specific channel.
The gateway can listen for all SF’s on a channel, but at a cost: range. Because it depends on detecting incoming messages using RSSI, it only receives strong messages. The range of my LoRaWanGateway is several hundred meters.
The RFM95 lora chip used can do much better: in single SF mode the range of my LoRaWanGateway became several kilometers using SF12.
So now I run two gateways in my attic: one listening for all SF’s that I use for the development of OTAA nodes, and one that only listens on SF12 giving me the range I need to experiment with mobile nodes in the field.
Of course the LoRaWanGateway is still able to perform uplink messages in both modes.
The all SF gateway gives me the means to perform quick joins and reliable uplinks so that I can test my nodes quickly.
My initial goal of supporting listening on multiple channels seems not feasible: (a lot of) experimenting show that the SX1276 has not enough channel separation to make a channel hopping strategy work. Today I even successfully received a message on channel 1 that was sent on channel 0, a 200Khz frequency difference…
There is a new version of the ESP8266 LoRaWanGateway.
The gateway can now be configured using the LUA shell, no need to configure via the init.lua file anymore!
Another change is that you can configure the frequency and BW the gateway has to listen to. This simplifies configuration when using non-EU channels.
I’ve also added remote access to the gateway: using telnet you can monitor and configure your gateway via wifi.
mini LUA gateway
[x] generated firmware and flashed the ESP8266
[x] wire the thing
[ ]
You definately have to flash a more recent build of the firmware in order to run the gateway…
LOL… I flashed the wrong one, I made one online yesterday tnx 
I think D3 from the ESP is not used in the LUA gateway setup.
Is it possible to connect a LED there, that function as a ‘heartbeat’ the moment the GW is connected to TTN ?
And where to put it in the code ,so that it won’t interfere with the SPI timing, just blink short on the incoming TTN packet
gpio.mode (3,gpio.OUTPUT) // D3
.
.
gpio.write(3,gpio.HIGH)
.
gpio.write(3,gpio.LOW)
A good place to blink a led would be in LoRaWanGW.lua. Turn on the led when a message is sent to the router (for instance here ) The led can be turned off when an ACK is received from the router (for instance here ).
This will light up the led when a message is sent to the router and dim it when the ACK is received.
I’ve added the following, which I did not yet clean up for a pull request, as I still need to ensure the extra timer (with its very small interval) does not affect scanning and downlinks…
In Config.lua:
-- On NodeMcu:
-- pin 0 = built-in program flash LED
-- pin 4 = built-in ESP8266 WiFi LED
CONFIG["GW_NSS"]=3 -- default was 0; continuous blinking on NodeMcu
...
CONFIG["GW_LED"]=4
…and boldly in the top of LoRaWanGW.lua:
local LED_INTERVAL=50
local ledPort=CONFIG["GW_LED"]
local ledCounter=0
local ledTmr=nil
local function blink(count)
if ledTmr then
-- If some blink is currently being handled, (only) override
-- if the new blink count is larger, hence more important
if ledCounter < 2 * count then
ledCounter = 2 * count
-- will restart the timer if already started
ledTmr:start()
end
end
end
local function blinkStop()
ledCounter = 0
end
local function start_blinker()
if ledPort then
gpio.mode(ledPort, gpio.OUTPUT)
ledTmr=tmr.create()
ledTmr:alarm(LED_INTERVAL,tmr.ALARM_AUTO,function()
if ledCounter <= 0 then
gpio.write(ledPort,gpio.HIGH)
ledTmr:stop()
else
-- LOW = 0 = LED on
gpio.write(ledPort,ledCounter % 2)
ledCounter=ledCounter-1
end
end)
-- blink a lot while starting up:
blink(999)
end
end
start_blinker()
…and added blinkStop() here:
-- start gateway
wifi.sta.eventMonReg(wifi.STA_GOTIP, function()
...
-- all set up; stop the blinking:
blinkStop()
end)
end)
Finally, after sending the pulls I use blink(1), after the stats blink(2) and for rxpk blink(4). As pulls and stats occur at almost the same time, blinks with higher counts override the ones with lower counts, to still make it easy to see what’s going on.
(Changed after I got some nice feedback from Jaap. Of course, still a temporary hack.)
very nice… one multipurpose feedback LED 
I have just uploaded version 4 of the ESP single channel gateway. The code can be found on http://github.com/things4u
Documentation (first version) on http://things4u.github.io in hardware guide and developers guide
Maarten