Difference between revisions of "DigI:Processes and Technology"
From its-wiki.no
Wessam9555 (Talk | contribs) (→3) Configuring, testing, sending and repair) |
Wessam9555 (Talk | contribs) (→3) Configuring, testing, sending and repair) |
||
| Line 60: | Line 60: | ||
'''Wisam''': | '''Wisam''': | ||
| − | 3.1 | + | 3.1 Ordering the needed MikroTik equipment for the coming information spots implementation. Configuring the equipment (LTE, LNCC, and Village server) and in case of extension spot (Sector antenna, Point reception, and Local hot-spot) |
| − | * documented | + | * The configuring processes are documented on OwnCloud (steps described in Owncloud = DeviceConfiguring = ....) |
3.2 Test plans are established for each village on OwnCloud (steps described in Owncloud = DigI-Vision 2030 = Village_installations=...) and sent to the local representer for installation work | 3.2 Test plans are established for each village on OwnCloud (steps described in Owncloud = DigI-Vision 2030 = Village_installations=...) and sent to the local representer for installation work | ||
| Line 69: | Line 69: | ||
3.3 Acceptance test in the field | 3.3 Acceptance test in the field | ||
| − | ''Initial testing'' - After receiving the equipment from the customs office, an initial test will be accomplished for the equipment set, usually in Dar Al-Salam, to figure out if the are working as expected before sending them to the field. That test is normally done by Felix. Then, the information spot set will be shipped to its final destination, the targeted village. | + | '''Initial testing''' - After receiving the equipment from the customs office, an initial test will be accomplished for the equipment set, usually in Dar Al-Salam, to figure out if the are working as expected before sending them to the field. That test is normally done by Felix. Then, the information spot set will be shipped to its final destination, the targeted village. |
| − | ''First | + | '''First installation''' - LTE Antenna: insert SIM card, connect cables, POE, power source test, and check that lights are working. A detailed connecting and testing document is available on OwnCloud (steps described in Owncloud = DigI-visjon2030 =Village_installation= ....) |
| + | LNCC router: connect the Internet wire coming from the LTE to port 1 on the LNCC, connect the LNCC to power source, and check if the power light is lightning green on the back side, in order to establish a local network /wifi. | ||
| + | Village server/ RPI: connect the RPI to electricity using the charger, normal Samsung mobile charger, and check if the power light is blinking/on. Then, connect the PRI to port 2 on the LNCC using an Internet wire. | ||
[[Has Image::File:LNCC-RPI-LTE.png|thumb|350px|Cabling between LTE (PoE in) to Port 1 on LNCC, and Port 2 from LNCC to RPI]] | [[Has Image::File:LNCC-RPI-LTE.png|thumb|350px|Cabling between LTE (PoE in) to Port 1 on LNCC, and Port 2 from LNCC to RPI]] | ||
| − | '''3.4 Error testing in the field''' <br/> | + | '''3.4 Testing in the field''' |
| + | |||
| + | '''3.5 Error testing in the field''' <br/> | ||
When the equipment (LTE, LNCC, Village server) are deployed in the field, the user should be able to perform simple steps to check the configurability. Through our central equipment, we are able to connect remotely to the LNCC and the RPI (if they are on the network). | When the equipment (LTE, LNCC, Village server) are deployed in the field, the user should be able to perform simple steps to check the configurability. Through our central equipment, we are able to connect remotely to the LNCC and the RPI (if they are on the network). | ||
A user being at the the site can test the following: | A user being at the the site can test the following: | ||
[[Has Image::File:TestingProcedure.png|thumb|350px|Testing procedure for Internet connectivity]] | [[Has Image::File:TestingProcedure.png|thumb|350px|Testing procedure for Internet connectivity]] | ||
| − | * ''3. | + | * ''3.5.1.''' I look for Wifi "BasicInternet", and connect to Wifi. <br/>Success: I can connect, next step 3.4.2. |
<br/>Failure: I can't connect, go to step 3.4.4. | <br/>Failure: I can't connect, go to step 3.4.4. | ||
* ''3.4.2.'' The user opens a browser (e.g. Chrome) and connects to Yeboo.com (or Yeboo)<br/>Success: The health information page (see Figure 1) is shown, and the hotspot works as planned<br/>Failure: Web site not found. Goto step 3.4.3. | * ''3.4.2.'' The user opens a browser (e.g. Chrome) and connects to Yeboo.com (or Yeboo)<br/>Success: The health information page (see Figure 1) is shown, and the hotspot works as planned<br/>Failure: Web site not found. Goto step 3.4.3. | ||
| − | * ''3. | + | * ''3.5.3'' In the Web browser, type ''google.com''. If google.com is not shown, then we have no network access. Potential sources: No credit on the SIM card, Devices not working, Cables unconnected/loose |
| − | * ''3. | + | * ''3.5.4'' Check the equipment: <br/>Is the light blinking at the back of the LNCC? If not, disconnect the power, reconnect and see if the lights come up. Check if you have electricity. If the LNCC still does not work, we need to replace (step 3.5)<br/> |
Check the RaspberryPI | Check the RaspberryPI | ||
| Line 89: | Line 93: | ||
'''Question:''' What happens if the RPI is "dead", what will the user see when typing Yeboo.com? | '''Question:''' What happens if the RPI is "dead", what will the user see when typing Yeboo.com? | ||
| − | '''3. | + | '''3.6 process for replacement'''<br/> |
Get into contact with the Foundation, | Get into contact with the Foundation, | ||
Revision as of 12:14, 26 August 2019
| Digital Inclusion (DigI) | |||||||
|---|---|---|---|---|---|---|---|
|
|
Processes and Technology
Processes
The DigI team consists of 11 partners from 8 countries. In order to collaborate efficiently, we have established the overall process flow. In this document we'll only describe the technical parts.
1) Village Web sites Yeboo.com
User story: A user finds a Wifi hot spot named BasicInternet. With the tablet or his/her own Smartphone, the user can connect to the hot spot. By opening a browser and typing Yeboo.com the user is redirected to the health information site, being health_information_dashboard.php
A) Yeboo Web site development: Maurice. The Web site shall have a common directory for all villages, and one specific directory (or a configuration file) for the specific villages. Thus, it will allow us to make one SD-card for all villages, and just "set the village name or redirect the Web server for that village. As an example, yeboo.com points to /var/www/yeboo/index.htm on the RPI, and this index.htm file is a copy of index_izazi.htm, index_migoli.htm, index_esilalei.htm ...
1. Yeboo site implementation: Hamed and Wisam install the specific village index.htm on the RPI and link it with the locally used LNCC
2. FeedBack on information usage: Maurice gets frequent results on the login to the village website, surveys, and questionnaires
3. Feedback on data usage, and access in the various locations: Josef and Maghsoud
To be done:
- Easier architecture: one /var/www/yeboo/common where all common files are located
- logical representation of village: Izazi, Migoli, ....
- Updating the existing running RPI in Izazi, and Migoli
Next steps:
- Maurice to provide a proposal on how these steps can be performed
2) Preparation of LNCC and RPI
User story: In each village, the core of the network is the Local Network Control Centre (LNCC) and the Village server, being a Raspberry PI (RPI). The LNCC gets a universal configuration, making it possible to be swapped by another device. Internally, the name of the LNCC (e.g. RDB52G-04) corresponds to a specific certificate (e.g. Tanzania04), which allows the secure communication to our control centre. The steps we perform include the installation of a RPI as the village server, displaying Yeboo.com from the local SD-card withing the RPI. Remote configurability of both LNCC and RPI are installed, to ensure that we can later on access the LNCC and the RPI in the field.
Questions:
- @Maghsoud: What is the advantage of using a specific certificate per LNCC?
2.A) Conversion of Web content to Raspberry Pi (RPI).
Platform development happens on Yeboo.com. From there, the specific files (both phpmyadmin, videos, scripts and other files) are downloaded to a local machine and transferred on an SD card in the RPI. The RPI is configured with Apache2, thus having a Web server to display the Web pages being available on /var/www. The above steps allows the Raspberry PI to act as a village server and displays the Yeboo.com pages locally.
Wisam:
- Configuration of the LNCCs according to the DigI project certificates and filtering files.
Documentation: .... - documented the process on OwnCloud (steps described in Owncloud = DeviceConfiguring = LNCC RBD52G)
- download a copy from Yeboo.com (Web server) and install on RPI
- linking each village server (RPI) to the local LNCC used
- documented the steps for download, and link of the RPI on OwnCloud (steps described in Owncloud = DeviceConfiguring = RaspberryPi_VillageServer)
Hamed:
- download a copy from Yeboo.com (Web server) and install on RPI
2.B) Remote configurability of both LNCC and RPI.
Implementation by Hamed with support from Maghsoud.
Allows us to configure the RPI through the LNCC from "anywhere in the world" using maincorerouter.basicinternet.org. The LNCC, once connected to a network, will announce itself to our central server. Our central server will provide the LNCC with an IP address
Testing should be performed in the Labs at Kjeller, or/and at Muhas (TZ). Testing includes the IP address of the LNC.
Question:
- Maghsoud: When we have configured and tested, and then send to TZ, will the IP address change? How can we establish a link between the IP addresses (seen on our central server) and the MAC address of the LNCC?
Next steps
- RPI configuration
- Documentation of the remote configurability process
3) Configuring, testing, sending and repair
Wisam:
3.1 Ordering the needed MikroTik equipment for the coming information spots implementation. Configuring the equipment (LTE, LNCC, and Village server) and in case of extension spot (Sector antenna, Point reception, and Local hot-spot)
- The configuring processes are documented on OwnCloud (steps described in Owncloud = DeviceConfiguring = ....)
3.2 Test plans are established for each village on OwnCloud (steps described in Owncloud = DigI-Vision 2030 = Village_installations=...) and sent to the local representer for installation work
3.2 Shipment The Mikrotik / information spot equipment will be shipped via an international carrier from the headquarter in Norway to the DigI team presenter in TZ. For now, Bernard is the person in charge for receiving the equipment and go through the clearance process.
3.3 Acceptance test in the field Initial testing - After receiving the equipment from the customs office, an initial test will be accomplished for the equipment set, usually in Dar Al-Salam, to figure out if the are working as expected before sending them to the field. That test is normally done by Felix. Then, the information spot set will be shipped to its final destination, the targeted village.
First installation - LTE Antenna: insert SIM card, connect cables, POE, power source test, and check that lights are working. A detailed connecting and testing document is available on OwnCloud (steps described in Owncloud = DigI-visjon2030 =Village_installation= ....) LNCC router: connect the Internet wire coming from the LTE to port 1 on the LNCC, connect the LNCC to power source, and check if the power light is lightning green on the back side, in order to establish a local network /wifi. Village server/ RPI: connect the RPI to electricity using the charger, normal Samsung mobile charger, and check if the power light is blinking/on. Then, connect the PRI to port 2 on the LNCC using an Internet wire.
3.4 Testing in the field
3.5 Error testing in the field
When the equipment (LTE, LNCC, Village server) are deployed in the field, the user should be able to perform simple steps to check the configurability. Through our central equipment, we are able to connect remotely to the LNCC and the RPI (if they are on the network).
A user being at the the site can test the following:
- 3.5.1.' I look for Wifi "BasicInternet", and connect to Wifi.
Success: I can connect, next step 3.4.2.
Failure: I can't connect, go to step 3.4.4.
- 3.4.2. The user opens a browser (e.g. Chrome) and connects to Yeboo.com (or Yeboo)
Success: The health information page (see Figure 1) is shown, and the hotspot works as planned
Failure: Web site not found. Goto step 3.4.3. - 3.5.3 In the Web browser, type google.com. If google.com is not shown, then we have no network access. Potential sources: No credit on the SIM card, Devices not working, Cables unconnected/loose
- 3.5.4 Check the equipment:
Is the light blinking at the back of the LNCC? If not, disconnect the power, reconnect and see if the lights come up. Check if you have electricity. If the LNCC still does not work, we need to replace (step 3.5)
Check the RaspberryPI
Question: What happens if the RPI is "dead", what will the user see when typing Yeboo.com?
3.6 process for replacement
Get into contact with the Foundation,
Make sure that all LNCCs and the corresponding RPIs are connect to the network, either in the villages
Check out: preferably through WhatsApp Info +47 2228 42.... (business WhatsApp)
4) Reporting
User story: Goal of the DigI project is to report usage of the local resources from the health information spot. This reporting has two aspects, the reporting from the LNCC on usage and the specific reporting from the RPI
4.1 Reporting rom
5) Voucher sales
Voucher platform
Sales process