Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.19 and the SmartSDR v3.8.19 Release Notes | SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
SmartSDR v1.12.1 and the SmartSDR v1.12.1 Release Notes
Power Genius XL Utility v3.8.8 and the Power Genius XL Release Notes v3.8.8
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
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.
Proper generic interfacing of FlexLib by logging program
Andy - KU7T
Member ✭✭
I am prototyping an integration of the FlexLib to a logging program. I can connect to the radio and slices fine, but have a generic design question.
I dislike coupling. So, I created a new Classlibrary called "FlexConnector" which will do all the interfacing to the multiple FlexLib libraries. The reason why I try to not reference the FlexLib from the main application is that it will pollute the code and logic. Assume that Flex is not the only radio type, so many other radios need to be interfaced.
Now, many data from FlexLib properties need to be read by the main program. For example, what frequency a slice is on. I see multiple options:
1. Add references to the FlexLib and WFPUIFramework to the Main application. Then the FlexConnector dll can pass around the Slice object, and read and set anything by directly accessign the FlexLib properties.
2. Have FlexConnector DLL expose a bridge object for the Slice, so the FlexLib and WPF libs are not needed to be known by the main application. In this case many properties and functions have to be adapted.
3. Same as 2, but instead of creating an object, use a Dictionary. The dictionary is owned by the FlexConnector but exposed for reading to the main applicaiton. Main application needs to know the formatting of the keys (coupling). Also, only strings or simple types can be put in the dictionary values, or the FlexLib will have to referenced as well.
4. ?
In general, I estimate that about 20% of all properties will be needed by the main logger.
I favor a solution where the FlexConnector class library can be shared with other programs, so a loosely coupled solution would be desirable.
How have others solved the problem? Any suggestions are welcome.
73
Andy
KU7T
I dislike coupling. So, I created a new Classlibrary called "FlexConnector" which will do all the interfacing to the multiple FlexLib libraries. The reason why I try to not reference the FlexLib from the main application is that it will pollute the code and logic. Assume that Flex is not the only radio type, so many other radios need to be interfaced.
Now, many data from FlexLib properties need to be read by the main program. For example, what frequency a slice is on. I see multiple options:
1. Add references to the FlexLib and WFPUIFramework to the Main application. Then the FlexConnector dll can pass around the Slice object, and read and set anything by directly accessign the FlexLib properties.
2. Have FlexConnector DLL expose a bridge object for the Slice, so the FlexLib and WPF libs are not needed to be known by the main application. In this case many properties and functions have to be adapted.
3. Same as 2, but instead of creating an object, use a Dictionary. The dictionary is owned by the FlexConnector but exposed for reading to the main applicaiton. Main application needs to know the formatting of the keys (coupling). Also, only strings or simple types can be put in the dictionary values, or the FlexLib will have to referenced as well.
4. ?
In general, I estimate that about 20% of all properties will be needed by the main logger.
I favor a solution where the FlexConnector class library can be shared with other programs, so a loosely coupled solution would be desirable.
How have others solved the problem? Any suggestions are welcome.
73
Andy
KU7T
0
Answers
-
I have a client that supports a Flex radio, but also supports a few other rigs. What I did was to create a super class I call AllRadios. AllRadios exposes common values supported by the rigs, such as the current frequency and mode. Each radio then inherrits this class.
0 -
Yes, I think this sounds like the right approach. That keeps it generic for the logging program. The fact that a lot of code has to be written to set and get the properties is necessary.
I am sure I will have more questions when I get deeper into it. Currently I can read frequency and set the mode :-)
73
Andy
KU7T0
Leave a Comment
Categories
- All Categories
- 289 Community Topics
- 2.1K New Ideas
- 535 The Flea Market
- 7.5K Software
- 6K SmartSDR for Windows
- 146 SmartSDR for Maestro and M models
- 360 SmartSDR for Mac
- 249 SmartSDR for iOS
- 231 SmartSDR CAT
- 172 DAX
- 352 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 29 FLEX-8000 Signature Series
- 851 Maestro
- 44 FlexControl
- 847 FLEX Series (Legacy) Radios
- 798 Genius Products
- 417 Power Genius XL Amplifier
- 278 Tuner Genius XL
- 103 Antenna Genius
- 243 Shack Infrastructure
- 166 Networking
- 404 Remote Operation (SmartLink)
- 130 Contesting
- 631 Peripherals & Station Integration
- 125 Amateur Radio Interests
- 870 Third-Party Software