Embedded Linux based LoraWan Balloon design

Introduction

This project is designed to build a linux based LoraWan HAB balloon. The idea of the project is to make an advancement of the current PicoBalloon communities. 

Project Advantages/Disadvantages

As ever, re-inventing the wheel has it's own pros and cons. This section aims to answer FAQs on why this project has been built and designed.

Advantages

* Linux based - In the past, common sense would have assumed to have used low-power/arduino based microcontrollers. However, as chips have become vastly more efficient and cheaper in recent years (OK, that's a topic for another day!). This means that it has become sensible to start building using Linux. Advantages include being able to use Linux based drivers. For example the LoraWan interface is now a standard linux socket interface, and the HAM radio module can be interfaced with sysfs!
* Ease of development - Linux will allow GDB to be run on the end device for debugging, the environment is running ADB allowing code to easily be pushed or shell to be accessed. Multiple layers of _shit_ can be abstracted... Don't understand the FSK Lora Protocol or SPI interfaces? Fine. It's just a unix socket now! :)
* Ease of build - You can repeat this project with a soldering iron, a few thin wires and a swear jar.
* Sets a new standard of MVP (Minimal Viable Product) - The SDK and simple build means it can be used as a base design for quickly bootstrapping any future projects.

Disadvantages

* Linux based - Yeah, it's not a RTOS. Looking at the drift of WSPR.. eh, famous last words but should be fine.
* Ease of development - It vastly changes the paradigm compared to Arduino based solutions. Also, "just a unix socket" is quite oversimplified, for example Lorawan NWK (Encryption key) currently needs to set using ioctl system calls.
* Ease of build - WEIGHT!!!!!! - I will work on this one.
* Complexity - While fine once you get used to it... there is a lot going on here.

Network design decisions

There are 2 major providers of LoraWan coverage:
* TTN (The things network)
* Helium

Both have their own pros/cons. 

I would consider TTN to be the more reliable choice, however seems to have an extremely strict fair use policy for the type of application I'm trying to work with. 

Helium has what I would consider almost a "snake-oil"-esque blockchain based method of trying to encourage gateways - potentially creating unreliablity. However I feel this is offset by the generous fair use policy, and the fact that the coverage at 10KM in the air is pretty much to the horizon. So if one of the nodes is down, it really doesn't matter.

Therefore, Helium has been the chosen provider for this project.

Hardware design desisions

The hardware design is modular based, rather than a complete homegrown design to simplify development, and also ease of access to the project. (It's easy to reproduce at home!)

If significant advantages arise from a home developed board then it might be considered in the future. The weight difference, while lower is insignificant enough to not warrant the extra overhead and difficulty of access. Previous attempts of an in house designed circuit board using the F1C200S as a base design added complexity beyond what made the project enjoyable. (But easyeda.com I would recommend)

The hardware chosen has been based on multiple factors:
* Form size 
* Power consumption
* Ease of hardware interface (The components should be able to work with each other without having to design an interface board in the middle to aid communication)

Hardware chosen

Main CPU Board

The Luckyfox Pico Mini B board was chosen as the main CPU interface board. (https://www.aliexpress.com/item/1005006175964407.html?spm=a2g0o.productlist.main.5.23e65e7fajW5dU&algo_pvid=d7ac3b67-3060-4390-9949-0ae884c76ab1&algo_exp_id=d7ac3b67-3060-4390-9949-0ae884c76ab1-2&pdp_npi=4%40dis%21GBP%216.24%215.62%21%21%217.52%21%21%402103080617001519217352442e2997%2112000036136791338%21sea%21UK%212760040230%21&curPageLogUid=gNBLw8xFaTQN)...