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.
No comments:
Post a Comment