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?
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 (184.108.40.206) is no longer valid so i tried:
- router.eu.staging.thethings.network (220.127.116.11) and
- router.eu.thethings.network (18.104.22.168) and see the pakket going out with wireshark to the router.
I see my gateway on https://staging.thethingsnetwork.org/gatewaystatus/
B827EBFFFFF7F30A offline N/A 6 minutes ago
However i am not able to check the data on TTN since https://www.thethingsnetwork.org/api/v0/gateways/B827EBFFFFF7F30A/ is not working anymore?
Any help is very much appreciated!
Please be aware i am a newby so have mercy on me
Regards, Walter de Gier
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
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…
-- 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
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()
-- 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
- Support for CAD (so multiple SF supported)
- Fully configurable over the Webserver interface
- History data and statistics (SF7-SF12).
- Bug fixes
- Works with Hallard and ComResult PCB’s
- etc etc.
Documentation (first version) on http://things4u.github.io in hardware guide and developers guide
For inspiration, my turn on single-channel-gateway physical appearance. Hardware-wise, inside wemos-d2-mini with oled 128x64, RFM95, PLA enclosure designed with Tinkercad.
Very nice, Great Job
Looks very clean, do you mind if I (or you) would add it to the TTN Media Bank ?
Sure, I will be honored.
@mw12554, have you done any range testing with the CAD enabled v4 codebase? There’s a CAD enabled Multi-SF gateway version done in Lua and the range is greatly reduced in the CAD mode. Author states a few hundred meters vs kilometers.
Hello from Toronto, Canada.
Excellent work on Single Channel Gateway.
Can this solution work for transferring sensor data from 50+ nodes to internet? Only uplink data. Or will node data get lost? I tried reading all the comments, but could have missed something in latest development.