His little brother … 
2 Likes
@PH3V
hey nice picture,
I’ve got some firmware with OLED support (on my RF69 gateway) that funny scroll between informative screen using this awesome library
If you are in a hurry check the OLED library demo here it very simple to implement and we added SH1106 support for 1.3" Oled
I will implement it first on my Wemos RN2483 node so you’ll have example but I’m sorry I have no release date for this (I’m working on 4 different firmware at the same time, quite complicated)
For LED you could check pin 1 of 1st led to see if it has 5V or 4.6V if you put D1 and cut trace. By the way, to light the LED you must use NeopixelBus library because it’s not “classic” LED but protocol driven LED.
On Version 1.1 I added footprint for Microchip 24AA02E64 64 bits serial number and restricted ground plane to avoid shorts sometimes on connectors pins, sorry just forgot to update the documentation.
I’ll try to do my best to release a working firmware with LED and OLED and try almost to post a video to show you all funky things we can do with 
1 Like
@PH3V
Waiting release for firmware node, I’ve published a sample sketch I use to test my boards, it’s simple and show you the OLED Use with RGB LED, OTA and I2C scan with ESP8266 (WeMos here)
Here the video sample with all features in action!
Sketch has it own repo
4 Likes
briiliant 
1 Like
I did read the topic, and yeah, i also did read that it “can’t replace a real gateway, and is for testing only”. So don’t kick me out please 
Having said that it looks to me that the thing could be very useful to cover uncovered corners in a developing network. I can’t recall where I read it but I think I saw someone who configured it to listen to all channels at the same time. Obviously that introduces collision risks but apart from that it sounds acceptable. Is it really feasible?
If you limit the expectations to a limited number of class a ABP nodes and connect a decent antenna, you’re close to a real gateway. I can imagine the result would be more satisfying when covering a city center with 2 real gateways an 10 single channels instead of 3 real gateways leaving a lot of poorly covered areas.
As I started this topic, the single channel gateway is great for testing, but it’s not fully LoRaWAN compliant. For that reason it’s fine to use it now on the staging server, but I think we should not allow these devices in the (soon to be launched) production environment.
You don’t really provide coverage with them, as they will not be able to properly support generic LoRaWAN devices (which are not aware of the type of gateway in their area) that use multiple frequencies and spreading factors. You would have to fix nodes on a single frequency and SF, which is not a good practice, and hard to get rid of later.
If we want to build a reliable and scalable Things Network we need to make sure all devices (nodes and gateways) fully support the LoRaWAN standard. Besides that, gateways are not that expensive. Let’s do it right from the start.
4 Likes
this is something my single channel gateway, listening on 868.100 picked up this afternoon 
Packet RSSI: -112 RSSI: -113 SNR: -12 Length: 61
rxpk update: {“rxpk”:[{“tmst”:445526776,“chan”:0,“rfch”:0,“freq”:868.099975,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:-12,“rssi”:-112,“size”:61,“data”:“tlJ+3kao1MjU3ol8kuTwhziot4L/wQGMXngnecZaq5dXGpqZFTHWkzg/Hea7Y4NEjZND1gARpWtPdwC1vQ==”}]}
I don’t understand that freq":868.099975 is it that my receiver is off freq 25 Hz ?
The frequency is converted from an integer value to a floating point frequency in Mhz. The lora chip cannot be configured listen on exactly 868.1Mhz.
1 Like
I agree that a Gateway should be as compliant as possible. I just made a pull request for your excellent single channel gateway. With a few small changes the gateway will not send hard coded “codr”:“4/5”, but instead will detect the used coding rate and set it accordingly. I hope you will accept my pull request
6 Likes
Hi guys,
Just to let you know I’ve released a new version of NodeMCU Lora board (V1.3), nothing fancy, just small improvements but could be usefull
- SMA/UFL Antenna connector has been size reduced
- Antenna trace and RF Module surrounded with via for better RF performance
- Increased “Isolate” ground planes to avoid shorts between connectors and ground (may happen sometimes after soldering)
- I2C OLED connector is now “lock” version, you can just plug to test it will fit without connector
- No more LED solder pad to choose VIN/3V3, added 1N4148 diode from 5V for the 1st LED to decrease VCC to 4.4V, always works
- added Microchip 64 bits Unique ID footprint 24AA02E64
- done a diode logic OR for DIO0/DIO1/DIO2 for current LIMC implementation
Schematics, pictures, board files on github repo and you can order boards PCB from PCBs.io
And for those fan of tiny boards, the new WeMos version with same features except connecting stuff)
Have fun
3 Likes
I’ve managed to use your code and get a RPi1B up and (almost) running.
I can see status updates every 30 second (so it found my RFM95W. But I don’t see any data. All counters remain 0.
“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0
I can find my gateway going to: https://www.thethingsnetwork.org/api/v0/gateways/
I can even find my gateway on the ttn map (I entered the correct lattitude and longitude in main.cpp).
The Gateway is listening to 868.1
// Set center frequency
uint32_t freq = 868100000; // in Mhz! (868.1)
My node (a Nexus running the LoRaWan v3.1 sketch from Ideetron) gets its payload to staging, but I’m not sure it’s using my gateway.
01 23:58:34 32 -121 868.10000
So it is using 868.1
What can I do to make this work?
I have a prototype of the Lua Single channel gateway that can receive all SF’s on a frequency!
I have a OTTA node configured to use SF9 after joining and my gateway receives the OTTA request in SF7 as well as the messages in SF9!
The strategy I used to make this work is to first detect a signal on the channel frequency using RSSI detection in the FSK mode of the SX1276.
When a signal is detected, CAD is used to detect a SF7 preamble. If a preamble is detected the message is received using the RX_SINGLE mode of the SX1276.
If a preamble is not detected on SF7, CAD is used to detect a SF8 preamble.
This is repeated for all spreading factors.
This works because the preamble always uses 8 symbols, and the length of a symbol is dependent on the spreading factor. The next SF’s symbol length is twice the length of the previous length.
Detecting a signal using CAD takes less than two symbols. So when a SF7 CAD returns, two symbols of the preamble are ‘used’, leaving 6 more to synchronize the reading of the message. When SF7 CAD does not detect a preamble, two SF7 symbols are gone which acounts for ONE SF8 symbol. So there are 7 preamble symbols available to detect a SF8 signal.
For a SF9 signal there will be 8-(1+0.5) = 6.5 symbols available
For a SF10 signal there will be 8-(1+0.5+0.25) = 6.25 symbols available
For a SF11 signal there will be 8-(1+0.5+0.25+0.125) = 6.125 symbols available
For a SF12 signal there will be 8-(1+0.5+0.25+0.125+0.0625) = 6.0625 symbols available.
So there are always enough preamble symbols left to try to detect a higher SF signal, if the lower SF detection fails.
In order to make this work it is important to detect the presence of a signal on the channel as soon as possible, the RSSI detection in FSK mode can be used to do that.
A drawback of this approach is that the range of this gateway will be less of that of a ‘real’ gateway; it can only receive messages that can be detected by RSSI.
I will publish my code after I tidied it up…
Logging of the gateway:
rxpk 012f560018fe34ffffde9937 message {“rxpk”:[{“rssi”:-30,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:18308070,“datr”:“SF7BW125”,“lsnr”:-55,“time”:“2016-08-08T00:32:11.068090Z”,“codr”:“4/5”,“data”:“AB4FANB+1bNwAQAAAAAAAACRlKq0Wxw=”,“freq”:868.099975,“chan”:0,“size”:23}]} length 241
txpk {“txpk”:{“codr”:“4/5”,“data”:“IN5EWks8Z7xtvGOJ0VSIwBEe2eyYuRgqliFvfqs7AG+b”,“freq”:868.1,“ipol”:true,“modu”:“LORA”,“powe”:14,“rfch”:0,“size”:33,“tmst”:23308070,“datr”:“SF7BW125”}}
txpk_ack {“txpk_ack”:{“error”:“NONE”}}
rxpk 0192bb0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-31,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:23565219,“datr”:“SF9BW125”,“lsnr”:-54,“time”:“2016-08-08T00:32:16.325123Z”,“codr”:“4/5”,“data”:“QKIozxyAAAAB0GqbYA==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 229
rxpk 011c2d0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-30,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:49674595,“datr”:“SF9BW125”,“lsnr”:-53,“time”:“2016-08-08T00:32:42.434631Z”,“codr”:“4/5”,“data”:“QKIozxyAAQAB6hF2qg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 229
rxpk 013e410018fe34ffffde9937 message {“rxpk”:[{“rssi”:-30,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:76115004,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:33:08.875066Z”,“codr”:“4/5”,“data”:“QKIozxyAAgABXhBICg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 229
rxpk 01503f0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-29,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:102934195,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:33:35.694263Z”,“codr”:“4/5”,“data”:“QKIozxyAAwABdeY8IA==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 01d5cf0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-30,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:128162079,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:34:00.922157Z”,“codr”:“4/5”,“data”:“QKIozxyABAABCaL+Tg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 0157210018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:154106470,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:34:26.866515Z”,“codr”:“4/5”,“data”:“QKIozxyABQABWFvHlg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 0128e90018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:180873907,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:34:53.633930Z”,“codr”:“4/5”,“data”:“QKIozxyABgABw0KZwg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 0126df0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:206762780,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:35:19.522842Z”,“codr”:“4/5”,“data”:“QKIozxyABwABjJwTTQ==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 01b0910018fe34ffffde9937 message {“rxpk”:[{“rssi”:-29,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:233323162,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:35:46.083213Z”,“codr”:“4/5”,“data”:“QKIozxyACAABKEsjvQ==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 01538e0018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:258992621,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:36:11.752688Z”,“codr”:“4/5”,“data”:“QKIozxyACQABR8Lzwg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
rxpk 0169730018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:284625055,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:36:37.385133Z”,“codr”:“4/5”,“data”:“QKIozxyACgABoWiDwQ==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
ntp synced using 213.239.154.12
rxpk 01b5b70018fe34ffffde9937 message {“rxpk”:[{“rssi”:-28,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:310634200,“datr”:“SF9BW125”,“lsnr”:-51,“time”:“2016-08-08T00:37:03.394192Z”,“codr”:“4/5”,“data”:“QKIozxyACwABnACQGg==”,“freq”:868.099975,“chan”:0,“size”:13}]} length 230
The logging shows the JOIN request (SF7), the JOIN response (txpk) and the messages received after joining (SF9)
6 Likes
wow ! great work … (and many hours I think)
It looks like the detection of all SF’s on a channel works quite well!
So now the LUA single channel gateway supports:
- Receive messages using all spreading factors on one channel
- Send messages to nodes
- OTTA nodes
The new LUA single channel gateway software can be cloned from https://github.com/JaapBraam/LoRaWanGateway . Please report your findings if you do so…
Next thing to do is to support more than one channel. The strategy will be to check for a transmission on a channel using RSSI. If no activity is detected, hop to the next channel and try again. If activity is detected start the SF detection mechanism and receive the message.
If the channel hopping turns out to be fast enough, more than one channel can be used to receive messages! (But only one at a time…)
2 Likes
Thart sounds good! My compliments
I’m making the original IDE version capable of 2-way traffic also. The prototype is working OK.
Somebody knows an easy way to tell an OTAA node (TeensyLC based) not to use any other channels or SF settings than the DR-SF7 (or DR-SF9) we are using for the single channel gateway?
At this moment it starts OK, but if the JOIN is not successful next attempts will be on SF8-SF12 and on other frequencies as well.
The ABP nodes stick to the requested channel fortunately.
Thanks,
Maarten
1 Like
Version 2 of the Sigle Channel gateway for the ESP8266 is now on github: 1ch Gateway 2.0
It works with TeensyLC and Arduino Pro-Mini nodes and has new features:
- OTAA support and Downstream for SF7 and SF8
- Possibility to have several WiFi access points configured.
- Communication with two (UDP) backend servers
- Enhancements to the webserver (on port 8080)
- Bug fixes
There are several Pro-Mini versions on the market, some are 8MHz versions while others even are 16MHz. Not all versions work with OTAA and downstream functions which is probably due to timing issues of the Arduino itself. You will have to check for yourself if your Pro-Mini works. I had best results with the standard 8MHz/3.3V type with the big Chrystal close to the reset button.
Maarten
5 Likes
Good idea to cycle the CAD detection of all SF in the same order of CAD/symbol duration.
Why change to FSK? in LORA modulation you can also read RSSI values, even during CAD.
http://www.semtech.com/forum/images/datasheet/an1200.21_std.pdf