View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003410 | 4 - Business Priorities | [All Projects] General | public | 2019-07-30 14:23 | 2019-08-12 14:25 |
| Reporter | WA9PIE | Assigned To | K7ZCZ | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0003410: Add the SDRplay to our panadapter display | ||||
| Description | Based 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. | ||||
| Tags | No tags attached. | ||||
|
|
"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. |
|
|
Make our panadapter feature work with the SDRplay in the same experience as what we’ve done for the Icom and Kenwood radios. |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
Absolutely! |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
Previously (prior to my comment), it was assigned to me. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
Looking at the log, I'm clearly mistaken. |
|
|
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? |
|
|
Test... |
|
|
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. |
|
|
Great, thanks. |
| 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 |
