it is possible to set LoPY to work as a LoRaWAN basestation?

In the documentation I can read about using LoPy as a end-device, but not as basestation

thanks

Màrius

I also got the Sodaq One on Kickstarter which is a LoRa based GPS tracker. I was hoping to use the LoPy as a Gateway to implement real time GPS tracking around our local Golf course.

We will provide the Python library needed to make the LoPy operate as a nano gateway and let you run your own private (or not, share it with your friends!) network.

We will supply more information about how to get the LoPy working as a nano gateway before the shipments in August 2016.

To be fair this was the main reason I wanted the Lopy:

I agree with you, using LoPy as a Nano Gateway as my main reason too.

So any news on that?

it is possible to set LoPY to work as a LoRaWAN basestation?

Yes, it s possible, but as being a nano-gateway the LoPy can only listen on 1 channel at a time, so there are some constraints. We already had this working with the LoPy beta prototypes and was used as a proof of concept by one of the beta testers.

We first want to sort out all the issues around basic LoRaWAN and the firmware updates. Then we'll provide the API and the examples for the nano-gateway.

Thank you for your patience and support.

Cheers,
Daniel

Devices like LoPy and others are usign the Semtech SX127x modems while gateways SX13xx. SX127x can detect only one signal at the same time with one fixed spreading factor, while SX13xx detect several signals at the same time with different SF. Additionally, RF performance is different.

It means, that you can't build a LoRaWAN standard compliant gateway with SX127x devices. Also you may not be able to configure a LoRaWAN compliant device's LoRaWAN stack to use single frequency,

Of course you can build a LoRa network with SX127x only hacking protocol and accepting poor RF and capacity performance, but it is not LoRaWAN anymore.

@bmarkus I'm aware of this limitaitons, but using a SX127X can still make a simple usable basestation.

Thank you all!

Yes, it s possible, but as being a nano-gateway the LoPy can only listen on 1 channel at a time, so there are some constraints.

What means "can only listen on 1 channel at the time"? and what are the "constraints"?

Thank you.

Hello.

Yes, it s possible, but as being a nano-gateway the LoPy can only listen on 1 channel at a time, so there are some constraints.

What means "can only listen on 1 channel at the time"? and what are the "constraints"?

Thank you.

Anyone?

and may be some other things i missed :)

*) it will not be able to function as a gateway for TheThingsNetwork
*) you need a fair amount of software to handle the tasks that TTN normally does for you (OTAA registration etc)
*) it will be able to handle less nodes as it only has 1 frequency instead of 8

and may be some other things i missed :)

But my main reason to get the LoPy is just to be a gateway - a gateway for TheThingsNetwork. Apart client mode, my intention with LoPy is a full LoRa gateway. I would like to construct a large, very large LoRa network to offer the LoRa network service for all, in many cities and states, and after in all the country. I'm so sad. :(

"
And what if you could build your own LoRa network?
Here is the clever part, you can use the module to switch a comms signal from WiFi to LoRa (and vice versa) thus making the LoPy both a LoRa Receiver / Transmitter and a Nano gateway capable of handling comms with up to 100 other LoRa nodes!
"

We first want to sort out all the issues around basic LoRaWAN and the firmware updates

Hey Daniel - could you share the timeline for when the API will be ready for the nano-gateway?

Kind regards
Kevin

@daniel Same question here. What's the time frame for nano-gateway documentation?
Roberto posted some demo code, but that's far from complete. Does Pycom plan to support the 100-node, 22km nano gateway featured in the KS?
Thanks!

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.

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.

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

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.

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.

A TELCO grade outdoor GW is costing cca. 1,000 EUR. Good news is that cheap professional indoor gateways are coming to the market in 2017Q1 thanks to the new Semtech SX1308 chip, you can expect them around 250-300 EUR.

Another solution to get a LoRaWAN concentrator board e.g. from IMST for cca. 150 EUR and connect it to a Raspberry Pi. It is just a board, so I would wait for the new indoor generation.

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

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

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?

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.

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 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 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.