Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- en:iot-open:remotelab:sut:generalpurpose2:u2 [2019/08/01 09:09] – pczekalski
+++ en:iot-open:remotelab:sut:generalpurpose2:u2 [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-==== U2: ====
+==== U2: Exposing access point (AP)====
-//Give few words about this scenario. Provide some objectives and impact on the students.//
+In this scenario, you set up your own access point. Please note, in this case, a number of devices you can connect to the AP is really limited. VRELs 1, 2, 3 and 4 are physically located together, while VREL 6 and VREL 7 are in two remote locations, thus you may not be able to reach hosted AP.
 === Target group ===
-//This hands-on lab guide is intended for the Beginners/Undergraduates/Masters/Professionals. Choose appropriate.//
+Undergraduate / Bachelor / Engineering Students
 === Prerequisites ===
-//Provide prerequisite readings/hardware/software/software libraries/skills if other than stated in the Laboratory Description. If none, remove along with the header. Please note some of those may be common for all scenarios (i.e. mqtt library), so provide it in the laboratory description level, not in the scenario level.//
+You need to know how to handle 4×20 characters LCD screen. In case of doubt re-work on scenarios B1 and B2.\\ <fc #ff0000>Warning: In no case should you give your AP the ''internal.IOT'' SSID name! You will mess up the laboratory environment and block other users from accessing network infrastructure. We consider this behaviour as hacking and it will be penalized under legal jurisdiction!</fc>
+<note warning>In no case give your AP the ''internal.IOT'' SSID! You will mess up the laboratory environment and block other users from accessing network infrastructure. We consider this behaviour as hacking and it will be penalized under legal jurisdiction!</note>
+To fully experience this scenario, you need to book another node (one of 1,2,3 or 4), to let the other node act as your networking client. You can use scenario U1 for this purpose but mind to update network SSID and passphrase in your code, to let it connect to your server. <note tip>Students physically present in the SUT IoT laboratory room 320 may use their own devices like laptops or mobile phones to connect to your AP.</note>
 === Scenario ===
-//Describe scenario to let the user understand its idea and process. Write information about the approach, algorithm, etc. (depends on the lab). Provide useful information about protocols, assumptions, addresses (i.e. communication servers), credentials, etc.//
+In this scenario, you will set up an access point and present on the LCD screen number of clients connected. The devices that connect to your AP obtain automatically an IP address from your AP so actually it hosts a DHCP server out of the box! The IP range is from the ''192.168.4.x'' subnet, but you can configure it for another one if you only wish via ''wifi.ap.shcp.config()'' function. if you use the default configuration, your AP is 192.168.4.1.
 === Result ===
-//Describe expected result when scenario is finished.//
+On the LCD you should present that AP is active, its name (SSID) and passphrase (select one no longer than 20 characters, to fit single line). In the last line of the LCD, there should be present a number of connected devices.
 === Start ===
-//Write starting conditions, i.e. what to do at the beginning, what to pay attention before beginning, how the mechanical part should look like,  etc.//
+Define some identifiers to separate and update AP's SSID and passphrase easily. To format lines for the LCD, we suggest using a char buffer of 20 characters (one full line) and some 2-3 integers for iterators. Remember to declare the LCD control class in your code. You do not need to instantiate WiFi communication class - as you have only one interface here, it is singleton class you can refer directly using ''WiFi''. you will use ''loop()'' to display a number of connected devices to your network. There do exist asynchronous way (event-based) to do it, but here we use a simplified, blocking approach. If you want to test the other one, refer to the ESP8266 WiFi implementation for Arduino documentation.
 === Steps ===
-// Write some extra information if i.e. some steps are optional otherwise cancel this paragraph (but do not remove header).//
+Following steps do not present full code - you need to supply missing parts on your own!
 == Step 1 ==
-//Describe activities done in Step 1.//
+Include all necessary libraries. The minimum set here is:
+<code c>
+#include <Arduino.h>
+#include <ESP8266WiFi.h>
+#include <LiquidCrystal_I2C.h>
+...
+</code>
+== Step 2 ==
+Give it some definitions as identifiers for cleaner code, remember to change ssid name to yours!
+<code c>
+#define wifi_ssid_ap put_your_unique_id_here //give it some unique name-change here
+#define wifi_password_ap "1234567890"
+</code>
+<note warning>Never use ''internal.IOT'' as your SSID name ''wifi_ssid_ap'' - you will overlap existing network infrastructure and we consider it as hacking that is subject to jurisdiction! Your account will be imediatelly banned!</note>
+== Step 3 ==
+Print some information about starting software WiFi AP, configure network interface as a WiFi AP and give it a try to start:
+<code c>
 ...
+  delay(10);
+...
+  WiFi.mode(WIFI_AP);
+  delay(100);
+  boolean result = WiFi.softAP(wifi_ssid_ap, wifi_password_ap);
+  if(result == true)
+  {
+... //Announce success, print status, SSID and passphrase to the LCD
+  }
+  else
+  {
+... //Announce failure. Print it on LCD
+  }
+...
+</code>
-== Step n ==
+== Step 4 ==
-//Describe activities done in Step n.//
+Implement in the ''loop()'' an information about number of connected clients, i.e. like this:
+<code c>
+...
+void loop()
+{
+  lcd.setCursor(0,3);
+  sprintf(buffer, "Stations: %d", WiFi.softAPgetStationNum());
+  lcd.print(buffer);
+  delay(3000);
+}
+...
+</code>
 === Result validation ===
-//Provide some result validation methods, for self assesment.//
+Check your AP is active on LCD eventually observe failure. If works OK, compile U1 scenario on another node(s), mind to update SSID and passphrase in the U1 source code then observe if connected clients counter increases.
 === FAQ ===
-This section is to be extended as new questions appear. \\
+Do I need to use WiFi.mode(WIFI_AP);?: Yes, please do. Theoretically, if consecutive compilations use AP (software server) mode of the ESP8266 wifi interface, your code may work without it. However, you never know if the previous user used STA or AP (or both). Your code may fail then if not explicitly stated!
-When using the printed version of this manual please refer to the latest online version of this document to obtain the valid and up-to-date list of the FAQ.
-//Provide some FAQs in the following form:\\
-**Question?**: Answer.
-//

en/iot-open/remotelab/sut/generalpurpose2/u2.1564650557.txt.gz · Last modified: 2020/07/20 09:00 (external edit)