Sunday, May 29, 2011

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.

Thursday, May 26, 2011

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.

Wednesday, May 25, 2011

(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

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

Tuesday, May 24, 2011

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?

Monday, May 23, 2011

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