MeshPoint - wifi router for humanitarian crisis

Autonomous, smart, wifi mesh router which is easy to use by humanitarian NGO first responders during humanitarian or natural disasters.

Similar projects worth following
"This, Jen, is the Internet." (Moss, IT Crowd)

MeshPoint is smart and rugged WiFi hotspot designed to provide instant Internet access in adverse conditions, suitable for crisis situations and social events, both indoor and outdoor. It can be employed and used by everyone, from non-tech-savvy to tech-savvy.
MeshPoint relies on principles of open source, open hardware, maker culture and modularity.

Crisis situations: we make rebuilding communication infrastructure fast, easy and affordable while providing extra services (e.g. connecting different sensors) that help with anticipating, assessing and managing those situations.

Social events: we provide fast and reliable Internet access as a support and added value to those events, whether a conference, festival, sport event, etc.

Our goal is to create completely autonomous device that can provide Internet in extreme situations and challenging conditions, while optimizing its deployment and performance.

Idea for creating MeshPoint started when volunteers from project Open network (Otvorena mreža) in Croatia led by Valent Turkovic started helping humanitarian organisations and refugees during Syrian refugee crisis of 2015. They saw that need for communication was really great - humanitarian organisations needed communication for coordinating volunteers in the field, for logistics (having enough food and blankets in field warehouses, etc.). They also noticed that all the biggest NGOs like Greenpeace, Red Cross, International Organisation for Migration, Unicef and others struggled to setup communication with their teams in the field, and how all current networking products are not suited to be used in crisis events by first responders.

Open network volunteers setup mobile and fixed wifi hotspots and gave them to volunteers and humanitarian organisations that were working in the field. Really soon it was apparent that creating solution from off the shelf components was just too complicated for humanitarian volunteers to maintain.

That is how idea for building an really easy to use and autonomous wifi hotspots came about.

In order to setup communication in crisis situations like floods and earthquakes devices first and foremost have to be easy to use, especially by first responders, but they also need to:

  • be able to provide connectivity to multiple thousands of people
  • be scalable
  • use mesh networking
  • be battery and solar powered.

So what are the requirements?

- Open source hardware and open source software
- Setup needs to be easy, as easy as creating social networking profile
- Needs to work autonomously for at least 6-8 hours (via battery pack)
- Needs to be able to charge battery pack over any power source (solar, wind, AC generator, car battery...)
- Can form a mesh network so coverage is spread really fast
- Has capacity to server lots of people (multiple radios and frequencies)

You can find out more about the project at:

  • 3 × TP-LINK CPE210 Wifi router board used in MeshPoint
  • 1 × Ethernet RJ45 outdoor connector with 20cm long cable Connector used for powering up MeshPoint via POE and for providing uplink or downlink lan connection
  • 4 × 3D printed case Download and 3D print case from our github repository
  • 2 × 10 cm utp patch cable Utp patch cables are used to interconnect internal wifi radio boards
  • 3 × M4 screws

  • Humanitarian IoT network + plans for the future

    sandi06/12/2017 at 13:24 0 comments

    IoVuT - Internet of very useful Things

    In London at Europas conference we received award for best humanitarian innovation, this was a huge things for us, because this award was given to us directly by Unicef.

    Just few days after the conference ended we've recieved a call from Unicef to establish an IoT network in Zaatari, Jordan, one of the biggest Refugee camps, with population of over 80,000 people. mostly Syrian civil war refugees.

    Zaatari camp was opened in 2012, at the beginning of Syrian War. Since the beginning, the humanitarian organizations have been struggling to keep up with growing demands of the camp's inhabitants.

    Uber for waste (IoT for good bad things?!?)

    On the call Unicef team from Jordan and Lebanon explained why they needed our help and why they gave us this award. We got this award because they said the bigges issue they face in the field today is setting up communication, and then recognised MeshPoint as an great solution to this problem.

    But project they wanted our immediate help actually had nothing to do with providing Internet, but with something completely else - human waste.

    One of the biggest issues currently in most refugee camps is managing septic tanks, and emptying them in time. Because if this is not taken care in proper time then with overflowing sewage diseases spread, and most often first to be affected are the most vulnerable - small children.

    Right now, we can help, by providing a backbone for a network of IoT sensors that would collect levels from clean and dirty water tanks. First step will likely be installation of water level sensors in water reservoirs and waste disposal tanks. The sensors will be connected via Meshpoint network to a server with an SMS gateway, alerting the companies responsible for the logistics when the water or waste reach determined levels, speeding up the process of delivery, cleanup, and cutting down costs and preventing hygiene catastrophes. The volunteers are already calling it 'Uber for waste'.

    Clean water and waste level sensors + MeshPoint = much less diseases.

    While we negotiate our involvement in this project, we're always looking forward to cooperate on similar projects in the future.

    Future plans

    In our IoT networks we predominately use ESP8266 chip as a basis for our sensors. It's a really powerful chip with integrated WiFi and a very economic sleep mode, that can last over three weeks on only one (used) Li-Ion battery, provided it 'wakes up' every five minutes. (We recycle batteries from old laptops and similar devices).

    When ESP wakes up, it searches for WiFi, connects and sends data to a server and shuts down. We have measured the time it needs to do all this tasks to 7 seconds. The ESP asks for DHCP from the router, and a few more messages are exchanged, which is time consuming. Some time may be saved by implementing a static IP address. We'll starting our measuring experiments soon. We expect with 4 cells to get over a year of completely autonomous sensor collection. Here is how our battery measurements are tracked:

    In our DB servers, we have implemented triggers that send out an alert roughly one day before the battery is totally depleted and damage can be done to it, so we're always able to change it before the critical moment.

    On our roadmap are also air quality sensor stations, which can be put in forests, and in combination with Meshpoint can act as a early detection mechanism for forest fires and also a climate monitor and analyzer tool

  • Eureka and rapid prototyping

    Valent Turkovic06/12/2017 at 13:17 0 comments

    Wifi mesh towers

    To provide internet to stationary humanitarian teams who had tents and usually solar panels or generator for power we started building wifi towers. Wifi towers consisted of these parts:
    - camera or outdoor speaker tripod
    - outdoor waterproof box or case
    - Ubiquiti Toughswitch (5 port POE switch)
    - Dovado TinyAC router with usb port (router used for setting up LTE link)
    - Huawei E3372h LTE USB modem (which can be setup to use external LTE antenna)
    - 3x Ubiquiti Loco M2 wifi routers (for hotspots)

    This setup worked great, and we created quite a few of them. We build them for Greenpeace, International Organisation for Migration, for Jesuit Rescue Service and for quite a few smaller NGOs.

    Have you tried turning it off and on again?

    This setup worked great... until it didn't. We started getting calls and getting out in the field and the issues was that because things still were quite chaotic humanitarain NGOs were moving their tents to different location almost every few days...

    And when they needed to move they had to take apart our wifi mesh tower and put it back together again on new location.

    This is really easy to anyone with at least basic IT knowledge, but this is not what first responders from humanitarian organisations were trained to do. Whey were great at their job, but this wasn't part of it, and they relied heavily on having stable connectivity.

    We would come each time and help them with what usually was a cable which was plugged in wrong port.

    Eureka moment

    By working with the first responders from all the biggest international humanitarian NGOs we saw that there is no device suited for their need. A device for humanitarian workers must me smart and powerful but first and foremost - easy to use. This is where idea for MeshPoint was born.

    First prototype

    First prototype were three wifi routers in a big water pipe with just few 3D printed parts.

    Second prototype

    Then we created second prototype with all 3D printed parts.

    This prototype worked great as proof of concept but has issues, mostly because radios weren't isolated wifi boards caused created interference for each other. Other issue was that all routers used omni directional antennas so they send wifi signal in all directions, but they also picked up noise from all directions.

    All these issues made this made issue for this prototype so it had shorter range then expected and when more than 100 people connected it would just stop working all together.

    But we got lots of valuable lessons from this prototype and moved further.

    Third time is the charm

    With third prototype we used all we learned so was and build a device which was much better. It used three separate sector antennas and has shielded radios. Also because it was POE powered and it had POE in and POE out we could daisy chain them and make assembly much, much easier.

  • Wifi mesh on top of light towers

    Valent Turkovic06/11/2017 at 23:57 0 comments

    How come there is no power socket in the middle of the field?

    After we solved getting internet uplink connection working we needed to tackle one other big issue - power.

    We take power (and most things) for granted, but we found our the hard way that during crisis events you can't rely on having power. And sometimes you have to provide Internet in the middle of the field, and there are no power sockets in the middle of the field.

    So even when we got Internet connection up and we could get out mobile hotspots to share the Internet we would run out of batteries after few hours and would need to swap them out.

    So we were thinking on using solar power but because we were in the field all the time we got in person with minister of Internal affairs and he allowed us to setup hotspots inside refugee camp.

    So we were looking how and where to install out devices, and first location that looked promising were light poles.

    Light poles were great location because by installing 12 hotspots on 4 towers we could cover whole refugee camp.

    But there was one big drawback, light poles had power only during the night, so during the day when most people would like to gave Internet connectivity we wouldn't have power.

    Of course we knew that devices such as UPS exist, but we decided UPS are not a good solution because of these reasons:
    - we couldn't afford ones we needed (ones with 4 batteries, which are really expensive)
    - we couldn't source high capacity UPS locally or in short time
    - UPS converts DC to AC and this conversion has up to 40% loss of energy
    - UPS aren't build to be used outdoor

    So we started to build 24V (most outdoor wifi devices use 24V POE power supply) DIY power solution from this parts:
    - 24V car battery charger
    - 4x 7Ah 12V batteries (ones used for UPS and scooters)
    - Arduino based voltage and temperature monitor connected to OpenWrt router via serial connection
    - big plastic box
    - 8cm thick sheets of styrofoam for isolation

    Batteries were connected two in series and two pairs in parallel. We didn't have time (nor money) to add or build proper over and under-voltage protection for batteries, but what we did was to carefully balance (with additional calculation and measurement) that batteries will hold this load and that charger will properly charge but not over charge batteries and that wifi devices won't over use and under voltage batteries.

    This system worked for all 8 months that refugee camp was operational. We have only one tower fail after few months, but others worked without any issue all this time.

    Hackerspace heroes to the rescue

    I co-founded #labOS hackerspace in my home town and when saw that there is no way I can build all that is needed in 3 days I knew that only was I was going to make it is with lots of additional help.

    When I asked people from out hackerspace to help out me response was overwhelming.

    Without such great support there is no way we could have made this happen!

    We managed to get four complete kits build, tested, connected to see if Arduino was collecting and sending data, and once everything was done disassembled it and prepared it for transport.

    Hope you have life insurance...

    In order to deploy wifi hotspots and diy power system we needed to climp 20m high towers that were very rusty because they haven't been used or maintained for over 20 years.

    In order to climb these towers I hired professional climber who trained me before to climb building, but this was something else, and much harder.

    Once we climbed up we were very happy :) But then we remembered that we also need to bring up all that equipment we prepared...

    So to bring up all devices, connect them and install them on all four light poles it took us 6 hours of non stop work. We were totally exhausted after that, but also very proud of what we acieved.

  • First try, and first fail.

    Valent Turkovic06/11/2017 at 23:21 0 comments

    How it all started

    In August of 2015 whole Europe was part of unprecedented humanitarian crisis in which hundreds of thousand Syrian refugees were fleeing from their war stricken country in hope to save their lives and for a better future.

    Overwhelming numbers of Syrian refugees that wanted to enter the EU surprised all humanitarian NGOs and caught them off guard.

    What we saw in the news and at the border crossing was total chaos...

    When humanitarian or natural disasters occur the need to communicate is immediate. We have witnessed first hand how the children who are most vulnerable are affected because rescue teams are not prepared to tackle this issue. Current solutions are too slow, require highly trained people to deploy it, don't scale and are very expensive.

    Because mobile networks were not designed to handle such big number of people (refugees, teams from multiple humanitarian organisations, police and volunteers) in small area the whole system collapsed and you couldn't call anyone or get data connection up to the Internet.

    First try and first fail

    Out first try was with few routers in backpacks with batteries and 3G modems. This approach mostly didn't work. But what we was in the field was just how important it was for refugees to get any kind of connectivity so that they could use their smart phones to let their families and friend know they are aright.

    Survey conducted by International Rescue Comity showed that first question that refugees asked when they landed on Greek islands was "Where am I?", second question was "Do you have Wifi?" and only the third question was "Where do I get food and water?".

    Communication taking precedence over food and water showed us just how important it was for refugees to stay in contact with their families and friends.

    Out approach mostly failed, because we were trying to connect via 3G modem towers that were not designed to handle this much people trying to use the network at the same time.

    Silver lining

    What we saw in the field also shocked us, it wasn't only us who were trying and failing to setup Internet connection during this humanitarian crisis, but also all the teams from the biggest humanitarial NGOs were also failing. We saw Greenpeace, Red Cross, Unicef and other teams from smaller organisations trying to setup any kind of communication with their HQs but they didn't succeed what ever they tried.

    This is what motivated us to try even harder and try different approaches and different pieces of equipment.

    We found out that 4G network was not overcrowded so after getting LTE 4G modems we managed to get uplink to the internet.

    After that we also managed to connect to 3G towers but we used long range antennas to connect to remote towers instead of local ones which were overcrowded and not working.

    Now we had Internet but all most wifi routers we tried couldn't handle more that 20-30 people at once. One NGO team is around 20 people, and also there were few thousands of destitute people, children and whole families who asked us for Internet access...

    So first part of the puzzle fit in place, but this was only first piece. We knew we were on the right path, but there was still lot of work to be done.

  • Dashboard is here!

    milijana.micunovic06/11/2017 at 19:49 0 comments

    While providing Internet network for one of the East European's greatest international extreme sports competitions, Pannonian Challenge XVIII-2017, we developed a dashboard in order to better monitor:

    • current number of wifi clients
    • currently connected wifi clients on all MeshPoints
    • wifi clients distribution per MeshPoint
    • total number of clients
    • total number of clients on MeshPoint hotspots
    • download and upload traffic through time
    • ultimate download and upload traffic
    • data usage

    In time, we will see whether it needs some improving or changes depending on type of hotspot/network employment (crisis situation, social event, or other).

    What is sure is that it will enable easier monitoring of hotspot/network performance indicators and ease the writing of different reports. :-)

  • Ongoing case studies

    milijana.micunovic06/11/2017 at 19:14 0 comments

    In May we revisited two locations where MeshPoint technology is being employed and tested – assylum seeker centers in Kutina, Croatia and Zagreb, Croatia.

    While in Kutina we upgraded MeshPoint components with ones that have more internal flash memory for additional software packages for remote management. We also did a speed test and network range check.

    Because of the architecture of Kutina assylum center and the layout of the buidling itself, there is poor network quality in some parts of the center. So we made plans with the center officials to expand the current wifi network by placing additional MeshPoint routers on different locations. We took photos of the place and talked to center beneficiaries to learn more about their needs and to better plan the position of new MeshPoint routers and further coverage of the network.

    In Zagreb we updated the firmware (from OpenWrt to LEDE) on the existing MeshPoint router. We checked the network range and we did a speed test on central MeshPoint used in the main lounge area. While talking to center beneficiaries we found out that network quality is great and if there are any issues, they are almost always connected to network congestion caused mostly by huge file downloads and video streaming.

  • Extreme weather testing

    milijana.micunovic06/11/2017 at 18:58 0 comments

    This winter (December, 2016), as a part of local wifi network project conuducted in collaboration with the city of Osijek, Coratia we installed a number of MeshPoint devices in one city block, which gave us an opportunity to test MeshPoint's endurance in low temperatures and extreme weather conditions such as snow, cold winds and freezing rain. It is now officially confirmed that MeshPoint is truly weatherproof and that it can stand low temperatures down to -22°C without any problems.

  • Logging data

    Marin Stević06/11/2017 at 15:03 0 comments

    It is very important for us to stress test our equipment because we can never know how many people are going to connect to our network and we need to know how to prepare for every situation.

    For that reason we are logging every data necessary to run our mesh network at full strength and find any weaknesses that could arise and cause the network to slow down or break. That is a big problem because in crisis situations it is very important that everything works as planned.

    For logging our data we use custom made scripts that record the number of users, data usage and bandwidth and send all of that data to a server running InfluxDB (used for recording time sensitive data) and Grafana for the representation of the data. We also have a dedicated page that is much simpler and accessible to everyone else to see the data in real time.

    In the pictures included you can see some of the data that we gather and a screenshot of our page for representing the data.

  • Improvements to the 3D files

    Luka Šimić06/11/2017 at 12:43 0 comments

    Recently, we had a great opportunity to test our equipment, a local skate event "Panonian challenge". Many people connected to our network at the same time is a great environment for testing.

    This meant that we had to make lot's of devices, and once you start making them in larger amounts, you tend to notice things that impede your workflow.

    During assembly, we noticed that some parts had a too tight fit, that made the devices tricky to assemble at times due to relatively low tolerances of our 3D printers.

    We also performed maintenance on a few devices that were out in the field for a few months, and noticed that the glue that was holding them in place did not held up as expected, so we had to implement some minor design changes there as well.

    These nuts tended to fall out of their place once the glue lost it's properties, so we chose to tighten our bolts directly in the plastic.

    Our technique of rapid prototyping allowed us to detect and eliminate the issues and test the solution in less than a day!
    These improvements, each on it's own, don't seem significant, but they add up, and result in a much better experience.

  • Migration to LEDE platform

    Robert Marko06/10/2017 at 22:47 0 comments

    Meshpoint has been using OpenWRT as firmware from beginning thanks to open source nature of OpenWRT.

    Unfortunately development on OpenWRT has been slowed for over a year and since then a lot has changed. So we needed newer solution that was open source and will provide us with improvements. We found that in LEDE Project, an open source fork of OpenWRT that is developing rapidly and offer a number of improvements over OpenWRT.

    Some of the changes are:

    • Move from Linux kernel 3.18 to much newer and stable kernel 4.4.61
    • Many drivers are updated and more stable
    • Packages are updated and offer more features
    • Lot of security issues have been fixed

    Biggest improvement and main reason for move to LEDE Project was introduction of Airtime fairness feature.
    In a typical conference room style environment someone could be using a old laptop with 802.11g standard while rest of the crowd is on newer 802.11n standard laptops or tablets.

    By the laws of Physics, slow devices take relatively longer times to transmit and receive data compared to faster and newer devices. This gives less time to faster devices and disproportionately longer times to slow transmitting devices. Similar behaviors in air time can be observed if a device is farther away from an access point relative to other clients or if many client are connected to the same access point.

    That way newer and faster devices get lower speeds. This behavior is not present in home networks due to small distances and small number of connected devices.

    To solve that and enable faster device to achieve higher speeds we use Airtime Fairness.

    Airtime Fairness gives equal amounts of time they can transmit or receive data to each client regardless of its theoretical data rate. This will ensure higher download speeds to faster devices and also makes sure that when larger number of clients is connected one cannot use all of the bandwidth.

View all 10 project logs

  • 1
    Step 1

    Firmware configuration and flashing

    1. Go to Nodewatcher in your web browser
    2. You need to login or register
      Got to right top corner as shown in picture
      Fill in required information and under Default project select Croatia.
      Click on register
    3. You now need to configure firmware for first of three TP Link CPE210 AP-s.
      Got to right top corner as shown in picture and click on Register New Node.
      Now you will see form like one shown in the picture.
      Now you need to at least fill out name and select TP Link - CPE 210 as Router from dropdown menu as shown in picture above.
      After filling in at least Name and selecting TP Link - CPE 210 as router click on Advanced mode.
      Now scroll down to the part where you will see Wireless Radio.
      Now instead of default channel 8 select channel 1 from dropdown menu.

      Click on Register at bottom and configuration for first CPE 210 is done.

      After registration you will be redirected to page containing information about your node.
      Now you need to click on Settings icon located on right side.
      Now click on Generate firmware as shown in picture.

      Then you will be redirected to a page to confirm that you want to Generate firmware.
      Just click on Generate.

      After that firmware will be generated in couple of minutes.

      You can wait for it to complete and refresh the page in couple of minutes or continue to next step and configure firmware for second CPE 210.
    4. Second CPE 210 configuration is pretty much the same as first one.
      So follow step 3 instructions but with this slight change.

      This time select channel 6 instead of channel 1 from dropdown menu.

    5. Third CPE 210 is configured like first two but this time select channel 11 from dropdown menu.
    6. Now go to the same menu as when Registering a new node but select My Firmware Builds instead.
      Then you will se the list of all firmwares built for all of your nodes.
      Since this is the first time that firmware is generated for three of your nodes you should see three builds.

      Click on first build ID.
      Then download factory image by clicking on it.
      Repeat that also for two
  • 2
    Step 2

    Device assembly


    • Make sure you have flashed and configured the firmware of the routers you will be using
    • Make sure you have assembled the 3D printed shell
    1. Mount the outdoor RJ45 connector to the bottom piece. This step does not require any tools. Simply place the connector trough the hole and tighten it using the included plastic nut.
    2. Place the routers onto the bottom piece with the antennas facing outwards. Cable that goes from the connector should go upwards trough the space in the center.
    3. Place the top part onto the routers. Thread the cable going from the connector trough the hole in the center and secure each router using a screw from the top.
    4. Plug the cable going from the connector into the ETH0 port of the first router. Then, using the 10cm patch cable, connect the remaining free port to the ETH0 port of the second router. Then connect the remaining free port to the ETH0 port of the third router using the second patch cable.
    5. Carefully place the router assembly inside the shell.
    6. Secure everything using the M4 screws
    1. 3
      Step 3
      Final firmware configuration after assembly
      In order to use only one UTP cable for data and power to all three CPE 210 AP-s additional configuration is needed.
      It is not time consuming and mostly consists of copy/paste.

      For this configuration you need to be connected to SSID broadcasted by CPE 210.
      By default it is

      1. Login to first CPE 210 via SSH
        IP can be found on your node details and password by clicking on Settings menu and then on Edit.
        It is under authentication section.
        Username is root

        After logging in you will see basic information about your node.
        In order to enable POE to power second CPE210 you need to issue following commands.
        echo 20 > /sys/class/gpio/export
        echo out > /sys/class/gpio/gpio20/direction
        echo 1 > /sys/class/gpio/gpio20/value
      2. After that second CPE210 will power on.
        Then in order to enable POE to second CPE 210 after the devices have been rebooted you need to edit rc.local file.

        Issue the following command:
        vi /etc/rc.local
        Then you should see the following.
        In order to edit the file in vi text editor you need to simultaneously press SHIFT+I keys.
        That way you enter Insert mode.

        After that copy and paste commands from step 1.
        Contents need to be after line 2 and before line containing exit 0.

        File should look like this:

        If it looks like that press ESCAPE key and then type :wq
        That will save and exit.

        You have completed configuring first CPE 210.
      3. In order to configure second CPE 210 follow same instructions like for first one but with IP and password of the second one.
      4. Third CPE 210 does not need additional configuring.

        You are done with assembly and configuration of your Meshpoint.

    View all 3 instructions

    Enjoy this project?



    Similar Projects

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates