The Wizard Gecko WGM110 Wi-Fi Module supports the following extensions of WPA2-Enterprise:
EAP-TLS
PEAPv0-MSCHAPv2 / PEAPv1-MSCHAPv2
PEAP-MSCHAP uses certificates + username/password, EAP-TLS uses just certificates. User certificate is optional in PEAP but mandatory in EAP-TLS. In all cases the root certificate must be provisioned to the module just like in TLS (for more details on how to manage certificates please refer to "AN974: Wizard Gecko TLS and SMTP Example" available from the WGM110 document library).
This article shows how to use the NIST Internet Time Service (ITS) to synchronize the Wizard Gecko WGM110 Wi-Fi module's internal RTC (Real Time Clock).
There are different ways to sync up time through the internet but for this article we selected the Daytime Protocol (RFC-867) over TCP. For this protocol the NIST ITS is listening to TCP port 13 and once a client connects it will send to the client the data representing the current time.
The standard does not specify an exact format for the Daytime Protocol, but requires that the time is sent using standard ASCII characters. Please visit the NIST link above to learn more about format used by NIST.
Requesites
This project is in many ways similar to the gmail example from the SDK.You will need an AP with internet access and the WGM110 WSTK because the LEDs on the kit are used to signal AP connection and on-going NIST query, and the push buttons are used to print the RTC time over UART and initiate the NIST query.
BGScript Project
Before building and flashing the project to the WGM110 it must first be modified with the credentials of your AP with internet access. The file sta.bgs contains the BGScript code that manages the AP connection and the comments there will guide you to write your AP's SSID and password.
Once you flash it to the module on the WSTK it will turn on LED1 which indicates that it has successfully connected to the AP. The application will now be waiting for the user to push PB0 to initiate the NIST query.
NIST Query
To retrieve the current time from the NIST ITS server it is first needed to resolve the hostname with the command below where nist_server_name = "time.nist.gov":
When the hostname has been resolved the event tcpip_dns_gethostbyname_result is raised where the hostname's IP is given. Then the TCP connection can be established on port 13 using the command:
Once this is done it's just a matter of a few seconds and the server will send the ascii string with the current time which is captured with endpoint_data event. When the data is received the string is parsed and the values are used to set the time in the RTC.
# The response starts with '\n', so the first year character is on index 7
call util_atoi(2, data_from_server(7:2))(year)
call util_atoi(2, data_from_server(10:2))(month)
call util_atoi(2, data_from_server(13:2))(day)
call util_atoi(2, data_from_server(16:2))(hour)
call util_atoi(2, data_from_server(19:2))(minute)
call util_atoi(2, data_from_server(22:2))(second)
# Year needs to be added to 2000
call hardware_rtc_set_time((year+2000),month,day,hour,minute,second)(result)
The NIST response is also fully printed out to the UART when it's received for visual confirmation by the user.
Printing RTC Time
When the user presses PB1 the WGM110 will print out the current RTC time. This way it is possible to see the time before and after the NIST ITS sync to confirm that it has been done correctly.
If you press PB1 before the NIST ITS sync you'll see that the default time after RTC initialization is 1/1/1970 0:00:00. This has not been selected randomly, it's the starting point for the UNIX time which counts the number of seconds elapsed since this point in time.
After sync with NIST ITS you can press PB1 again to confirm that the data was correctly parsed and the RTC was updated correctly. The NIST gives the current UTC time so it needs to be adjusted to your particular time zone.
This article will show how you can host a JavaScript-based Space Invaders game on the WGM110 HTTP server and play the game using the push buttons on the WSTK and the expansion board.
For better understanding on how the WGM110 HTTP server works we recommend to read "AN967: Wizard Gecko WSTK Demo Walkthrough" available from the Document Library.
Preparing the Project
Before detailing how the demo works let's setup the project so it can be built and flashed into the WGM110 with the Wizard Gecko BGTool. To learn how to build and flash a project please the WGM110 Getting Started video.
BGScript
Download the zip file attached to this article which contains the BGScript and project/hardware configuration files.
JavaScript Space Invaders
Due to unclear license terms we will not distribute the source code for this space invaders implementation. Instead download the Space Invaders JavaScript source from this git repository and extract it to the same folder where you have the BGScript project. Your folder should then look like the image below.
The files following files are not needed so you are free to remove them:
.gitignore
README.md
screenshot.jpg
Adding WSTK Controls
The game takes input from the keyboard left/right arrow keys and space bar (for shooting the aliens) but we also want to be able to feed those controls from the WSTK and its expansion board. You should then copy the code snippet below and paste it between the toggleMute function's closing bracket and </script> tag in the index.html file.
var myControlObj = { "button_shoot": 0, "button_left": 0, "button_right": 0 };
var xhr = new XMLHttpRequest();
xhr.timeout = 10000; //10 seconds timeout
xhr.onreadystatechange = function() {
if (xhr.readyState === 4 && xhr.status === 200) {
myControlObj = JSON.parse(xhr.responseText);
getButtonsValue();
readControls();
}
};
xhr.ontimeout = function() {
readControls();
};
readControls();
/**
* Function for requesting the controls
*/
function readControls() {
xhr.open("GET", "/api/controls", true);
xhr.send();
}
/**
* Function for parsing the button values
*/
function getButtonsValue()
{
var iButton_shoot = myControlObj.button_shoot;
var iButton_left = myControlObj.button_left;
var iButton_right = myControlObj.button_right;
// Sanity checks
if(iButton_shoot != 0)
game.keyUp(32)
if(iButton_shoot == 0)
game.keyDown(32)
if(iButton_left != 0)
game.keyUp(37)
if(iButton_left == 0)
game.keyDown(37)
if(iButton_right != 0)
game.keyUp(39)
if(iButton_right == 0)
game.keyDown(39)
}
What this code does is issuing GET requests for the status of the control buttons on the WGM110 and parsing the response (more details further down).
After this the project is ready to be built and flashed into the WGM110.
Running the Demo
After the project has been flashed you will see LED0 turn ON which means that the WGM110 is in AP mode. If you open your Wi-Fi networks list you should see "Space Invaders" network which you can connect to freely as it is an insecure network.
Once you are connected to the network open the browser and type the WGM110's IP address 192.168.1.1 which will load the front page.
To start playing you can either press Space bar on the keyboard or PB0 on the WSTK which will take you to the game.
To play the game you must use PB0 on the WSTK (for shooting) and BTN3/BTN2 on the expansion board to move left/right.
Project Walkthrough
When you type 192.168.1.1 into the the browser it will issue a GET request for the root resource ("GET / HTTP/1.1") to which the WGM110 responds with the content of index.html file. This is the default behavior of the WGM110 HTTP server when the root path '/' is set to either the Flash or SD-Card. That is followed by GET requests for all the other relevant files. The transactions are visible in the wireshark log below.
The highlighted frame is the GET request for the resource "/api/controls" which is not handled automatically by the WGM110 HTTP server but rather by the BGScript code as the response must be built with the status of each of the push buttons.
Looking closer into the HTTP response to "GET /api/controls" request it is visible the JSON formatted data with a value for each button. If the value is 0 it means that the button is being pressed, otherwise it is different from 0. The value is the direct response result of hardware_read_gpio command with the bitmask set for the relevant pin.
When the BGScript application receives the HTTP requests it will check if any of the buttons has been pressed by looking at the the status of button_change variable. This variable is set inside the interrupt handler which is triggered by either a rising or a falling edge on any of the button pins. This is to make sure that no button press is missed in case it happens in between responding to an HTTP request and receiving a new one.
# Event received when REST API request is called
event https_api_request(request, method, resource_len, resource_data)
api_request = request
if resource_len = API_MEASUREMENT_RESOURCE_LEN && memcmp(resource_data(0), API_MEASUREMENT_RESOURCE(0), API_MEASUREMENT_RESOURCE_LEN)
if button_changed then
# If there has been a button change in between sending the last response and getting the new request then responde immediately
call api_handle_control_request(request)
else
# Otherwise set a one-shot timer to respond 5 seconds from now at the latest
call hardware_set_soft_timer(HTTP_REQUEST_TIMEOUT, HTTP_REQUEST, 1)
end if
end if
end
If button_changed is already set a response will immediately be sent with the latest button status which are read inside the interrupt handler. If it hasn't been set then a soft timer is initiated with a 5 second timeout. This is because HTTP requests don't need to be responded straight-away and this way we avoid an unnecessary flow of HTTP requests/responses. However, if any of the buttons is pressed during those 5 seconds then a response will immediately be sent, again to ensure minimum latency.
event hardware_interrupt(interrupts, timestamp)
if interrupts = $0004 then # When pressing button PB0 at the eval board
# Flag the button change and read the status
button_changed = 1
call hardware_read_gpio(GPIO_PORTA, $0004)(result, button_shoot)
# If there is a request waiting for response then respond immediately
if api_request != -1 then
call api_handle_control_request(api_request)
end if
end if
On the browser side the GET requests are being sent as soon as the response for the previous request has been received. When the JSON formatted response is received it will parse the values to emulate actual keyboard key presses by calling game.keyUp/game.keyDown with the adequate value (32 for space, 37 for left arrow key and 39 for right arrow key).
Wi-Fi Knowledge Base
WGM110 - Which WPA2-Enterprise extensions are supported?
WGM110 - Sync with NIST Internet Time Service
Space Invaders on WGM110