NMEA stream over UDP #644
NMEA stream over UDP #644
Conversation
|
Thank you for recommending this feature. I like the idea in principal. But as you've discovered, there is a lot of work being done on the release_candidate. We are working to separate the network layer out so that various consumers/generators (TCP, NTRIP, Servers and Clients) do not have to know about how the device is connected to the internet. This is groundwork so that we can add fall back between WiFi/Ethernet/etc. You are welcome to get this PR completed but we may break things as we complete the network layer work. Port 10110 looks perfect! Naming: PVT_UDP is fine for now, I don't have a better one. I'll check in with @LeeLeahy2 and see if he has any opinions. WRT the WiFi Config interface, it is the last thing we update once the core settings have settled. Thank you for pointing it out. If you want to contribute to the WiFi Config page, I would gladly welcome it. |
|
I absolutely understand. I will keep my branch up to date with the release_canditate once in a while to check for breaking changes. Until then I will use and test this feature with my own working copy. Alright, maybe I will contribute to the WiFi Config page when everything is working in the network layer. Is there a timeline for releasing all those new features? |
|
No timeline but active work. I'm hoping for 2-4 weeks to being stable. |
| } catch (error) { | ||
| console.log("Issue with ID: " + id) | ||
| } | ||
| } | ||
| else if (val == "false") { | ||
| try { | ||
| ge(id).checked = false; | ||
| console.log("Set " + id + ": " + val); |
There was a problem hiding this comment.
This is fine for your own local debugging, I am hesitant to console log anything but errors, just because I don't want to load the user's browser. Would you please comment these out?
|
Our goal is to have the clients and servers independent of the network. To achieve this, would you please create a NetworkUdp.h based upon UDP similar to NetworkClient.h which abstracts the interface between WiFi, Ethernet and in the future other types of networks. Create the NetworkUdp object with the network type (Ethernet, WiFi, etc.) from the network object. Replace WiFi calls in PvtUdpServer.ino with calls to the NetworkUdp object. This will allow the PvtUdpServer to run on Ethernet, WiFi and other networks in the future. Thanks for your help |
|
I tried to implement that and will test it tomorrow. |
|
Everything worked fine on my setup. Is this the way you imagined it @LeeLeahy2? |
|
Would you please add testing comments at the beginning of the module, see PvtClient.ino for an example. Please include the name and link to the application used for testing. Alternatively add a test application into the Tools folder. The code looks good for now. Some changes will eventually be necessary to support Ethernet. Explicit calls to WiFi will need to be removed and some replaced with calls into NetworkUdp.h. Similar changes are needed in PvtServer.ino. |
|
@DavidBerschauer - We've got v3.8 released so now is a good time to get this merged into the release_candidate. Please let us know how we can test NMEA over UDP and we'll start working on it. |
|
I'm sorry, I had alot todo at work. I added a few test comments in PvtUdpServer.ino For the naming I thought of PvtBroadcast because it's all about broadcasting the PVT data and UDP is the way to do that. |
|
Thank you! This looks good and I think the name PvtBroadcast is good. We will get your code tested shortly. |
|
This is testing well for us. Thanks! |
Streaming NMEA data over UDP, just like the TCP server
Applications like QField support NMEA streams over TCP and UDP.
Currently only TCP is supported by this firmware, which requires typing in IP adresses or typing in a hostname and a working DNS. With UDP it's possible to broadcast the NMEA data to the network, for example a smartphone hotspot. To use this data, any application has to listen on a specified port, making it easy for developers to get RTK position data in their App without providing any UI for configuration. For the port I suggest 10110
Naming things
I started to implement things accidentaly based on the main branch and it worked fine, but then i figured out the TCP server an client changed alot on the release_candidate branch. Everything is named PVT server and the new UDP server would also provide position, velocity and time as a server. So I started to name the new server PVT_UDP server but that doesn't feel right. How would you call this feature? I will add the complete implementation soon.
Web configuration
By the way: the current web config page on the release_candiate branch does not work with the PVT server settings and has a different structure than the CLI configuration. It also seems to me, that on the main branch, the TCP Server or Client will never show up as enabled in the web page, because this setting is not passed to the browser. Only the port is send