Achievements

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.

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.

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

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

Hi, Thanks for the comments!(1) You could increase the height of the wall bracket and put a straight TNC to SMA adapter in (to go from the GPS antenna to the SMA coax). For us the receiver gain from the GPS antenna meant the little extra loss from another adapter was negligible for us.(2) Yup you can just use a saw if you want; I considered that when I first wrote the Instructable, but guessed any person comfortable in doing that would just do so anyway. (3) This is a tricky question. Technically you should have at least 1/4 wavelength spacing of the lower frequency between the antennas - so in this case about 86mm (which we don't have); otherwise one antenna can effect the characteristics of the other (mostly the omni). If this is of concern you can widen the adapter plate or increase ...

Hi, Thanks for the comments!(1) You could increase the height of the wall bracket and put a straight TNC to SMA adapter in (to go from the GPS antenna to the SMA coax). For us the receiver gain from the GPS antenna meant the little extra loss from another adapter was negligible for us.(2) Yup you can just use a saw if you want; I considered that when I first wrote the Instructable, but guessed any person comfortable in doing that would just do so anyway. (3) This is a tricky question. Technically you should have at least 1/4 wavelength spacing of the lower frequency between the antennas - so in this case about 86mm (which we don't have); otherwise one antenna can effect the characteristics of the other (mostly the omni). If this is of concern you can widen the adapter plate or increase the length of the plate and offset the mounting holes to obey this rule. I'll try and take it down the antenna lab on campus to see how the antennas are effecting each other and report back to this comment. However, it's also worth mentioning that if you intend to have fewer gateways and are able to site it somewhere good (e.g. mast) then I personally wouldn't bother with the rubber duck and go straight for something like a collinear antenna. We like using the rubber duck for testing and on our portable rigs, but would jump to a good basetation antenna in a heart beat.

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/1voGA...

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!

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.