Indeed, channel 0 (868.1 MHz), SF 7, like your gateway log shows you.
But your node’s log shows it’s transmitting on at least two channels. Given @matthijs’ comment when his example sets up the channels:
Without this, only three base channels from the LoRaWAN specification are used
…and apparently lacking anything similar in @platenspeler’s example, I assume his code relies on those “three base channels”? Assuming that includes channel 0 (868.1 MHz), for testing just add:
LMIC_disableChannel(1);
LMIC_disableChannel(2);
But still then, assuming the base channels include channel 0 (868.1 MHz), some of the node’s transmissions should already use that, and hence be visible in the gateway.
Note that many SX127x modules only expose a single antenna connector and then use the SX127x’s RXTX pin and an onboard switcher to wire that single antenna connector to either transmission or reception, hence not needing the LMIC rxtx to control anything. See also Matthijs’ excellent documentation (but note that LMIC_UNUSED_PIN is a recent addition, not yet merged into every clone of Matthijs’ repo).
Note that it’s platenspeler’s repo, not TTN’s. Minor detail.
@platenspeler
You said that DIO1 and DIO2 of the radio is not needed when setting up a gateway with the ESP module, freeing two pins on the module. The communication with the radio is done via SPI, which is a bus. Do you think we can add two more radio’s to the same bus, using the two free pins as chip-selects?
My thoughts are going in the direction of building a three channel, single datarate (single spreading factor) gateway, using three HopeRF RFM95w’s and one ESP8266. Do you think this will be possible?
I was first thinking in the same direction, however I think it will be a major change in the software to keep track of all extra administration. Not only the DIO0 but also the slave select line is in general duplicated for every slave on the bus.
Since the ESP8266 only costs $2.70 or so, the same functionality can be achieved at little extra cost by just having 2 or more single channel gateways work in parallel.
This does mean multiple IP addresses but apart from that it works quite well. (I have 3 now: 2 ESP and one Raspberry).
The ESP-based gateway is super nice, it would make for a very handy testing device. Could you add a HOWTO to the new wiki on the DIY gateway section? https://github.com/TheThingsNetwork/wiki/commits/rewrite (currently, the way to edit this new wiki is to send a pull request)
Just as an FYI - I’ve spent quite a bit of time trying to get those SX1276 modules working, with no joy. Today a couple of RFM95W’s arrive in the post and connecting them up in place of those other modules and it all works fine right away. Yay. Would be interested though if anyone else can manage to get those other modules working.
I guess you do this on the Raspberry based one? It does not have DNS support. You have to add the IP address of the new router. The ESP8266-based single channel gateway does correctly resolve hostnames.
By the way, I have done some coding for the Raspberry version that adds DNS support and some other features. But I think that @Thomas was also planning those functions.
I also have very good experience with the simple RFM95 modules. They do what you expect them to do. I found for example the “luxe” Australian InAir9 modules more difficult at times.
I guess I have to make a new version of the ESP8266 version on GitHub one of these days (the old name will still work over the next weeks). If you want to make the change yourself: Change the .h file and update the _TTNSERVER like this:
Dear all. Nice discussion over here. I gave my first try with @Thomas single_channel_gateway on RPi A+ board and RFM92. I have attached snapshot of my log file.
But I am not receiving any packets. Should I have a near by node device to receive the packets?. I am located at Chennai, India. And I dont have any data on my gateway, http://thethingsnetwork.org/api/v0/gateways/7cdd90ffff0375ee/
Yes, of course. The distance depends on many factors. And your gateway could also receive LoRa packets that are not using LoRaWAN or are using LoRaWAN keys not known to TTN, both of which would then not show in the API but would still show in your own logs.
So, as your logs shows nothing, it seems there are simply no nearby nodes sending at 868.1 MHz, using “virtual channel” SF7 (which is for the shortest distance). Are you sure 868.1 MHz is even the frequency you should use in your area (please discuss that there)? You also might want to get in touch with @Nat; see Chennai, India.
