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.
10 Likes
Very nice, Great Job 
Sure, I will be honored.
Sweet!
@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.
Thanks.
@vseta that would depend on how you set up your nodes. If each node had a RTC and scheduled xmits when it was clear to do so then yes. Being a single channel and single SF you would have to manage when nodes xmitted or if relying on unsynchronized xmits and random numbers you will be seeing collisions( more than 1 node xmitting at the same time).
Why not build or buy a real gateway?
If your nodes will be close to the single channel gateway( a couple of hundred meters) then you could try the Lua based single channel gateway which does multiple Spread Factors too.
Thanks Douglarue for feedback.
I was trying to understand if multiple nodes near a single channel gateway would require timing synchronization?
As single channel gateway works only with one node at a time.
Does the Raspberry Pi hack with PCIe Multitech gateway work or just spend $600 and buy the whole thing. I haven’t read many good things about Multitech from low range (could be antenna impedance matching) to over heating LoRA gateway PCIe card. Not many options for 915Mhz North America. Kerlink is very expensive ~$3,000
you still have to obey FCC rules on how much time your nodes are transmitting. ie they can NOT stream data and infact have to obey a 1% rule as in if they xmit for 1 second then they have to off air for 99 seconds. Theoretically, if you had 100 nodes and each was assigned a sequential number of seconds to wait before xmitting then you could get 100 nodes on a single gateway without much packet loss.
As for a full up gateway goes, the MultiTech MTAC with a rPi/Odroid/etc does work but it requires a heatsink and probably a fan to keep the wasted heat down. Two linear regulators dropping 5V to 3.3V and 1.6V dump/waste lots of heat and it gets very hot without cooling.
I just ordered a board from RisingHF( the RHF0M301V1A-920 ) and should get it in a week or so. MultiTech uses a USB to SPI interface to get the miniPCIe format and that is going away so I was told about a SPI based board which has the 915MHz option. So there are 2 options for the US market for DIY and both are in the $140-$170 range for the radio and <$50 for the gateway controller(rPi/ODroid/OrangePi/etc).
My Single Channel Gateway received a message once sent from more than 30km away… There was perfect line of sight: the node sent it’s message from a balloon…
…true, but just to be sure: a full blown gateway can also only handle a single node per channel and spreading factor. True, unlike a single channel gateway, a full blown gateway can handle multiple simultaneous nodes that use different channels, or use different spreading factors on the same channel. But if multiple nodes use the same settings at the same time, then collisions will occur and data will be lost.
(That’s why it’s important that nodes follow the LoRaWAN specifications to change channels for each transmission.)
@JBraam, I thought you’d said your multi-SF(Lua) version had degraded performance so you keep it for testing locally and have a single channel/single SF for the long haul. Are you saying differently here?
BTW, I just bought a Yaggi for doing long range balloon tests. What antenna(s) did you use?
Fundamentally the multi-SF version is less sensitive because it is only aware of signals above the noise level. It uses RSSI measurements to detect the presence of a signal. A full blown gateway can also detect weaker signals that are below the noise level. When running the gateway in a single SF mode it is just as sensitive as a full blown gateway…
The few hundred meters range that I reported for the multi-SF mode is based on my measurements in my situation. My gateway is situated in the attic of my house, about 7 meter above the ground, The antenna is a homebuilt J-type antenna described on this forum. I live in an area with a high density of houses and trees. My antenna isn’t on a pole and isn’t above any rooftop in my area. So there is hardly any line-of-sight.
In other circumstances like when mounting a better antenna on a large pole in a rural area I would expect the range to be much better, but a full blown gateway will always have better range…
On the other hand, I’ve read about a guy that had troubles getting more than 600m range with his full-blown gateway in a dense city area, so talking about range is not an exact science…
2 Likes
Hello everyone !
The single channel gateway can use with 433MHZ band ? And if I want to upload data to FireBase , what should I do ? .
Great work 
can you explain more the wirings (pin assignment) between raspberry and the lora module
Hello to all,
First, I would like to congratulate everyone on their job. And thank you to all the more advanced people who work on the project and support this community. Really an amazing job!
I currently live in Singapore and I’m working on my master thesis which I’ll do about IoT-LoRa implementation. I have started with this single channel gateway version as a first prototype, since the hardware for the full gateway is a little bit expensive for me. My setup is the following:
Raspberry Pi with inAir9b and the code available at the beginning of this thread
Arduino MEGA2560 with inAir9b and the Arduino-LMIC library code from matthijs.
TTN server. (ABP)
They seem to communicate properly as I can see in the ttn console that the gateway receives frames sent by the node as well as in the stat update. However, the server drops those packets and don’t get to the application (and you see that the node is “never seen” and it took me a while to realize that it was because the device address received at the gateway side (and then forwarded to the server) is not the same as the one sent by the node. I printed both device addresses, one before exiting the node on the radio side and the other on the gateway side, and I found that they are different. I followed this How can I tell which nodes are connected to my gateway to check for the device addresses. I don’t know why this is. Also, I cannot see if the payload is correct because it is encrypted. This was with the 868MHz frequency band. If I change to 915MHz it doesn’t even work. Should I change the gateway code to the center frequency or the one for the first channel?
I then changed the gateway to one based on Lua and ESP8266 which has been developed by Jaap Braam, and everything is working now. So I’m guessing that there is something wrong with Rpi gateway. I don’t know if it can be the wiring (although I had a problem like that before and the error was a version assertion) or something on the radio part of the code. However, I guess it is working for everybody else so… 
And to make use of the post (sorry it’s too long) here are a couple of questions:
-
If a node sends a confirmed data up and doesn’t get an ack, does it resend the same packet or that case has to be handled on a higher level?
-
Can it be send some command with the ack, as part of the body of the ack? As long it’s short enough to send in the Rx windows. In order to not need a class B end-device.
-
Last, in the Arduino-LMIC code/part, it seems I can only send unconfirmed data up. How can I make it confirmed so that I get an ack back?
Finally, if there’s anybody in Singapore that would like to meet, it would be great!
Sorry in advance for my misunderstanding concepts or inaccurate language or naming. If there is anything I can do to clarify please tell me.
Thank you all!
Asier
1 Like
- It could also be that there is no (working) gateway in range of the node
( keep in mind that you can only send a very limited number of downlink messages per day)
there are some TTN’ers active in Singapore
I understand. So the node doesn’t send again and again the confirmed packet if it doesn’t get an ack right? Because it could be doing that forever in that case.
Thanks!
Hi mate,
can you give me some clarity on the connections you’re using on the InAir9B?
SX1272 - Raspberry
3.3V - 3.3V (header pin #1)
GND - GND (pin #6)
MISO - MISO (pin #21)
MOSI - MOSI (pin #19)
SCK - CLK (pin #23)
NSS - GPIO6 (pin #22) What is NSS called on your InAir9B? Is that the ‘CS’ pin next to the 0V and should that be #24 instead of 22?
DIO0 - GPIO7 (pin #7)
RST - GPIO0 (pin #11)
Thanks in advance.