Software Defined Radio

During the past month or so I’ve implemented a few more enhancements to PowerSDR-OpenHPSDR mRX PS, summarized below.  They were included in release 3.4.3.  CTUN mode continues to have quirks but I think it’s operating much better than before.

Improved CTUN mode operation:

A “CTUN Scroll” check box has been added to the Setup-General-Options tab.

When this box is checked:

• The display scrolls when the VFO gets near the display edges, allowing tuning to continue. The VFO cursor stays near the scrolling edge as you continue to tune toward that edge.
• Frequency changes greater than 500kHz cause a re-centering of the VFO in the display (e.g. when recalling a memory from a far removed frequency).

When this box is unchecked:

• CTUN behaves as before the CTUN enhancements – the VFO stops at the bandwidth edge (e.g. 192kHz edges)

Forcing CTUN to turn OFF when selecting Split or MultiRX has been eliminated.

MIDI controller support 

MIDI controller mapping in Setup now supports the Behringer CMD Studio 2a.  In fact, it may work with all the Behringer controllers now, barring unforeseen additional idiosyncratic behavior of specific controllers that differs from the currently supported ones (CMD PL-1, CMD Micro, and now CMD Studio 2a).

The MIDI/CAT VFO manipulations (A>B, B>A, A<>B) now behave exactly like their corresponding buttons on the console. Previously the CAT versions of these commands just changed frequency and nothing else associated with the VFO (e.g. mode).

Variable codes coming from wheels in the Hercules Compact controller are now handled properly to eliminate the digital “backlash” that was previously occurring.

MIDI VFO sensitivity control:

A new setting and set of MIDI commands have been added to change the sensitivity of MIDI wheels when mapped to VFOs. This is useful, for example, when the tuning step is set to a coarse value, such as using 100Hz steps when tuning in SSB mode. In such a case using the normal sensitivity (one single MIDI message causes one single frequency step) makes tuning difficult since barely touching a wheel, causing an update message to be sent, results in a jump in frequency. To customize this behavior, you can now change the wheel sensitivity by specifying the number of MIDI updates required to produce one frequency step. Thus, requiring, say, 10 updates to produce one frequency step, means you have to turn the wheel further to get one single update, effectively decreasing its sensitivity.

Two new up/down controls have been added to the Setup/CAT Control tab next to the “Configure MIDI” button, that are labeled as “”MIDI Wheel updates/step. These controls set the minimum and maximum number of MIDI wheel updates per frequency step (i.e. maximum and minimum wheel sensitivity, respectively).  The two values can then be alternated between using a new MIDI command and mapping as below.

The following three functions and mappings are new:

1. “Increase wheel rotation per VFO tune step” – increments the number of wheel updates per tuning step (i.e. decreases wheel sensitivity), mappable to a button
2. “Decrease wheel rotation per VFO tune step” – decreases the number of wheel updates per tuning step (i.e. increases wheel sensitivity), mappable to a button
3. “VFO Wheel Sensitivity High/Low Toggle” – toggles between the high and low values set in MIDI setup, mappable to a button

When you press buttons mapped to the increase/decrease functions (#1 and #2) it changes the number of MIDI messages from the jog wheel needed to cause one frequency increment. Increasing starts at 1 and then increments it by factors of 2 for each button press, up to 32, (i.e.  1, 2, 4, 8, 16, 32).  Likewise, decreasing cuts it in half with each press. When you press a button mapped to the toggle function (#3) the sensitivity alternates between minimum and maximum (see above) with each button press.

Disabled audio processing in digital modes

CFC is now disabled automatically when switching to DIGL or DIGU. This operates in the same way the disabling of other processing functions, such as TX EQ, operates now, in that it simply disables the function in the current transmit profile to ensure that CFC isn’t used in digital modes.  This is not normally how you’d really want it to manage things since if you started with a non-DIGI profile then change mode to a digital mode, you end up with a changed profile, forcing you to switch to another one and back again when you change modes back to, say, LSB (or another non-digital mode).  A better way to handle this, as some are already doing, is to create a transmit profile for digital modes and switch to it before selecting a digital mode.

Miscellaneous

• VHF band stacks are now 5-deep like the others.
• The display scale shifting when going between transmit and receive has been mostly eliminated.
• Fixed a bug causing a crash when zoomed in past the point where the passband fits in the display.
• Fixed bugs in split VFO operation when RX2 is on.
• Fixed a bug that was causing an incorrect vertical display scale in transmit under certain circumstances.

de W2PA

This describes modifications I’ve made to the Midi2Cat package from Andrew Mansfield, M0YGG, as of this date.  They should appear in the next release of OpenSDR/PowerSDR mRX PS (hereafter referred to simply as OpenSDR).  They were first applied to version 3.3.16, which may, in fact, be the next release. The new features provide special handling for messages produced by two MIDI controllers from Behringer: the CMD PL-1, and now also the CMD Micro.

Although MIDI is a standard of sorts, the messages from controllers such as these can vary widely.  The original code worked well with the Hercules controllers, and to a limited degree, with some of the controls on the Behringer units. That function has been preserved in this new version. In fact, it is possible to use more than one of these controllers together, connected at the same time.

For complete instructions on setting up MIDI controllers using the Midi2Cat package, see M0YGG’s original document, usually found in the OpenSDR package, with a file name such as “Midi2Cat Instructions V3.”  This posting, and the corresponding document in the new release, are each intended to be an addendum to those instructions, adding details on how to use the package with the Behringer controllers.

Setup Process

Setting up the various controls works as it did before in OpenSDR.  This means that the MIDI setup dialog window still works as before, and you get a tab labeled properly as “CMD PL-1,” or “CMD Micro”, similar to how it works with the Hercules.  The mapping procedure is mostly unchanged for the Behringer controllers, with some minor exceptions described below.

Main Wheel

The PL-1 main wheel is big and very smooth, so it works great as a tuning knob.  For example, you can set it to control a VFO—the most obvious mapping and probably the most useful.  If you do, the program makes use of the wheel’s speed sensitivity to change the VFO tuning rate in three steps: slow, medium, and fast.  It transitions through the speeds gradually as you turn faster.  If you give it a good spin you’ll fly across the band, and if you turn it slowly you’ll fine-tune the radio using the step size defined in the OpenSDR window.  By default, the wheel’s sensitivity to touching its top surface is not used.  It’s always possible to touch the top surface accidentally while tuning, causing something else to happen inadvertently, so it probably is best left unmapped. All of this is true also for the two large wheels on the Behringer CMD Micro.

To program a large wheel, go through MIDI setup as usual, spinning it clockwise and counterclockwise.  The max/min numbers won’t matter because to get the speed sensitivity, the program reads the all the reported values anyway and does the right thing.  If you plan to use the single large PL-1 wheel for both VFOs, first program it for VFOA, then follow the instructions in the next section for setting it up for VFOB.  If you’re programming the two large wheels on the Micro, just follow the above instructions for each VFO, one at a time.

For the PL-1, there is a new CAT function called “Toggle Wheel to VFOA/VFOB.”  You can map this function to any of the buttons.  It is used to toggle the function of the PL-1’s main wheel between controlling VFOA and VFOB. To set this up properly you need to do it in the following order:

1. In MIDI Setup, map VFOA to the main wheel as above.
2. Map a button of your choice to the “Toggle Wheel to VFOA/VFOB” function.
3. Save and exit MIDI Setup.
4. Press the button you just mapped in step #2 once (and only once) to switch to VFOB.
5. Go back into MIDI setup.
6. Map VFOB to the wheel, which behaves now as a different control from that in step #1.
7. Save and exit setup.
8. Have fun.

Small Knobs

The small knobs on the Behringer CMD PL-1, and the center knob on the Micro, all behave like mini-wheels (they keep turning without limit) instead of knobs as OpenSDR defines them and is expecting knobs to behave, i.e. with limits and values like a slider or potentiometer. That’s why OpenSDR lumps knobs and sliders together.  So when you program a PL-1 knob, you have to choose “Wheel” as the control type in the MIDI setup.  You can map any mini-wheel to anything in the OpenSDR UI that makes sense.  That is, it can be used to control anything that has a value that changes continuously, whether or not that value has limits in the OpenSDR window, such as on sliders.

In addition to handling messages from the Behringer controllers send to the computer, messages are sent back to the controller that activate certain LEDs on the PL-1, such as those around each knob and alongside the single slider, and make them do something sensible. As you rotate the knobs or slide the slider, the LEDs light up roughly corresponding to a percentage of the specific function’s setting, somewhere between its minimum and maximum values.  At this time, this feature works for AF gains, AGC gains, RIT/XIT, drive level, CW speed and some others.

When RIT or XIT is mapped to a PL-1 mini-wheel, the LEDs behave a bit differently. First, the center (midpoint) LED lights only when the RIT/XIT is set to exactly zero.  Then, the counterclockwise and clockwise LEDs light depending on how much you turn the knob.  Despite the wide range of settings possible in OpenSDR, the LEDs will only indicate a maximum of plus or minus 2 kHz. (I found that if it took in a wider range, they changed too slowly to have any meaning.)  Note: you can still keep turning the knob and go well beyond 2 kHz to the limits of OpenSDR, but the LEDs will hit their maximum and minimum indication at 2 kHz or slightly less.

For most of the mappings of mini-wheels to on-screen user interface (UI) slider controls in the OpenSDR window, the LEDs also react to changes made on screen. For example, if you map a PL-1 knob to the RX1 AF Gain, then slide the on-screen RX1 AF slider in the OpenSDR window, the LEDs on the PL-1 will change just as if you were turning the PL-1 knob.

The second feature of these mini-wheel knobs is that they act as buttons when you push down on them.  So you can map them as buttons.  For RIT/XIT this is done for you so when you push a mini-wheel mapped to RIT or XIT, it zeros the value of that control. You can, of course, map the RIT/XIT on/off function to any other button you like.

Buttons

The PL-1 and Micro buttons behave as usual—they produce messages when pressing down and springing back up.  You map them just as with any other controller.

Some buttons are capable of changing from their default orange to one other color. So, you can add messages to make them do what you want, using the MIDI Setup Advanced options according to M0YGG’s instructions.  To control colors on the PL-1, you just need to send back the same message as received, but change the value part of the message to a number, depending on what you want the button’s LED to do.  For default orange, send 0 (0x00 – 00 hexadecimal); for the alternate color, send 1 (0x01), and to have it alternate or flash between the two colors, send 2 (0x02).

Thus, when you map, for example, a button, click on “Show Advanced Options” and you’ll see a window like the one below.  In this example, I pressed the “CUE” button on the Micro, which brought up the window showing I had previously mapped it to the “Multi Rx On Off” function.

In the lower right, the two lower text boxes are where you enter these messages to control button lights.  The Setup window lets you use “SS” and “YY” for the status and control ID bytes sent by the controller, instead of having to figure out what those values are and enter them explicitly.

The example shows what gets entered to toggle between flashing (SSYY02) and constant alternate color (SSYY01).  To use the default orange color, the message would be SSYY00.

The buttons that can change color have only one alternate color. For example, the PL-1 CUE button can be pinkish-purple, Play/Pause can be green, and all the others can be blue; and on the Micro, only the Play/Pause and CUE buttons have alternate colors.  OpenSDR changes some of them to their alternate color on startup for some initial variety.  I think it looks better than all orange.  I may make this customizable in Setup some time later.  For now, you can use the built-in messaging (as above) to change color however you like.

As an example, I have my PL-1’s SCRATCH button mapped to toggle between VFOs.  In MIDI setup, I entered a message to turn it blue for VFOA and orange for VFOB.

The photo shows examples of mappings and colors, and some labels appropriate for SDR use.  This is the same as in the previous post.  The knobs (mini-wheels) labeled “LO” and “HI” correspond to the filter low and high settings in OpenSDR, and basically behave like LowCut and HighCut knobs on Kenwood rigs.  They’re quite intuitive to use with the panadapter.  Turning Lo clockwise moves the lower filter edge up, and counterclockwise moves it down in frequency.  Likewise for the Hi knob.  These make slicing out adjacent QRM very easy.

PL-1 Slider

The PL-1 slider can be mapped in setup as a “knob or slider.”  When you map it to an existing slider in the OpenSDR window, the LEDs follow the slider’s movement.  One bit of quirkiness comes about because there is, of course, no way to physically move that slider under program control.  Thus, if you change the slider in the OpenSDR window, the LEDs will change and become out-of-sync with the actual slider, until you move the PL-1 slider yourself.  When you do, its value will jump instantly to the physical slider’s actual setting.

The knobs don’t have this problem.  Since the PL-1 knobs (and the Micro’s center knob) are mini-wheels and have no absolute position (they just turn freely), there is no direct correspondence between knob position and value or slider position in the OpenSDR window, and so the quirkiness described above for the PL-1 slider’s LEDs isn’t an issue with the mini-wheels.

On the Micro, the sliders behave normally and have no LEDs.

Multiple Controllers

M0YGG’s original code nicely handles multiple controllers.  The changes to handle the Behringer controllers have their effect only for the PL-1 and Micro.  So mapping and using a Hercules controller, for example, should be unaffected.  In fact, you can use both connected at the same time.  You can also use both Behringer controllers at the same time.

Example CMD Micro mapping and labeling

de W2PA

After my ramblings about the code and discovering how to get the PL-1 working, I thought I ought to document some kind of summary. So here it is.

Setting up the various controls work as before in Px (see previous posts – using “Px” saves me typing its long name).  By that I mean that the MIDI setup dialog still works and you get a tab labeled properly as “CMD PL-1,” similar to how it works with the Hercules.  The mapping procedure is mostly the same with the Behringer.

Main Wheel

The main wheel is big and very smooth turning, great as a main-tuning knob.  You can set it to be, for example, a VFO – the most obvious mapping and probably the most useful.  If you do, the code makes use of the wheel’s speed sensitivity to change tuning rate in three steps – slow, medium, and fast.  It transitions through the speeds gradually as you turn faster.  If you give it a good spin you’ll fly across the band, and if you turn it slowly you’ll fine-tune the radio using the step size defined elsewhere (mine is set to 10Hz).  I’ve eliminated the wheel’s sensitivity to touching its top surface.  It may be useful for something but I haven’t thought of anything yet.  And besides, it’s always possible to touch the top surface accidentally while tuning, causing something else to happen inadvertently – so I’m guessing it’s probably not going to be useful for anything.

To program the main wheel, go through MIDI setup as usual, spinning it clockwise and counterclockwise.  The max/min numbers won’t matter because to get the speed sensitivity, the code reads the all the reported values anyway and does the right thing.  If you plan to use it for both VFOs, first program it for VFOA, then keep reading…

There is a new CAT function I’ve added called “Toggle Wheel to VFOA/VFOB.”  You can map this to any of the buttons.  It is used to toggle the main wheel’s function between controlling VFOA and VFOB. To set up this function properly you need to do it in a certain order:

1. Map VFOA to the main wheel as above.
2. Map a button of your choice to the “Toggle Wheel to VFOA/VFOB” function.
3. Save and exit MIDI Setup.
4. Press the button you just mapped in step #2 once (and only once).
5. Go back into MIDI setup.
6. Map VFOB to the wheel, which behaves now as a different control than it did in step #1.
7. Save and exit setup.
8. Have fun.

Small Knobs

The knobs on the Behringer CMD PL-1 behave like wheels instead of knobs as Px defines them or is expecting knobs to behave, i.e. with limits and values, like a slider. That’s why Px lumps knobs and sliders together.  So when you program a PL-1 knob, you have to choose “Wheel” as the control type in the MIDI setup.  You can map any knob to anything in the UI that makes sense.  That is, it can be used to control anything that has a value that changes continuously.

In addition, I’ve written code that activates the LEDs around each knob as you rotate them, roughly as a percentage of the specific function’s minimum and maximum values.  At the time I’m writing now, this feature works for AF gains, AGC gains, and RIT/XIT.  I can add others if needed.

For RIT/XIT there are additional behaviors.  First, the center (midpoint) LED lights only when the RIT/XIT is exactly zero.  Then the counterclockwise and clockwise ones light depending on how much you turn the knob.  Despite the wide range of settings in PowerSDR, I chose to limit the LEDs to only indicate a maximum of plus or minus 2kHz. I found that if I took in a wider range, they changed too slowly to have any meaning.  Note: you can still keep cranking the knob and go well beyond 2kHz all you like – but the LEDs will hit their maximum and minimum at 2kHz or slightly less.

For most of the mappings of knobs to UI slider controls, the LEDs also work in the reverse direction. For example, if you map a PL-1 knob to the RX1 AF Gain, then slide the on-screen RX1 AF slider in the user interface, the LEDs will change just like you were turning the PL-1 knob.

The second feature of these knobs is that they act as buttons when you push down on them.  So you can map them as buttons.  But I’ve implemented code that detects when you push them to zero the RIT/XIT.  This seems more useful than on/off, which you can map to any other button you like.

Buttons

The PL-1 buttons have fairly standard behavior – they produce messages going down and going up.  You map them just like with any other controller.

They are capable of changing to one other color than their default orange. So, you can add messages to M0YGG’s already existing MIDI setup dialog to make them do what you want.  For the PL-1, you just need to send back the message as received, but change the “value” part of the message to a number, depending on what you want the button’s LED to do.  For default orange, send 0 (0x00); for the alternate color, send 1 (0x01), and to have it alternate or flash between the two, send 2 (0x02).

The buttons all have only one alternate color: CUE can be pink/purple, Play/Pause can be green, and all the others can be blue.  I added a section in the code to change some of them to their alternate color on startup.  I think it looks cooler than all orange.  I may make this customizable later.  For now, you can use the built-in messaging (as above) to change color however you like.

As an example, I have my “SCRATCH” button mapped to toggle between VFOs.  In MIDI setup, I entered a message to turn it blue for VFOA and orange for VFOB.

Slider

The PL-1’s slider can be mapped in setup as a “knob or slider.”  I had to do some interception of its messages because its control ID changes (something none of the other controls do).  Now it works fine and the change in control ID is transparent to the user (although you might notice I chose to use “73” – 0x49 – as the code).  When you map it to an existing slider in the UI, the LEDs follow the slider’s movement.  The one bit of quirkiness comes about because there is, of course, no way to move that slider under program control.  Thus, if you change the slider in the UI, the LEDs will change and become out-of-sync with the actual slider, until you move it yourself.  When you do, its value will jump instantly to its actual physical setting.

Notice that the knobs don’t have this problem.  Since the knobs have no absolute position (they just freely turn), there is no direct correspondence between knob position and value or UI slider position, and so the qurkiness described above for the PL-1 slider’s LEDs isn’t an issue with the knobs.

Multiple Controllers

M0YGG’s original code nicely handles multiple controllers.  The changes I made to handle the PL-1 have their effect only for the PL-1.  So programming the Hercules, for example, should be unaffected.  In fact, you can use both connected at the same time.  This hasn’t been thoroughly tested but W1JA, who has one of each, has verified that both work together.

de W2PA

I modified the code handling messages from the Behringer CMD PL-1 to enable it to separately control VFO A and VFO B, and toggle between the two using one of the other buttons.

To set up the two VFOs (two wheels, really, as far as the SW is concerned) is a little different from how you normally do it for one – there is an order you have to follow. This is because you have to first set up the button for doing the A/B wheel mode switch and then exit MIDI setup and actually use it to change mode before going back and setting up the wheel again for VFOB. So, here’s how it goes:

Inside MIDI setup, press the button you want to use as the toggle function and name it as usual, choose “Button” and then choose the new function I added, which is all the way at the bottom of the list and is called “Toggle Wheel from VFOA to VFOB”. Save, hit OK, and exit MIDI setup.

Now that the toggle button is set up, you have to press it, once and only once, *outside the MIDI setup*, to change the wheel’s mode from A to B. Then you go back into MIDI setup with the wheel mode having been changed, and set up the wheel for changing VFOB – it will now appear to be a different wheel to MIDI setup (because its ID has changed). Spin left/right, name it, and choose Wheel as before for VFO A, but this time choose “Change Freq VFO B,” and save. Then you’re done.

This is all because while you’re inside the MIDI setup, the PL-1 controls don’t actually execute their respective commands – there is a completely separate MIDI message handler for the setup process. Thus, if you set up the AB switch button and then press it again without exiting setup, it just brings you back to setting up the button but does not execute the switch of the wheel from A to B mode.

I’ve thought about making a special case for the A/B switch function that allows the mode switch to execute within MIDI setup. But on second thought, the way it works now is logically consistent, even though it makes for a different setup sequence.

de W2PA