Mar 18, 2014

An ALS That Does RGB

posted by Bryon Moyer

My oh my, how the smartphone has colored our (or at least my) expectations. And color is the operative word here.

When you think, “ambient light sensor (ALS)” (yes, I know you think the parenthetical too), what do you think next? That sensor on the smartphone that can tell whether the ambient light is high or low so that it can adjust the display and keyboard backlights and such? Yeah… me too.

So then I see an announcement from Maxim about their new ALS. And it separates out colors. Now… color me stupid, but is it that someone doesn’t want their phone to react if they’re, say, in a darkroom with red light? That would make no sense – because no one uses darkrooms anymore. [Prepares for filmophile rage…]

It’s actually not that crazy; we did cover Intersil’s RGB sensor recently, and we noted there that an RGB sensor can help with tinted glass, but it was also set out in contrast to an ALS.

So here’s me feeling kinda dense, so I checked in with Maxim. Who kindly and gently helped me remember that there are more applications out there than just cellphones. Who knew.

They listed as exemplary applications:

  • Color sensors
  • Contrast sensors
  • Color sorting
  • Gas and fluid analysis
  • Label presence
  • Lid insertion verification
  • Shrink-wrap presence
  • Tamper-proof seal confirmation
  • Visual inspection replacement
  • Automatic display brightness

In other words, there are many sensing applications – particularly in an industrial environment – that benefit from analysis of the ambient light. And that might involve looking at very specific colors or fractions of colors. Which is why they have three color sensors and feed the separate color components for use in detection algorithms.

Now, based on the Intersil definitions, this would be an RGB sensor, as contrasted with an ALS. In Maxim’s terminology, this is an ALS. You can rationalize either nomenclature; I just feel better knowing there might be some miniscule rationale for my occasional lapses into states of confusion. (No need to suggest that they’re more than occasional, thank you anyway.)

Interestingly, though, Maxim focuses on different applications from the ones Intersil was suggesting; Intersil seemed more focused on displays (not just phones, but TVs and such), LED lighting, and cameras – less industrial in flavor than what Maxim has outlined. Which I guess goes to show that there are many ways to use an RGB sensor, or ALS with RGB, or whatever you want to call it.

On the heels of yet another light sensor that senses UV without a specific UV sensor – that is, by using a single visible light sensor that also detects into the UV range, and then extracting the UV by algorithms – I checked in to see whether this truly had three sensors or whether the colors were extracted from a single sensor. Answer: yes, three sensors.

You can find more detail in Maxim’s announcement.

Tags :    1 comment  
Mar 17, 2014

A New Coverage Concept

posted by Bryon Moyer

OneSpin announced a Quantify MDV product a few years back. With it, they defined a number of different coverage aspects – things that could be verified with their formal technology. Now they’ve reinforced that product with a new version. And that version contains yet another coverage concept.

The older coverage concepts focused on the design itself and the quality of stimulus used in verification. It would check for things like dead code and over-constraining, the former reflecting a possible code issue and the latter indicating that legitimate cases may not be covered by existing tests. I discussed these elements in my original coverage of the tool.

In recent times, they struggled a bit with what to call these checks. You might think they’re simply “design” checks, except for the constraining bits. The aspect that gets to simulation coverage had them calling it “simulation” coverage, but that didn’t really cut it either. They landed on “reachability,” since things like dead or redundant code indicated design elements that may or may not be reachable, and the constraints also get to whether or not certain failures can be reached by the tests. It’s not a perfect nomenclature, but, absent something perfect, it’s what they settled on.

Why even worry? Well, they needed to distinguish all of those coverage aspects from a new one they were adding. This new one tests the completeness of the assertions and checkers in the design. The assertions are designed to catch problems during formal verification, but it’s possible to write ineffective assertions. Looked at another way, if assertions are poor or incomplete, then there may be code failures that could never be observed by the assertions.

So they refer to this as “observation coverage.” And they test it using a form of “mutation” analysis: making a code change and seeing if the assertion picks it up. If not, then there may be a hole in the assertion.

This appears to be a newish concept, and it’s not comprehended in the UCIS coverage standard; they’re in discussions on that.

You can get a more complete picture of their latest Quantify release in their announcement.

Tags :    0 comments  
Mar 12, 2014

Clearer Phone Conversations

posted by Bryon Moyer

I recall the few times I was able, for some reason, to take advantage of noise-cancelling headphones on an airplane. Once on your ears, when you turned them on, you gradually heard the background hiss of the airplane disappear. It took a few seconds for this to happen.

My assumption was that this was a slow integration problem, and that only long-term constant sounds could be cancelled out; the circuitry simply wasn’t fast enough to eliminate short, sharp sounds. (Which is probably good, since you certainly wouldn’t want it to cancel out important flight attendant messages, like the fact that you can get a great deal on a credit card or that duty free is now available).

This means, of course, that such headphones wouldn’t solve the “cocktail party” problem: isolating one voice and dimming the others, something our ears and brain somehow manage effortlessly.

Solving that would be particularly nice on our phones; as Cirrus Audio points out, if you use the phone in a bar, all voices go through, not just yours.

Of course, headphones on an airplane don’t include a microphone. With a phone, even if you had super-fast algorithms that could cancel short, bursty noises, you’d need to avoid cancelling out the person speaking into the phone. That would kind of defeat the purpose.

Cirrus recently announced some new devices dedicated to improving phone sound, and noise reduction and cancellation are part of it. Phones are moving to multiple microphones to figure out which sounds to suppress, but the audio guys have a challenge in that they don’t get much influence over where those microphones go. So Cirrus is trying to be as adaptive as possible.

They claim that most other audio chips are pre-optimized and fixed, while, by contrast, they dynamically adjust their noise reduction/cancellation to adapt both to the phone and the specific sound environment. And their noise reduction applies to both ends of the conversation – the voice at the phone and the voice at the other end of the line. (And if you think that solving the noise at one end makes solving it at the other unnecessary, you haven’t listened to cell phones much. Although apparently cellular systems are moving to wideband voice so that whe_ _he voi_ isn’t drop_g out, it wi_ sound _reat.)

CS48LV12-13_Block_Diagram_2_-_colorized_red.png

The other bit that caught my ear was their approach to voice recognition and control. This gets to the always-on problem: if your phone is going to be voice activated, then you want that to work without your having to turn the phone on first. If the phone goes completely to sleep, then this won’t work.

But having the phone on all the time kills the battery. So Cirrus has a three-step wake-up routine. A low-power block listens to determine if there’s a significant sound. If so, it wakes the next block, which determines whether or not the sound is noise or a voice. If it’s a voice, then the third step wakes up, which does two things in parallel: decodes the command and decides whether it’s the authorized voice. If it’s not an authorized voice, then the phone automatically responds, “You’re not the boss of me!” and goes back to sleep with a righteous pout.

OK, maybe not quite like that… that might be a cool feature, though, in case you product planning guys are listening…

Anyway, you can find more details in their announcement.

Tags :    0 comments  
Get this feed  

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register