Thanks jbraam for the Lua code.
The node cannot receive messages. But it can send.
Has anyone tried the Lua code and had success on sending commands to node?
Have a nice day!
who sells the nice breadboard for the RN2483?
I created a bug in the transition from floating point NodeMCU firmware to the integer only version. Fixed now on github. I receive messages on my node again.
1 Like
My LUA Single Channel Gateway works quite reliable now.
I test it using an Arduino + RFM95w node running LMIC software.
Logging from the node:
Starting Packet queued 220: EV_JOINING 773994: EV_JOINED 844184: EV_TXCOMPLETE (includes waiting for RX windows) Data Received: Hi! Packet queued 2164428: EV_TXCOMPLETE (includes waiting for RX windows) Data Received: Hi! Packet queued 3843184: EV_TXCOMPLETE (includes waiting for RX windows) Packet queued 5163401: EV_TXCOMPLETE (includes waiting for RX windows) Data Received: Hi! Packet queued 6483653: EV_TXCOMPLETE (includes waiting for RX windows) Data Received: Hi!
1 Like
i cannot wait to test it!!!
Very nice to see downlinks working on a single channel gateway. Especially great for OTAA, I think. Not to spoil the fun: beware that TTN might some day limit the number of downlinks you can send to only 10 per day, per node (and that includes confirmed uplinks).
2 posts were merged into an existing topic: Limitations: data rate, packet size, 30 seconds/day Fair Access Policy, nodes per gateway
If anyone has functional single channel gateway code for North America, I’d sure appreciate it. I’ve had no luck yet -
https://www.thethingsnetwork.org/forum/t/arduino-uno-dragino-shield-v1-3-code/2647/12
After adding the geolocation of the gateway to my main.cpp, I do see the gateway here now:
http://ttnmapper.org/gateways/map.php?gwaddr=b827ebffff558b26
So the gateway did send out my geolocation.
However, cannot see anything here yet from my node.
https://www.thethingsnetwork.org/api/v0/nodes/6185FF1D/
So I must be doing something very silly wrong because the rest seems to be working. Any ideas?
If you’re using the staging environment (good), and are NOT using the default demo keys 2B7E151628AED2A6ABF7158809CF4F3C (also good), then you won’t see the packets in the old REST API. On staging, you’ll need to use MQTT instead.
Hi Charles,
I build and test your board. It’s working fine but i have one minor issue… The LED’s doesn’t work. I have to figure out what’s the problem.
Recently you released V1.1. What’s the difference? Any plans to add OLED support? That would be great.
me to yesterday 
at the moment working on oled
2 Likes
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 ?