So what will be next steps for MeshPoint?

We need to reduce size of solar mppt charger/battery management PCB and integrate it into MeshPoint case with batteries.

But we are also looking into what are other use cases for MeshPoint so we partnered with Hexaworx drone engineering company to create drone for crisis situations.

Here is MeshPoint Hexaworx drone maiden flight and few photos. 

We managed to establish wifi link 1km away without problems on first try. In out next test we will do 5km and 10km range tests.

Since we are a small team and our resources are limited we currently do not design and manufacture WiFi router boards used in MeshPoint. We hope to design and manufacture our own boards in future. That way we will not depend on vendors who usually release a new revision of their products every year or sometimes even more often. Although devices still have the same product name and look the same hardware and software they use is often completely different.

We are currently using TP-Link CPE210 v1 boards in current MeshPoint version. Unfortunately TP-Link discounted v1 of CPE210 couple of months ago and currently, v1 is not available at all and only v2 can be purchased. That poses a big issue to us since v2 of CPE210 brings completely new hardware and unfortunately second RJ45 port was removed.
Since hardware has completely changed there was no existing support for LEDE we use as the operating system for MeshPoint. So the only solution was to work on supporting CPE210 v2 by us and the community.
After a couple of weeks of intensive work done by us and the LEDE community finally, we have a working version of LEDE for CPE210 v2.
Most of the time spent in development was due to unusual hardware design in which TP-Link did not use registers that usually tell bootloader what frequency to run CPU, RAM and reference clock. So values passed from bootloader were not correct and since LEDE uses those values to set correct clocks completely wrong values were set and the device will refuse to boot. That was eventually bypassed by having LEDE calculate clocks in the same way as stock firmware.

After that was solved serial also started working and from there development process was the same as for any other Atheros powered device.

We are still testing and fixing bugs as we find them but we expect that official support will also land in LEDE soon.

We also may have a temporary solution in form of CPE220 v2 which uses the same hardware as CPE210 v1, so we will investigate that solution also.

CPE210 v2 PCB:

Bootlog from a working LEDE image on CPE210 v2 can be seen here:

GitHubGist

Source code for CPE210 v2 can be seen here:

GitHub

And for those not interested in whole source a small snippet of code that powers  RJ45 port of CPE210

    ath79_register_mdio(0, 0x0);
    ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
    ath79_eth0_data.duplex = DUPLEX_FULL;
    ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
    ath79_eth0_data.speed = SPEED_100;
    ath79_eth0_data.phy_mask = BIT(4);
    ath79_register_eth(0);
    ath79_register_wmac(ee, mac);

In Radiona / Zagreb Makerspace we always need wireless for our project so we often use more then one router on events and some time we are setting up mesh network. There are always questions what mesh is and how does it work. So in one project that we realized through the Clubture network program for 2016 we decided to visualize mesh network.

We have prepared 5 routers with openwrt, Croduino (https://e-radionica.com/hr/croduino-basic2.html) and 5 lasers. We wrote simple arduino sketch that starts lasers with serial messages. And we got first light :)

Testing

Lecturing

At router we wrote small script that takes data from babel and sends serial message to arduino to start or stop lasers...

And finally mesh visualizing

Here is MeshPoint buiness plan canvas:

Having easy and simple to use technology that gives you exactly what you need, when you need it, is great. But it can be even better if you can use that technology in arduous and demanding situations where possibilities are limited, if not exhausted. Think of earthquakes, fires and floods when different parts of towns and villages get cut-off; or think of people trapped in wilderness or rugged mountain areas. These are situations where you need fast, simple and light solutions to your problems. One of them being communication – communication with those in need and communication with your team and center.

This is one of the reasons why we decided to develop completely portable MeshPoint kit, i.e. MeshPoint in a backpack. The idea is to have weatherproof backpack containing battery and 20W solar panel that can be used for charging if needed. The backpack itself would serve as a construction with an attached pipe that carries MeshPoint.

In an accident, disaster or crisis situation when people need to stay mobile or when rescue teams, such as mountain rescue service or firefighters, need to reach rugged and inaccessible mountain terrain, wilderness or remote cut-off areas, having portable Internet kit that enables you to move easily and use your hands freely can be of great help. Any individual, professional or other, could take a backpack and easily 'turn herself/himself' into an instant mobile hotspot while continuing with her/his search and rescue activities.

(Valent carrying "Free WiFi" backpack and providing Internet connection to refugees in Croatia, September 2015)

And, in a way, this is MeshPoint going to its origins. In September 2015, when Syrian refugees filled the streets of villages in Slavonia and Baranja county (Croatia), Valent and his friend took a backpack with few routers, battery and LTE sticks and went to help those in need.

Now we want to empower others to do the same.

Idea

For our fire alert system we are using devices that need to be spread across a large area and sometimes they need to be placed in hard to reach places. Therefor to deliver our nodes we needed to use something that was quick and easy. We also couldn’t place them by hand because it would take too long and we needed to place them evenly across the whole area, so we figured out to use drones. With drones we get a better view from above that helps us determine where to place our nodes and we don’t need to worry about hard to reach places.

Using drones

After figuring out to use drones we needed some kind of a mechanism that would be fast and reliable to release the nodes from the drones. First idea was to use resistors that would burn a wire and drop the node but we would need to land the drone to replace the resistor every time and it would be messy to do that every time. Then we settled on using servos with custom 3d printed holders that would allow the node to be carried using a string attached to it and then dropped by releasing it over the drop point and we wouldn’t need to land the drone.

Release mechanism

The next step was to find out how to control the servo and there were 2 options: first was to use an RF module that would give us the ability to drop the nodes from far away, and the second one was to use 2 ESP devices connected to each other as a server and a client. We went with the second option because if we ever wanted we could even send some kind of commands with the ESP and not only to release the node, also we can achieve the same connection distance like the RF module by connecting an antenna to the client ESP. The use of ESP also enables us to put some kind of a router to the drone and we would be able to release the nodes from anywhere and by using a GPS module we could even automate the process.

2 ESP devices connected and communicating over WiFi and able to send commands

What is next?

We still need to test the distance that we can achieve between the 2 ESP-s and also this could be helpful later on if we needed to make a mesh network out of ESP-s for our fire alert system.

Nodewatcher is a platform that we use for easy creation, configuration, firmware generation and monitoring from the web browser.

In order to run Nodewatcher Docker and Docker-compose are required, instructions for their installation can be found here.

Preferred OS for running Nodewatcher is Ubuntu/Debian and rest of Debian based distributions.

1. git clone https://github.com/wlanslovenija/nodewatcher
2. cd nodewatcher
3. Edit docker-compose.yml
   Configure DB username and password to something other than the default.
   Change InfluxDB and PostgreSQL DB paths to preserve changes even after a reboot since by default tmp is used.
   Configure image builders to include your own custom built ones or you can use pre-built ones from here .
   Also changing private and public key pair is recommended.
4. Run sudo docker-compose pull
   This step will pull are required docker images.
5. Run sudo docker-compose build
   This step will build web and generator docker containers with required Python packages.
6. cd nodewatcher and edit settings.py to suit you.
   This file handles most of the customizations.
7. Run sudo docker-compose up
   This step will start all docker containers.
8. In another terminal run sudo docker-compose run web python manage.py migrate
   This will make the required database migrations so Django apps can function properly.
9. Run sudo docker-compose run web python manage.py collectstatic -l
   This will compile SCSS into CSS.
10. Open your browser and go to http://localhost:8000/setup
    Replace localhost with correct IP.
    This will enable you to create an administrator account.
11. Further configuration will be done from http://localhost:8000/admin/
    Replace localhost with correct IP.
    
    Now you have running but not configured Nodewatcher instance.
    The further configuration will be contained in another project log.

During crisis situations telecommunication infrastructure is often disrupted and in order to bring connectivity to affected areas we decided to use balloons and drones.

We plan to use balloons and drones in order to have line-of-sight communication between two MeshPoint routers. We need to take them around 25-35 meter above the ground if terrain is flat. We only need to be few meters above tree line, and in hilly areas we would use terrain to our advantage and setup MeshPoint on highest local point (small hill top) or on top of buildings if we are close to urban areas.

We have bought Totex CR800 japanese military meteo balloons that can carry 800g of weight. We plan to deploy them soon and then update build log after that.

Drones

Also we have build a custom DIY drone that could also be used to keep MeshPoint at desired altitude and powered via land tether. We are now searching for power cable that has is light and still can handle power requirements (around 850W - 17V and 50A).

We tested how much our drone uses power when under full load (with 1.5kg of weight).

In order to make MeshPoint mobile we need two things - batteries to keep it running, and battery management system (to charge the batteries, to keep batteries from under-voltage, to monitor power charging and power consumption and to manage power distribution).

Charging

For charging we needed battery management system that would charge from different power sources:

• solar power (with active MPPT algorithm)
• AC power (generator of from power grid)
• external DC power (car battery or AD/DC converter)

Monitoring and power management

Monitoring is extremely important because then we can decide how to manage power we have in batteries and power coming in from input (solar or other types of power). For example we plan to disable 1 or even 2 (out of 3) wifi radios in MeshPoint if power capacity drops below 50% and there is not enough solar power to charge batteries faster then they are being depleted. Also with enough data from last few previous days and weather forecast for next few days we can predict how much we can expect to get solar power generated and stored in batteries.

Battery chemistry

For batteries we needed ones that could perform very well in outdoor conditions (high and low temperatures), that are safe to handle and that have good power/weight ratio. 

We decided against lead-acid batteries because they would make MeshPoint much less portable and most lead batteries are not designed to be operated at high and low temperatures during hot summers and cold winters.

Batteries based upon Li-ion and Li-polymer technology were also tested, and they have great capacity to weight ratio which made them almost ideal for making MeshPoint routers as light and as mobile as possible. Unfortunately these batteries are very dangerous when heated over 50°C (122F), if they get punctured they can easily catch fire and even explode. MeshPoint will be used in outdoor conditions, exposed directly to sun and needs to be rough handling during crisis events, so if we decided to pair MeshPoint with Li-ion batteries this could potentially make it quite dangerous.

Li-FePO4 battery chemistry

We decided to go with Li-FePO4 battery chemistry because they have really good weight to capacity ratio and can handle both high and low temperatures. Also if they are damaged or punctured they don't explode or catch fire, which is really important also. Li-FePO4 batteries are used in electric cars, scooters and bicycles there they are know for their good outdoor performance in wide temperature ranges. Only downside is that they are a bit more expensive, but because they are getting used more prices have also started to drop. Also one big advantage is number of cycles LiFePO4 have, which is usually few times more than other Lithium batteries and much, much better than Lead based batteries.

Most efficient MPPT solar charger

There are a lot of different solar chargers in the market which can be bought off the shelf, but we had specific requirements that none that we found could match:

• active MPPT solar tracking
• designed for LiFePO4 batteries
• power charge/discharge monitoring
• as light and as small as possible
• 5V, 12 and 24V outputs
• power management (turning off and on specific loads)
• open source and open hardware
• designed for 40W solar panels (most MPPT solar chargers are 100W and up)
• to be extremely power efficient

When we started MeshPoint project two years ago there were no open hardware solar MPPT projects, currently there are two besides one our design will be based upon:

• IRNAS IoT battery pack
• Freifunk open mppt

MeshPoint battery management system and MPPT solar charger is based upon Soldernerd's (Lucas) open hardware MPPT solar charger project and firmware is also fully open source as well.

Some of modifications what will be done:

• removed screen to reduce size
• 24V output voltage
• smaller PCB design to make it more compact
• usb mini instead of full size usb connectors to make it more compact
• designed for 5S battery pack
• power management to turn off loads under low power situations

At Meshpoint we're always looking for ways to improve performance and stability.
Therefore we're looking for compare our current setup that uses ad-hoc interfaces on top of which we use babel mesh routing protocol with 802.11s mesh that recently became available in OpenWrt and LEDE.

With the availability of IEEE 802.11s mesh technology we wanted to compare results and is which solution offers better stability and more bandwidth.

For first round of tests we devised this test:

We used 2 TP-Link WR842ND routers flashed with our custom LEDE firmware image that uses babel mesh routing protocol. For the purpose of the test we disabled AP mode on there routers so that no client could connect and disrupt results on our test routers. 

The routers were placed 2 meters away from each other (keep in mind that this was not a range test but stability and bandwidth test) and laptop with iperf3 was connected on each side.  On one side there was direct internet connection (fiber 200/100Mbits) for the dslreports.com part of the test.

We used wireless channel 13 to minimise interference from other wifi networks.

                                                             Test network layout diagram

The results:

Ad-hoc mesh

Results were erratic and unpredictable, going from 5 to 33 Mbps, so we ran tests 10 times but we never got anything even remotely close to stable and reliable network bandwidth.

                                                         Iperf3 basic test results ad-hoc

                                             Iperf3 speedtest results via dslreports.com

Internet bandwidth test was done with laptop connected to router 2 that then run the tests. The graph shows that speed is inconsistent, starting with only 25 Mbps and dropping further to only 5-8 Mbps. Testing directly on router 1 showed is that Internet connection is not the cause of poor performance, but ad-hoc interface itself.

IEEE 802.11s test results

After testing ad-hoc mesh we switched to testing the 802.11s mesh. 

Iperf3 test: 

And speedtest results:

802.11s mesh results were much more consistent, bandwidth was greater than with ad-hoc mesh and there were no bandwidth dropouts.