-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why won't support for multiple channels work? #45
Comments
I did quite some experiments. The idea was to do frequency hopping over three channels. It turned out that changing the listening frequency on a SX1276 chip takes to long to reliable detect messages on all channels. I also tested this in C in order to make sure that that wasn't caused by some LUA overhead. Hopping over three channels resulted in quite some message loss, using only two channels worked better, but still missed some messages. The goal was to support 3 channels, because that would possibly qualify as a compliant lorawan gateway. A compliant lorawan gateway must support at least the three channels used for joining. I wanted to start the discussion to support 3 channel gateways in TTN. The network server should detect and support 3 channel gateways. In case of OTA and ADR, the network server should instruct a joining node to only use 3 channels. I would not have a strong case with only a not so reliable 2 channel gateway. pseudo code: |
Would it be possible to hook 3 SX1276 together and use the same logic?
…On 1 September 2018 7:17:00 pm AEST, Jaap Braam ***@***.***> wrote:
I did quite some experiments. The idea was to do frequency hopping over
three channels.
It turned out that changing the listening frequency on a SX1276 chip
takes to long to reliable detect messages on all channels. I also
tested this in C in order to make sure that that wasn't caused by some
LUA overhead.
Hopping over three channels resulted in quite some message loss, using
only two channels worked better, but still missed some messages.
The goal was to support 3 channels, because that would possibly qualify
as a compliant lorawan gateway. A compliant lorawan gateway must
support at least the three channels used for joining. I wanted to start
the discussion to support 3 channel gateways in TTN. The network server
should detect and support 3 channel gateways. In case of OTA and ADR,
the network server should instruct a joining node to only use 3
channels. I would not have a strong case with only a not so reliable 2
channel gateway.
pseudo code:
loop
if RSSI on channel
then receive message
else next channel
end loop
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#45 (comment)
|
Maybe that will work, but I think the LUA overhead will make it a difficult task. In this implementation it is already necessary to run the ESP8266 on the high clock frequency to make it work. In C and using an ESP32 I think it should be possible to hook 3 SX1276's together... |
@JaapBraam : Very interesting. I was wondering if you were trying to frequency-hop with a single SX1276. I suspected that wouldn't work due to exactly the reason you discovered (and because I figured it wouldn't be in Semtech's interest to make it work this way). @dmascord : This is essentially what Dragino did (although only two SX1276's): http://wiki.dragino.com/index.php?title=LG02 Going with 3 chips would potentially let you build a minimal EU-band LoRaWAN gateway, but at that point, you may be close to the BOM of a "full" gateway (I haven't done the math, so just a guess). But it still doesn't address other bands (US and AU, for example, have 8 "base" channels instead of 3). |
What is the advantage of supporting for receiving multiple SF's on a channel,can it solve the problem of signal collision? |
Nodes can choose what SF they send on, receiving on multiple SF's lets you receive more messages... |
You write in your goals "Add support for more than one channel (won't work :-( )". I'm curious as to why not and what your intended approach was.
The text was updated successfully, but these errors were encountered: