Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need the latest SmartSDR and Power Genius Software?
SmartSDR v3.1.12 and the SmartSDR v3.1.12 Release Notes. | SmartSDR v2.6.2 and the SmartSDR v2.6.2 Release Notes.
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes. | Power Genius XL Firmware v3.5.23. | Power Genius XL Utility v2.2.10.
SmartSDR v3.1.12 and the SmartSDR v3.1.12 Release Notes. | SmartSDR v2.6.2 and the SmartSDR v2.6.2 Release Notes.
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes. | Power Genius XL Firmware v3.5.23. | Power Genius XL Utility v2.2.10.
History Feature
W B McCarty
Member
I thought to suggest a command UNDO feature. Because I know that programming an UNDO for every command could be difficult or time-consuming I thought maybe just an UNDO for tuning would be good enough and would be easier to implement. Then I saw existing discussion of a command UNDO and I didn't want to revisit an idea that's apparently been discarded. So here's a new idea that proposes a different way to get to the same place.
How about a tuning history like the URL history feature in a web browser? Any time you wanted you could pull up the history (which might hold a limited number of tuning actions) and see what tuning changes had been made, from most recent to oldest. And by clicking on a frequency you could trigger an action that asks what panafall/slice you want to tune. The action also gives the option to add a new slice within an existing panafall or a newpanafall, if resource levels permit.
How would this look? You'd list each existing panafall and, at the bottom, you'd provide a means of creating a new panafall. Within each existing panafall you see the slices, ordered by frequency. At the bottom of the list, you'd provide a means of creating a new slice within that panafall. Of course, if the system has no available panafalls or slices, the related action would be visible but disabled. It would be very easy to use this structure. Most often you'd quickly find the slice you want to tune and then click it.
It would be possible to present the information differently. You might disregard the panafalls and provide an alphabetical list (or a list sequenced numerically, by frequency) of slices. That's more streamlined. But then the action of adding a new slice becomes more difficult because the user must somehow identify the panafall in which the slice is to be placed.
When I write this out it sounds rather complex. But just think about the way the Chrome browser's history works and suppose you had something similar that would remember and let you re-do tuning actions.
Yes, this can already be done by some external rig control programs. That merely shows that the function is useful and not impossible to develop. It would be best to have this feature inside SSDR rather than an external program.
How about a tuning history like the URL history feature in a web browser? Any time you wanted you could pull up the history (which might hold a limited number of tuning actions) and see what tuning changes had been made, from most recent to oldest. And by clicking on a frequency you could trigger an action that asks what panafall/slice you want to tune. The action also gives the option to add a new slice within an existing panafall or a newpanafall, if resource levels permit.
How would this look? You'd list each existing panafall and, at the bottom, you'd provide a means of creating a new panafall. Within each existing panafall you see the slices, ordered by frequency. At the bottom of the list, you'd provide a means of creating a new slice within that panafall. Of course, if the system has no available panafalls or slices, the related action would be visible but disabled. It would be very easy to use this structure. Most often you'd quickly find the slice you want to tune and then click it.
It would be possible to present the information differently. You might disregard the panafalls and provide an alphabetical list (or a list sequenced numerically, by frequency) of slices. That's more streamlined. But then the action of adding a new slice becomes more difficult because the user must somehow identify the panafall in which the slice is to be placed.
When I write this out it sounds rather complex. But just think about the way the Chrome browser's history works and suppose you had something similar that would remember and let you re-do tuning actions.
Yes, this can already be done by some external rig control programs. That merely shows that the function is useful and not impossible to develop. It would be best to have this feature inside SSDR rather than an external program.
0
Leave a Comment
Categories
- 15.9K All Categories
- 64 Community Topics
- 1.9K New Ideas
- 139 The Flea Market
- 5.4K Software
- 4.9K SmartSDR for Windows
- 39 SmartSDR for Maestro and M models
- 96 SmartSDR for Mac
- 144 SmartSDR for iOS
- 152 SmartSDR CAT
- 71 DAX
- 280 SmartSDR API
- 7.1K Radios and Accessories
- 5.8K FLEX-6000 Signature Series
- 562 Maestro
- 14 FlexControl
- 729 FLEX Series (Legacy) Radios
- 163 Power Genius Products
- 126 Power Genius XL Amplifier
- 14 Power Genius Utility
- 23 Tuner Genius
- 45 Shack Infrastructure
- 24 Networking
- 95 Remote Operation (SmartLink)
- 50 Contesting
- 147 Peripherals & Station Integration
- 64 Amateur Radio Interests
- 425 Third-Party Software