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 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.

API for GPS info

Martin AA6E
Martin AA6E Member ✭✭✭
edited January 2020 in SmartSDR API
I'm having fun checking out the Ethernet API for my 6500 using Python.  In particular, I'm looking for the GPSDO information that we see on SSDR's "GPS" tab.

I've found some GPS info.  The TCP connect reply includes "radio oscillator state=ocxo_gpsdo setting=ocxo_gpsdo locked=1", but this seems to be a lie, since it always indicates "locked" even when the GPSDO is not locked up.  Maybe it's talking about the reference oscillator source switching.

There is a better indication through the info command that delivers gps="Locked" that actually does reflect the current status of the GPS module.  ("Holdover", "Warming up", etc.)

But there should be much more: lat/long, sats tracked/visible, UTC, etc.  Where do they come from?

In general, how up-to-date is the Wiki data supposed to be?  I see info for the new 6400/6600, but the GPSDO has been around for a long time.

The G3WGV Primer has been a great  help!

TIA / 73 Martin AA6E


Answers

  • Jay Nation
    Jay Nation Member ✭✭
    edited May 2019
    Martin, and for that matter, everyone else.

    Wiki's are designed to evolve, so they don't have to contain out of date information, they only contain whatever information the registered users decide to add to them. You seem to be figuring out some of the responses for the GPSDO, Maybe you can register to edit the wiki and document what you're finding out. Clicking on the login link in the upper right of the Main Wiki page will reveal that if you want to register this is how.

    To receive an account that allows editing of wiki articles, contact: devhelp@flexradio.com

    Wiki editing is really simple, not much harder than posting something in the community.

    Clicking on Recent Changes on the left side menu will allow you to see what was changed last. and the name of the user that made it.

    Currently, the latest change was made on February 28, 2018.

    I think they might welcome any help they can get, with creating API wiki content.  Any other registered user can later login and correct any incorrect Information. Even if its just a typo.

    The wiki software maintains a change log so reverting any errors is also simple.

    Wiki instructions can be found by clicking on the Help link on the left side.

    We probably only need to ask for editing permission and behave ourselves.

    That's how wikis are supposed to work.

    Anyone with the knowledge, that wants to share it, probably can.

    #Flexradio

    73, Jay / NO5J

  • Martin AA6E
    Martin AA6E Member ✭✭✭
    edited January 2020
    @Jay.  I am quite familiar with Wikis, and I would be happy to add to this one.  The problem is that I don't have the data.  Maybe we could reverse engineer the protocols with WireShark, but it would be so much easier if the Flex folks would document things.  If they would provide the raw data (command definitions etc.), one of us could do the prose and the formatting.

    73 Martin AA6E
  • K1DBO
    K1DBO Member ✭✭✭
    edited March 2018
    Use the source, Luke.
    --Obi Wan Kenobi
    As far as I can tell, the best "documentation" for the API is the source for FlexLib. You can download it from http://www.flexradio.com/downloads/flexlib_api_v2-1-32-zip/ It's not perfect but it's accurate.  Just take a look in Radio.cs, for example, and search for The SendCommand() calls.  


  • Jay Nation
    Jay Nation Member ✭✭
    edited March 2018
    Martin

    Yep me too, but experience working with the data, already in the wiki might help flesh out, some of it into better data, in the wiki, Me I look for typo's, I haven't found any yet, but I'll correct any I find, so don't worry about spelling too much.image 

    #Flexradio

    73, Jay / NO5J

  • Martin AA6E
    Martin AA6E Member ✭✭✭
    edited March 2018
    Flexlib is not exactly my idea of self-documenting or literate code (!), but it does provide hints.  I have found in the wiki that there is a "meter" for the GPS data, but we're on our own to figure out the format details. 

    You would think FRS would document their code if only for internal purposes.  They must have, but perhaps not in a form that can be allowed out of the house. They wouldn't want to embarrass us with their brilliance. :-)

    TKS/73 Martin AA6E
  • Steve-N5AC
    Steve-N5AC Community Manager admin
    edited March 2018
    Martin,  the first line you mentioned is the oscillator status -- the GPSDO outputs 10MHz that is then phase locked by the main oscillator in the radio.  The Locked status on the oscillator line says that the main oscillator is locked to the GPSDO 10MHz reference, not that the GPS module itself is locked.

    To get the detailed GPS data, subscribe to the GPSDO status messages:

    http://wiki.flexradio.com/index.php?title=TCP/IP_sub#SUB_GPS

    I think the status message format will be fairly self-explanatory.  If not, let me know what you're missing.
  • K1DBO
    K1DBO Member ✭✭✭
    edited March 2018
    Usually, the "form that cant be allowed out of the house" is the source code itself.  Very little of the commercial software I've seen has much in the way of internal documentation.  Since developers have access to the code the need for much more than the initial architecture documents is minimal.  Worse, the internal documentation quickly gets out of sync with the code. 

    It's likely that Flex would choose to spend the development time on fixing bugs and adding features rather than on maintaining a document that is rarely used.  Documentation takes time.  Good documentation takes a lot of time.  I like to think that the folks who write life critical software do things differently, but I've managed to stay away from that myself.

    The meter API is a bit of pain to deal with.  Knowing there is a meter is easy, getting the data for a meter requires some bit fiddling. Check out Vita/MeterVitaPacket.cs.

    For everything else, the calls to SendCommand() do a great job of "documenting" what you can ask the radio to do while the various ParseXXXStatus() methods "document" what the radio sends back. 

    Often there's an obvious connection between what is sent and the status messages it generates, but not always.  A document that describes this sort of thing is something I'd find useful.  Experimentation works here but that can be tedious and error prone.  It's also the kind of thing that could change between releases.  Knowing the difference between what happens and what is required to happen can be helpful at times.


Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.