LoPy as LoRaWAN Basestation?

[bmarkus]

@daniel said in LoPy as LoRaWAN Basestation?:

Dear all,

I am not able to offer a time frame for the LoRaWAN nano-gateway example and the documentation, as we are still working on the implementation. The example Roberto posted is for a raw LoRa nano-gateway.

The way the LoRaWAN nano-gateway works requires the node to only transmit on one channel, for this the LoRa stack needs to be modified a bit to make the 3 default channels the same and remove the rest. There's going to be a third mode on the LoRa class called NANO_GW. At first only joining via ABP will be supported on the nano-gateway so there will be a method to add the node and its keys.

Cheers,
Daniel

Daniel,

that's fine. But please, do not call it LoRaWAN gateway to avoid misunderstandings, there are too much already. It will not compatible with standard LoRaWAN devices (nodes).

Béla

[bmarkus]

@daniel said in LoPy as LoRaWAN Basestation?:

At first only joining via ABP will be supported on the nano-gateway so there will be a method to add the node and its keys.

Daniel, can you make a clarification what is the functionality of the nano gateway?

In the LoRaWAN terminology a gateway is a device which forwards packets received by the radio board and sends them to a network server without evaluating them, just checking sync byte, 0x34 for public networks and CRC and transmitting packets from the network server to the air. By default a GW is is using the Semtech Packet Forwarder UDP protocol to communicate to network server.

ABP has nothing to do with GW, it is a higher network server layer. When you say nano gateway, it is a gateway which can be connected to a network server of a service provider like Loriot or TTN or/and it has a built in network server?

[daniel]

that's fine. But please, do not call it LoRaWAN gateway

I just called it that way here to explain the difference with the raw-LoRa one. During the KS campaign we said it was not going to be LoRaWAN compatible and we made it clear that it was going to have the single channel limitation.

[daniel]

@bmarkus

In the LoRaWAN terminology a gateway is a device which forwards packets received by the radio board and sends them to a network server without evaluating them, just checking sync byte, 0x34 for public networks and CRC and transmitting packets from the network server to the air. By default a GW is is using the Semtech Packet Forwarder UDP protocol to communicate to network server.

Yes, that's how it will work. With ABP I meant that we won't be supporting OTAA joins (this involved replying with the join accept and handling the proper timing). Sorry for the confusion.

When you say nano gateway, it is a gateway which can be connected to a network server of a service provider like Loriot or TTN or/and it has a built in network server?

As a first stage it will just be an UDP packet forwarder, but the ultimate goal is to provide a small built-in network server as well in order to connect to TTN.

[beyonlo]

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

I'm insterest too to do a very large network using LoRa (in this case LoPy), as gateway and client. So, I need to know if LoPy can be works as a complete LoRa gateway for others LoPy (as clients) and if are there some restriction. And, how many LoPy clients one LoPy gateway support.

Thanks.

If you want to deploy a very large LoRa network, use LoRaWAN compatible gateways equipped with SX130x chips. You can get an indoor GW for cca. 200 EUR. LoPy is not soutable for LoRaWAN compatible GW.

All right. Now I understand that LoPy is not possible to works as LoRaWAN GW. It is a chip limitation.
What means indoor GW, what is difference to the outdoor GW? Why I can't to use a indoor GW as outdoor GW? Just because the indoor is not rain proof, or what?

Also for end devices LoPy in its current state doesn't work. Use a proven, certified module using e.g. RN2483 or similar.

I like so much of LoPy as device because I can write software in Python.

Actually LoPy is not a matured solution. Hope it will be but it will take 6 mionths or so if ever will get documentation and a working LoRaWAN stack as I see.

But what is the problem with LoPy as device? The chip is not capable (there are limitations) to be a real LoRaWAN device, like as GW? Or the chip is fine to works as a real/compatible LoRaWAN device, but just software/firmware from Daniel is still missing features?

Thank you.

[beyonlo]

@borjam said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

I'm insterest too to do a very large network using LoRa (in this case LoPy), as gateway and client. So, I need to know if LoPy can be works as a complete LoRa gateway for others LoPy (as clients) and if are there some restriction. And, how many LoPy clients one LoPy gateway support.

The problem is: LoRaWAN uses several channels and different coding rates which, crudely said, trade speed for range.

LoRaWAN nodes, when transmitting, must chose a channel at random (there are several of them). This makes it easier for different users to share the spectrum.

So, in order to build a real LoRaWAN gateway you need a receiver capable of listening to several channels simultaneously and decoding several coding schemes rather than being fixed on one.

The LoRa subsystem you need to to this is far more complex than the "node" oriented chip present in the LoPy (and other LoRa devices) which is configured for one channel and one coding rate. That's the reason why LoRaWAN gateways are much more expensive than end nodes with an average price of around 500 euro.

That said, you can still do LoRa, which means using the interesting transmission methods employed in LoRaWAN, but just not the whole protocol stack.

The number of devices you can support will depend on how often your nodes communicate with the nano gateway, how much data they send of course, and your coding rate which will depend on your intended range.

All right, I will need a real LoRaWAN gateway, that LoPy can't to do that because the chip limitation.

1. So, my idea for now is to use LoPy as gateway just for other LoPy devices. And when I have many LoPy devices that LoPy not support more, I will to buy one real LoRaWAN gateway and change all LoPy devices to connect to the new 200/500 euro LoRaWAN gateway. That's is fine?

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

[bmarkus]

@beyonlo said in LoPy as LoRaWAN Basestation?:

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

No way.

Project 1: It is not for LoRaWAN even not for an 8-channel professional GW. LoRaWAN is not for 100KB data transmission, it is for sensor network sending low volume data in most cases in one direction w/o confirmation much less frequently..

Propject 2: Channel usage, transmit duty cycle is limited to 1.0/0.1% depending on channel.

I kindly advice to read basic documents and FAQ on LoRaWAN and redesign your projects. You need something else than LoRaWAN. It is not about LoPy.

[beyonlo]

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

No way.

Project 1: It is not for LoRaWAN even not for an 8-channel professional GW. LoRaWAN is not for 100KB data transmission, it is for sensor network sending low volume data in most cases in one direction w/o confirmation much less frequently..

Propject 2: Channel usage, transmit duty cycle is limited to 1.0/0.1% depending on channel.

I kindly advice to read basic documents and FAQ on LoRaWAN and redesign your projects. You need something else than LoRaWAN. It is not about LoPy.

Hello.

Sorry for my ignorance, but yes, I already read about the Technology (data rate specifically), from here https://www.lora-alliance.org/what-is-lora/technology and say : "LoRaWAN data rates range from 0.3 kbps to 50 kbps. "

Yes, I know that 50 kbps is a theory and/or with a perfect environment. But if I have just ~5kbps, is fine for Project1, Project2 and Project3, see?

Thank you.

[bmarkus]

@beyonlo said in LoPy as LoRaWAN Basestation?:

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

No way.

Project 1: It is not for LoRaWAN even not for an 8-channel professional GW. LoRaWAN is not for 100KB data transmission, it is for sensor network sending low volume data in most cases in one direction w/o confirmation much less frequently..

Propject 2: Channel usage, transmit duty cycle is limited to 1.0/0.1% depending on channel.

I kindly advice to read basic documents and FAQ on LoRaWAN and redesign your projects. You need something else than LoRaWAN. It is not about LoPy.

Hello.

Sorry for my ignorance, but yes, I already read about the Technology (data rate specifically), from here https://www.lora-alliance.org/what-is-lora/technology and say : "LoRaWAN data rates range from 0.3 kbps to 50 kbps. "

Yes, I know that 50 kbps is a theory and/or with a perfect environment. But if I have just ~5kbps, is fine for Project1, Project2 and Project3, see?

Thank you.

GW's support SF7-SF12 which means cca. 5kbps max. But do not design for SF7. Really, what you want is not a LoRaWAN use case. I can't tell you more.

[beyonlo]

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

No way.

Project 1: It is not for LoRaWAN even not for an 8-channel professional GW. LoRaWAN is not for 100KB data transmission, it is for sensor network sending low volume data in most cases in one direction w/o confirmation much less frequently..

Propject 2: Channel usage, transmit duty cycle is limited to 1.0/0.1% depending on channel.

I kindly advice to read basic documents and FAQ on LoRaWAN and redesign your projects. You need something else than LoRaWAN. It is not about LoPy.

Hello.

Sorry for my ignorance, but yes, I already read about the Technology (data rate specifically), from here https://www.lora-alliance.org/what-is-lora/technology and say : "LoRaWAN data rates range from 0.3 kbps to 50 kbps. "

Yes, I know that 50 kbps is a theory and/or with a perfect environment. But if I have just ~5kbps, is fine for Project1, Project2 and Project3, see?

Thank you.

GW's support SF7-SF12 which means cca. 5kbps max. But do not design for SF7. Really, what you want is not a LoRaWAN use case. I can't tell you more.

All right. So, please, going to the point: "how many LoPy devices can one LoPy (as gateway) to support?"

A real and valid scenario (project): send 100 bytes each 10 minutes.

Thank you.

[beyonlo]

@beyonlo said in LoPy as LoRaWAN Basestation?:

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

@bmarkus said in LoPy as LoRaWAN Basestation?:

@beyonlo said in LoPy as LoRaWAN Basestation?:

2. But for start in this way, I still would like to know how many LoPy devices can one LoPy (as gateway) to support?
   Project 1: The idea is that each LoPy device send 100KB each 5-10 minutes.
   Project 2: The idea is that each LoPy device send ~20bytes each second.
   Project 3: The idea is that each LoPy device send 100KB each day.

Thank you.

No way.

Project 1: It is not for LoRaWAN even not for an 8-channel professional GW. LoRaWAN is not for 100KB data transmission, it is for sensor network sending low volume data in most cases in one direction w/o confirmation much less frequently..

Propject 2: Channel usage, transmit duty cycle is limited to 1.0/0.1% depending on channel.

I kindly advice to read basic documents and FAQ on LoRaWAN and redesign your projects. You need something else than LoRaWAN. It is not about LoPy.

Hello.

Sorry for my ignorance, but yes, I already read about the Technology (data rate specifically), from here https://www.lora-alliance.org/what-is-lora/technology and say : "LoRaWAN data rates range from 0.3 kbps to 50 kbps. "

Yes, I know that 50 kbps is a theory and/or with a perfect environment. But if I have just ~5kbps, is fine for Project1, Project2 and Project3, see?

Thank you.

GW's support SF7-SF12 which means cca. 5kbps max. But do not design for SF7. Really, what you want is not a LoRaWAN use case. I can't tell you more.

All right. So, please, going to the point: "how many LoPy devices can one LoPy (as gateway) to support?"

A real and valid scenario (project): send 100 bytes each 10 minutes.

Thank you.

From: https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300

"
Fair Access Policy: Practice

• Golden rule: 30 seconds air-time per device per day
• For 10 bytes of payload, this translates in (approx.):
  20 messages per day at SF12
  500 messages per day at SF7
  more for SF7BW250 and FSK (local-area)
• If your application requires more bandwidth, think of another solution
• This allows for >1000 nodes per gateway
• Downlink bandwidth is even more restricted
  you can’t send all messages as ‘confirmed uplink
  "

[Batilan]

@beyonlo said in LoPy as LoRaWAN Basestation?:

From: https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300

Note that although LoPy and TTN are "a match made in heaven" they are not actually maried :-)

You should however always take into account local duty cycle regulations, in EU typically max 1% (14 minutes per day), see also this document (in Dutch).

In general the more airtime you will be using per node the less nodes you can support. But note that a gateway can receive multiple LoRa encoded packets simultaneously because it can decode multiple channels at the same time, but also multiple spreading factors within a single channel.

See also:

• Spreadsheet for Lora Airtime calculation
• Lorawan limitations
• Scalability of LoRaWAN

[livius]

I am really curious who and how can check this 1% ;-)
Ok if i talking with some provider yes, but if my devices talking each other i suppose that this regulation is virtual i am right?

[bmarkus]

@livius said in LoPy as LoRaWAN Basestation?:

I am really curious who and how can check this 1% ;-)
Ok if i talking with some provider yes, but if my devices talking each other i suppose that this regulation is virtual i am right?

You are using a license free frequency which is shared between users. 1.0% limitation is imposed to keep it usable for others. Be fair using it.

In a LoRaWAN network devices do not talk to each other but devices talk to base stations (gw) and rarely base stations to devices, but limitation is valid for base stations too.

Device modules, like RN2483 do check it and reject transmission exceeding the limit. Well, you can change the limit in the configuration.

Limitation is not for the LoRaWAN usage but for the free ISM band and is not virtual. Or as virtual as the red light on the road. Check the frequency regulations in your country.

[livius]

@bmarkus
You know how it is - if something is only prohibited and no one checks. I am confident that users will use it in excess. This is the same as for parking. If one would not controlled despite the paid parking zones one would not pay for it ;-)

One more sample:
In my country one operator prohibit use of LTE(normal LTE) to talking without person. You know person is only autorized no device to device talking. This is for me really virtual regulation ;-)

[bmarkus]

@livius said in LoPy as LoRaWAN Basestation?:

@bmarkus
You know how it is - if something is only prohibited and no one checks. I am confident that users will use it in excess. This is the same as for parking. If one would not controlled despite the paid parking zones one would not pay for it ;-)

Why don't you buy a jammer and connect to a roof antenna?

[livius]

@bmarkus

you meant something like this? :)

[livius]

And sorry for spamming
but is this 1% for one device or for one "virtual user"?
You know i have 100 devices and use summary 100% of bandwidth

[bmarkus]

@livius said in LoPy as LoRaWAN Basestation?:

And sorry for spamming
but is this 1% for one device or for one "virtual user"?
You know i have 100 devices and use summary 100% of bandwidth

1% is for one device and one channel. So yes, 100 devices on a single channel use 100% of the channel. If you have 8 channels, situation is better, you need 800 devices to fully load it.

However there are channels with only 0.1% allowed duty rate. Check your regulations. In which country you are?

[livius]

Thank you for the info.

country - Poland - we have really early setup and regulations are only from providers
maybe i am wrong then someone can correct me