Thanks Mr.Green
'
Sorry I wasn't more specific.
'
I'm looking for the hop frequency's that the WiFi uses, And mostly what the Parallax WiFi hop frequency's will use.
'
I can tune my wireless cameras to a different freq. but I'm limited to a small tuning band.
'
The cameras never effected my old WiFi router that was damaged by a lighting strike.But with this new router their problematic.
'
I've re-tuned my wireless cameras to work with the new router.
'
This leads me to believe that not all WiFi routers hop to the same Freq.
'
I fear I'm going to run out of tuning options on my cameras with the Parallax WiFi.
'
If my cameras won't work(cause interference) with the Parallax WiFi, I need to change cameras.
'
I have waited a long long time for a Parallax WiFi module, I just want to have ever thing in place for its deployment
Depending on the router and how you use it you may be able to turn off hop frequency and set the router to a channel that does not interfere with your cameras. Most wifi devices will scan the spectrum for active connections and use the same channel as the router.
Depending on the router and how you use it you may be able to turn off hop frequency and set the router to a channel that does not interfere with your cameras. Most wifi devices will scan the spectrum for active connections and use the same channel as the router.
' orthogonal frequency-division multiplexing
'
Sorry Franklin
'
I got all balled up on the WiFi _router_ programing routings.
'
The WiFi router has to deal with this freq. hopping.
'
Not the individual WiFi device.Like the Parallax WiFi unit.
Hey Bill, I've called in Kevin to comment on where we are with the WiFi module. I'm a bit tired of being his spokesperson on this issue, so. . . . here's Kevin!
Thanks a lot for taking interest the product! All of us around here are very excited about the module, and it is truly a great source of motivation to know that so many people are planning to buy this thing we've worked so hard on! ;-)
All the core difficult stuff is pretty much done, and now I'm finishing up the refinements to the user-interface in the firmware to make the module's configuration commands consistent and easy-to-use. As I've been working on the firmware, Jeff has been working on the graphical configuration tool (that runs on the computer), and the interface with the Stamp Editor and Propeller Tool. The next milestone is bringing the two together for direct functional/usability testing, which will be about 2-3 days from now. And once we're done making any last minor tweaks, we will run a pre-production prototype of the hardware and then follow almost immediately with full production. While Manufacturing is handling production, I'll be converting caffeine into product documentation so we can make the modules available to you right as they come out of the oven (well, after they are tested and packaged and Ken slaps a giant "Made in USA" sticker on them of course). ;-)
I don't know the specific date when they will be available for sale on the web, but we will definitely be letting everyone know as soon as we begin production. And at that point we should have a pretty clear estimate of when they will be for sale. I'll try to provide another update soon when we reach the next milestone (beginning production).
Truly thanks again for all the excitement you have all shown for this product's release. It give's us all a lot of inspiration in this final home stretch of the project!!
-Kevin McCullough
The reason it is an exciting product is because Parallax is producing it. This means quality and support are beyond match. A person like me can buy it and have a reasonable expectation of being able to use it because Parallax is the producer.
There must be a lot of pressure on you and other members of the team.
Hey, I was just reading through some of the posts from a little while ago and thought I might answer a few things related to the questions that were brought up...
--> Can you operate the module from your iPhone? Oh yeah!! I'm a little partial to Android OS... but really the module can be accessed from ANY smart phone. Or any device with a connection to the internet for that matter. There are an abundance of free apps which can be used to communicate with the WiFi module and therefore your robot or project connected to it. And one reason we are trying to make the configuration interface so simple and intuitive is to also make it really easy to write your own custom phone or computer apps to interface with your robot/WiFi module if you want to. Just like you would normally have to open a COM port to talk to the robot sitting on your desk using a serial connection, you would now simply open a TCP Socket to access that same robot from anywhere in the world (assuming of course that your robot is within range of a WiFi signal).
--> As far as existing devices (2.4GHz wireless cameras) interfering with the WiFi signal, it would be just as much a problem for any other WiFi-enabled device such as a phone, laptop, etc. as it would be for the WiFi Module. However, if those other devices are able to connect, then the WiFi Module should also be able to connect. In that situation, I would suggest setting up your wireless router (wifi access point) to operate on an RF channel that is at least a few channel numbers away from whatever your wireless cameras are using. This Wikipedia page describes the frequency ranges for WiFi RF channels: http://en.wikipedia.org/wiki/List_of_WLAN_channels. As permitted by the FCC, our module will be able to operate on channels 1-11.
--> To give a very brief description of the logical connections that can be made to the WiFi Module... there is a "Command" connection and a "Data" connection. The Command connection interprets everything as commands and is used to configure and/or run higher-level tasks on the module. Things like setting up saved WiFi connections, setting the UART's baud rate, or reprogramming an attached BS2/Propeller would be done over the "Command" connection. The "Data" connection is raw, transparent, no-questions-asked data. From your robot's perspective, it might as well be talking to a computer COM port. The Command and Data connections from the WiFi side are accessed on two different ports (which can be user-selected to any port numbers you want). The Command and Data connections on the UART (serial port) side are shared over the same physical UART, but are logically separated based on the current mode of operation.
The main goal is that you'll configure the module to know how to connect to your WiFi network(s), and from then on be able to use it to interface with your existing project just like you would a regular serial connection (except without all the wires to tangle and trip over of course). There are some more advanced things you can do with the module for users who want to get more into that (and we will be adding even more power-features in additional firmware updates), but we want the module to remain simple and straight forward to use by anyone - especially non-wifi-experts.
--> Will it work on the S2? It will most definitely work on the S2, and the original Scribbler too. In fact we will will have a specific version of the module to match the top-facing DB9 connections used on the Scribbler/S2 (in addition to the regular side-facing connectors on the BOE-bot and other boards).
Ok, now here's a question for you guys... even though you can reprogram your Basic Stamp or Propeller from your iPhone/Android Phone (using the WiFi module), can you think of a situation that would make you want to do that? A few people have asked in conversation if they will be able to reprogram their robot using their iPhone, and the answer is "Yes, you totally can" - but all I can think is that I would go blind trying to code Propeller objects from the comfort of my phone's tiny 4" screen. Controlling and accessing data on my robot from my phone is a totally different story; I'm big-time all for that. But what kind of applications can you think of where you might want to reprogram a microcontroller from your phone? Let me know. :-)
There must be a lot of pressure on you and other members of the team.
--Bill
Hey Bill,
We are definitely trying to push to get it out to market as soon as possible, but as far as difficulty it's actually mostly down hill from here. The hard, unknown, learning-curve stuff is behind us so we are getting a taste of the easier, satifying part of smoothing out the edges and watching stuff work. Certainly there are a few more minor challenges as we near production, but it's all very tangible now. It's kinda that feeling like when you work on a project for a long while and you get everything programmed, and all wired up, and then you finally flip the switch for the first time (gently) and the light actually turns on, and you're like "TOTALLY AWESOME!"... wait it's actually not "kinda" like that, it's exactly like that. :-)
@Bill, yes, Kevin is under some pressure but not too much because it has a reversal effective of loss of motivation. We all want the same result of completion and I'm already planning the WiFi Victory Party in expectation. You can appreciate the challenges of making a mixed RF/firmware/hardware design like this especially when you're part of the team. Usually a product design like this one has a whole team due to the variety of disciplines, but this is being completed by Kevin with some PCB layout help from Thomas and inside consulting from David. Kevin has worked for well over a solid year on this product - when we arrive at Parallax in the morning he's usually leaving the office. This is sometimes required to make a complex set of elements easy to use. Experiencing completion is equally important for Kevin and Parallax at this stage - he's got a significant career investment in WiFi!
Hey Kevin, I can think of one example of when somebody might want to reprogram a Parallax microcontroller from an Android or iPhone: field reprogramming. For many years we sold Tracy Allen's Stache, an SX-based field programmer for the BASIC Stamp just for this purpose. I don't foresee anybody editing code on a phone either, but I could easily imagine a quick data file upload and reprogramming of a microcontroller from a phone. Bill, you'll be surprised at how easy it was for Kevin to configure a little telnet session on his phone with icons that sent a string of data out to the WiFi Module. We'll show our customers how to set this up so they can get results quickly.
Kevin,
I have an embedded BASIC running on the spinneret using telnet.
Could I do the same with the S2 / Parallax WiFi wirelessly ? That would be great. From what you have posted so far, I would assume I can.
PC running telnet -> Wireless router -> Parallax WiFi -> Serial port on S2
Serial port on S2 -> Parallax WiFi -> Wireless router -> PC running telnet
I'd be happy to beta test this setup
P.S. To try embedded BASIC on a real spinneret use "TELNET 173.67.187.91"
Kevin, Does the WiFi module allow it to become an access point? Is the Command and Data communication happening over the same Tx/Rx pair or separate?
Ken, I agree that being able to program a Stamp or Propeller over WiFi would be good. If there is more than one WiFi module active, it may be difficult for the user to figure out which module belongs to which IP address, not unless there is some type of Bonjour service allowed by the WiFi module and the user's router.
* Regarding reprogramming a microcontroller from your phone:
Ok cool, I'm starting to see the usefulness for field programming and pre-storing the binaries on your phone for use later. I just wanted to throw out a little heads up that it will be REALLY easy to do this from your phone or computer.
1. Open a TCP socket to the WiFi module's "Command" connection.
2. Send an ASCII command string which specifies the microcontroller type (e.g. BS2), and the length of the program image (in bytes).
3. Then send that number of bytes.
4. The module takes care of the rest and responds when it's done with the status of the programming attempt.
* Regarding running embedded BASIC and a telnet client:
If you have a telnet server running on a Propeller attached to the WiFi module then you should be able to do that over the "Data" connection. You would set the "Data" connection to be on Port 23 (the default port for telnet) and use the contents of the data stream to interact with any remote clients that open a connection to the module's listening server. This starts to hint toward some of the more advanced features that that module will ultimately support such as allowing users to actually manage many different socket connections at once, but some of those kinds of features will come as free firmware updates after we initially launch the product. Initially you will be able to have one client connection at a time.
* The module does not act as an access point. It is a host device on an existing infrastructure (access point) wireless network. And regarding your other question, there is one UART on the wired connection side that is used to configure the module (logical "Command" connection) and transparently send/receive data (logical "Data" connection). There is a Cmd/Data select pin that is used to switch between the modes on the module. And they are completely logically separate, with separate buffers (so no data is missed if you switch to command mode). When not asserted, the pin defaults to Data mode so it always looks like a seamless UART data connection (so your device doesn't even have to know/care that it's actually connecting over WiFi). You'll be able to directly swap it out for your existing wired serial cable in your project. No worrying about accidentally sending/receiving an escape sequence or something that would put you in a mode you don't expect.
We'll be providing a bunch of clear and thorough documentation that will cover how everything works, and how the module can be used in different ways, so I think that will probably answer a lot of the questions once I can release that. Also, we're doing some really cool stuff in hardware that I think you guys will find makes the module super convenient and intuitive to use.
Man, if only I could share more details with you about some of the features... but shoot, gotta run.... ;-)
Thanks for the update Mr.McCullough
'
I really like the device being a HOST device. Since I will have several of these WiFi devices running shortly after their release from Parallax.I like to force an IP address to simplify PC programming.
'
I know of three really good BETA tester's
Bean, Bill Chennault, And my self $WMc%
(We can all be reached by PM's here on the forums)
'
Just trying to help out.
Thanks for letting me know, we may take you guys up on that.
...
Also, I wanted to make sure to clarify my previous post about the steps for reprogramming from a phone or computer. Those couple steps would only be necessary when doing the operation manually (as in, that's what the application would need to do). But if people use the configuration tool Jeff is making for the pc, it will essentially be a matter of click a button to find your device, then click a button to download your code to it. Actually, you may have to double-click at some point I'm not sure... ;-)
That is actually a multifaceted question, because it really depends on what mode the module is operating in at a given time. So I'll break it down with a few estimates, but can't give away all the details right now.
1) Peak full-power normal operation (transmitting/receiving/listening over WiFi) is in the ballpark of 150mA.
2) Charging the battery can be a max charge rate of 300mA and can be charging while the module is fully on, off, or in any other mode of operation. So a safe absolute max consumption at any given time would be the charge current plus the peak full power consumption = 300mA + 150mA = around 450mA so it easily stays below USB limitations, and is reasonable for most other supplies too.
3) The device can operate in several lower power modes, such as full operation but WiFi radio off, which is approx 20mA. And we plan to implement a couple other extremely low power modes that could average around 1mA or even significantly lower depending on the wakeup interval.
We wanted to stay really flexible with the power supply options so the module can be powered from a couple different sources. On-board rechargeable battery (3.6V lithium ion), external USB power, auxiliary power (3-pin header), and power over DB9 port. The auxiliary power and DB9 power can both be around 5V up to 18V. We left a wide supply range for auxiliary/external inputs to achieve maximum efficiency (because our module uses on-board switchers to step the voltage down to what it needs), and it leaves a lot of flexibility for the user. And power over the USB connection is pretty standard and I think has to be between 4.5V and 5.5V.
We may not have the super-low power modes for the initial release, but we will be implementing that as soon as possible as part of a free firmware upgrade. :-)
Some android phones do have keyboards, probably not the best device to edit code on but it is more likely a person would be carrying a phone in their pocket than a netbook or laptop. So it will be a matter of time before someone will want and or need the ability to edit code in the field with their phone.
-dan
Will the network API be available at the Propeller side? E.g. can I from the Propeller/SPIN/PASM open a socket etc in the same way as with the Spinneret/W5100?
We're wrapping up a lot of final details right now. After some internal reviewing and discussion we decided to implement a couple minor changes in the interface which make things a lot better. I've finished implementing most of it, and am going back through testing right now to make sure it all works well.
I don't have too many details at the moment, but I'll get back to everyone soon. Thanks,
-Kevin
Sorry about missing your question earlier. The WiFi module does not have the same interface as the Spinneret. We've focussed a lot on making everything as automatic as possible inside the module, and are going mainly for a transparent serial connection (requiring little - if any - configuration after initial setup). We do plan to add some more advanced capabilities in the future to allow many simultaneous socket connections to be setup and managed all at once, but that would be in a later firmware update as it goes above and beyond our primary goal of the module being automatic and the connection being transparent. Indeed a fully-featured WiFi web server will require a substantially different feature-set than our transparent serial-to-wifi connection.
Until we incorporate that into the full firmware, if your application requires more advanced socket control than what we've currently implemented then we should be able to provide you access to a different set of firmware you could load on the module which would give you some of those capabilities. It would have a completely different interface which uses "AT+" commands. We could provide some brief documentation to get you started, but unfortunately wouldn't be able to provide code support or examples for this alternate set of firmware. After we launch the product, let me know if this is something you want a copy of and we can explore a little more into what would be involved to make this happen.
Ok, lets see if I understand you correctly - using your firmware, no network API available from the Propeller side. Using the native GS1011M firmware, the network API available via Gainspans extended Hayes command set. Right?
Our firmware is focusing primarily on transparent serial-to-WiFi, and programming microcontrollers over WiFi, so we decided that implementing the features to manage multiple simultaneous socket connections could be some of the additional features which could wait until after the initial release. You still have complete control over one socket connection at a time, but just not several at once quite yet. We believe our firmware is easy to use and very handy for allowing any existing serial connection to be instantly WiFi-enabled. It takes care of all the WiFi stuff pretty much automatically and doesn't require the attached microcontroller to have to care about or actively manage the WiFi or socket connections.
If you are hoping to port a Spinneret web server application over to the WiFi module, then using GainSpan's native firmware on our WiFi module may be the way to go. Their command set is based off the extended Hayes AT commands and would allow simultaneous socket connections. Keep in mind though that it's not exactly transparent serial and doesn't support microcontroller re-programming. In this case your microcontroller application needs to know that it is connected to the WiFi module and be aware of the socket connections and the command interface.
The nice thing is that you are not locked into one option or the other. Both sets of firmware will be available for free, and you can easily re-flash the module with either firmware image, and/or load firmware updates as we implement new features.
Comments
'
Sorry I wasn't more specific.
'
I'm looking for the hop frequency's that the WiFi uses, And mostly what the Parallax WiFi hop frequency's will use.
'
I can tune my wireless cameras to a different freq. but I'm limited to a small tuning band.
'
The cameras never effected my old WiFi router that was damaged by a lighting strike.But with this new router their problematic.
'
I've re-tuned my wireless cameras to work with the new router.
'
This leads me to believe that not all WiFi routers hop to the same Freq.
'
I fear I'm going to run out of tuning options on my cameras with the Parallax WiFi.
'
If my cameras won't work(cause interference) with the Parallax WiFi, I need to change cameras.
'
I have waited a long long time for a Parallax WiFi module, I just want to have ever thing in place for its deployment
orthogonal frequency-division multiplexing
'
Sorry Franklin
'
I got all balled up on the WiFi _router_ programing routings.
'
The WiFi router has to deal with this freq. hopping.
'
Not the individual WiFi device.Like the Parallax WiFi unit.
Do you have time for a WiFi update?
Thanks!
--Bill
Hey Bill, I've called in Kevin to comment on where we are with the WiFi module. I'm a bit tired of being his spokesperson on this issue, so. . . . here's Kevin!
Ken Gracey
Thanks a lot for taking interest the product! All of us around here are very excited about the module, and it is truly a great source of motivation to know that so many people are planning to buy this thing we've worked so hard on! ;-)
All the core difficult stuff is pretty much done, and now I'm finishing up the refinements to the user-interface in the firmware to make the module's configuration commands consistent and easy-to-use. As I've been working on the firmware, Jeff has been working on the graphical configuration tool (that runs on the computer), and the interface with the Stamp Editor and Propeller Tool. The next milestone is bringing the two together for direct functional/usability testing, which will be about 2-3 days from now. And once we're done making any last minor tweaks, we will run a pre-production prototype of the hardware and then follow almost immediately with full production. While Manufacturing is handling production, I'll be converting caffeine into product documentation so we can make the modules available to you right as they come out of the oven (well, after they are tested and packaged and Ken slaps a giant "Made in USA" sticker on them of course). ;-)
I don't know the specific date when they will be available for sale on the web, but we will definitely be letting everyone know as soon as we begin production. And at that point we should have a pretty clear estimate of when they will be for sale. I'll try to provide another update soon when we reach the next milestone (beginning production).
Truly thanks again for all the excitement you have all shown for this product's release. It give's us all a lot of inspiration in this final home stretch of the project!!
-Kevin McCullough
The reason it is an exciting product is because Parallax is producing it. This means quality and support are beyond match. A person like me can buy it and have a reasonable expectation of being able to use it because Parallax is the producer.
There must be a lot of pressure on you and other members of the team.
--Bill
--> Can you operate the module from your iPhone? Oh yeah!! I'm a little partial to Android OS... but really the module can be accessed from ANY smart phone. Or any device with a connection to the internet for that matter. There are an abundance of free apps which can be used to communicate with the WiFi module and therefore your robot or project connected to it. And one reason we are trying to make the configuration interface so simple and intuitive is to also make it really easy to write your own custom phone or computer apps to interface with your robot/WiFi module if you want to. Just like you would normally have to open a COM port to talk to the robot sitting on your desk using a serial connection, you would now simply open a TCP Socket to access that same robot from anywhere in the world (assuming of course that your robot is within range of a WiFi signal).
--> As far as existing devices (2.4GHz wireless cameras) interfering with the WiFi signal, it would be just as much a problem for any other WiFi-enabled device such as a phone, laptop, etc. as it would be for the WiFi Module. However, if those other devices are able to connect, then the WiFi Module should also be able to connect. In that situation, I would suggest setting up your wireless router (wifi access point) to operate on an RF channel that is at least a few channel numbers away from whatever your wireless cameras are using. This Wikipedia page describes the frequency ranges for WiFi RF channels: http://en.wikipedia.org/wiki/List_of_WLAN_channels. As permitted by the FCC, our module will be able to operate on channels 1-11.
--> To give a very brief description of the logical connections that can be made to the WiFi Module... there is a "Command" connection and a "Data" connection. The Command connection interprets everything as commands and is used to configure and/or run higher-level tasks on the module. Things like setting up saved WiFi connections, setting the UART's baud rate, or reprogramming an attached BS2/Propeller would be done over the "Command" connection. The "Data" connection is raw, transparent, no-questions-asked data. From your robot's perspective, it might as well be talking to a computer COM port. The Command and Data connections from the WiFi side are accessed on two different ports (which can be user-selected to any port numbers you want). The Command and Data connections on the UART (serial port) side are shared over the same physical UART, but are logically separated based on the current mode of operation.
The main goal is that you'll configure the module to know how to connect to your WiFi network(s), and from then on be able to use it to interface with your existing project just like you would a regular serial connection (except without all the wires to tangle and trip over of course). There are some more advanced things you can do with the module for users who want to get more into that (and we will be adding even more power-features in additional firmware updates), but we want the module to remain simple and straight forward to use by anyone - especially non-wifi-experts.
--> Will it work on the S2? It will most definitely work on the S2, and the original Scribbler too. In fact we will will have a specific version of the module to match the top-facing DB9 connections used on the Scribbler/S2 (in addition to the regular side-facing connectors on the BOE-bot and other boards).
Ok, now here's a question for you guys... even though you can reprogram your Basic Stamp or Propeller from your iPhone/Android Phone (using the WiFi module), can you think of a situation that would make you want to do that? A few people have asked in conversation if they will be able to reprogram their robot using their iPhone, and the answer is "Yes, you totally can" - but all I can think is that I would go blind trying to code Propeller objects from the comfort of my phone's tiny 4" screen. Controlling and accessing data on my robot from my phone is a totally different story; I'm big-time all for that. But what kind of applications can you think of where you might want to reprogram a microcontroller from your phone? Let me know. :-)
Take care,
-Kevin McCullough
Hey Bill,
We are definitely trying to push to get it out to market as soon as possible, but as far as difficulty it's actually mostly down hill from here. The hard, unknown, learning-curve stuff is behind us so we are getting a taste of the easier, satifying part of smoothing out the edges and watching stuff work. Certainly there are a few more minor challenges as we near production, but it's all very tangible now. It's kinda that feeling like when you work on a project for a long while and you get everything programmed, and all wired up, and then you finally flip the switch for the first time (gently) and the light actually turns on, and you're like "TOTALLY AWESOME!"... wait it's actually not "kinda" like that, it's exactly like that. :-)
Take care,
-Kev
Hey Kevin, I can think of one example of when somebody might want to reprogram a Parallax microcontroller from an Android or iPhone: field reprogramming. For many years we sold Tracy Allen's Stache, an SX-based field programmer for the BASIC Stamp just for this purpose. I don't foresee anybody editing code on a phone either, but I could easily imagine a quick data file upload and reprogramming of a microcontroller from a phone. Bill, you'll be surprised at how easy it was for Kevin to configure a little telnet session on his phone with icons that sent a string of data out to the WiFi Module. We'll show our customers how to set this up so they can get results quickly.
Glad to see you on the forums.
Ken Gracey
John Abshier
I have an embedded BASIC running on the spinneret using telnet.
Could I do the same with the S2 / Parallax WiFi wirelessly ? That would be great. From what you have posted so far, I would assume I can.
PC running telnet -> Wireless router -> Parallax WiFi -> Serial port on S2
Serial port on S2 -> Parallax WiFi -> Wireless router -> PC running telnet
I'd be happy to beta test this setup
P.S. To try embedded BASIC on a real spinneret use "TELNET 173.67.187.91"
Bean
Ken, I agree that being able to program a Stamp or Propeller over WiFi would be good. If there is more than one WiFi module active, it may be difficult for the user to figure out which module belongs to which IP address, not unless there is some type of Bonjour service allowed by the WiFi module and the user's router.
Carl
Ok cool, I'm starting to see the usefulness for field programming and pre-storing the binaries on your phone for use later. I just wanted to throw out a little heads up that it will be REALLY easy to do this from your phone or computer.
1. Open a TCP socket to the WiFi module's "Command" connection.
2. Send an ASCII command string which specifies the microcontroller type (e.g. BS2), and the length of the program image (in bytes).
3. Then send that number of bytes.
4. The module takes care of the rest and responds when it's done with the status of the programming attempt.
* Regarding running embedded BASIC and a telnet client:
If you have a telnet server running on a Propeller attached to the WiFi module then you should be able to do that over the "Data" connection. You would set the "Data" connection to be on Port 23 (the default port for telnet) and use the contents of the data stream to interact with any remote clients that open a connection to the module's listening server. This starts to hint toward some of the more advanced features that that module will ultimately support such as allowing users to actually manage many different socket connections at once, but some of those kinds of features will come as free firmware updates after we initially launch the product. Initially you will be able to have one client connection at a time.
* The module does not act as an access point. It is a host device on an existing infrastructure (access point) wireless network. And regarding your other question, there is one UART on the wired connection side that is used to configure the module (logical "Command" connection) and transparently send/receive data (logical "Data" connection). There is a Cmd/Data select pin that is used to switch between the modes on the module. And they are completely logically separate, with separate buffers (so no data is missed if you switch to command mode). When not asserted, the pin defaults to Data mode so it always looks like a seamless UART data connection (so your device doesn't even have to know/care that it's actually connecting over WiFi). You'll be able to directly swap it out for your existing wired serial cable in your project. No worrying about accidentally sending/receiving an escape sequence or something that would put you in a mode you don't expect.
We'll be providing a bunch of clear and thorough documentation that will cover how everything works, and how the module can be used in different ways, so I think that will probably answer a lot of the questions once I can release that. Also, we're doing some really cool stuff in hardware that I think you guys will find makes the module super convenient and intuitive to use.
Man, if only I could share more details with you about some of the features... but shoot, gotta run.... ;-)
-Kev
'
I really like the device being a HOST device. Since I will have several of these WiFi devices running shortly after their release from Parallax.I like to force an IP address to simplify PC programming.
'
I know of three really good BETA tester's
Bean, Bill Chennault, And my self $WMc%
(We can all be reached by PM's here on the forums)
'
Just trying to help out.
Thanks for letting me know, we may take you guys up on that.
...
Also, I wanted to make sure to clarify my previous post about the steps for reprogramming from a phone or computer. Those couple steps would only be necessary when doing the operation manually (as in, that's what the application would need to do). But if people use the configuration tool Jeff is making for the pc, it will essentially be a matter of click a button to find your device, then click a button to download your code to it. Actually, you may have to double-click at some point I'm not sure... ;-)
-Kevin
What is the current consumption of the Wifi module when idle and active?
What is the required voltage to power the module?
That is actually a multifaceted question, because it really depends on what mode the module is operating in at a given time. So I'll break it down with a few estimates, but can't give away all the details right now.
1) Peak full-power normal operation (transmitting/receiving/listening over WiFi) is in the ballpark of 150mA.
2) Charging the battery can be a max charge rate of 300mA and can be charging while the module is fully on, off, or in any other mode of operation. So a safe absolute max consumption at any given time would be the charge current plus the peak full power consumption = 300mA + 150mA = around 450mA so it easily stays below USB limitations, and is reasonable for most other supplies too.
3) The device can operate in several lower power modes, such as full operation but WiFi radio off, which is approx 20mA. And we plan to implement a couple other extremely low power modes that could average around 1mA or even significantly lower depending on the wakeup interval.
We wanted to stay really flexible with the power supply options so the module can be powered from a couple different sources. On-board rechargeable battery (3.6V lithium ion), external USB power, auxiliary power (3-pin header), and power over DB9 port. The auxiliary power and DB9 power can both be around 5V up to 18V. We left a wide supply range for auxiliary/external inputs to achieve maximum efficiency (because our module uses on-board switchers to step the voltage down to what it needs), and it leaves a lot of flexibility for the user. And power over the USB connection is pretty standard and I think has to be between 4.5V and 5.5V.
We may not have the super-low power modes for the initial release, but we will be implementing that as soon as possible as part of a free firmware upgrade. :-)
Take care,
-Kevin
-dan
We're wrapping up a lot of final details right now. After some internal reviewing and discussion we decided to implement a couple minor changes in the interface which make things a lot better. I've finished implementing most of it, and am going back through testing right now to make sure it all works well.
I don't have too many details at the moment, but I'll get back to everyone soon. Thanks,
-Kevin
Hi kuisma,
Sorry about missing your question earlier. The WiFi module does not have the same interface as the Spinneret. We've focussed a lot on making everything as automatic as possible inside the module, and are going mainly for a transparent serial connection (requiring little - if any - configuration after initial setup). We do plan to add some more advanced capabilities in the future to allow many simultaneous socket connections to be setup and managed all at once, but that would be in a later firmware update as it goes above and beyond our primary goal of the module being automatic and the connection being transparent. Indeed a fully-featured WiFi web server will require a substantially different feature-set than our transparent serial-to-wifi connection.
Until we incorporate that into the full firmware, if your application requires more advanced socket control than what we've currently implemented then we should be able to provide you access to a different set of firmware you could load on the module which would give you some of those capabilities. It would have a completely different interface which uses "AT+" commands. We could provide some brief documentation to get you started, but unfortunately wouldn't be able to provide code support or examples for this alternate set of firmware. After we launch the product, let me know if this is something you want a copy of and we can explore a little more into what would be involved to make this happen.
Cheers,
-Kevin McCullough
Ok, lets see if I understand you correctly - using your firmware, no network API available from the Propeller side. Using the native GS1011M firmware, the network API available via Gainspans extended Hayes command set. Right?
If you are hoping to port a Spinneret web server application over to the WiFi module, then using GainSpan's native firmware on our WiFi module may be the way to go. Their command set is based off the extended Hayes AT commands and would allow simultaneous socket connections. Keep in mind though that it's not exactly transparent serial and doesn't support microcontroller re-programming. In this case your microcontroller application needs to know that it is connected to the WiFi module and be aware of the socket connections and the command interface.
The nice thing is that you are not locked into one option or the other. Both sets of firmware will be available for free, and you can easily re-flash the module with either firmware image, and/or load firmware updates as we implement new features.