Skip to main content

Category Archives: Blog

TI – Critical Link White Paper on Machine Vision

Posted on by

At Critical Link, we work very closely with Texas Instruments, and I had a recent opportunity to co-author a white paper with TI’s Asheesh Bhardwaj, a senior applications engineer. The topic is machine vision, a technology that is becoming increasingly important, and one we’re hearing about a lot more often from our customers and prospects that we were just a few years back.

More specifically, the white paper lays out an architecture for compute- intensive machine vision. This is an architecture that can be used when you have processing needs that can’t be handled by the completely off- the-shelf building blocks that are available, and when your application is not produced in volumes sufficient to justify the expense and hassle of creating a dedicated ASIC from scratch.

The architecture that’s outlined the white paper is based on our MityDSP-L138F SoM, which has been deployed in instrumentation and inspection equipment applications. This SoM features the TI OMAP-L138 DSP+ARM9™ processor, and a Spartan-6 FPGA. (We also offer a development kit that includes a module, camera (from a choice of five), baseboard, and SDK containing sample algorithms.)

Anyway, the white paper can be found here.

Those interested in a more detailed discussion on this topic may want to look at a recent IEEE paper published by TI, “An Optimized Vision Library Approach for Embedded Systems”, G. Dedeoglu, B. Kisacanin, D. Moore, V. Sharma, and A. Miller, Proceedings of the IEEE Workshop on Embedded Computer Vision, pp. 8-13, 2011, which is available for download to IEEE Xplore members.

Enjoy!

H.265 is coming. What will this mean for encode and decode engines?

Posted on by

Earlier this year, Tech Crunch reported ­on the ITU’s approval of the H.265 standard for streaming video. The goal for the new standard – a.k.a. HEVC (for High Efficiency Video Coding) – is that, with better compression techniques, high quality HD streaming will be possible for those in bandwidth challenged areas, and/or relying on mobile connections to cellphones and tablets.  Those of us with good bandwidth will get some benefit, too. We’ll get better resolution for 4K TV/Ultra HD streams.

All this isn’t going to happen overnight, but having the new standard out there is good news.

Anyway, when I read about this on Engadget, I got to wondering what this would mean for encode and decode, which prompted me to pose a question in the comment section:

 With the advantages of 1/2 the bandwidth requirements over H.264, what will be the increased requirements on encode and decode engines to support it?

Someone – thank you, CPTel_Mike – jumped in with an answer.  Mike had talked to Envivio (which does software-based video processing solutions and which apparently hadn’t waited for ITU to speak before getting going on their H.265 work – they were talking about it last fall. He was told that they’ll be releasing a 1RU HEVC software encoder in the near future:

According to them this device can do 4 HEVC encodes at the same quality as 4 AVC encodes would be. Or to gain a 30% reduction in bandwidth it can do 1 HEVC encode. This is 1st gen technology for HEVC encoders. Back when AVC first came out 1 encode per a 1RU encoder was normal. Nowadays you can get up to 40HD AVC encodes per a 1RU encoder. So I expect that as time goes on encoders will get more dense.

Regarding decoding, that usually takes much less work than encoding. I’d expect that any modern (i3 and up) CPU could decode a HEVC video in software no problem.

That’s one answer, but it’s not 100% what I was looking for, and I’ve still got more questions. For sure you’d  think that, in order to decrease the bandwidth required of an encoded stream, the video encode algorithm is more complex, and would require additional CPU or CODEC power to accomplish. But how much?  And how soon do we think that the hardware-based CODEC engines will be available?

Any thoughts? Any answers?

Smarter than the average basketball

Posted on by

We’re in Syracuse. This time of year, this means that we’re really, really, really focused on basketball. I’m writing this a bit before March Madness kicks off, but I’m pretty sure that The Orange are still in it at this point. Maybe this is even our year, though the way they have been playing lately, that seems unlikely.

As a basketball fan, and an embedded systems engineer, I was doubly interested to read that the world’s smartest basketball is going to be available to consumers.

What’s so smart about the world’s smartest basketball?

The 94Fifty Sensor Basketball, which many Division I college teams use a version of, looks like any other regulation-sized ball. That’s to say all of its tech is hidden inside, so don’t expect to spot any of its sensors, which capture 6,000 points of data per second, embedded in the exterior.

Those sensors capture loads of data, including dribble force, backspin, shot arc, shoot speed and consistency, and how long the ball has been in one hand while dribbling. The ball transmits all the info to an app on a smartphone, providing the coach with instant metrics.  (Source:  Article by Katie Lindendoll on ESPN)

Naturally, I wanted to know what’s on the inside, processing those 6,000 points of data per second.

The nitty gritty: the brain (or core) of the basketball uses a TI-developed, low-power, high-performance digital signal processor (DSP) calculation engine. It’s an engine that collects and processes the raw data from nine inertial sensors. TI’s dual-mode Bluetooth/Bluetooth low-energy connectivity wirelessly transmits the data from the basketball to smartphones and tablets.

TI also developed a Qi-compliant antenna, which partners with InfoMotion-developed multi-layer flexible circuit boards. This means that the ball can be wirelessly charged without plugs or  And all of this tech is integrated into the ball. (Source: TI Blog Around TI)

I’m presuming the developer used a TI C5x DSP, TI’s lowest power family of DSP’s – we haven’t yet had the opportunity to use one, but look forward to it In our next very low power design.  It would be interesting to know what sensors are used – clearly an accelerometer, but what else? And, how do they determine how long the ball has been in one hand? Good to know that DSP – and a TI DSP, no less, which is what we use in many of our boards –  is alive and well, and living in smart basketballs.

Meanwhile, what else is there to say except GO ORANGE!

Syracuse Logo

How well does SO-DIMM stand up to shock and vibration?

Posted on by

Critical Link’s System on Modules use a SO-DIMM connector, and we sometimes get asked just how well this type of connection will stand up to shock and vibration for applications that really get a workout.  This is a good question, and if the answer were “it doesn’t”, customers with apps where there’s a whole lot of shakin’ going on would be looking at designing – not plugging – their communications module in. And we all know that a full custom design is more expensive than something that’s off the shelf.

So we looked for a way to make our SO-DIMM’s more rugged. And to do it cheaply.

But before revealing our secret sauce, I first want to say that SO-DIMM’s perform better than people might think. To begin with, the lever arm is not all that long, and the mass is not all that high. But what we added to make sure that the module wouldn’t shake loose was mounting holes on the back end.  These are used to secure the connector in the socket, so shock and vibration aren’t a problem.

We, of course, worked with our customers to perform some shock and vibration testing to make sure that this would work in their application, checking out how the module would survive under a couple of scenarios.

In the first test, we subjected a board to random vibration of 50Hz – 5000Hz starting at 6Grms level. The vibration level was increased from 6Grms to 20Grms in 2Grms increments. The dwell time at each level was 30 minutes where the frequency was varied between 50hz to 5000hz.

For the second test, we tested for both vibration and shock. On the vibration side, we varied the vibration from 20Hz to 2000Hz for two hours in each of the three perpendicular axes at an acceleration spectral density of .04 G**2/Hz. For shock, we dropped the DUT along each of the three perpendicular axes at 20 G’s with a 1 mS duration for a total of 18 shocks.

The boards passed both tests.

And, just to put this into context, by way of comparing our tests to real life, here are the vibration levels experienced in some vibration-intensive situations:

  • Turbine      engine vibration = .03 G**2/Hz
  • Rail      cargo = .002 G**2/Hz [0 -> 350Hz]
  • Jet      aircraft cargo = .01 G**2/Hz [11 -> 2000Hz]
  • US      Highway truck = .02 G**2/Hz

So the answer about a SO-DIMM connector standing up to some pretty rugged situations, the answer is “yes, it can.” All it takes is a couple of small standoffs to hold it in place.

 

How the MityDSP got its name

Posted on by

Every once in a while we’re asked how the MityDSP – the original member of Critical Link’s Mity family – got its name.  Were we paying homage to MIT? (Or to James Thurber’s Walter Mitty, but forgot to add a second “t”?) Does “mity” have some special engineering meaning that only CriticHere he comes, to save the dayal Link was familiar with? Were we thinking of all the Mighty Mites out there – guitar parts, canister vacuums, triathlons, Jeeps, dog gear?

The truth is, we were thinking Mighty Mouse. (And the truth is, we couldn’t spell.)

Mighty Mouse, after all, embodies a lot of what the original MityDSP – and all the other Mity’s that have followed in its path – is about:  packing a lot of power in a very small package. And, for developers who needed embedded, customizable computing, the MityDSP, like Mighty Mouse, comes to save the day. It may not be saving citizens of Mouseville, but for our customers, the day is saved in terms of speeding up development and lowering costs.

By today’s standards, the original MityDSP may no longer seem as mighty as it did a decade ago.  The speed, memory, and throughput of the system on modules that have followed it far surpass what the first MityDSP could do.  And we’ve branched out to include ARM-based SoMs in our family as well. (You’ll find a quick comparison chart here.)

Anyway, while we may not have got our initial spelling right, our Mity family has kept with the original problem:  small in presence, mighty in power, flexibility, and quality.

 

 

Partner Focus: Timesys for Embedded Open Source Linux

Posted on by

In developing our System on Modules (SoMs), we look to incorporate the best available hardware and software components – components that support the purpose of each SoM, and that are produced by partners that share our commitment to quality.  Our MitySOM-3359 SoM is embedded in a lot of applications that require sophisticated UIs and 3-D graphics.  For us, that means Linux.

Providing general Linux support isn’t the primary focus of our business. So we knew we wanted to work with a partner with expertise in supporting commercial-strength embedded Linux, a partner that could support the types of apps that use the MitySOM – industrial, instrumentation, medical, commercial, transportation, and agricultural applications, integrated into bench-top, handheld, kiosk or mobile devices.

The partner we chose to join forces with was Timesys. Like Critical Link, Timesys is a platinum member of the TI Design Network, a group we’re very proud to be a part of, so we knew that Timesys meets TI’s high standards. (Okay, that’s a plug for us, too…)

And from a product standpoint, Timesys has an embedded Linux software development framework, LinuxLink.  We liked LinuxLink because it has the advanced customization capabilities our customers were looking for. Having access to LinuxLink is important, because the learning curve for Linux can be steep. Setting up a development environment and building a customized root file system and kernel is a real challenge if you haven’t done it before.  Timesys provides an easy (and free) way to do all this. There is a free version of LinuxLink which allows you to build a custom BSP/SDK that includes a kernel, toolchain, root file system and gives you access to lots of open-source software packages. And with it, you get to use Timesys’ TimeStorm IDE for application development and debugging for 30 days. (You can register for the BSP/SDK here.) There’s also a PRO Edition of LinuxLink for developers looking for advanced customization and integration of their Linux platform, and with the PRO Ediction, you get support from Timesys whenever you need help.

The end result of Critical Link and Timesys joining forces? Our customers get their applications to market faster, without sacrificing on quality or on the customization capabilities they need.

Just wanted to let you know so you can go check Timesys out…

Is DSP Dead? Not Really.

Posted on by

With Gene Frantz, the father of DSP, retiring from TI, I thought it might be time to once again revive a question that comes up every few years (sometimes even because Gene has raised it): is DSP dead?

Believe me, since many of our SoM’s incorporate DSP, and, in turn, are used in our customer’s applications, it’s a question that those of us at Critical Link often ask ourselves.  And it’s certainly easy to see why someone might have doubts about DSP’s future.

Many of the tasks that DSP has taken care of are – especially for consumer devices like cell phones and cellular-enabled PDA’s – are being moved to dedicated, hard-coded hardware. For applications like these, that basically have a shelf-life of a couple of years, using a CODEC makes perfect sense, and we see a shrinking DSP market for devices that are more or less throwaway.

But for more complex applications  – like those in the instrumentation and test and measurement worlds where Critical Link’s customers are – we predict that DSP’s will be around for the foreseeable future.  Let’s face it, there are some tasks – like application specific or “special sauce” mathematical computations– where DSP’s are still far better than general purpose processors.  And for longer-lived applications, you want to have the option of programmable processing, because of its flexibility. There are also situations in which you’d choose a DSP because you need to support a brand new protocol for which no CODEC as yet exists (in fact, the standard is just now being finalized). One example of this is H.265. There’s no CODEC, so initial products supporting H.265 will be implemented in programmable DSPs .  In fact, even when a hard core like a CODEC exists, , we see customers that want to do something just a little bit different – so they leverage the CODEC, then add their own twist using the flexibility of the DSP.

So, while we are seeing growing interest these days in non-DSP processors – a number of our latest SoMs are ARM-based – rumors of DSP’s death are greatly exaggerated.

And to Gene: congratulations and best wishes for the next big thing you’ll be working on.

 

Product Quote Engineering Support Inquiry General Contact Email Us