Anyone here ever worked with the Air602 module?

https://www.seeedstudio.com/Air602-WiFi-Module.html
http://wiki.seeedstudio.com/Air602_WiFi_Development_Board/

It's a very affordable WiFi module that I plan to integrate into a project of mine, using a PIC16LF1454 to control it. But the website's help is a little sketchy, and the quality of its English leaves a bit to be desired.

 

Finally got the samples, both of the module and its development board. I'll be posting (most likely "in the blind", since no one has shown interest yet) my progress here as a means of logging it. And also for posterity, in case a single soul out there ever gets interested in the subject.

 

I'm back.

It's now time to set out and explore this WiFi communications tech, which up until now has been almost completely alien to me.

After doing a little research, and partially following the instructions on the development module's "Getting Started" webpage, I was able to wirelessly connect the module to my home network.

The way it works is you plug the module to a USB port, and it then inserts itself in the computer's hardware as a serial COM port. In my case it was COM9. From there, I used a Hyperterminal style serial communication program to communicate with the module using AT commands. I've attached the module's "AT Command User Guide" as a reference. The communications software that I used is a nifty little app called Termite, which is well withing my price range... that means it's free.

After some tinkering, this is how I finally made things work:

1. Connect the module to the computer
2. Check the computer's device manager to see to which COM port number the device has attached itself to. In my case it was port 9
3. Start the communications software, and configure it to COM9, 115200 bps, 8N1, no handshake. In the software's settings, make sure that the "Append CR-LF" option for transmitted text is checked.
4. Type in the following commands:

    AT+                                                           ;establish connection
    AT+RSTF                                                       ;Reset to factory settings
    AT+Z                                                          ;System reset
    AT+WSCAN                                                      ;Scan for available networks
  
    AT+WPRT=0                                                     ;change to WiFi to STA (static) mode.
    AT+SSID=JardÃn César                                         ;set SSID as the network's name one wants to join.
    AT+APENCRY=1                                                  ;set secuirity mode to WEP64

    AT+KEY=1,0,XXXXXXXXXX                                         ;set the wireless network password to XXXXXXXXXX
    AT+NIP=1,192.168.1.25,255.255.255.0,192.168.1.25,192.168.1.25 ;set the ip address and subnet mask
    AT+PMTF                                                       ;save above parameters to spi flash
    AT+WJOIN                                                      ;join wireless network JardÃn César
    AT+SLIST                                                      ;Query the STA information which connected to your SoftAP  
    AT+LKSTT                                                      ;to find out the IP address of the Air602 module
  
    AT+CNTPARAM                                                   ;query the configured network's parameters
    AT+WLEAV                                                      ;disconnect from network

• Line #1 is there to make sure that the module is connected and responding. In this case, it will answer with a simple "+OK"
• Line #2 is not really necessary, but it's there so that the module will start from scratch, to undo any unwanted configuration changes made by all of my previous attempts at communication with the module.
• Line #3 is necessary for the previous factory reset to take effect
• Line #4 commands the module to scan for available WiFi networks. In my case, there are two networks, one's called "Casa Cesar" and the other one is "Jardín César". But the special characters in the latter network's name makes it look like "JardÃn César" to the module. That's the network that I'll connect the module to.

The next lines have all to do with setting the device's parameters properly for a successful connection.

When I finally typed "AT+WJOIN", the device responded with a successful connections message: "+OK=862aa80dfd35,0,6,1,"JardÃn César",59"

​

After that, I opened a command window, and pinged the device to confirm that it was connected to the network... Success!

​

 

Now that I've been able to connect this thing to the network, the following questions need to be answered:

1. In the previous example, I attached the device to a fixed network address: 192.168.1.25, I need to learn the network's rules to find which address ranges are legit. For example, I tried connecting the device using 192.168.25.1 and failed. I'm sure it has to do with "legal" rules when assigning addresses to devices. Of course, one can tell I'm a complete neophyte in this subject... but I'm taking baby steps here.
2. Instead of me assigning a fixed address that I know is available in my network, how can I make the device automatically find itself a free address to connect itself to?
3. On the software side of things, what would be the best way to find my device's address among the plethora of all of the other connected devices?
4. So I connected my device to my network... that's great. What's next? How do I transmit information between the device and my computer?. I mean, no problem, the device has UART compatible I/O lines that I can easily connect to an MCU. And I can make said MCU communicate with it via the already shown AT commands. But how do I transmit data to and from the device? In example, I like programming in Visual Studio's VB, so what set of instructions should I be looking at to apply to this task?

@MrSoftware , I have a hunch you may be able to help me out with that last question, if it's not too much bother.

 

So far, I can tell that what I want to do has something to do with creating socket connections... I have no idea what a network socket is... need to look it up and understand things more.

 

A faint voice preaching in the desert César...but one day you will be rewarded.

 

A faint voice preaching in the desert César...but one day you will be rewarded.

*laugh*.... thanks for that ... believe me, I know someone will eventually get interested in this thread, and then things will move faster and smoother.

This topic is probably too advanced for most, or not applicable to their interests... or both... but you have to admit it's fascinating stuff, because a stamp-sized $2 dlllr WiFi module capable of connecting any trinket to the web is too good a thing not to learn how to use it...

 

I am interested in it so far, what kind of applications would this be suited to, I assume that it would be for a stand-alone device to operate over the internet?
So far I haven't done much with WiFi or blue-tooth etc.
Max.

 

I've no experience with building wi-fi stuff, or immediate plans to start, but your practical investigations are certainly interesting, Cesar. Thanks for sharing.

 

I am interested in it so far, what kind of applications would this be suited to

I cannot share the specifics of this project, but I can definitely tell you about its general points:

Imagine a device with a sensor which is battery operated and has an extremely long lifespan before changing the batteries becomes an issue. In this case, according to calculations done around my design, the batteries should last between 7 and 9 years, tops.
This device lies semi-dormant (consuming an itsy bitsy tiny amount of current, in the order of nA) until an event triggered by its sensor wakes it up.

What happens next is:

• The device wakes up and gathers all the pertinent data.
• It then connects to a predetermined WiFi hotspot, and sends said data either to a website, or to a server, where specific software analyzes it.
• Said software contacts the user through their phone, and requests attention.
• The user sees the message, and decides either to take action, or let things be.
• If the user does not respond after a given amount of time (because he's asleep, out of town, his phone's turned off or whatever) then the device itself takes action according to pre-programmed criteria, and generates a report that the software will keep in a log. The user will later find out what happened when he looks at or turns his phone back on.

One could say that the device is its own master, and that it's ready to take action on its own if neither the server nor the user respond.

That's the purpose of this project.

 

I think I've figured it out... at least the communication between the device and computer side of things ... I'll be back shortly with a full report...

​

 

Alright, this is the way I'm understanding things at this moment:

• One needs to configure the Air602 module either as a client or a server for things to work. And the other device to which it will be establishing communications with (in this case, the computer) needs to be configured the opposite way. The normal operating mode would be to set the module as a client, and the computer as a server.
• An IP number needs to be affixed to the device, so it will know its address within the network. We've already gone through that in the previous posts.
• A "socket" needs to be created in Air602 module, so that communication can be established with the server. This socket is defined as the protocol to be used (in this case TCP) the IP address of the server (the computer with which it will be establishing communications), the remote "port" number, and the local "port" of the device. One can think of a "port" as a channel that is created in the IP address being referred to through which communications will be transmitted and received.
• Once that socket is created, one needs to run a small program in the computer which task will be to receive whatever the device is transmitting, and to send information to it when requested.

This is how things went:

• The first line shown at the Termite window requests a socket being created using TCP protocol, in client mode, with the computer having the IP number 192.168.1.75 (which is the IP assigned to my computer by the network, which was verified using the ipconfig command), using port 1000 at the device, and port 1000 at the computer. The manual says that the device can be connected directly to the internet, establishing communication with a specific website, but I'll leave that exercise for much later when this project is well within way.
• The second line confirms that socket as created, and assigned as number one.
• At the SocketTest window (another nifty free app) a server connection service was started using the computer's IP address, and assigning it port 1000. This was confirmed when the software reported "Server Started on Port: 1000"
• As soon as the socket creation command was executed at the module, the SocketTest detected it and confirmed it reporting the message "New Client: 192.168.1.25"
• Next, the following message was sent from the server: "Buenos días, güey" (good day, dude) to the device.
• The command AT+SKRCV=1,18 was executed at the device. The command states that 18 characters will be received at socket #1. The device responds with an +OK=18, and then displays the characters received from the server. It is important for the server to first send the characters before the device requests their reception, otherwise things won't work.
• The next test consisted in sending a message from the device to the computer. It has a similar format to the previous command: AT+SKSND=1,30. That is like saying: "send the next 30 characters through port #1".
• The line "Greetings to my friends at AAC" was sent from the device, and the SocketTest software reported them as received within its conversation window.
• One can disconnect either one of the participant devices in the connection by either telling the SocketTest app to disconnect, or executing the AT+WLEAV command at the device

​

That's pretty much it. I haven't yet figured how to send special characters such as <Enter>+LF (chr[13]+chr[10]) but I'm not worried about that because I'm pretty sure those are limitations of the Termite and SocketTest apps. And I don't think sending special characters from an MCU should be a problem at all because I've done it many times before through its UART.

My next, and possibly hardest task, will be to figure out how to:

• Automatically detect the network to connect to
• Automatically grab an available IP address and record it in the device
• Automatically connect and disconnect from the server software when needed

 

One last observation. The documentation from both the Air602 module as well as its core chip (the Winner Micro W600) both *suck*. Most of the documents are confusing, lack clarity of structure, have visual formatting deficiencies, have lots of typos in them, and sometimes have conflicting/contradicting statements. Not to mention that they're are also completely lacking in context most of the time. In short, the documentation is an ergonomic disaster. It's been through careful observation and a bit of trial and error that I've gotten this far.

One of the reasons I'm recording my progress in this thread is to make it easier for future users to learn its use. And who knows, maybe I'll also learn new things from them in the process, if anyone chooses to participate.

You're welcome, Winner Micro.

 

Well, it seems that I've finally done it.... I've bricked my device.

I had been trying to enable DHCP working mode to no avail. I tried everything mentioned in the manual, and I just couldn't make it work. I could only communicate with the device using a static IP address.

Stupidly, I followed the instructions mentioned in the very last page of the manual on how to enable "Transparent transmission application in automatic working mode". What that's supposed to do is set the device to automatically connect to a socket as soon as it's powered up. But one of the instructions sets it in DHCP mode, which as I've already mentioned, does not work.

Predictably, as soon as I saved the changes and rebooted the device, it simply locked up. The reason being (I believe) that since DHCP does not work, it will never be able to create a IP address on its own, and so it's locked in an endless loop trying to communicate through a socket using a nonexistent IP address.

The next few hours were spent trying to figure out how to make the device reset to its factory settings, or at least to break said loop and see if I could communicate with it somehow.... I failed in all instances...

Fortunately, I still have four more of those $2 dlls modules with me to work with.

Stupid Winner Micro...

 

No any "factory reset" of sorts?

 

No any "factory reset" of sorts?

Not activated through hardware. The only way to effectively reset it is through software... and that's definitely hung and locked up

 

Well, it's been a while, but I thought it pertinent to report back here with my results.

After much guessing and testing, I've finally found how to properly use this module. Its documentation definitely sucks, but it's better than nothing I guess. One thing that is not yet enabled in the modules is their WiFi direct capability, even though their specs boast about it. No matter how many different combinations I tried, there is just no way to enable said operating mode. But fortunately I was able to circumvent that by setting the Air602 module as an access point and open a server socket within it, and then set whatever device connects to it (in my case, a smartphone) as a client.

I now know enough about this little piece of hardware to write a tutorial about it if I felt like it (I'm not). If any of the members in this forum is interested in using these modules as part of a project, let me know.

 

After much experimenting, I'm about to finally install the module on one of my circuits so that a PIC16 will be able to interact with it. But now I've run into a conundrum... one of the module's pins (pin #2) is intended so that an antenna can be connected to it. I've been playing around with an evaluation board of said module, and I noticed that the antenna's connection is not as straightforward as one might think. In fact, after some measurements and verification, I found that the antenna is connected in series to what seems to be a ferrite (a small inductor whose resistance is about 0.015Ω), and also to a capacitor (1nF) connected to ground. Here's a couple of pictures, plus a diagram of the way I understand the antenna is connected to the module:

​

So I have three questions:

• Are said components absolutely necessary? Or are they more of a recommendation to filter and refine reception/transmission?
• Should the geometry of the antenna I plan to use be similar to the one present in the evaluation board?
• Is the length of the antenna important?

Here's a clip from the datasheet that might be pertinent to my questions:

​

@nsaspook, this sort of thing seems to be right up your alley, any thoughts? @joeyd999 awhile ago I followed one of your threads in which you documented your progress with a Bluetooth module, maybe you'll find this thread to be of your interest.

 

My head is officially spinning...

 

More questions:

How come some chip antennas need an L-C matching network and some seem they don't?

I.E. The Johanson brand needs one, and the Molex doesn't? Does it have to do with the fact that the Molex is actually a 3D antenna?

EDIT: I take that back... after careful examination of more documents and datasheets, it seems that ALL chip antennas need a matching network. Some simpler than others.