A New Meaning For SDR

First of all, for my multiply friends, this blog is more in the way of documenting this project as I need to leave it for a while to turn to some other things.  But I would like some of my non-multiply friends to comment on it, so it needs to be public so they can see it.

A little background -- well, a lot of background.  One of my objectives longer term is to get DXCC on a radio I built.  "I built" has taken on more and more varying meaning over the years, and it has reached the point where it means something I designed and constructed from scratch, and likely involves some unique characteristics.  And of course, it will be QRP.

In 2007 I went to a Microchip seminar called the Spring 16-bit Seminar.  They bragged on about their 16 bit parts.  These PICs had been somewhat interesting, but some of the things they did at the seminar led me to guess that they had raised the bar a lot further than I had suspected.  Some of the things they were doing I couldn't believe they were doing with a PIC.  Over the past year, the prices of these things have tended down, too.  Now amazingly capable PICs are available for under $10,  PICs well beyond anything that was available a couple of years ago.

Microchip has several 16 bit experimenter boards, the more capable (and expensive) is the Explorer 16. This does a couple of things.  Many of the cooler PICs are only available in hobbyist-hostile packages.  In recent years I have gotten to the point where I'm not afraid of these parts for a "final" design ... printed-circuit boards to support these parts are accessible to the hobbyist, if a little on the pricey side, and I've gotten pretty decent at soldering these tiny things.  But during the development, one might try several different PICs, probably many circuits, and while $50 or $100 for a PCB might be OK for a more or less final project, going through dozens of them on the way to a working design isn't something that seemed reasonable to me.  Well, the Explorer 16 supports these parts on a little plug in board, so you can simply plug in different PICs.  The Explorer 16 brings all the PIC pins out to card edge connectors, and Microchip has reasonably priced proto boards that plug into those connectors.

In the fall, Microchip announced the "Graphics PICtail Plus".  This is a QVGA display with a touch screen that plugs into their Explorer 16 development board.   Microchip also has a graphics library to go along with the Graphics PICtail. (QVGA stands for "quarter VGA", this is basically a quarter of a VGA screen, although the color depth happens to be better than the original VGA, if not as good as modern SVGAs).

So I broke down and got an Explorer 16 and Graphics PICtail to see whether what I thought I was seeing was real.  Well, it turns out to have been better than I expected.  Not only are the 16 bit parts fully capable of driving the QVGA, but Microchip's graphics library was reasonably competent; something of a surprise because much of Microchip's software in the past has been pretty lame.  I was surprised that a few days of playing led to quite reasonable GUIs.  Yes, there are a few things that might be better, but all in all, much easier to work with than I had anticipated.

Some time back, Wayne Burdick of Elecraft made a presentation at Atlanticon where he said that his approach was to design the front panel first, then design the radio to go behind it.  This seems like a very good approach.  Many computer programmers use this strategy of designing and perhaps even mocking up the user interface, and when it looks like what the customer wants, only then do they go to designing the stuff to make it actually work.  The most pleasant radio I have ever used is my Elecraft K1, guess what, a Wayne Burdick design.

Now, one of the problems with building radios is that front panel.  For my radio, there are a number of features I want, and those features mean lots of controls.  Lots of controls spells a big ugly radio, to say nothing of the cost of those controls.  Buttons and encoders tend to be a lot more expensive these days than transistors and microprocessors.  Commercial radios solve this problem by confusing combinations of press, double press, hold and cryptic menus.  This isn't something I would really like to emulate; I want a radio that I like to use.

With the touch screen, however, there is a new possibility.  The front panel only needs to have the knobs and buttons I am using at the time.  A virtual front panel opens up all sorts of possibilities. It certainly gives a whole new meaning to the term Software Defined Radio!

Well, put all this together and the obvious answer is to mock up the UI for this "ideal" radio.  Figure out what the features are I need, and sort out how to arrange those features in the UI so that they will be convenient to use for my purposes.

So, at this point, I have mocked up pass 1.  I did make a few discoveries in the process.  The display needs to show not only the frequency, but a number of status tags.  I started with Manual Notch, Noise Reduction (DSP features), AGC Speed, Filter Width, and Code Speed.  I soon realized that since I can change the text on the buttons, the buttons that control these things can have the legends and I do not need to use up valuable screen real estate.  Control placement is an issue.  Since I am right handed, it is important to have the frequency knob, for example, on the right so I can read the frequency on the upper left.

The buttons themselves need to be fairly large.  I want to easily use this thing with my fingers; I don't want to have to use a stylus like the Palm.  The short movie below shows how the mockup behaves; some buttons merely toggle their legends, others lead to new screens.  On some of the examples I did use a stylus so my hand doesn't block the movie.

Short movie here

After playing with that for a while, I realized I need some additional features:

  • Frequency step size
  • XIT, maybe RIT
  • Probably move keying speed to the main panel a la K1, may have to sacrifice some other things, like DSP and/or AGC
  • Possibly a separate transmit frequency display

As I got more thickly into the code, I also realized a few things about the graphics library:

  • RAM is precious
  • Fonts seem to take RAM even though they may be stored in onboard FLASH or external FLASH mounted on the PICtail board
  • FLASH isn't nearly as scarce as I first thought
  • The library wants to link in all sorts of things you aren't using unless you are careful
  • It might be a problem to port the library to the dsPIC33 (my intended target)
  • I need to further explore the PIC32 as that is supported, and apparently has the gas to do the DSP operations without the DSP engine

Some General Comments on the Code

The Microchip graphics library represents a very MS Windows-like view of the world.  There are differences to be sure.  Basically, everything happens through a message loop.  New windows are created somewhat more easily than in Windows, but the message loop and various callbacks tend to be a bit more arcane.

The Microchip examples tend to include all the application code in one file.  I prefer to have individual files to do specific jobs, so I did a certain amount of breaking up.  I may have more to break up:  The "library" code is all individual files for specific purposes.  I made an object library for those that were purely generic,  although they are not quite as independent as I would like.  At this point, my modules are:

  • RPanel_main - This is the mainline, which includes the initialization calls (most are handled by library routines), the main message loop, the message callback routine, the draw callback routine (null), and the interrupt service routine.
  • makePage - This file includes the routine which creates all the widgets for each page, and a few small subroutines that are used by this routine and not much else.
  • makeSchemes - The widgets are colored according to a "scheme", and I wanted to try different color schemes.  This routine creates the set of schemes used for this execution.  One of four schemes is chosen based on whether a button on the Explorer board is depressed during initialization.
  • ProgressBar - This is a library routine modified to be used as an S meter.  The default progress bar didn't work right for this use.
  • NumFont - This routine contains nothing but the static data used to draw the small numbers under the S meter.
  • NumBFont - Contains the font used for highlighted numbers (frequency, code speed, etc.  Arial, bold, generally bright).
  • stringSubs - Nothing more than a couple of K&R string routines that should have been in the default library and weren't.

The interrupt service routine does nothing but make the S meter move in a semi-realistic fashion.  The S meter is the only thing that needs to be updated frequently, and I wanted to see whether it would be very distracting, and whether I had enough processor to update it frequently enough to seem to be in real time.

At some point I'll add the pictures of the other color schemes and possibly some of the other screens here.  The picture at the top is one of the nicer schemes so far, the different scheme in the movie is actually quite nice, too, but the moire effect on the movie kind of wrecks it.

Some other schemes

I tried four different sets of color schemes.  One I really didn't care for I don't have a picture of.  Here are two of them ... they really look better than they photograph:

 

 

 

 

 

 

 

 

 

Things to do

When I get back to this I need to:

  • Do the math to determine where the RAM is going when I use larger fonts
  • Get the frequency step size working
  • See if I can sort out how I want to implement XIT
  • Check if I want to do something different with the keyer controls
  • Look for other missing/suboptimal bits
  • Explore how the transmit frequency will be displayed
  • N5HF suggested a CI-V interface.  That could be a big help in understanding whether the UI is useable before building the actual radio

Documentation

doxygen documentation for the project (pdf)

 

 

Link to original multiply article