Sorry for being late with this blog, especially for those interested and keeping track…
We announced BCC, or Background Color Compensator, last week. This technology enables OEMs of pico projectors to design in an automatic compensation for other-than-white backgrounds.
So the obvious question is: “Is this important?” We believe so, and here’s why:
Standard projectors like those found in conference rooms, home theaters, classrooms, and so forth all have one thing in common—they are all designed to be shown on a white background. Frankly, it’s something that users likely don’t notice, as we are all so used to seeing white screens everywhere. What makes pico projectors stand out from other projectors is their mobility. With that mobility comes the realization that a white screen (or wall) will not always be available for projection. And, as you can see using the exampled image on our website, the color of the projected surface can definitely effect how you perceive the colors in a projected image. At a minimum this is going to cause the viewer to say ‘this just doesn’t look right.’ Worst case, it causes the pico projector to be no longer used, or even returned to the place of purchase due to a bad user experience.
Implementation-wise, BCC is a PSB (Proven System Block) that is implemented on our CSSP devices. In the ArcticLink II VX2 and VX4, it would be a PSB fabric option. We’ve also hard-coded it into the ArcticLink III VX6 chips that are meant for embedded pico projectors. Note that we call out the VX6 series specifically—BCC is not hard-coded into the ArcticLink III VX3 or VX5 parts.
A key facet of BCC is that it does need to know what the color of the projected surface is (to which you likely say “Yes, Paul, that is patently obvious”). If the host system (phone, tablet, etc…) has an on-board color sensor, data from that color sensor can be fed through the system to our CSSP device, where BCC takes over and adapts content for that color. If the host doesn’t have an on-board color sensor, manual input will be required to compensate. That manual input is at the OEMs discretion, and is likely best done through software.
Q: How many colors can BCC compensate for?
A: As many as the OEM wants to design for. Our research shows that likely creating a compensation table for 8-10 colors is adequate for most customers and usages.
Q: Can this be done without BCC?
A: Yes, but likely not without in-depth color mapping software, which translates to increased power consumption and storage/processing needs in the host system.
Q: What requirements does BCC place on the host system?
A: BCC requires information on what color it needs to compensate for. No processing power is required, and the incremental power required is miniscule (<1mW)
Q: What are BCC’s resolution limits?
A: BCC is effective up to the resolution of VEE in the particular device.
Q: Is there calibration involved, like with VEE?
A: Yes, a small amount of calibration, performed by QuickLogic with the OEM/system designer, will be required.
Q: Could BCC be used on the on-board display of a smartphone or tablet?
A: Yes, it can. BCC can theoretically be used to adjust the color characteristics of the on-board display for varying lighting. While we’ve broached this subject with OEMs, we don’t see a ton of interest in this now. However, as displays continue to grow in size and resolution, it may become something interesting. To be continued…
4 thoughts on “On BCC…”
Paul could you comment on Texas Instruments new released chip(smart saves on battery) and if similar to what you guys are doing? Who are your main competitors in regards to VX3,CX?
TI releases a lot of chips, so I am guessing you are referring to the CC2541? If so, this is a low-power Bluetooth chip. While we do have Bluetooth uARTs, our connectivity products tend to be multifunctional. We wouldn’t view this product as a competitor in any way, as it performs a function we don’t compete against, nor does it offer the flexibility of a CSSP.
< < if this wasn't the product, let me know >>
Regarding competition, I would see it as follows:
* For bridging functions, there are a number of discrete chips that perform this. As we mentioned in the ArcticLink III VX introduction a few months back, they tend to be large, single function, and somewhat costly.
* For VEE and DPO, there are a number of less-abled technologies like DCR and CABC (which is comparable to our IBC).
* There are a few ASSPs available that have USB and SD controllers, but not all the capabilities the CX has. You can view the CX as sitting in the middle between a full-blown processor and an ASSP.
The product from Texas Instruments is Wilink 8.0
The fact that TI is putting functionality into this new WiLink device is further evidence that there is an issue in the market today with centralizing all processing and tasks into one application processor. There are performance and, more importantly, power consumption tradeoffs to be wrestled with. In certain use cases, we believe that the solution to this challenge is to adopt a de-centralized architecture that separates the system into tasks that GHz Application Processors (APs) run efficiently, and ones that do not. TI clearly shares this view as seen from the description of the new WiLink device. In order to create a market, multiple people must share a common view of the problem, so we view this press release as more market evidence to substantiate what we have been touting for a while.
To the specific question on whether this is a competitor to QuickLogic… the short answer is no. QuickLogic does not have, nor do we intend to have in the foreseeable future, a silicon platform with embedded radio technology. The majority of the WiLink device described in the press release is centered on multi-radio functionality. They appear to have embedded some microcontroller capability to offload certain tasks from the AP – ones that are handled more power-efficiently in a de-centralized architecture.
The bottom line is that we welcome these devices as it only helps strengthen our story, without creating a direct competitor.