extend GNSSNTRIPClient to return source table to the main app #40
Replies: 3 comments 5 replies
-
Hi @SebKuzminsky, So, as you've summised, retrieving the sourcetable and streaming the live RTCM3 correction data will always need to be separate operations, as the caster closes the HTTP connection after returning the sourcetable. Also, bear in mind that sourcetable retrieval doesn't generally require authentication, whereas streaming RTCM3 data generally does. For example, the PyGPSCllient GUI utility uses a threaded GNSSNTRIPClient operation to populate a sourcetable Listbox from which the user can select the required mountpoint, but then needs to re-run that operation with a non-blank mountpoint to actually stream the correction data. It was intentionally designed this way. To achieve the functionality your're after, you would - as you say - need to run the two separate operations consecutively, retaining the sourcetable list between operations and invoking the existing Of the options you list, 'option 2' would also be my preference, though I would be inclined to make both calls non-blocking to facilitate programmatic use by external applications. However, I'm not 100% convinced a fully automated selection would be that useful in practice - some observations off the top of my head:
But happy to discuss further - contributions always welcome :-). |
Beta Was this translation helpful? Give feedback.
-
Hi @SebKuzminsky , FYI I've been thinking about this and, as you say, "option 1" has the advantage of requiring just simple changes to the existing
It then becomes a trivial matter for the calling application to read the sourcetable and closest mountpoint from the output queue and then invoke the GNSSNTRIPClient again using this mountpoint, e.g. something like this quick adaptation of the existing
This would be a relatively trivial change to make and minimises duplication of code - any thoughts? See for example https://github.com/semuconsulting/pygnssutils/tree/auto-mountpoint-detection |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Hi there, I'm in the process of writing a program with the following behavior:
From my reading of the source code I think there is currently no way for a program to get the source table using GNSSNTRIPClient: if no mountpoint is supplied it fetches the source table and prints it to stdout, then exits. I can imagine getting around this problem by capturing and parsing stdout, but that seems clumsy and awkward.
I would like to discuss ways of extending GNSSNTRIPClient to enable the above use case.
I can think of two possibilities:
output
Queue for the main application to read. This is a relatively small change, but it has the downside that after fetching, parsing, and adding the sourcetable to the queue, the GNSSNTRIPClient has no more work to do - since it doesn't have a mountpoint, it can't subscribe to any RTCM3 correction data.get_ntrip_server_list()
function to the GNSSNTRIPClient API. When called, this function would make the HTTP request with the NTRIP Caster, parse the data as above, and return it to the calling function.My preference is option 2. I welcome thoughts and feedback on these ideas. I'm happy to implement whatever is deemed most desirable.
Beta Was this translation helpful? Give feedback.
All reactions