Subscribe to the Free Print Edition!
Celebrating 25 Years
Sprint
researchstore




Tech Blog


By Wyatt Kash


The rise of collaboration teams

John Chambers, Cisco Systems chief executive officer, has a reputation for recognizing emerging technology trends and then having Cisco lead by example.

So his comments in the November issue of the Harvard Business Review, particularly on the shift to--and growing importance of--collaboration teams, makes interesting reading.

As Steve Kelman, the Harvard University professor and former OMB Administrator of the Office of Federal Procurement Policy observes in his blog for GCN’s sister publication, Federal Computer Week, the shift to a collaborative world that Chambers sees has important implications for those in government.

In particular, Kelman notes, Chamber’s comment that “At Cisco, our major priorities are managed not by our top five to 10 executives but instead by cross-functional, collaborative councils and boards.

You can read more of Kelman’s take-away here.

Comments (0) | Post Comment | Link to this Page



By Joab Jackson


Resolution is not accuracy

Resolution is not the same as accuracy: That was one of our favorite lessons from last week's Embedded Systems Conference in Boston.

Systems architect Kim Fowler made this distinction during his talk on analog-to-digital converters (ADCs), though its validity could apply to any process of digitizing real-world signals.

The distinction between resolution and accuracy is an important one insofar as while both reveal how well your digital processing system is measuring what it is supposed to be measuring, each describes an entirely different way in which you could get incorrect results.

"Resolution is the minimum span [the ADC] can measure," Fowler told attendees. "Accuracy speaks to how far the real transfer function of the ADC is from the theoretical transfer function."

Resolution is the smallest increment of input that a system would register as an event. It represents size as a single code value.

When thinking about resolution, picking the right sampling rate is critical. The sampling rate is the number of discrete samples taken per second, that are being taken of some continuous signal.

Sample at too low of a rate and you miss the critical contours of what you are trying to measure. Events could happen below detection levels, or your device could capture the beginning, but not the end of some event. Or vice versa.

Also, a low sampling rate can cause aliasing, when shadows of the thing being measured can muddy the image. Filters can be used, but different filters remove aliases in different ways, some of which might affect the results if you don't plan accordingly.

Engineers have long held that to accurately reproduce a signal, the sampling rate should be twice that of the highest frequency of what is being sampled. For instance, most digital recordings for audio CDs are sampled at 44,100 Hz, about twice that of the audible range for humans, which is about 20 Hz.

"That is an absolute minimum," Fowler said of this sampling rule-of-thumb, called the Nyquist–Shannon Sampling Theorem. "And if we are designing appropriately, we want to use that as a bottom line, but we want to have an appropriate margin above that."

For the most accurate signal reproduction, Fowler recommends a sampling rate of 5 to 10 times the original frequency.

Upping the resolution, of course, will provide a more complete picture of what you are trying to capture. But the higher sampling rate you want, the more you will pay for circuitry.

Even if you work out the best sampling rate for your budget, you still have to factor in accuracy issues.

Accuracy is the degree to which your measurement equals the thing actually being measured. The accuracy of ADC could be thrown off by several factors.

One factor, for instance, might be the quality of the ADC unit itself. "Fabrication of the ADC will inject harmonics into your signal," Fowler said.

Such harmonics can cause a nonlinear transfer function, meaning that the device captures input more accurately at some ranges than it does at others.

All of which goes along way to stating that incorporating a 24-bit ADC into your system design will not get you 24-bit fidelity. This worth keeping in mind when considering purchasing or building any system that has to convert some signal into digital form.

Comments (0) | Post Comment | Link to this Page



By Joab Jackson


Why so many bugs?

Why do programs have so many bugs? Because they are so easy to make, especially given the challenging syntaxes of most programming languages.

Recently, Elkridge, Md.-based consultancy firm Netrino published a book, “Netrino Embedded C Coding Standard,” written to help programmers write code with fewer bugs. The volume contains about 100 rules and principals, all involving how to reduce errors that programmers make while composing functions, macros, variables and the like.

At the Embedded Systems Conference, being held this week in Boston, we caught up with Netrino president Michael Barr at and asked him to give us a guiding principle from the book. The one he gave reminded us how a simple mistake could create a huge problem.

Here it is: When having the program compare a variable with a constant, Barr advises to always put the constant on the left side of the comparison, i.e.

"If 1 == Q then [execute the rest of routine]"

This statement says that if the variable Q equals 1 then go ahead and perform the routine. In the parlance of C, the double equal signs mean that the digit on left side is equal to the variable to the right side. It is used to determine when to execute conditional loops, such as this one.

Here is where a mistake can creep in: The C programming language has a very similar statement to the double equal sign, namely the single equal sign "=." The single equals sign actually assigns a value to a variable. When you write "Q = 1" then the variable Q will then have the value 1.

Now, say a hasty programmer meant to write "If Q == 1..." but forgot the second equal sign and instead wrote "If Q = 1."

With C, the program would just assign the value 1 to the variable Q, overwriting the true value of Q. No warnings would be given, no flags would be raised. But with this small, unintended change, all heck could break loose when the program actually runs, because Q now has an incorrect value.

But if the programmer were to follow Netrino's guide and get into the habit of writing "1 == Q" rather than "Q == 1" then when such a mistake were to be made (i.e. " 1 = Q") then the compiler would immediately highlight the error.

The C programming language is dangerous language to work with, insofar as you can create a lot of these kinds of deadly errors. But it is also the overwhelming favorite language for embedded systems developers, Barr noted. So by having programmers abide by these practices such as those offered by Netrino, a development shop could save hours of programmer time spent debugging code.

Comments (2) | Post Comment | Link to this Page



By Wyatt Kash - GCN Staff


Twittering the Trillions

David Walker, former comptroller general of the United States and now CEO of the Peter G. Peterson Foundation—and a growing user of Web 2.0 technologies--alerted Facebook friends earlier today that Twitter is coming to the rescue to replace an aging technology.

It seems a few weeks ago, the National Debt Clock in New York City ran out of digits to show the debt, which has broken the $10 trillion mark.

Well, now you can stay current on the size of the national debt by following it on Twitter.

The Twitter version lacks the series of flashing digits that conveyed the visceral sense of relentless deficit spending by the Federal Government—and was a traffic-stopper on Manhattan streets.

But if your one that likes having the latest sports scores and other salient statistics delivered to your PDA, and aren’t afraid of big numbers, you’ll want to check this Twitter site out here.

Comments (0) | Post Comment | Link to this Page



By GCN Staff


SANS seeks input for IT job survey

We recently alerted GCN readers about a survey the SANS Institute was conducting about the nature of IT security jobs.

The Institute gave GCN an advanced look at the early results. You can find them in this story on GCN.com.

Here is the original alert appears:

The SANS Institute is conducting a survey to find out what the "coolest" jobs are today in IT security, and is seeking help from government IT workers. The security institution will use the results to compile a booklet for students that will tout the benefits of choosing a career in IT security. It needs examples of interesting, high-impact and impressive jobs within the field of information security. Users are asked to provide descriptions of job duties, as well as exciting real-life scenarios, of network administrators, network security engineers and other IT security specialists. Submissions will be anonymous.

Click here to participate in the survey.

Link to this Page