There are no gateways in my area (Prince Edward County, Ontario, Canada) and I want to fix that. Please forgive my ignorance but would this hardware work?
The LG02 is a 2-channel gateway, you should not use this kind of gateways in TTN.
Use the Dragino LPS8, it is a true 8-channel gateway, costs a few dollar more.
To be more precise, it is a Lora gateway, not a LoRaWAN gateway. TTN is LoRaWAN so you need a compliant gateway. LPS8 is one of many options. For a cheaper solution (but more work) you could check pygate combined with wipy.
There are roughly three types of “real” (8 channel) gateways out there.
“Traditional” gateways use an embedded computer (almost always embedded Linux) designed to be robust for field deployment and flash storage types specifically chosen for this. They typical run variations of the open source Semtech packet forwarder code, and can usually be customized, but various manufacturers make that more or less difficult. They almost always support wired Ethernet for backhaul, and most can also be ordered/configured with mobile data modems instead. These are the majority of devices on the market. The Dragino LPS8 and RAK7258 are two of the lower cost options in this category - architecturally robust, but shipping in indoor-environment housings, vs a lot of others which come from entrenched telecom vendors charging corresponding prices.
Low-end gateways like the TTIG and the pygate try to use more MCU-like compute platforms which require very integrated unique software. To date, they are entirely inflexible - no source code is available for TTIG, and it’s not clear if any is or will be for the pygate. These also tend to be wifi only, and not infrequently exhibit wifi-related connectivity issues.
Pi-based gateways derive from ways to find a cheaper solution, where people took radio cards intended for multi-standard traditional embedded gateways and wired them into raspberry pi SPI busses instead. They’re now available as kits, though typically costing a little more than the economy tier of traditional gateways (eg, RAK’s pi kits cost more than their 7258 platform or its Dragino LPS8 competitor mentioned above). They’re quite flexible and a great way to try out ideas for different gateway behavior (though there isn’t really all that much behavior to customize in LoRaWAN, since all the interesting stuff happens at the server and node). A raspberry pi is not, however, something designed to be an industrial embedded computer. In comparison to more tailored solutions, it tends to draw more power, and be more fragile in the face of unexpected power loss - critically it depends on the consumer technology of an SD card - a storage device never intended to hold the filesystem of a running Linux system. There are strategies people use to try to use the SD card more safely, but there’s always card-maker-unique management code running in the card itself, out of sight (something starting to include not only wear leveling on write, periodic refresh of even blocks that are only ever read). Essentially, pi gateways are great for learning and experiments, great for debugging nodes, and installation in an office or attic, but less suited to field installations which may be difficult to re-visit, and have constrained or unreliable power.