For this project I wanted to build a webserver using the new Dexter IndustriesWifi sensor for the NXT. Dexter have produced a very exciting wifi sensor that you program through the RS485 port on port 4 of your NXT. The RS485 port can communicate with the wifi sensor at speeds up to 921600 baud, so your NXT can have high-speed Internet access!

The wifi sensor is cleverly packaged to communicate over the RS485 port using the classic AT command protocol which should be familiar to anyone who has used modems back in the 1990s (remember them). Essentially you send commands to the wifi sensor using ASCII text and the sensor responds over the RS485 link.

Dexter have not yet officially released this sensor, so everything I’ve done here is based off a prototype unit they kindly sent to me to evaluate. Treat this as an experimental project. Based on what I’ve seen this sensor has huge promise – NXT’s connected directly to a wireless network open up a whole new arena of robotics projects! But it is one of the most complex sensors yet attached to the NXT, and using it requires some extensive programming knowledge. Hopefully the examples I show below make life easier for all you hobbyists out there!

Wifi driver API

Based on work done by Xander Soldaat I created a set of NXC functions to speak to the Dexter wifi. They wrap the AT command exposed by the wifi sensor in NXC function calls. There is minimal error checking performed in this API; most of the function calls return a string variable. It’s up to you to make sure that the correct result was received!

The basic flow in using the Wifi sensor is:

Initialise the RS485 port on the NXT

Disable verbose mode on the wifi sensor (by default the sensor echoes back text strings for status messages and this is unnecessary

Tell the wifi sensor what network SSID to associate with

Set the WPA2 encryption passphrase (this takes a while as the wifi sensor has to compute the key and store it internally]

Enable DHCP to obtain an IP address from the network.

Start a server listening on port 80.

Consume data on the RS485 port which is sent by the wifi sensor.

Send an HTML page back to the wifi sensor on the RS485 port.

This appears simple, but the devil is in the details!

Building the webserver

The source code for the webserver is in a set of files which are built together to create the final executable. The files are:

diwifidriver.nxc: this is the core wifi driver file. It contains all of the functions that make it easy to work with the wifi sensor.

logging.nxc: the standard logging library I wrote about in a previous post that creates a user-readable log file so you can debug the webserver.

listener.nxc: the web server core code. You will need to enter the SSID and WPA2 passphrase for your wireless network on line 31 and 32 before you can compile this file.

The steps to getting a webserver up and running on your network on your NXT are:

Edit listener.nxc to set your SSID and WPA2 details. The Diwifi sensor supports WEP and WPA2 networks, but my code is only written for WPA2 networks.

Build the webserver as follows: nbc -r -EF listener.nxc. It will pull in the diwifidriver.nxc and logging.nxc files as needed.

The display on the NXT will show status messages as it initialises the DiWifi driver and connects to your network. You should see the MAC address for the wifi sensor displayed, and after some time an IP address displayed, as follows:

If you don’t see a MAC address displayed on the NXT screen then the NXT is not communicating with the wifi sensor correctly (probably incorrect baud rate set on line 58 of the listener.nxc file). Look at the listener.txt logfile on the NXT for clues – or you can mail it to me.

If you see a MAC address but do not see an IP address then the NXT can talk to the wifi sensor, but the wifi sensor didn’t connect to the wireless network for some reason. Check that you entered the SSID and WPA2 passphrase correctly.

When you see the IP address displayed you should be able to ping it from a terminal window on your PC (assuming that you are on the same network).

Open a web browser and try connecting to the IP address displayed; you should see a simple web page displayed!

If the browser connection fails, and you are comfortable on the command line, try telnet to port 80 and type “GET /” to simulate requesting a webpage. You should see HTML echoes back in the terminal window.

If all this fails then reset your wireless network (i.e. power cycle your wireless router), turn off the NXT and the DiWifi sensor, turn them all on again and try again 🙂

Utilities

•autoconn.nxc: this sets up the wifi sensor to attach to the wireless network and stores this as the default profile in the non-volatile RAM of the wifi sensor. What does this mean? Computing the WPA2 encryption key takes time so the wifi sensor will cache it in NVRAM. You can then #ifdef out lines 339-346 in the listener.nxc file to speed up the startup time of the webserver.

•sendcommands.nxc: a simple utility that reads AT commands a line at a time from a file named atcmds.txt on the NXT and then sends them to the DiWifi sensor. This lets you test and experiment with the sensor. The reply from the sensor is stored in results.txt file on the NXT.

•atcmds_setup.txt: this is a sample AT command script for the sendcommands.nxc program. It sets up the Wifi sensor; you’ll need to edit it to enter your SSID and WPA2 passphrase. Save it as atcmds.txt and then upload it to your NXT.

•atcmds_http.txt: this is a sample AT command script that opens a HTTP connection to a website.

•atcmds_dnslookup.txt: a sample AT command script that shows how to do DNS domain name lookups on the sensor.

Known bugs?

There are definitely some issues with my code. I absolutely promise you that there are bugs here – consider this an alpha release! If you spot any please let me know!

The wifi sensor can occasionally fail to connect to a wireless network. If this happens restart your wireless network and try again.

The parseHTTPRequest() function in listener.nxc is not used; it should work but as of right now it’s not fully debugged.

The sendWebpage() function in listener.nxc returns a simple static webpage.

The default baud rate of the Wifi sensor is 9600 baud at 8N1. This is pretty slow, so I’ve set mine to run at 115,200 baud.

I often see the RS485 connection losing data from the wifi sensor to the NXT. I’m not sure why this is happening. It seems to be an intermittent problem, and could be a bug in my code, or a bug in the NXC firmware. If you want to debug this I wrote a simulator (simulate.nxc) that pretends to be a wifi sensor. Install this program on a second NXT connected to the NXT running the webserver on port 4. All going well you should be able to simulate sending a request and receiving a reply.

Sending the webpage back to a browser works…. sometimes. Often the browser seems to hang as if the data connection wasn’t closed. Not sure why this happens, but I’ve found that starting a second connection to the wifi sensor will “unjam” the first connection and the browser will display the webpage.

The wifi sensor uses a 9V battery for power. And it will go through them quickly! I hacked a wall-wart 9V transformer to attach onto the battery clip so I could do extensive testing.