Welcome to the FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR or 4O3A Genius Product Software?
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
If you are having a problem, please refer to the product documentation or 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.
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
- All Categories
- 349 Community Topics
- 2.1K New Ideas
- 615 The Flea Market
- 8K Software
- 2 SmartSDR+
- 6.3K SmartSDR for Windows
- 173 SmartSDR for Maestro and M models
- 412 SmartSDR for Mac
- 267 SmartSDR for iOS
- 249 SmartSDR CAT
- 186 DAX
- 375 SmartSDR API
- 9.2K Radios and Accessories
- 22 Aurora
- 206 FLEX-8000 Signature Series
- 7.1K FLEX-6000 Signature Series
- 921 Maestro
- 53 FlexControl
- 860 FLEX Series (Legacy) Radios
- 893 Genius Products
- 455 Power Genius XL Amplifier
- 322 Tuner Genius XL
- 116 Antenna Genius
- 283 Shack Infrastructure
- 199 Networking
- 444 Remote Operation (SmartLink)
- 138 Contesting
- 754 Peripherals & Station Integration
- 139 Amateur Radio Interests
- 973 Third-Party Software