When I sell a boxed product with an imp in it and the end users takes it home, how do they setup the product for their Wifi assuming they do not have a supported smart phone? This is a very non-technical product for non-technical people? I did see that someone did a quick-and-dirty Windows Blinkup. Is there a spec where we can do our own Blinkup for our products web page and we leave an optical windows open from within our packaging. Ideas?
Currently, you require a supported smartphone.
We’ve experimented with webpage blinkup but current browsers don’t appear to be able to reliably sustain a good frame rate - plus this is very dependent on the PC, OS and browser in use.
Blinkup contains not only the SSID/password but also manufacturer and user tokens, which allows the product to be associated with a vendor account if needed (or just to the app being used) - it’s a bit more complex than just getting it on wifi.
Is a spec available that we can develop and deliver a WinApp instead?
Not right now I’m afraid, no.
Any suggestion on how to ship a boxed product to a standard consumer market? I always use my parents as the “average” user and they do not have a smart phone, but anyone who would use a product with Wifi has a computer (PC or Mac).
To help a few of us early users out when the iphone app wasn’t available. It was a stop gap.
Not why, but how? As you can tell by this thread, EI has a large roadblock to wide-scale adoption and distribution unless this is resolved. If they want to build a market with Imps in it, this must be resolved quickly or developer like us will just throw our hands up and go back to Microchip PICs which we have used for 15+ years.
Winblink was developed with our help; Rob was contracting for us at the time.
Whilst this helps developers get units online, it’s not a complete solution like the smartphone libraries are, as it only fetches auth tokens for the developer service. Winblink is also not compatible with all PCs - variations in computers will impact whether this works at all. There’s less variation between smartphones than there is between PCs.
We don’t believe there’s a “large roadblock” to wide-scale adoption here. Smartphone penetration is over 50% in the USA and climbing rapidly. Are we purposely restricting ourselves to people who own smartphones? Yes we are.
Thank you for your forthright honesty. At least for these two projects we will have to move back to PICs and Microchip’s Wifi (bummer!) since our clients can not limit their market to smartphone users for setup. I have a hard time believing the buyers at Costco, Walmart, Target, and QVC would carry the products with a smartphone being a requirement for activation. I will ask and see. You never know until you ask.
Though I am new to the Imp, I have 30+ years of professional development under my belt, including Windows, Mac OS, and iOS and know each platform very well. You may as a strategic or tactical business decision decide not to allocate resources in this area, but I find it a stretch that even with the variation across machines (XP/2000 and later & Mac Lion and later) that (in C++ Windows (not .NET) or Objective-c Mac) it can not be made as reliable as iOS and certainly Android. We have seen other blink of screen programming there.
In one of our own future product plans, an iPhone is required since it is an iPhone app talking to the consumer hardware device via the Imp, so there we are fine. I still have to figure out how to commission the Imp while embedded in a case; maybe with a light pipe? Here too, any ideas?
Being a startup, we do have to concentrate our efforts; the bulk of the customers we are working with are building smartphone controlled devices so that’s what we’re building.
Also bear in mind that the overlap between buyers of wifi-enabled products and the people who own smartphones is very large. Yes, there are large numbers of people with dumbphones, but usually they are also the people who either don’t have wifi at home or who are not the early-adopter types who would buy connected devices - for one because they don’t have a suitable control/monitoring endpoint in their pocket at all times.
If you use the imp-002 solder-down module, you get 12 I/Os and also get to place the phototransistor and LEDs wherever convenient in your housing (using a light pipe if required).
Ouch, I didn’t think of this? I was going to make something for my Mom, but hmm. I would have to reBlink-UP everytime there was a change.
@godfish: I don’t understand quite what your issue is there? You only need to blinkup once (to set wifi access and account). After that point, you can move the card from device to device, change software on the devices, etc all without needing to blinkup again.
Hugo, I believe I asked you once already, but what is wrong with WPS? I read a lot of comments similar to this and even that someone had developed a blinkup for Windows that makes me wonder. Wouldn’t WPS be a consistent alternative to having to own a smartphone to setup the imp?
Being a PIC guy for so long, every problem is solved by a PIC. (The old nail and hammer metaphor.) I do not know if this will work since I do not know enough about the specific technical details of Blinkup, but with a very cheap USB PIC and an LED a very simple dongle could be created that could be distributed with the product to replace the Blinkup. Once plugged into a PC or MAC USB it could connect to the server just like the smartphone and do exactly the same job. (No display screen performance variations here.)
Even better, though it would add a small cost and extra items to the BOM, just build it into our product. No light pipe needed since the LED is directly facing in the light sensor in the dark case. Is there a reason using PWM that an LED could not do the job? I can’t see the LED timing and duty cycle being worse than the smartphone screen.
Just a PIC idea from a PIC guy who really likes EI.
@marcoeg: We already support WPS for wifi config, but that doesn’t deal with getting user credentials to the device. Both are required.
@lzerman: absolutely a pic could send this pattern, I’ve sent it with arduinos before. Creating a dongle, driver, housing etc to make this a consumer product is not a small task though. The solder-down module version of the imp supports configuration via direct electrical connection from another micro - basically still blinkup - and some vendors are using this in their products.
Creating a dongle, driver, housing etc to make this a consumer product is not a small task though.
Yes, we know. We do this.
The solder-down module version of the imp supports configuration via direct electrical connection from another micro
Ahhh! Why didn’t you say so earlier? This changes the whole equation!
The solder-down module version …
Available when and to whom? I have my 14 year-old just itching to dive into an Eagle PCB project with me. (He is already my Solidworks expert for 3D printing.) We will just slap a PIC16f1454 on the board with it and we are USB and Wifi ready to go. Cool!
An extra part on the BOM and an extra $1 on the COG, but well worth it!
@Hugo, I didn’t think about before but now that you have mentioned it maybe I’ve understood. Do you mean that the OPTO_IN (pin 6) of the Imp002 it can actually receive an equivalent of a blink signal from some other source and not just from a phototransistor’s emitter?
@lzerman, I’m not the right one to say it, but for the information I have I think it will be hard to get the hands dirty on the solder-down module, that’s only for manufacturers and sold in bulk quantities.
There’s another thread on the solder-down module. Not available yet and we’re not sure how it’ll be sold in small (<200) qty. We’re talking to some distributors about this.
100% (literally not figurative) of the chip manufactures that we have dealt with over the past 15 years have a manufacture sampling program of some sort. Many free for up to 5 chips, others at cost plus shipping. Some you just call and they send them, some have a formal paperwork and approval process like Apple’s MFi. Microchip’s just show up at the door unordered. But, all have a small volume way that designers and developer can have enough of the exact chips that will go into the products to go on to test boards. The SD card format is nice for functionality exploration and for some companies to use, but as you can tell from this thread, it is not going to work for companies that need the chip format to design and mount on a PC board. Requiring a design company to buy a large volume of chips to start their design becomes a non-starter and designers like ourselves will work with those who we find inviting and that minimize the risk of using their product.