author

danielknox

52
Inbox View Profile
1Instructables116,905Views7Comments

Tell us about yourself!

Achievements

10K+ Views Earned a bronze medal
  • danielknox commented on danielknox's instructable LoRaWAN Gateway

    Hi, the gateway itself can made to be highly mobile as we use one for mobile testing (it happily runs on a battery all day long) -- if you use a Pi zero, rather than a Pi 3 the unit uses around 20watt hours a day. However, it sounds like you are wishing to use this to improve your Internet connectivity to your motorhome, in which case this would likely not be suitable for your needs. This kind of wireless network is primarily designed for very low bandwidth system (sensors that 'dribble' data), so things like emails, web browsing, etc. whilst we may think of them as lightweight, would require bandwidth that this kind of network could simply not provide (and likely quickly go beyond the allowed duty cycle). Hope this helps.

    View Instructable »
  • danielknox commented on danielknox's instructable LoRaWAN Gateway

    We indeed use an NTP server for coarse time. A LoRaWAN gateway is able to provide its location to the network (which is included in the meta data of every received packet), so at the moment we primarily use GPS for this. However, the actual reason for GPS in this gateway was for the longer term; current LoRaWAN deployments are generally "Class A" deployments, which means nodes wake up and send messages and then can get downlink messages shortly after a transmit (this is the lowest powered version of LoRaWAN). In a "Class B" network, the nodes on the network open extra receive windows at scheduled times; but to do this they need a time synchronized beacon from the gateway; as such, the inclusion of GPS was a decision to make this gateway hardware ready for Class B netwo…

    see more »

    We indeed use an NTP server for coarse time. A LoRaWAN gateway is able to provide its location to the network (which is included in the meta data of every received packet), so at the moment we primarily use GPS for this. However, the actual reason for GPS in this gateway was for the longer term; current LoRaWAN deployments are generally "Class A" deployments, which means nodes wake up and send messages and then can get downlink messages shortly after a transmit (this is the lowest powered version of LoRaWAN). In a "Class B" network, the nodes on the network open extra receive windows at scheduled times; but to do this they need a time synchronized beacon from the gateway; as such, the inclusion of GPS was a decision to make this gateway hardware ready for Class B networks. However, to reduce the price, you can leave the GPS parts out and just "fake gps" in the packet forwarder (if you know their static location at configuration time).

    This is heavily dependant on a large number of factors; including: antenna choice, urban density, things in the fresnel zone, etc, but we easily get a few kilometre in a city with ours using the rubber duck antenna. We have been working on a few tools to help map the signal quality using a phone and Arduino+LoRaWan shield combination (kinda like OpenSignal, but for LoRaWAN networks); so we'll release these soon to help people get a more accurate idea of what is possible.

    Hi Instruct_: LoRaWAN is ideal for public networks where there is one / few "providers". The protocol is noise resistant, has very good range (in theory 15KM line of site -- realistically several kilometer in urban environments), and has relatively low power demands (when compared with GSM), but this comes at the cost of bandwidth. It is most suited for "data dribblers", so devices that occasionally send data to the Internet (i.e. remote sensors). Because LoRaWAN generally uses ISM bands, it gets effected by duty cycle regulations, so you are legally limited on the amount of airtime you are using within in a period of time. Things network have a calculator which can give you a ballpark idea of number of msgs within 24hour (https://docs.google.com/spreadsheets/d/1voGAtQ…

    see more »

    Hi Instruct_: LoRaWAN is ideal for public networks where there is one / few "providers". The protocol is noise resistant, has very good range (in theory 15KM line of site -- realistically several kilometer in urban environments), and has relatively low power demands (when compared with GSM), but this comes at the cost of bandwidth. It is most suited for "data dribblers", so devices that occasionally send data to the Internet (i.e. remote sensors). Because LoRaWAN generally uses ISM bands, it gets effected by duty cycle regulations, so you are legally limited on the amount of airtime you are using within in a period of time. Things network have a calculator which can give you a ballpark idea of number of msgs within 24hour (https://docs.google.com/spreadsheets/d/1voGAtQAjC1... Gateways also are effected by the duty cycle rules, so whilst message acknowledgments for nodes is supported by LoRaWAN, its better if you can live without it (as it needs this downlink time for join requests and session key exchanges with nodes -- as the transport layer is symmetrically encrypted).In terms of service providers, there isn't one in the traditional sense. Community groups like The Things Network provide the backend network servers that route messages from your sensor to the right application, and also handle things like message de-duplication when multiple gateways pick your message up; but ultimately the gateways that actually form the network are owned by the community themselves (i.e. you and I). There's nothing stopping you from operating a completely private LoRaWAN network (by running your own network servers), but at the same time it could mean you start competing for airtime with other networks that exist in the same area; hence why its better suited for fewer network providers in a single area and for those to be made available for everyone to use. This page gives a more in-depth overview of the general architecture of a LoRaWAN network (https://www.thethingsnetwork.org/wiki/Home)Hope this helps!

    In terms of the number of nodes able to be supported and available channels, there is no difference (the ic880a board has the exact same underlying chips as the Linklabs one that we use). The biggest difference between that one and ours is we have GPS included; although this alone shouldn't currently be a massive difference as most networks only support Class A Lorawan networks. Other minor differences is the choice of shield creates a more secure connection between it and the Lorawan shield (rather than breadboard jumper cables); we use a 802.3af compliant device (rather than a passive splitter), so it plays nicer over long distances with switches that have POE built in, etc.

    View Instructable »
  • danielknox commented on danielknox's instructable LoRaWAN Gateway

    Hi, the shield used in this gateway is designed for making use of frequencies around 868MHz; so primarily it is meant for European markets (making use of the ISM band there). LoRa itself is designed to be used on pretty much "any" frequency; with specific hardware implementations designed for different parts of the bands.

    View Instructable »