Roving RN-134 GSX Wifly and Propeller notes
T Chap
Posts: 4,217
Earlier in the year I posted a thread on the Wifly, I got busy and didn't get back here and I see there were a few posts to the original thread. Since then there is now a wireless forum, and I wanted to update some progress and notes on how I was using the Prop/Wifly combo.
The Wifly GSX RN-134 is a development platform for the RN-131 Wifly module. Digikey sells the 131 module (smt) for around 50.00, the RN-134 for around 100.00. The RN-134 takes just 4 connections to run it, power, gnd, tx and rx. I use it with the Propeller, and after many hours of testing, I find that it is a really nice gadget with a lot of possibilities.
The biggest issue on the Wilfy for me was understanding what modes to work in, and trying to understand terminology with very little networking experience. I found that creating an app to manage the Wifly really helped both in learning networking protocol, and in making quick adjustments for testing. Granted, you could configure the Wifly direct from the Propeller with strings.
One thing that I did that had some advantages for my experiments was to learn a little bit of php. With different pages parked on a server somewhere, a php page could be dedicated to some useful work, and the Prop/Wifly only had to call up the page and include any data with it(GET/POST), and the php page would do whatever it needed to do ie write or read to a mysql db, send emails etc. With this intermediary approach, it would be much easier to modify the php page (simple text files) versus having to access the Prop/Wifly... which might be not easily accessible at times. Also, some side benefits of using a mysql DB as part of the intermediary, is that you could send a command to the Prop indirectly using the DB, and the Prop could be scanning the DB at X frequency looking for instructions. If the Prop/Wifly goes offline for some reason (mobile internet for example), as soon as the internet is restored, the Prop can get messages that were sent earlier. Another thing I did was to have the Prop writing a time stamp to the DB on each check for instructions, so that it was easy to monitor the DB for the Prop/Wifly status and last communication. Obviously there is a slight time lag with the intermediary, but if direct communication was required, that would be simple enough too if you had the IP of the Wifly. That brings up another point. I find that using wifi cams were a headache trying to get DYNDNS to be reliable. So I made the Prop constantly open a page that would provide the current IP (like I mentioned, mobile internet), the page would respond with the IP, the Prop would parse out the IP, and post the IP back to the database as well as email the current IP to the user. So, to access the Prop directly, simply get and use the IP that was posted to the DB. Now, many people would not be working with wireless (mobile) internet, so some of this is moot. But, for a remote gadget on mobile wireless, this round about method has proved to be valuable.
What I do on the Prop, is to send out a GET or POST, then start waiting on a response. Since the project would not be looking for large responses, there was no need to park the info anywhere, just parse the responses by some method, and make use of the info. It is easy to have the Wifly act like a server, whereas the Prop can issue the response(page data etc). Port forwarding is required to use the server, and obviously the current IP. The tricky part was figuring out how to send requests with the right protocol, I don't think I fully understand it, but hacked together some code that was very reliable for the sites that were needed to communicate with.
Here is an example of getting the IP from a site:
There are a few main things to understand in terms of how the device 'flushes' data through, I prefer to use Set Com Size at 512 with a short Set Com Time around 10. This means it forwards in 512 increments what it receives, unless it times out at 10ms with no new data, in which cases it sends whatever it has already. Except for the flush time and size, most of the other values are set correctly for my setup in the photo as shown. One note, I do not enter values into the Wifly config for websites, servers etc. I send the info a la carte from the Prop. Otherwise trying to store many different configs in the Wifly with different webservers gets to be a hassle, because then you are constantly saving different configs, and having to load the configs each time you want to access a different server. It is better to just figure out the protocol and code it in the Prop. I have other examples as well that work besides the dyndns, including the db communication with php helper code. BTW, coding the protocol on the Prop for accessing the DB was a big hassle, as well as FTP. It is far simpler to code a web page with php, as the php page 'just knows how to access' db and ftp, then talk to the php page with get/post. You can definitely use the Wifly to talk to FTP or DB directly, and it can manage the protocol internally, but again, the added configs create their own issues.
The Wifly GSX RN-134 is a development platform for the RN-131 Wifly module. Digikey sells the 131 module (smt) for around 50.00, the RN-134 for around 100.00. The RN-134 takes just 4 connections to run it, power, gnd, tx and rx. I use it with the Propeller, and after many hours of testing, I find that it is a really nice gadget with a lot of possibilities.
The biggest issue on the Wilfy for me was understanding what modes to work in, and trying to understand terminology with very little networking experience. I found that creating an app to manage the Wifly really helped both in learning networking protocol, and in making quick adjustments for testing. Granted, you could configure the Wifly direct from the Propeller with strings.
One thing that I did that had some advantages for my experiments was to learn a little bit of php. With different pages parked on a server somewhere, a php page could be dedicated to some useful work, and the Prop/Wifly only had to call up the page and include any data with it(GET/POST), and the php page would do whatever it needed to do ie write or read to a mysql db, send emails etc. With this intermediary approach, it would be much easier to modify the php page (simple text files) versus having to access the Prop/Wifly... which might be not easily accessible at times. Also, some side benefits of using a mysql DB as part of the intermediary, is that you could send a command to the Prop indirectly using the DB, and the Prop could be scanning the DB at X frequency looking for instructions. If the Prop/Wifly goes offline for some reason (mobile internet for example), as soon as the internet is restored, the Prop can get messages that were sent earlier. Another thing I did was to have the Prop writing a time stamp to the DB on each check for instructions, so that it was easy to monitor the DB for the Prop/Wifly status and last communication. Obviously there is a slight time lag with the intermediary, but if direct communication was required, that would be simple enough too if you had the IP of the Wifly. That brings up another point. I find that using wifi cams were a headache trying to get DYNDNS to be reliable. So I made the Prop constantly open a page that would provide the current IP (like I mentioned, mobile internet), the page would respond with the IP, the Prop would parse out the IP, and post the IP back to the database as well as email the current IP to the user. So, to access the Prop directly, simply get and use the IP that was posted to the DB. Now, many people would not be working with wireless (mobile) internet, so some of this is moot. But, for a remote gadget on mobile wireless, this round about method has proved to be valuable.
What I do on the Prop, is to send out a GET or POST, then start waiting on a response. Since the project would not be looking for large responses, there was no need to park the info anywhere, just parse the responses by some method, and make use of the info. It is easy to have the Wifly act like a server, whereas the Prop can issue the response(page data etc). Port forwarding is required to use the server, and obviously the current IP. The tricky part was figuring out how to send requests with the right protocol, I don't think I fully understand it, but hacked together some code that was very reliable for the sites that were needed to communicate with.
Here is an example of getting the IP from a site:
PUB GetIP
ser.str(1, string("Getting IP")) 'serial port 1 is printing to terminal for display purposes
ser.tx(1, CR)
ex ' exit command mode, this insures the Wifly is not stuck in CMD mode from previous action
ser.str(1, string("---")) ' visual marker
ser.str(2, string("$$$")) 'port 2 is the Wifly, this enters command mode CMD
Viewreply ' this kills time, flushes any non useful data out of the Wifly
ser.str(2, string("open getip.dyndns.org 80")) ' address to open
ser.tx(2, CR)
Viewreply 'must wait for connection to open before sending GET, view any responses in the mean time to clear buffer
Viewreply 'time needed here to get connected
Viewreply 'kill more time, flush useless reponse
ser.str(2, string("GET /index.php HTTP/1.1"))
ser.tx(2, CR) 'must be CR
ser.tx(2, LF) 'must be LF
ser.str(2, string("Host: getip.dyndns.org"))
ser.tx(2, LF) ' two LF required
ser.tx(2, LF) ' CR or LF works, here is where the real response will start.
RecWifiData ' receive the response, load in whatever comes back, 512 bytes
ShowWifiResponse 'display what comes back in on the screen, parse the IP, check for connection close response
ser.str(1, string("::")) ' visual marker on screen to see completed code sent
There are a few main things to understand in terms of how the device 'flushes' data through, I prefer to use Set Com Size at 512 with a short Set Com Time around 10. This means it forwards in 512 increments what it receives, unless it times out at 10ms with no new data, in which cases it sends whatever it has already. Except for the flush time and size, most of the other values are set correctly for my setup in the photo as shown. One note, I do not enter values into the Wifly config for websites, servers etc. I send the info a la carte from the Prop. Otherwise trying to store many different configs in the Wifly with different webservers gets to be a hassle, because then you are constantly saving different configs, and having to load the configs each time you want to access a different server. It is better to just figure out the protocol and code it in the Prop. I have other examples as well that work besides the dyndns, including the db communication with php helper code. BTW, coding the protocol on the Prop for accessing the DB was a big hassle, as well as FTP. It is far simpler to code a web page with php, as the php page 'just knows how to access' db and ftp, then talk to the php page with get/post. You can definitely use the Wifly to talk to FTP or DB directly, and it can manage the protocol internally, but again, the added configs create their own issues.
1024 x 705 - 111K