Sunday, March 01, 2015

Algoram / Whitebox: SDR For the Masses

The Info

Bruce Perens (K6BP) and Chris Testa (KD2BMH) are on their way to releasing a new device to encapsulate the spirit of Ham Radio and Open Source: Witebox.

Here is an interview on the subject of SDR and Whitebox from Hamvention 2014:

Just this week, Bruce put up a Slashdot Article, linking to a slide show about the Algoram HT, presented at the 2015 Florida HamCation.

Seriously: Read through Bruce's slides on the Algoram HT. It's the best snapshot I've yet seen to describe where his mind is with respect to Amatuer SDR, Codec 2, and the Ham Radio industry in general. 

Some Analysis

From the slides, it appears that the 'dev' version of this project will be a revised version of Chris' Whitebox design, slid into a standard Hammond case. Additionally, there is no indication of a 'MIC IN' or 'PTT' connection. Fingers are Crossed!

Whitebox is still building a notification list to let people know when engineer-level eval kits for the experimenters/engineers among us will be available. From the slides, at least, it seems that they are well on their way to having something tangible in production within the year.

Where This All Fits

Though the HackRF has been out for a while, the vagaries and technicalities of GnuRadio can make it harder for 'regular' hams to readily adopt such systems. This is not a criticism, by the way. 

GnuRadio is really for/by the Experimenter Crowd, for the same reason that you are probably not likely see Septuagenerian Hams sporting their 2-pound RF enclosure duck-taped to a random Android device -- complete with drooping cables hitched into a fanny-pack loaded down with LiPo cells: It's a burden for the newer generations to endure, and see through. FlexRadio already seems to understand this dynamic, as well as Elecraft.

In order to go mainstream, a radio 'kit' needs a lot of supporting hardware and an innovative community that has done things with it. If anything, this make it look much easier to adopt the radio and do the same things. Hams are willing to pay for having the hardest things done for them. Case in point: in 1981, ARRL published schematics and code for CMOS Super Keyer. That became part of the genesis story of Idiom Press, for which KCØQ and NØII continued to produce the Super II (which the ARRL published docs/schematics for in 1994), and then on to the Super III and modern Logikey series.

I now have two Super II CMOS Keyers, if only because I forgot that I owned one of them... and, it seemed like such a great product with amazing utility at the time.

While Whitebox appears no further along the path to 'main-streaming' SDR for hams, the spirit of K6BP is ever present, which portends good things for the FOSS/Ham community, as a whole.


Monday, October 08, 2012

For Hiring Managers: Dump the Resumes, and Play More Ultimate Frisbee

Slashdot turned me on to this article in the blog.

The gist: There appears to be an issue with employers over-specifying the properties required of applicants for job openings.

I am not sure if the article is wholly accurate, and if so, to what degree existing Tech-related or Non-tech-related concerns are guilty of this charge, but I can vouch that the concern is real.

Moreover, I will use my podium to take Loukides' assertion two steps farther:

  1. Most companies over-specify jobs because they want to hire tallent, sometimes from somewhere else, attempting to avoid the perceived drag of inexperience from a new hire
  2. Over-specification has a long-term negative effect on the tallent pool by building silos

Shooting the Moon

H.R. reps, by and large, are not so good at selecting or pre-selecting candidates for positions if they don't fully understand what the hiring manager really needs.

My uncle graduated with a degree in HR, worked in a major tech firm in the HR department for many years, and has since left to be an officer in the family business. He was the first to inform me that many HR reps feel it's their job to find the right person for the position, when in fact their job should be limited to ensuring that good applicants don't get missed, and/or that the hiring managers not make costly mistakes. The problem of over-specification of a job opening, then, can arrise with '... the Pointy-Haired Boss,' when she/he doesn't want to spend resources [that they may or may not have] on training someone -- or at least seeing that they have a handle --  on the specific problem to be solved. Instead, they write up a new job description, and hand if off to the Human Resources group for fulfillment.

I have seen this happen a few times, where the process can only seem as if a manager feels their organization deserves the tallent they are hunting, or as near an analog as their brand may attract. It has been explained to me that they are '... Shooting the Moon,' and seeing if even a little lunar regolith will grace the applicant pool... after all, aren't there 1 Million worthy candidates out there, already? Why should anyone have to handle (the thinking continued) the crush of replies to a job posting for a good programmer which would have to train up a bit before being let loose on the issue while earning a salary?

So, instead, the manager feels comfortable to post an add specifically describing a friend they already know, who works in that OTHER successful company. The description enumerates their friend's exact duties (which, the manager may not realize, are most likely NOT the ones for which her/his friend was already hired). And, the manager hopes, if the perfect analog tho their friend should apply, H.R. won't miss the resume.

The real downside here is that, in each case, the hiring manager usually
- never gets exactly what they were looking for:
- blames H.R. for the resulting lack in their productivity/ability to reach some goal
- missed out on at least a few people who, in retrospect, would have been a perfect fit for the position

Usually, the manager would forget the forces exerting pressure on their team, resulting in shifting goals and dynamics, along with shifting job titles and responsibilities. Hiring someone that they, and their team, can work with in the long term never seems to be as important as trying to fix something broken at that moment.

That's why my resume is not particularly good or focused on some skill set: I want to be handing a resume over AFTER I have met them, so they have more to talk and think about before our next meeting, instead of my attempting to fit myself into some arbitrary and ephemeral box. Chances are that the manager who hires me will see my skills for what they are, and can be... not necessarily what they want to see at that moment.

Which brings me to my second point:


If the job description is so targeted (and sometimes unreasonable), does the application pool fail if no one submits a perfect resume? In the real world, probably not. Close-enough will do, by-and-large. This is most likely why most online job postings have at least 5 bullet points each for the sections on Experience and Responsibilities*.

Either way, the 5+ bullet points are a scoring mechanism to add some arbitrary level of comparison of applicants**.

By releasing these strong job descriptions, in-transition professionals (such as myself, at the moment) may be forced to assume their only chance at being hired on to any organization is through possession of the exact skill set and experience listed for some job. This leads to professionals working harder to build up their '...credz,' in a given discipline, or to abandoning hope altogether and instead going out to play some Ultimate.

By constantly working towards a job title, the professional eventually builds a skill set that may only be marketable to one or two organizations. By the time they are ready (in the case of the Tech industry, around 5 years) the need for those skills has been satiated or depleted. A good example are people who worked very hard to become versant in repairing radio electronics by hand in 1996, which turned out  BIG mistake, from the future-marketable-skills perspective. Instead of looking for the next brace of technologies that would bring increasing job opportunities, I was repairing equipment that would probably not be in service 5 years later. It took me another eight years of hard work just to 'come even.'

The idea, of course, is that a good professional will always be able to see the new trends while they are hired in the industry, so that when the time comes, they will either be ready with required skills for the next '... Generation[al Fad],' of jobs, or that they will at least have the contacts established, and therefore able to find new employment.

Unfortunately, I have some friends who are otherwise well qualified to handle just about any programming job, but have struggled to find work, for lack of publishable skills matching to the needs of the job postings. One has told me this is because their previous employment required so much of their time that they didn't have any resources left to network or train up properly. Again, with the '... Pointy-Haired Boss' argument, from the perspective of the 'victim,' but I do believe there a seed of truth in their argument: silos happen before and after the hire.

* Try counting how many experience-required bullets each job posted on one organization's website has. Notice that it's the same number each time?

**The fact is, by the time a job is posted on-line, either/or:
- the hiring manager has probably exhausted all possible leads from internal contacts
- the job description is likely for a number of positions (i.e. '... generic')
- the H.R. Department might just be following some internal protocol intended to gain more applicant submissions

So, What to do?

I have a few suggestions:

Future Employees, You need:

a) Luck (We all have it, just not always at the right moment...)
b) Networking Skills
c) A worthy display of passion for something that may not endear you to the next employer, but does display an ability to do great things

The right manager will come along, as long as you are 'out there.' In the Tech industry, we programmers tend get noticed when we have our signature on a project or software release, but that's not a good answer to the problem, either.

When I was hiring people for my teams, the I found those who proved to be the most awe-inspiring, innovative, hard-working employees were referrals. Resumes were submitted, and I admit that I missed some good opportunities by relying on paper. Referrals, on the other hand, came from friends in my hobby, professional and service group circles, and then from my own employees. Likewise, for almost all of my friends, I have watched their progress to being hired into some amazig jobs through the simplest connections. With sports (e.g. Ultimate Frisbee) and other Endeavors of Entusiasm, the silo walls tend to come a-crashin' down.


a) Consider what it would be like to throw the resume'd application system out of the window.
b) H.R., by it's nature, is not set up to find you the one person who will be the perfect fit for your team [trust me, here]: it's up to you, in the end. Solely relying on resume metrics to distill your applicant pool can run a serious risk of loosing that applicant you are really looking for (see 'a').
c) If you haven't found someone within your pool of local contacts, try expanding the circles... or [to be kind] if you are already working too hard to build a pool of candidates already, hire the head-hunter that can tap into, and build those social circles. Either way,
d) Try to use H.R. in the manner which they were intended: to disallow you from making bad mistakes. e) Resumes should be seen as a conversation starter, not as the main course! Otherwise, we all loose out on the chance to find, foster, and lead great tallent down the road.

In short: Perhaps it's time to play some more Ultimate Frisbee!

My real point: Emphasizing relationships and trainability (two metrics NOT easily evaluated from a flat resume), a hiring ecosystem can be developed where the barriers of generic, compartmentalized, silo'd, measurable organizational charts can be broken, and everyone has a better chance at a fair shake.

Saturday, August 25, 2012

This Is Why We Moved Here

Sunnyvale Farmers, Bean Scene, and The Merc. All 5 min from our front door. I <3 SV!

- Posted using BlogPress from my iPhone

Saturday, January 28, 2012

Why I Like Threads

To me, `Coding' has more to to with being an outstanding Animator  -- ensuring that my character's actions are in tune with the rules of Cartoon Physics --  than simply computing and passing results.

I am about 8 months in to earning by Master's Degree in Computer Engineering from SCU, and my favorite class this year, entitled "Operating Systems," has just hit Pay Dirt!

Within the required reading, Tannenbaum is explaining the broad concepts, to intricate detail (ala: ground-up-in-abstract... heh), concerning the topic of 'Threads.'


Informally: the term threading is the use of rather simple, and therefore powerful, programming techniques and constructs to keep modern computers from working like Word 2.0. Back then, when you selected the "Save..." menu item, your computer completely froze until the disk was done being written to.

The reason your PC Jr. was unable to respond to outside stimuli had a lot to do with the inability of the [now] primitive microprocessors and software to handle the human equivalent* of drinking a sip of coffee and scratching an itch simultaneously.

Today, Computers can do this.  With technological advances comes the ability to execute thousands, or even millions, of separate chores at once... though not really**.

*I am not yet sure if science™ has yet resolved the question of whether an intelegent organism is actually capable of processing two things at once. Though, I do hear rumors that there is an ever-increasing number iPhones being damaged due to sudden deceleration in concert with auto accidents... so the jury is -- most certainly -- still out.

**I'm still not there, in the book...

My Revelation

Remember that old cartoon, where the pro- and antagonists are scrumming along, humorously slapping each other around, tit-for-tat, and there's the sound of a wheel of rubber gloves rhythmically striking a brick wall? Inevitably, they transfer the fight over the edge of a cliff, and the slapping continues... in free-fall.

That's what I now think of when I see pure threading constructs in programming: choreographed, perfect, comedic free-fall.

... and when I think of threadding in a Windows, I also hear that comic slapping sound.

The analogies

  • The free space we see our characters falling through is, in truth, contrived. On one level, the environment, and the characters, are provided to us by the animator. In threading, the Operating System is that free space. Both have significant and arbitrary power over the characters in question.
  • The physics of the cartoon is arbitrary, and can be modified for comic relief. So, too, with Operating Systems.
  • The Characters are, to the viewer's mind, set in their pattern of action. The only way to halt the fight is to stop the film. So too, with the threaded programs.
  • Once the animator has committed their subjects to film, there is no turning back: neither the audience, nor the animator has a way to change the outcome of the fight. So too, with threaded code.

Sunday, November 13, 2011

Idea: Sleep-Start Multi-OS Handling

Please, tell me if you've heard this one before: I think we need a way for a CPU to be able to go to sleep in a particular OS paradigm, and then wake up in a different OS Paradigm.

I.E. Given a Dual-Boot Machine (How about my trusty old NW9440?), with Linux and Windows installs selectable from the MBR (Grub, in this case): In order to make a context switch, I must either shut down or hibernate the current OS -- gracefully or otherwise -- and re-boot or 'wake from hibernate' into the desired OS.

This is getting old! Though most hibernate functions have a cost 1/10th of the full-boot/shutdown options, that's still not fast enough for me;)

What am I missing, here?

Idea: by being able to ensure that there is as little time as possible spent in my context switch, I may also have the ability to rapidly integrate the opposite 'sleeping' OS into a new VM inside the 'awake' OS.

If I could make sure that the hibernate process only integrates my sleeping OSs to disk, I may have a shot at dual-boot nirvana, where a sudden-power-off condition will be even more-rapidly recovered than before.

So: I would need to find out just how a specific OS goes to sleep versus invoking 'hibernation,' and then see if I can use something, perhaps a micro kernel or tiny VMC to encapsulate these OSs with a MINIMUM of recurring overhead (let the penalties come as they may in the boot up cycles).

After minimal research, the VM may have all of these capabilites, but at what cost? I don't belive I am talking about hot-swapping between live kernels in a hosted environ...

Thankfully, the Advanced Processor Arch. class I am taking now, as well as the 'OS' class next semester, should provide both background, and illumination to the problem.


Monday, September 12, 2011

OMG-IDL: How To Build a Protocol


After a long summer, it's time to start focusing on... something.

For today: it's Protocol Definition! Thankfully, the Content Creation Wiki has provided the answer I've been looking for, to a question I have not quite defined:

"What is the difference between a protocol and and an API?"

In short: An API is more 'vertical,' in nature, as it can make a protocol take on certain 'un-defined' properties; a protocol is a common space/language, which many API layers may wrap and concede to.

So, it seems as if I have opted to take on the learning of OMG-IDL (Open Model Group - Interface Definition Language) in order to plan the OpenT/Rx communications architecture. The goal is to allow media-agnostic, jitter-resistant, multi-layer, multi-class communications between a controlling element and the [tran|re]ceiver.

OMG, buy the way, is the group that brought you COBRA, and acts as Standards Keeper for UML... so how could IDL be wrong ?!?

Sunday, June 12, 2011


Everyone: Please check this out. I soooo wish I'd a garage, don't you?

JES: Rocken Sie an!


Publc Libraries -> HackerSpaces ?

I vas knoodlink through the last 2+ months of blog backlog (wow... I was THAT busy?), and stumbled across this Intriguing Piece, by Phillip Torrone.

The short argument: "It takes money, and manpower, and there is a lot of liability involved... but why not make Hacker Spaces a public asset?"

I agree with the sentiment, but I disagree with the means: We DO (in the State of CA, at least) have accessible public institutions that already cater to the safe, efficient training and supervision of would-be craftsman.

It's called Community College!

This would be the best forum to extend the facilitation of more advanced arts, such as laser cutting, 3D printing, and circuit hacking. Oh, yeah: there's still the old wood planer and lathe for the more 'classically-oriented.'

Certainly, Community Colleges are not above receiving more funding for the facilitation of the furthering Humanity... why not start an organization to lobby for their adoption of the Hacker Space paradigm?