WifiFunctions - EyesOfThings/Software GitHub Wiki

Index

  1. Introduction
  2. Functionality provided
  3. WiFi power policies
  4. Limitations
  5. Dependencies
  6. Licensing

Introduction

In this task, software has been developed on top of the SPI driver, developed by Movidius, for the WiFi module CC3100MOD used in EoT. This software provides a layer of functions for creating an ad-hoc WiFi, establishing a connection with another device using the desktop and mobile APIs defined in Tasks Middleware API Desktop and Middleware API Android, sending/receiving data (of any kind) and closing connection. Moreover, the application developed in Task “Control Mode” directly depends on this.

images/wifiFunctions.jpg

The CC3100MOD can create an ad-hoc network and has security and encryption (WPA2). The ad-hoc WiFi allows connection with the external configuration computer even without WiFi infrastructure. Furthermore, since the SSID is public, an additional security feature is used: a network password. When using WPA, the password is a string between 8 and 63 characters long. When in place, this password is necessary to use the EoT device. The password is stored in the CC3100MOD’s flash memory and can be eventually changed (or removed) from EoT’s Control mode.

Functionality provided

The result of this task is a library called WifiFunctions, which is an abstraction layer between the Simplelink WiFi driver and the programmer. The functionality provided, apart from the Simplelink driver functions (check CC3100 programmer’s guide for more information), is as follows:

  • Generation of access point.
  • Connection to existing access points.
  • Scanning of the WiFi spectrum to find the less saturated channel.
  • Profile management for saving a previously generated access point, and reuse it when the device is restarted.
  • Ping.
  • Change own MAC address.
  • Set WiFi signal intensity and power policy.

WiFi power policies

The WiFi subsystem supports predefined power management policies which allow a host application to guide the behaviour of the power-management algorithm. The available policies are:

  • Normal (Default) – Features the best trade-off between traffic delivery time and power performance.
  • Always on – The WiFi subsystem is kept fully active at all times, providing the best WLAN traffic performance. This policy is user-directed, whereby the user may provide the target latency figure.
  • Long Sleep Interval – This low power mode comes with a desired max sleep time parameter. The parameter reflects the desired sleep interval between two consecutive wakeups for beacon reception. The WiFi module computes the desired time and wakes up to the next DTIM that does not exceed the specified time. The maximum allowed desired max sleep time parameter is two seconds.
  • Low latency power – This device power management algorithm exploits opportunities to lower its power mode. Trade-off tends toward power conservation performance.

WifiFunctions power management functions

  • i32 setWlanPower (_u8 power) --> This function changes the operational power of the device.
  • _i32 setPowerPolicy (_u8 policy) --> This function sets the device power policy.
  • _i32 sleepWlanDevice (int time) --> This function is used to make the device enter sleep mode.

Limitations

  • The Wifi chip only supports one client connection in AP mode. This was first observed by UCLM. This is not indicated neither in the Wifi manuals nor in the TI web. It is only mentioned in one post in the TI forum. We assume only one client will make the first connection to the EoT device. This, in fact, can be considered more secure. More clients can connect to the EoT device after connection to an external Wifi.
  • Potential conflict detected with FlashIO in the first hardware setup proposed over the SPI bus. This conflict is solved with EoT Rev1 board.
  • Nonblocking calls in the first version of WiFi driver do not work in server- related functions (accept and select, the timeout parameter does not work, so these calls block forever). Movidius subcontractor Emdalo sent additional code that uses the non-blocking call along with a wait, and another thread to signal the end of the wait, but this hack does not solve the problem completely. It will be solved in future versions.

Dependencies

No external dependencies.

Licensing

simplelink.h - CC31xx/CC32xx Host Driver Implementation

Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of Texas Instruments Incorporated nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.