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.

MTF.

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

Slashdot turned me on to this article in the radar.oreilly.com 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:

Silos

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
and/or
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.

Managers:

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.

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

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.'

Background

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.
  

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 Xen.org 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.

MTF.

OMG-IDL: How To Build a Protocol

So,




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 ?!?

BeerScore

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

JES: Rocken Sie an!

-CH

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?

A Slight Pause...

It's Finals next week, so my posts have been held up.

In the Pipe Line:
- SDR? What the Heck Is That? (Part 2)
- Leigh's (WA5ZNU) ground-breaking work ('Weekend Hack') on a 128-pole SDR waterfall, on an Arduino
- Idea: 802.11 'Broadcast' for AF streams; Use your spare router to let others hear what you have to say.
- Idea: Quasi-Open 802.11 AP, locked down for Echo Link; Facilitate local hams, and have the ability to make contact in 'RF-Shaded' locales. OpenTRx should be able to handle this mode as another CLASS 1 or 1a RF adapter over IP.

Reflections on HamLib

There is no doubt in my mind that HamLib is a brilliant implementation of rig control software. As an API, it's contribution to the Ham Community is invaluable.

However, HamLib's strength is it's weakness: HamLib must exist to unify the interface to computer-controllable radios because the manufacturers have neglected to revolutionize how we interface with the rigs, on their own. With the notable exception of Kenwood Inc., instead of being a symbiotic relationship, Rig Manufacturers see computerized control as an afterthought... an 'added feature.'

'...Allow just enough of the radio to be controlled by computer, so that contesters can take advantage of our rig,' in the case of main-line HF Radios. Of course, those Contesters are usually the ones who spend oodles of money for the newest features, either simply to posses them, or in order to try and increase their scores.

Perhaps 'Regular Hams,' are not seen as being lucrative enough to justify innovations that could change the Radio Art.

Moreover, each manufacturer's implementation of computer control strategies is so radically different from the next, that the only common denominators in a unified control protocol -- especially when it comes to 'conventional,' 'narrow-bandwidth' rigs -- is the ability to change frequencies, bands, and modes.

Even these features have their own discrepancies: There are differing implementations (if any implementation exists) of feedback, or 'alerts,' so that the controlling software will knows that an operator changed something on the face of Radio (something very important to successful software control paradigms).

So, what can be gleaned from HamLib, and applied to OpenTRx?

1) The groundwork has already been laid: HamLib already defines the minimum operating features a unified protocol must have in order to flexibly interface with a CLASS 1a OpenTRx (OpenTRx 1a) module. 

2) An OpenTRx 1a adapter should, effectively, be a host of the HamLib libraries and rig interface, be it single-purpose, or multi-rig capable.

3) The OpenTRx Protocols should be offered as rig type in HamLib, ensuring backwards compatibility with existing software implementations, meaning that CLASS 2 interface modules must be backwards-compatible with the CLASS 1a control librar[ies].

4) There is no need to implement OpenTRx as a serial- or parallel-port-based protocol, as most all newer computer configurations will not easily or reliably host these technologies, and any that still do will most easily implement the established HamLib libraries natively.

HamLib

HamLib.org, originally founded by Frank Singleton (VK3FCS/KM5WS), Seems to have been following VA3LGD's call for a concrete protocol in rig control by creating HamLib.org (now hosted at SF.net).

HamLib is a 'wrapable' library (API) for communicating to conventional Amateur Radio rigs via [RS-232]. There is still a lot to absorb here, bit it looks like a good protocol definition is already in place for the OpenTRx Class 1 and 1a paradigm!

I am a bit nervous to subsume an entire library, wholesale, until I am sure that we can easily present the right 'hooks,' allowing developers to take advantage of our pipeline with little to no modification of existing code.

For now: take a look at FLDigi, by W1HJK. His group seems to have taken on the mantel of library development for HamLib.

The Need for Standard APIs in Amateur Radio

I found this article, by Lawrance Dobranski (VA3LGD), was linked from the ARRL SDR page.

He was WAY ahead of his time.

In Summary:

Software Developers have to scramble in order to provide new interfaces for new equipment, and for the betterment of the Amateur Radio Community, there needs to be a common, extensible, supported communications protocol (API) between the radios and their controlling software.

Lawrence's article was orriginally published in the back of the Jan/Feb issue of QEX, in 1999.

(I gotta brag)

It's just a quiz, but 30+ years of battling ADD and Dyslexia...

Finally, it seems that


I'm mastering the [mental] tools I need to make it at School.


- Posted using BlogPress from my iPhone

Location:Sherman St,Santa Clara,United States

More from Kristen (K6WX) on Elecraft

First, I agree with her comments, which is why I am quoting her (below)

Second: I really should ask if she wants to contribute here...

Thank You, Kristen!

[H]ere is another screed I wrote right before that on this topic to W6DH:

I had seen part of it, but not the whole thing. It's a weird slice; it has a neither fish nor fowl feel to me. I'm not sure what I think of it yet. They seem to be stuck in the past with displays. I don't know why they think having the K3's display is a good thing. An iPod Touch is lightyears ahead. I also don't like the choice of NiMH batteries. Why not LiFePO4? It's also quite expensive with a base price of ~$800. With all the options, I'll bet they are in IC7000 territory. They seem to have come around on SDRs. They used to poo poo them. Apparently they will only have a K3 compatible serial control signal. Why not something a bit more modern? The output I/Q might be only marginally useful given how narrow the bandwidth will be out of the roofing filters. I guess time will tell.

I think Elecraft has lost their way a bit. They may sell a bunch to the people who will buy anything they make. I might change my mind about it after I see more, but who knows.

- Posted using BlogPress from my iPhone

SDR: What The Heck Is It? (Part 1)

There is a lot to say about the exploding field of SDR.

From an Amateur Radio Perspective, this technology may — once again — fulfill the promise of a new frontier in research and innovation for the hobby, that may spread to commercial uses.

I see it as a pathway to renewed currency (to be 'current,' not as Specie) for our cherished hobby.

The thing is: SDR is still, largely, un-approachable by the common Ham.

For one thing, we seem to be confused by the question: “What is an SDR?” Does it always involve an external control device? Does a TRUE SDR process signals on-board, or allow something else to handle the translation of Modulated information to/from a human-readable format?

Another perceived barrier to adoption is outlined by the question: “Do I really have to pay that much for the term “‘Software Defined?’”

Lastly, even if one take the leap, what software will be available to make a piece of hardware work?

Towards the first question, I offer this:

“First, Software-Defined Radios — as a broad definiton — are not completely Analog in nature. Therefore, some element of Digital Hardware is integral to their operation.”

Yes, this would mean that there has been, for at least the last two decades, professionally manufactured radios, as well as hobbyist creations, which have relied on some level of digital facilitation, that could fall under this definition. After all, even the Kenwood TS-840 has a digital readout, right?

So, what differentiates these from the newest, latest, coolest-looking computer-hosted radios out there?

For one thing, there appears to be a threshold of implementation, where discrete logic is displaced by a more flexible, dynamic logic.

As an example, let’s take an original Heathkit HW-101. It is well-known to be a venerable, light-weight (for it’s time), analog, Direct-Conversion Transceiver. What if modified it to accept an external Digital VFO?

In the past, there have been numerous digital VFO kits, designed for the specific task of replacing unstable, noisy, or inaccurate analog resonators. These VFOs, for the most part, are designed as pure implementations of finite state machines (FSM), where a discrete (‘defined’) number of inputs generate defined changes in ‘state.’ Most notably: turning of the dial generates a pre-defined signal to the FSM, which causes it to change it’s frequency.

Notice that there is no mention of any other input to this FSM, besides the knob turn. It is up to the designer of the Digital VFO to ensure that just the right signal produces just the right result, using any technique she or he may choose. Moreover, only a physical change in the hardware of the Digital VFO will allow it to respond to more inputs, which requires (at least a partial) re-design.
Just about every radio on the market today shares the same ‘FSM,’ aspect of operation. That is, there are only pre-defined inputs and outcomes.

The Kenwood T M - D700 series of radios only respond to sets of pre-defined control inputs; the internal Packet (AX.25) Controller is able to be connected to any RS-232-enabled Terminal device in order to operate as a stand-alone TNC. But even in this case, there is no element of pure, dynamic control over the inner workings of the radio and controller deck. There is only the ability to change the Packet Controller from APRS to KISS TNC; a simple state change.

Going back to our example of the HW-101 with a Digital VFO:

What if, instead of discrete logic, we placed a sightly more advanced VFO that was designed to respond to inputs through a USB cable, connected to a stand-alone computer?

By relying on the USB standard (one that is defined in both physical and logical realms), we — necessarily — rely upon software, resident on the computer, to control the VFO frequency.

This, precisely, is what occurs in the case of the SoftRock series of radios: A USB cable connects a host machine (Mac, Unix, or Windows, in this case) to a small ‘USB Controller,’ (manufactured by FTDI, in this case) which is responsible for decoding and encoding information to and from the radio. The information, for the most part, alerts the on-board digital VFO (A Silicon Labs Si570, in most cases) to change to a specific frequency, as requested by the Host computer… which is running a piece of customized software… which is being controlled by the Ham Operator (auspiciously).

So, does the Example of a SoftRock USB control meet exceed the threshold for our definition of ‘Discrete Logic?’ It’s a grey line, to be sure. Yes, the radio is controlled by software, which can be seen — in itself — as a dynamic actor in the chain. However, the if VFO can only accept frequency change requests, or report it’s state through the FTDI USB controller, there is still a degree of re-engineering involved when it comes to doing anything besides changing from one frequency to the next.

‘Ah,’ you say, ‘… so that means the SoftRock — by definition — can’t be accurately described as a Software Defined Radio!’

Not so fast, I tell you! Here’s the rub: there are not one, but two wires (besides the power lead) emanating from the SoftRock. The first is the aforementioned USB cable. The second wire:

I/Q data.

Stay tuned, friends, for the next chapter in the Continuing  Saga:

“What the Heck Is It!?!”

Preliminary Mission Overview of OpenTRx

Here is a transcript of my [rather disjoint] mission concept, posted to my friends (and project contributors) Kristen, Leigh, and Mike this last Monday:

Everything is stated only as a suggestion, with the sincere hope of a feedback and change.

What are your thoughts on the points below:

My original idea with this project: flesh out a framework for uniform discovery and control of radio assets, be they adapted-conventional (FT-817/K-n), or sofrtware/Pan-adapted/I/Q (SoftRock, RFSpace, GNURadio-Based, etc.). Let's ensure that there is a facilitation of building blocks for new radio sets (control calls for everything form f(LO) to AGC speed). Let's be ready to handle new definitions of discrete blocks of radio architecture, so that one may select UI, IF/LO, PA, Filter, and myriad other elements for their operating needs.

my overall vision: a new modular portable radio, with swappable RF decks and UI; A manufacturer releases a new radio, with claim to compatibility with certain elements of this standard so that customers know that their open software will be able to control/program/test the radio, just like their other radios; a budding experimenter can use our platform to handle all the other elements of operation and control, while they simply build a new, fun, and excitin [fill-in-the-blank].

a general plan suggestion:

1) define boundaries of the project, in view of use cases;

2) break the project to discrete elements

3) single out our most relevant elements for implementation by this time next year,

4) and then implement a reference design for a [simple] device.

Steps 1 to 3 should be done (in draft) soon, so we can start coding ASAP.

Here is a framework I was playing with:

Stratification by Classes of control:

Class 1: Conventional interface, conventional rig

- TxAF/ RxAF (<=5khz); PTT

Class 1a: Conventional interface, conventional rig + (some level) of remoted control

- All Class 1 Atributes + CAT/CiV/[hacked TM-D700]/[etc.]

Class II:

- All Class1a Attributes + IF (I/Q) Rx/Tx

Class III: TBD

I think controlling devices should be os-based with custom binaries, implementing JSON. I'd prefer the devices to act as USB Hosts, which may get in the way of iOS, initially.

The protocol would be light-weight for all Class 1/1a out-of-band operation. More importantly, I think a ham should not be intimidated to put someone's embedded controller implementation onto their own rig.

For now, we should assume local (i.e. <=5m) control, with minimum latency/jitter assured; REST sounds like a perfect solution, Leigh!

I proposed these Classes of control (above) as a suggestion for an extensible development framework. Also, in order to stratify the levels of intelligence needed to make a client radio work: Class 1 should be the easiest thing to implement from scratch by a budding experimenter.

One of my ideas is that each Class of radio would be a modular replacement for the next in it's class, with a set of required attributes, and a set of optional attributes that can be auto-discovered, where a simple binary or xml upload reports the units capabilities... though the auto-discover should be taken on at a later stage of development ;)

The overall power consumption will have to be a concern at some point, so no approach should force us to (re)hack extensive libraries in order to get the efficiency we need.

For now, USB seems the most accessible media... But I wonder if the focus should not be fixed on implementing everything through IP (v6, preferably, as mDNS/bonjour could be our friend here, and we'd have a LOT of flexibility in more complex environs down the road).

Mike, to your question of architecture: ARM has the Thumb2, and the Jazelle instruction sets, so we get logic-level compatibility with just about every language out there, including Java. The Eclipse toolchain for the ARM is not perfect, but I am happy with it. Mostly, I think that the ATMega/Arduino paradigm is just too limiting. So, for instance, I'd advocate for ARM M0 when it comes to cheap radio adapters.

The downside of arm: the only DIP packages available are as stamps, with a min of 48 pins on the processor, so not as accessible without SMT/adapter techniques. The upside: code longevity.

Besides, there's nothing that says a super-simple host controller can't be implemented with an AVR-8, which is something the protocol should try to not limit.

The Straw That Broke the Camel's Back

Following is the Email thread (edited), started the day after Maker Faire, that convinced me it was finally time to finish the daydreaming stage, and bring OpenTRx to the real world :

[Last Reply from Kristen, K6WX; Monday, 5/23/11; 13:00 PDT]:

I'm with you on the control channel.

Either BT, ethernet, USB, or WiFi; why not take the control architecture into the 2000s.  Who cares about the K3 command set.  Have a compatibility mode, if you must, but you can only advance by breaking from the past.  Get rid of PIC (if they're still using them); use ARM or something more capable.  Run some real operating system.  Allow me to add daemons, or apps.  Allow me to telnet / ssh to the radio.  Give me a real display.  Let me get I & Q both before *and* after the roofing filter.  Adequate ADCs are cheap, especially if you're doing analog mixing first.  There is so much more that can be done with embedded computing these days, and all with minimal power requirements.  Cell phones are lightyears ahead.

I was also surprised that Wayne said NiMH batteries were to be used.  They're certainly cheap, but Lion or even an optionally more expensive LiFePO4 pack would be better.  A123 cells aren't that expensive.  Charge controllers are cheap.  NX6S and I found that out on a project we were working on together a few years ago.

If you carry too much past baggage around, you end up like MS.

On May 23, 2011, at 1:31 PM, Leigh L. Klotz, Jr. WA5ZNU wrote:

> They mention optional roofing filters, but if the IQ out is after that
> it's going to be severely band-limited.  In the K3 it's before it so I
> suspect it's similar.  "Totally different architecture from the K3" could
> mean anything or nothing.
>
> At Pacificon I repeated until Wayne asked me to stop that they should put
> in the ability to do absolutely everything you can do from the front panel
> over a wired/wireless connection, i.e. an interface that one can make
> available over BT via serial, for example.  He said the command set would
> be K3-compatible.  If you want wireless spectrum display on your phone or
> pad, a likely solution is an 802.11/linux box with built-in sound card
> hooked to the IQ and then serving up the spectrum over TCP.  (That's what
> I did in znudigi, for example.)  This box can be pretty small.  A beagle
> board may be overkill.
>
> Leigh/WA5ZNU
>
>> After looking at the video, it could be an interesting choice for mobile
>> operation.  I sure wish they would go to a dot matrix display, and that
>> would open up some interesting UI possibilities.  They are so cheap,
>> dense, and power efficient these days.  I had an amusing thought just now
>> of making the front panel of a radio from an iPod Touch.  I also wonder
>> where the SDR slice happens.  The total price is also important (at least
>> to me).
>>
>> On May 23, 2011, at 7:17 AM, Leigh L Klotz, Jr. wrote:
>>
>>> It look fun, priced a little above the 817 supposedly around 799.  We
>>> ran a "focus group" for it at Pacificon (hfpack forum) and the consensus
>>> there was 20W for SSB.  The specs say 10+.  We got Wayne to fix the T1
>>> so it would handle 35W from the HFPacker amp from K5OOR instead of the
>>> orignal 20W, but this may be harder to change.
>>>
>>> On May 23, 2011 12:02 AM, "Michael Pechner" wrote:
>>>> Looks really interesting.
>>>> http://www.youtube.com/watch?v=mbtyRyEEADo&feature=player_embedded#at=326
>>>>
>>>> --
>>>> Michael Pechner
>>>> NE6RD - Amateur Extra
>>>>
>>
>>
>>                                    -Kristen (K6WX)
>>
>> "Your eyes ... it's a day's work just looking into them"
>>                                        Laurie Anderson
>>
>> (--... ...--  -.. .  -.- -.... .-- -..-)
>>
>>
>
>


                                    -Kristen (K6WX)

"Your eyes ... it's a day's work just looking into them"
                                        Laurie Anderson

(--... ...--  -.. .  -.- -.... .-- -..-)

There's a New Logo

Cliche? YOU BET!

Now that there's some kind of logo, the rest will just take care of itself, right?

Open T/Rx Manifesto

I am sick of manufacturers defining how Radio Amateurs interface with, and use our own equipment.

As a community, we stand upon a tradition of innovation, creativity, and openness.

For far too long, I, and my fellow Radio Enthusiasts have allowed this spirit of innovation and sharing to atrophy, allowing our hobby to, in large part, be defined by a select group of companies.

I don’t blame the Manufacturers; they make excellent, reliable, fun, and (mostly) equipment. Their contribution to our hobby has been unequaled, and they have carried the mantle well. In fact, I believe that there is a severe need for the engineering and reliability that they bring to the table.

But, in order for Ham Radio to stay relevant in this new world, I believe it is incumbent upon the innovators of our community to, again, step forward, and provide the tools, technology, and experience that can fulfill the promise of what makes Amateur Radio great:

Each and every ham should have the opportunity to design, hand-build, and operate the most modern, cutting-edge equipment as they see fit.

To that end, I offer:

opentrx.org

More to follow...

- DE KG6O

No one expects...

The two best things Apple can do for the iPhone OS at this point: 

• Allow applications to be aware of an on-board file repository (i.e. allow apps to access the same file on the same device at different times)
• Add multi-tasking (like allowing audio apps OTHER than itunes to play music in the 'background' while using Safari.) 

The third... 

• thing is allowing Safari to render static Flash apps, or Apple should AT LEAST provide a viable in-browser alternative for developers.

...and a fanatical devotion to the Pope.