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.
API separators, "=" vs " "
Doug - K3TZR
Member
Some API commands are in the form <name=value> whereas other are <name value>. I believe individual commands require one form or the other. In future versions could the API be made to accept either separator? That wouldn't break old code but would make the API more consistent.
0
Comments
-
This seems like a reasonable suggestion.
There are similar protocol variations in the command responses which makes parsing more complex. There's probably a perfectly good reason for these differences and I'm not suggesting that any changes need to be made, especially if to do so would damage backward compatibility. Is there an API design document that discusses these differences and the rationale?
0 -
In general, commands that need parameters have parameters in a "command parameter parameter..." structure. If the parameters to commands are name/value pairs, then the name/value pairs are separated with = and the parameters are separated with space. For example:
radio filter_sharpness DIGITAL level=3 auto_level=0
Does this help understand why it's this way? If this doesn't "cover it," please provide some examples we can look at and think about.
Just as a side note, my original goal was to use a recursive descent parser for the API and I was amazed that the tools to do this in C were awful. I made several aborted attempts at it while the API was growing and finally gave up on the idea (too much to do, so little time). As a result, the API is parsed with CRT primitives (strnlen, strncmp, etc). Altering an API that does not have a grammar codified is considerably harder. The method we ended up with is also responsible for any inconsistencies you see. Having said this, we have altered some commands for required updates and made it so they would work with either a past or new format (slice is an example). With so many programs using the API at this point, we would have to look carefully at any changes, especially sweeping ones.2 -
Great reply, thanks Steve.
I don't think this is worth spending time on - we've gotten used to the API's little quirks and it isn't really that hard to parse, honest! I'd far rather any effort on the API was put into adding functionality, for example, the persistent client identifier suggestion that I discussed with Ed when I visited back in May.
0 -
Thanks to everyone for their comments.
Here's a simple example:
interlock tx1_delay=<value>
vs
cw break_in_delay <value>
Both are in the form <command> <param> <value> but one use "=" and the other uses " " to separate the <param> from the <value>.
Small difference but it makes the code to format commands dependent on specific knowledge of each command rather than knowledge of the pattern followed by all commands.
0 -
Yep, totally agree that this is inconsistent. I've entered an issue (#5040) in our tracker to look into changing this. Thanks!0
-
Thanks Steve0
Leave a Comment
Categories
- All Categories
- 289 Community Topics
- 2.1K New Ideas
- 534 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
- 230 SmartSDR CAT
- 172 DAX
- 352 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 26 FLEX-8000 Signature Series
- 850 Maestro
- 44 FlexControl
- 847 FLEX Series (Legacy) Radios
- 796 Genius Products
- 416 Power Genius XL Amplifier
- 277 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