Ways of doing things.

[kjm]

I've deployed a few GPYs. The lte capability is great in that the only thing between the device & my server it the lte network but the cost of sim cards starts to add up with more GPYs.

I stated to think about raw lora. Raw lora allows small packets & is pretty easy to get working reliably (unlike my experience with lorawan & the TTN which was a bloody nightmare). A bunch of lopy4s could raw lora link to a fipy that uploads all their data to the server. I was thinking about how to synchronise all the lopy4 RTCs from the fipy (so I could have each lopy4 sending in it's own time slot) when I saw https://forum.pycom.io/topic/3479/cellular-lorawan-nanogateway

Is it fair to say that using lorawan between a bunch of lopy4s & a gateway fipy recoded to use lte to my server rather than wifi to the TTN could be worth a shot? If so does the nanogateway code avoid having to synchronise all the lopy4 RTCs & confining them to their own time slot?

[jcaron]

@kjm nope, quite the contrary, there is explicitly no listen-before-talk (LBT) in the LoRaWAN spec (at least in the EU region, not too sure about the others). In the EU region LBT-AFA would allow increased airtime, but they chose not to implement that, don’t know why. Probably to make the node as simple as possible and reduce power consumption.

IIRC on the LoPy, raw LoRa actually uses LBT.

Note that given the distances covered by LoRa, LBT does not guarantee absence of collisions. A gateway could hear both nodes A and B while the two nodes can’t hear each other, so A could think the channel is free when B is sending.

I believe LoRaWAN class B included some form of beaconing for sync but I’m not sure of the details and I don’t think this is widely implemented on either devices, gateways or LNS.

[kjm]

@jcaron said in Ways of doing things.:

So devices can send uplinks at any time they want without any coordination, and there could be collisions.

So lorawan confers no advantage over raw lora in many-to-one topology? I thought I read somewhere that it has listen-before-send?

[jcaron]

A nano gateway is just a regular LoRaWAN gateway, with one difference: it only listens on a single channel, with a single SF.

So devices can send uplinks at any time they want without any coordination, and there could be collisions. The fact there there's a single channel and SF makes that even more likely.

If you want guaranteed delivery, you have no option but to use confirmed messages, but there are limits on the airtime of a gateway (like any device), and in many regions this makes it highly impractical if you have any decent amount of traffic (which would be the cause for those collisions).

If you want to use timeslots, then it's something you need to add on top of LoRaWAN or raw LoRa, taking into account the fact that the gateway may send data back in RX1 or RX2, so you probably need pretty long timeslots.

Also sync may be quite an interesting problem in regions where there are strong limits on airtime (such as EU868).

Note that time slots do not guarantee delivery: there are other possible reasons for collisions, such as noise (or even other LoRa devices in the vicinity). It's a shared band after all.

What kind of volumes are you talking about? How many bytes per update, frequency of the updates (on regular intervals, or triggered by an external event?), how many devices, what range...?

Also, the monthly cost of the SIM should be very low, so the cost is mostly linked to the volume of data. Whether each device sends data directly or via a gateway doesn't change the total volume, so it shouldn't change costs significantly.

And of course the gateway needs to have a constant power supply (can't be battery-powered). If you want to go the gateway route, you're probably better off with a Pygate + GPy.