WiFi Module
Bill Chennault
Posts: 1,198
Dave and Chip and Chris and Kevin and Everybody--
May we have an update on the Wifi module?
The Wifi module topic seems to have disappeared from this forum, also. It was a handy place to keep track of this issue.
Thanks.
--Bill
May we have an update on the Wifi module?
The Wifi module topic seems to have disappeared from this forum, also. It was a handy place to keep track of this issue.
Thanks.
--Bill
Comments
Sure, I'd be pleased to tell you everything I know. Over the last couple of weeks I've had the opportunity (?) to get more involved with this project. The R&D behind the WiFi module is more than we expected, so Kevin and I are closely coordinating the schedule in expectation of a completion.
To appreciate the delay you need to know a bit more about the project, from my perspective as a manager.
When we started this project more than two years ago we were working with the GainSpan GS1010 WiFi chip. Their business model was focused on having customers design their own WiFi module from the GS1010 processor, a dual-core ARM with an expensive suite of C programming tools. One core ran the GainSpan WiFi firmware; the other was for the user's project.
Time passed and two significant changes occurred. First, GainSpan decided to obsolete (End of Life) the GS1010 in favor of the GS1011. The replacement was coupled with a development tool upgrade that required us to port our code to the GS1011. Next, the new device wasn't pin-compatible and required enough changes to our firmware that it was a re-write and a port of our code.
This firmware was designed on the GainSpan development tool hardware.
Concurrent with the above efforts another engineer was designing the WiFi module. Our design was a complete WiFi module with all the discrete components, a metal cover, etc. As we were prototyping our hardware GainSpan changed their business model to produce modules. The type of customer they would now support would buy their FCC-approved modules for direct insertion in semi-custom designs. The change in the GainSpan business model was ultimately a benefit to us because we are now designing around their modules instead of making our own. The shift in their attention is certainly a result of customer experiences similar to ours - supporting a chip customer is difficult; dropping a complete module into a design is much easier. Our whole custom module efforts are now shelved - a loss of 120 hours of PCB layout/engineering.
From the above you can see that our long R&D time was coupled with EOL of our chosen chip, development environment updates and a supplier's changing business model that involved a loss of PCB design time.
This project would test the most skilled engineer and project manager, presenting enough design challenges and financial worries (AKA return on investment) to stress our casual crew.
In the last month we've redesigned our PCB around the GS1011 module. These are the remaining tasks:
(a) PC-software "WiFi Configurator" to automatically detect and configure the Parallax WiFi module. This is a three-week task for Jeff Martin, and he's scheduled to begin it the minute we turn the "firmware corner" defined in (b) below.
(b) Firmware. The biggest challenge we're coding now is the WiFi modules "auto detect manager" which identifies and manages an auto-connect sequence. This involves adapting several modules: a wireless device driver, WLAN firmware interface and a network stack. We expect to understand this challenge more clearly by October 29th. And if we understand how to proceed the remaining firmware steps are quite manageable.
(c) Changes to the Stamp/Propeller IDEs. Estimated at a week or more. This involves packetizing the byte streams to match the WiFi module firmware so it can mimic a PC and download code to the target processors.
Production is the least of our worries right now. We can build these quickly, but we're not going to get beyond prototyping and into production until (b) is resolved. My best guess is that we'd have the production line rolling in December.
And I didn't mention product documentation, which would involve a fourth engineer concurrent with the firmware engineer, PCB layout engineer and software engineer. Also not a delay on it's own.
This product would have been released long ago if we didn't need to customize it for our processors. GainSpan has standard serial firmware that acts as a WiFi to serial bridge. This function will also be available and can probably be achieved with a number of WiFi devices out of the box, but we really need to be able to program our processors ad-hoc or over the internet.
We remain hopeful about the future of this product, but have some healthy concerns about the development cycle. Parallax puts a significant effort into some of our designs. And it can take a long time to bring some of these products to market. We have to make a serious commitment for the long-term to see this product to completion. And even the day it is released doesn't mean you're done; it just marks the day you start raising the child and a whole new life is developed around the idea.
Hope this helps.
Ken Gracey
Parallax Inc.
This is the "reliability" or "robustness" factor.
If you're doing something for a specific application, whether it be for business or hobby, you have a limited set of "test cases" that you need to design and test for. How formal that process is depends on your situation. For a hobbyist, you may not even realize you're doing a "design/test/evaluate" cycle, you just put it together, test, make changes, test, and then eventually it works.
In a commercial environment, things get more formal, but if you have a specific application, the number of issues you have to deal with is reasonable.
Now, take the Parallax example of creating a WiFi module for use with their processors, and specifically, for use in programming their processors. To start with, think of all the fun posts we've had from time to time on users that try and use a low end USB to Serial converted (non-FTDI), and the problems they have. Then, Parallax also has to worry about how else us fools will try and use the thing, and attempt to cover every possible scenario. As they say, you can't make anything fool proof, because fools are so dang ingenious.
The bottom line is, while many of us have a predefined set of design parameters that are fairly narrow in nature, Parallax more generally has to deal with a wider set of prameters, and not only design for them, but find a reliable way to test for them.
The also have to find ways to make things "usable" for us. For a one off job in the lab, if you have to go through a sequence of 8 pages of gunk to configure something, and end up having to take three tries before it works, no big deal. Parallax can't afford to put out a product like that. They need things to work easily, and in a manner that can be documented in a way that a non EE can understand and use. This ties in not only to lengthining the design cycle, but increasing the time and cost of documentation.
So next time you thing along the lines of "for crying out loud, I could have designed that and built a prototype in 2 days", think deeper, and think about all that needs to go into a product that will be used by "who knows who" and "who knows how".
John R.
Ken, thank you for all that information! You must think a lot of GainSpan to stick with them through all the changes. I remain convinced this will be a very important product in the Parallax lineup.
John, re: "for crying out loud, I could have designed that and built a prototype in 2 days".
Ha! I am a USER! I couldn't design and build it in TWO CENTURIES! But, as a user I have certain inalienable rights and one of them is to keep this thread alive and try to get all the information I can concerning this project. Which, thanks to you and Ken, I have!
--Bill
Your question evoked Ken's amazingly interesting response, so I'm very glad you asked it. These "behind the scenes" posts about developing products are a whole second education (besides what I'm learning about electronics). Given how relatively easy it is for a newcomer to develop a useful device these days - and then get the "maybe it could be a commercial product!" itch - it would be useful for Ken/Parallax to put together educational materials about that process as well. Eventually. In their spare time.
Not to sound negative, But I see history repeating it self. The Programmers have out ran the Hardware guys., Not hard to do.
'
Now the question is who is gonna pay for all of this RAM to make the WiFi work???? What Company will introduce WiFi to the Micro-Controller word???
'
I feel when WiFi Finlay comes out to the Micros, All of the other RF units will be out dated!!! And the users will all switch to WiFi over X-Bee and 4.33mHz RF.
'
I'm Just looking into the future!
'
I see a nice profit for the Micro Co. that gets there first!!!!
Xbee will be around for a while.
Jim
I thought about the "apples to oranges" comparison long ago. But, I think it is moot for a big reason: Wifi is everywhere. Everyone knows something about it. It is in our homes, workplaces, leisure areas, public places and even on the highways. Wifi is THE THING.
What is X-bee? Compare the two markets. EVERYONE knows they need Wifi. Almost NO ONE knows they need X-bee. For example, I don't know what X-bee-based consumer products exist. I can't even COUNT the number of Wifi-based consumer products. Therefore, which product wins the consumer acceptance race? In the long run, even Parallax competes in the consumer acceptance race.
Please let me know if you disagree with this concept.
--Bill
Jim
For several years there have been small hobbyist companies building GPS trackers for high power rockets and high altitude balloon flights, using APRS. A couple of months ago a new little company called "Tragic Little Aerospace" came out with a license-free tracker, which uses an XBee 900 XSC
http://www.tragiclittleaerospace.com/
Then just a few days ago, Greg of BigRedBee (a longtime maker of APRS based GPS trackers) released his own version, again using an XBee 900 XSC:
http://www.bigredbee.com/brbxb.htm
In the meantime, Stratostar, the main maker of instruments and equipment for educational high altitude balloon flights is also using XBees:
http://www.stratostar.net/products/
(You can't see the XBees, but I've talked with their guys. They've got regular 2.4 GHz XBees wirelessly connecting the various payload pods with the command pod, and then 900 MHz XBees sending the data and GPS information down to the chase van).
I don't see any of that moving over to WiFi. I'm sure this isn't the only area in which XBee is the right technology, and I'm also pretty sure that XBee is quickly moving towards becoming the technology of choice for this kind of thing. Obviously it's a tiny tiny market compared with the market for WiFi, but the point is that they are two different markets.
Frankly, I have very little interest in WiFi, though I suppose I should eventually learn how to use it. But XBee is what rekindled my interest in microprocessors.