Sunday, December 29, 2013

API access, more testing, lots of fun

Long time, no post (... real life intrudes on my fun, unfortunately).

However, recently Flex have been kind enough to grant me access to their API program, so I have been learning and experimenting with connecting to the radio over ethernet.

This is every bit as fun as I had hoped, not least because it brings together some of my biggest passions: radio, digital comms and functional programming (the latter because I'm creating a Flex 6x00 Haskell API as I go).

Visibility into what Flex have done in regard to the radio as an internet appliance further reinforces my positive impression of this product and the company.  Clearly, the 6x00 is a product resulting from a remarkable amount of combined intellectual capital.  It continues to be very exciting to contemplate the opportunities afforded by bringing together the technologies in the 6x00.  Without a doubt this was a very ambitious project, especially for such a small company, but I really respect what they have accomplished already here, especially 'in the box'.

As an aside, it's clear that the SmartSDR client has a long way to go to fill out features and ergonomics, however even there I would commend Flex for making a great start - the UX is clean and uncluttered, emphasizing the signal visualization in the panadapter(s).  SmartSDR does not semi-permanently surface every single control a la HF radio front panel, which I think is a big mistake of many SDR interfaces.  Doing a 'genuinely digital', simple, yet efficient UI for an SDR is far more intellectually challenging than just sticking controls everywhere on the screen (even if they are organized in different panels).  There is of course always a 'matter of taste' involved in UX and naturally also a large degree of hysteresis due to experiences that users become habituated with.  In Amateur Radio it's certainly true that many operators prefer hardware front panels with many options immediately available via dedicated controls.  However, I feel that the default views for software controls should be clean as possible, even if there are options for pinning additional controls in the UI so they are available with fewer clicks or keyboard interactions.  One thing it's hard to argue with concerning SmartSDR today is that the basic panadater view is awesome, affording such an amazing real-time, high-fidelity view of the received signals.  It's wonderful to have a realtime frequency analyzer as your view on the world (and from experience with my son, it's also an amazing learning tool). That's not unique to SmartSDR of course, but the emphasis and fidelity of this feature is the best I've personally seen.

Back to the API, unsurprisingly my initial goals are to get signal data streaming from the radio.  Hopefully I can send audio out without too much trouble and then move onto some of my ideas for scanning the band and deducing signal locations and modes.

Finally, Adam has run a fresh barrage of tests on my 6700 with the possibility of doing even more.  The reasons for the number of test runs are twofold:

  1. The radio is evolving with features and fixes that have a bearing on the testing
  2. There's a lively discussion ongoing regarding appropriate and effective metrics for SDRs given their entirely different modus operandi compared to analog radios.   This discussion is converging on some methodologies and metrics that should be a better fit for meaningful comparisons across SDRs (in particular) and additional test runs are collecting relevant data.