View Issue Details

IDProjectCategoryView StatusLast Update
00034104 - Business Priorities[All Projects] Generalpublic2019-10-17 16:44
ReporterWA9PIEAssigned ToK7ZCZ 
PrioritynormalSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003410: Add the SDRplay to our panadapter display
DescriptionBased on our specification for this feature, we have a desire to integrate our panadapter feature to the SDRplay.

Based on the information available regarding N1MM's approach, radios made by Yaesu and Elecraft do not have the type of internal capability that the ICOM IC-7300/7610/9700 or Kenwood TS-890 have. So our only remaining option is to take a similar path and build out support for the SDRplay to enable radios that are not otherwise internally capable to enjoy the panadapter functionality.

https://n1mmwp.hamdocs.com/spectrum-display-window/

It seems that N1MM accomplishes this by using the SDR Vendor Provided ExtIO*.dll. This is also referenced in our specification.

We can get a lot of "bang for the buck" with supporting the SDRplay as it would open up the feature to many many radios that otherwise have no path for the feature.
TagsParityGap
ModuleRig Control
Sub-ModuleInterfacing
TestingNot Started

Activities

K7ZCZ

2019-07-30 16:43

administrator   ~0008304

"Integrate" doesn't make much sense here because the Icom and Kenwood panadapter support is tailored to the command and data interfaces prescribed by the radio. Integration wouldn't be the right path; instead, a new panadapter window should be implemented to display the data made available by the Smart SDR radios.

Adding a panadapter display to support the SDR Play radios can mean any of several things.

Maybe it means that we connect Rig Control to an SDR Play radio, and that's that. It's controlled as if it's its own radio. If the user asks to tune it or switch modes, it does so just like any other radio we might support.

Maybe it means that we connect to some other traditional radio, but offer a SDR Play connection side-by-side to provide panadapter display in concert with the traditional radio. This means that we must implement separate connection and configuration management for the panadapter connection to the SDR separately from the main radio. This setting must be managed, persisted, configured differently. We'll have to design how to control the SDR Play as a secondary radio while the first radio is the primary radio, controlled by Rig Control's main UI.

Or maybe it means something else.

I think this issue would benefit from a clearer problem statement and some conversation about approach and desired results before development work starts.

WA9PIE

2019-07-31 01:27

administrator   ~0008308

Make our panadapter feature work with the SDRplay in the same experience as what we’ve done for the Icom and Kenwood radios.

WA9PIE

2019-07-31 02:35

administrator   ~0008309

Adding some more context here...

What we want in-the-end is a way to display the SDRplay in our panadapter feature. However (using this use-case as an example), clicking on a "stream" (I can't find a better word for this) in the panadapter display generated by the SDRplay should retune the primary radio. Again, this is the solution for people who have radios that cannot internally support the panadapter display.

Let's use the ICOM IC-7600 as an example. It has no internal ability to support the panadapter display with commands. However...

The IC-7600 does have an "RX ANT OUT" connector. This can be connected to the input of the SDRplay to provide a RX antenna to the SDRplay. As the user interacts with the panadapter display that comes from the SDRplay, they may click on a frequency in the panadapter display. This action should change the frequency and mode of the IC-7600. (There are almost endless use cases here. The SDRplay doesn't need to be connected to the main rig at all. It can have it's own RX antenna. But in any case, clicking on a frequency in the panadapter display should change the frequency and mode of the primary radio (Yaesu, ICOM, Kenwood, Elecraft... etc).

K7ZCZ

2019-07-31 13:42

administrator   ~0008310

To me, your note 8308 means that we implement SDRPlay support in Rig Control, then add Padapter support to that, just as we have for the Kenwood and Icom radios.

Your next note (8309) seems to contradict that. It seems to asy that ,if Rig Control has a connection to an SDRPlay radio, clicking in the panadapter should tune the SDRPlay and another attached radio. I guess this must be selectable, since any number of radios might be attached in one Rig Control session. There's no notion of a "primary radio" in Rig Control, as far as I can tell. How is that established?

Perhaps you mean that both are true: that we add SDRPlay support to Rig Control, and optionally allow the SDRPlay panadapter window to control a second connected radio at the choice/option of the user.

In your example, it seems like it would be necessary for the IC-7600's tuning to change the SDRPlay tuning. If the SDRPlay is being used as a scope for the IC-7600, then tuning the IC-7600 either manually (on the radio's front panel) or with Rig Control should cause the SDRPlay to change its tuning. Is that always true? If the IC-7600 is in split mode, which side is followed? Is it possible to want to use an offset or a different band?

I haven't yet looked into the SDRPlay programming interfact, but I don't expect these things are too involved to implement. But I think it's necessary to clearly understand and agree upon what we want to implement before we start implementing it.

WA9PIE

2019-08-01 11:47

administrator   ~0008316

It's not likely that I can explain this thoroughly (which is why my comments may see contradictory). I can explain it conceptually.

This article gives us some insight to what hams want to do (in the context of using the SDRplay): https://n1mmwp.hamdocs.com/spectrum-display-window/

The SDRplay is not the transmitter (obviously, it doesn't have a transmitter). It doesn't seem that it's the receiver they're using either. (That is - no one seems to want to use the SDRplay as their receiver and use another radio as the transmitter. They really want to just pretend that the SDRplay is a "panadapter inside their radio." As such... when they change frequency and/or mode from within the panadapter display (by clicking the panadapter or whatever), they want their transceiver to change frequency and/or mode.

The link provided supports this conceptually. It talks about using the SDRplay as the panadapter hardware that their panadapter software is using to control other radios (Elecraft, Yaesu... IC-7600 in-particular).

So... it almost seems like it should be possible to have the Rig Control display using a given rig (eg. IC-7600) and the panadapter display using a different radio (SDRplay).

In the end, I don't care if we can control the SDRplay in the main (legacy) Rig Control screen. But that won't satisfy this need. So I wouldn't put a lot of priority on enabling the Rig Control screen to control the SDRplay (unless that's otherwise necessary).

The objective here is to use the SDRplay as the panadapter for radios that otherwise can't do it in code... such that they can control their transceiver by clicking on the panadapter display rendered from data from the SDRplay.

K7ZCZ

2019-08-06 17:40

administrator   ~0008330

Sounds like we could add a command to the "Tools" menu to connect to an SDRPlay and bring up a panadapter display based on the data sent from the SDRPlay. This could work independently of the radio view, though we can set it up so that they tune eachother.

Does that plan satisfy the request?

WA9PIE

2019-08-07 02:37

administrator   ~0008332

Absolutely!

K7ZCZ

2019-08-07 12:33

administrator   ~0008335

OK, I can work on that.

It will take quite some time, as the SDRPlay radio outputs raw I/Q data, which we must process in order to get a usable panadatper-style display. Some filtering, probably; FFT to get power data out of the band. Scaling, maybe more filtering.

K7ZCZ

2019-08-09 13:35

administrator   ~0008348

Tim, in the 2019-08-08 call, you raised concerns that this work wasn't the right direction for the product. CAn you please review the plan we have and raise your concerns here, so that MikeC can review and address them?

WA9PIE

2019-08-10 20:08

administrator   ~0008361

MB - with all due respect to Tim (and I'm happy to discuss it with him), please do not stop development on this item.

This is an extremely important addition to the software.

K7ZCZ

2019-08-10 21:48

administrator   ~0008362

This is assigned to Tim to collect his input, as he and Ferry vehemently objected to the plan.

I'll start on this implementation after 3001 is fixed; that issue has substantial effort behind it and needs to be completed and checked-in as there's a cost to switching contexts and leaving the code lying around, outside of the merge path from other versions. The work described here (in 3410) is substantal, and will take several weeks to research and implement.

WA9PIE

2019-08-11 03:07

administrator   ~0008367

Previously (prior to my comment), it was assigned to me.

KB3NPH

2019-08-11 04:32

administrator   ~0008368

Last edited: 2019-08-11 04:45

View 2 revisions

I spoke with Mike C about my thoughts on this project. Apparently I didn't fully understand the scope of this project and the reasoning for adding support for the SDRPlay.

WA9PIE

2019-08-11 04:46

administrator   ~0008369

For context... this change isn't being requested for the people who already use something like SmartSDR with their Flex. This change is being requested on-behalf-of those who have asked us for a panadapter display for radios like the FT-857D (which has none internally).

As described in the N1MM page "N1MM Logger Website | Spectrum Display Window", these users want more than what the SDRuno software can provide.

They want a panadapter display that has DX spots... and will change the frequency and mode of their FT-857D... as-if the panadapter was built into their radio. Essentially, as with the N1MM example, they will want to use the Ham Radio Deluxe panadapter feature because it offers more than what SDRuno is capable of.

K7ZCZ

2019-08-11 11:56

administrator   ~0008371

Something must be wrong with Mantis, then, Mike.

The history below says that, at 2019-08-09 11:35, I assigned it to Tim. Your comment was on 2019-08-10 18:08, about 36 hours after. The last time the issue was assigned to you was 2019-08-01 09:47. I'm not sure which time zone Mantis shows -- might be Pacific, might be UTC. But the issue hadn't been assigned to you for more than a week prior to your comment #8361.

How can we track down why issues aren't being assigned correctly?

WA9PIE

2019-08-11 16:12

administrator   ~0008379

Looking at the log, I'm clearly mistaken.

K7ZCZ

2019-08-12 02:45

administrator   ~0008380

Thank you for acknowledging your mistake, MikeC.

Ferry also had substantial reservations about this work, so I've assigned this issue to him to be sure that his input is heard.

Ferry, on the 2019-08-08 call, you strongly objected to this work. Can you please provide your input?

PD9FER

2019-08-12 09:19

updater   ~0008381

Test...

PD9FER

2019-08-12 09:21

updater   ~0008382

Ok I got an error posting before...

On this Mantis issue: I heard Mike-C and it is now clear what the intentions are.
I might was not 100% understanding what he wanted.

pse do continue development and feel free to ask any SDR related questions.

K7ZCZ

2019-08-12 14:25

administrator   ~0008390

Great, thanks.

WA9PIE

2019-09-22 02:41

administrator   ~0008573

Here's a few videos that describe the scenario, but think of it this way...

For radios that do not have an internal panadapter (that we can get to with code), they are "non-capable radios." So... the approach that's being used by N1MM and others is to add an SDRplay to the station to get the same effect of having it built into the radio. In this scenario, the SDRplay can connect to (a) the radio's IF output, (b) the radio's RX antenna out port, or (c) use an "SDR switch" like the MFJ-1708 SDR. But the goal here is to display the panadapter generated from the SDRplay and interact with it "as-if" if were inside the "non-capable radio." That is - if you click on the panadapter display generated by the SDRplay, it changes the frequency and mode of the "non-capable radio" (as well as changing the frequency on the SDRplay). Zooming in zooms in on the SDRplay's bandwidth, just as it did with the "capable radios."

This is critical in order for us to have a full-blown solution for folks who do not have capable radios.

Videos:
https://www.youtube.com/watch?v=0yqniB6plWA (short one where they're using an IC-7600; a "non-capable radio")
https://www.youtube.com/watch?v=eDK4mCTonp0 (club demo where they also talk about turning "rig sync" on/off)

But the idea here is that this should be the solution for customers who do not have capable radios.

Issue History

Date Modified Username Field Change
2019-07-30 14:23 WA9PIE New Issue
2019-07-30 14:23 WA9PIE Status new => assigned
2019-07-30 14:23 WA9PIE Assigned To => K7ZCZ
2019-07-30 14:24 WA9PIE Project 3 - Current Dev List => 4 - Business Priorities
2019-07-30 14:24 WA9PIE Category Enhancement => General
2019-07-30 16:43 K7ZCZ Note Added: 0008304
2019-07-30 16:43 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-07-31 01:27 WA9PIE Note Added: 0008308
2019-07-31 01:27 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-07-31 02:35 WA9PIE Note Added: 0008309
2019-07-31 13:42 K7ZCZ Note Added: 0008310
2019-07-31 13:43 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-08-01 11:47 WA9PIE Note Added: 0008316
2019-08-01 11:47 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-08-01 12:02 WA9PIE Summary Integrate the SDRplay to our panadapter display => Add the SDRplay to our panadapter display
2019-08-06 17:40 K7ZCZ Note Added: 0008330
2019-08-06 17:40 K7ZCZ Assigned To K7ZCZ => WA9PIE
2019-08-07 02:37 WA9PIE Assigned To WA9PIE => K7ZCZ
2019-08-07 02:37 WA9PIE Note Added: 0008332
2019-08-07 12:33 K7ZCZ Note Added: 0008335
2019-08-09 13:35 K7ZCZ Assigned To K7ZCZ => KB3NPH
2019-08-09 13:35 K7ZCZ Note Added: 0008348
2019-08-10 20:08 WA9PIE Note Added: 0008361
2019-08-10 20:08 WA9PIE Assigned To KB3NPH => K7ZCZ
2019-08-10 21:44 K7ZCZ Assigned To K7ZCZ => KB3NPH
2019-08-10 21:48 K7ZCZ Note Added: 0008362
2019-08-11 03:07 WA9PIE Note Added: 0008367
2019-08-11 04:32 KB3NPH Note Added: 0008368
2019-08-11 04:35 KB3NPH Assigned To KB3NPH => K7ZCZ
2019-08-11 04:45 KB3NPH Note Edited: 0008368 View Revisions
2019-08-11 04:46 WA9PIE Note Added: 0008369
2019-08-11 11:56 K7ZCZ Note Added: 0008371
2019-08-11 16:12 WA9PIE Note Added: 0008379
2019-08-12 02:45 K7ZCZ Note Added: 0008380
2019-08-12 02:45 K7ZCZ Assigned To K7ZCZ => PD9FER
2019-08-12 09:19 PD9FER Note Added: 0008381
2019-08-12 09:21 PD9FER Note Added: 0008382
2019-08-12 14:25 K7ZCZ Note Added: 0008390
2019-08-12 14:25 K7ZCZ Assigned To PD9FER => K7ZCZ
2019-09-22 02:41 WA9PIE Note Added: 0008573
2019-09-22 03:01 WA9PIE Tag Attached: ParityGap
2019-10-17 16:44 WA9PIE Sub-Module Functional => Interfacing