Support for external receiver via NMEA over TCP

[pyrog]

Some GNSS receivers could send a NMEA stream over TCP (port 1958 by default).
The receiver could be a client of your app (SMASH is the TCP server)…
or the server (SMASH is the client).

Softwares

• Vespucci an OpenStreetMap editor

GNSS receivers

• Sparkfun RTK devices
• Emlid Reach M2

[moovida]

That is a long time wish also for us. But we never had a usecase paying for this kind of implementation.

At this year's foss4g I sopke to someone from HOT that told me they are testing external low cost devices. Maybe the two thing could finally lead to an implementation. Let's see. Thank you for the input.

[gdt]

Also, Ardusimple devices are like this, and more importantly, don't do bluetooth. So while this issue is valid, the real point IMHO is "enable smash to work with the above 3 devices while the devices get RTCM3 via NTRIP over the internet, and while they get it separately".

[pyrog]

For information:

• TCP port 1958 is the port used by Vespucci.
• UDP and TCP ports 10110 are registered by the IANA for NMEA.

[frafra]

There are some Android applications which are able to connect to external receivers and provide a "mock" location, even over TCP. It could be worth trying a couple of these in the meanwhile.

[github-actions]

This issue has been marked as stale due to inactivity for 60 days.

[gdt]

Hey stale-bot just because no recent activity doesn't mean the issue is no longer valid!

[moovida]

Agreed @gdt :-) Got to revive it. And if we are lucky, in near future there might be a funding for this. Fingers crossed.

[gdt]

I also sort of meant "stale bot considered harmful". I'm ok with humans deciding "this feature request being in the bugtracker is causing more cognitive load than usefulness", but stale bots just cause humans to have to pay attention for keepalives.

In a project I maintain, I ping people and set feedback when I think the bug is no longer useful, and if it's asking for a feature that just no one has got to and it's useful and I can see it happening Someday, then I leave it. I view stale bots as a problematic part of github culture.

[moovida]

Hi @gdt , I had a long thought before enabling stale bot. The problem is that we have not been able to build up enough critical mass around the app to have contributors. We lack code contributors, we lack documentation contributors.
And issues pile up and are there for years, often with a poor description and people not answering after asking integration.

So at the end I decided to activate the stale bot to do some cleanup and try to kind of start from scratch. Some people like you and others will keep the issues alive, also showing interest, others will let issues die. Most of the times, if the issue is a bug, I will anyways try to solve it or at least keep it alive. If it is a feature request, then I find it ok, if people show that there is still interest.

I am open to discussion. I could also make the stale bot more relaxed on time (currently 60 days).

[gdt]

If there were a way for you to add a valid tag, to exclude it from the bot, then I wouldn't mind so much.
Lengthening the time would help, maybe 180 days. But really the issue is that once a human maintainer has judged an issue valid, it should remain until a human decides to close it.

I do understand the need to clean out non-useful issues. In a project I maintain, I close them if people don't respond. I don't care if you use a bot for that, as long as it doesn't keep tryiing to close things where there's human agreement they are valid.

[github-actions]

This issue has been marked as stale due to inactivity for 60 days.