NMEA feed
Post by iconPost by zezo | 2020-05-28 | 13:44:52

I've been asked (again) if it's possible to have boat data fed into 3rd party software by the VRDashboard. The purppose is practicing real-world nav software usage during VR races, but it should also be useful for collecting boat track/stats.

So I wrote a little sever that turns game data into NMEA feed over TCP.

Details below.

commenticon 127 Comments
Post by iconPost by zezo | 2020-05-28 | 13:56:17
First, the functionality is not in the official extension, so a beta version has to be installed manually:


1. Download http://zezo.org/VRDashboard.zip and unpack it somewhere
2. in Chome, open the More Tools -> Extensions
3. Disable the installed VRDashvoard
4. Check "developer mode"
5. Check "load unpacked"
6. Point to the place you unpacked the .zip in step 1
7. Done.

Connect your router or another tool to a zezo.org, tcp port 10000 + the race_id you want to follow. You may have to enter the race once if the port is not open.

race_id can be found in http://zezo.org/races2.json

{ "id" : "458.1", "name" : "Cape to Goa", "url": "cape2goa" },
{ "id" : "461.1", "name" : "LA - Tahiti", "url": "tahiti" },
{ "id" : "446.1", "name" : "Rund Skagen", "url": "skagen" },
{ "id" : "434.1", "name" : "Honolulu - Yokohama", "url": "yokohama_maxi" },
{ "id" : "459.1", "name" : "Beneteau", "url": "oceanis" },
{ "id" : "460.1", "name" : "Tresco", "url": "morlaix" }

So Tahiti would be port 10461

telnet zezo.org 10461
Trying 212.50.14.242...
Connected to zezo.org.
Escape character is '^]'.
$GNRMC,135217,A,3342.6726,N,11827.5580,W,6.35,188.3,280520,,,A*46
$INMWV,052.44,T,03.22,N,A*08

After entering the race again to trigger the data transfer you should get the boat position, SOG, COG, TWA and TWS data.



Data is currently retransmitted every 30 seconds because the tested nav software gives up after one minute without NMEA feed.


Post by iconPost by Luis75 | 2020-05-28 | 14:00:14
Cvetan this is awesome!
Post by iconPost by Luis75 | 2020-05-28 | 15:35:29
I tried and it works pretty good.
The only thing I am not able yet to configure is the update frequency...
Post by iconPost by zezo | 2020-05-28 | 14:03:48
The boat is correlated to the user by IP address, which can be problematic if you are behind NAT with other users.

It also means you have to run the nav software on the same machine as the browser, or in the same LAN behind the same IP, so point 1 may actually be a feature.

The problem with may users having the same address can be overcome by running a simple VPN that only routes requests to zezo.org if need be.
Post by iconPost by zezo | 2020-05-28 | 14:06:24
Another possibility would be someone to develop a local software that you run on your PC, like GPSD, and point the extension to it. Current implementation uses websockets because I've written something similar short time ago for my job, but a local version could use simple HTTP GETs

Then we have to add a input line and a checkbox or two to the official extension to let you select if and where data is fed.
Post by iconPost by zezo | 2020-05-28 | 15:06:34
Few more things. Connecting from unknown IP (without extension running) returns a stream of empty lines. Maybe should disconnect right away to avoid denial of service attacks.

Closing the extension/game will generate and endless stream of stale data to already connected clients.
Post by iconPost by zezo | 2020-05-28 | 15:41:32
@Luis75 The actual position update will be every 5 minutes once the race goes underway, triggered by the game server position push.

It is possible to do dead reckoning and move the boat the way the game client does, but then it won't serve as data logging. Maybe those should be separate services.

This functionality could also be built into the extension, so it would work with local clients and be configurable.
Post by iconPost by Luis75 | 2020-05-28 | 16:56:40
Thanks Cvetan!
Post by iconPost by Hardtack | 2020-05-28 | 16:21:30
Hi Cvetan, that's very cool!
I got one or two requests for NMEA integration, but as I didn't know the protocol and I don't have any NMEA devices I could not help.

I'll be happy to merge your code. I would leave websocket output off by default and add a switch in the UI, so we don't spam your server with messages that are never picked up.

Do you think we should add authentication to protect your server? But if you disconnect unknown IPs immediately it is probably unnecessary.

Post by iconPost by zezo | 2020-05-28 | 16:37:19
Ideally it should not be running on my server, but it's a catch-22 type problem and that was the easiest solution.

Problem is: Extensions can't talk raw TCP/IP. Then it could be Chrome app which can, and also could talk serial via virtual com port, but Google are obsoleting Crome apps and tey will be unavailable within an year.

Then remains the possibility of client-side app. Maybe could even be still javascript via packaged npm exe. Or someone with C# development skills and IDE could throw something together. But then someone will want to run it on a Mac ;-)

As for developing the current proof of concept I can imagine it like you say:

Authenticating - not really needed. Someone feeding the ws with proper json would be enough to authenticate accept() for the TCP connection and I can do it server-side.

UI - yes, maybe another tab with list of races, their TCP ports and a checkbox to send data or no. Possibly an option for dead reckoning with configurable interval (not less than 30 seconds) and configurable websocket host:port. Maybe select HTTP as protocol if we develop local client - it could be easier to write.

Right now the dashboard just resends every position message it gets. About 5 lines of code without much error checking. Data should be filtered to save some traffic.

But let's leave it this way for a while and see how it goes and get some more suggestions and ideas.

Post by iconPost by Ultimate Victory | 2020-05-29 | 12:54:41
It works like a charm with Adrena. The only issue I'm having is that Adrena is reporting a GPS Lost message that I can't avoid. I understand this is due to the 5mn refresh period, but I don't know how to fix that.
Also it display SOG, COG and TWA but not TWS and TWD.
Post by iconPost by zezo | 2020-05-29 | 13:36:17
Thanks. Guess it does not like the MWV sentence with true wund data.

Real anemometer would generate a VWR sentence. That would require making the reverse vector calculation, but it's not a big deal.


Post by iconPost by Ultimate Victory | 2020-05-29 | 14:11:10
In fact TWS/TWA works until Adrena display the "Lost GPS" message. I'm looking for any timeout in the settings, but there are no obvious ones.
Post by iconPost by zezo | 2020-05-29 | 14:13:49
Oh, that's even better. So we just have to add dead reckoning and generate different position messages.

What's the timeout before losing the "GPS" signal?
Post by iconPost by Ultimate Victory | 2020-05-29 | 14:52:23
It seems to be 10 to 20 seconds
Post by iconPost by Ultimate Victory | 2020-05-30 | 07:00:21
Cvetan can you please explain exactly how to use it and how it works ?
Do I need to leave the VR page open on the race menu or with a race being loaded ?
Does the communication between the router thru the NMEA TCP channel is done with the zezo.org web site or thru the dashboard ?

I'm asking because while my dashboard is displaying a new value almost every 5mn, the trace in Adrena is not. There are plenty of missing values, sometimes I've got a value after 25mn, more often every 10, but almost never every 5mn.

If I do a "telnet zezo.org 10461" while the dashboard is running, then I get a "connection to host lost" after about 30 seconds. If I reload the game I'm getting values. So I guess the Adrena behavior is certainly related to what I'm experiencing with telnet.
What are your thoughts on this ?
Post by iconPost by zezo | 2020-05-30 | 08:18:44
Web pages and Chrome extensions can't talk raw IP for security reasons. That's why we need a small program/proxy server to translate between HTTP and NMREA/TCP

Currently that program runs on zezo.org, but we (Michael, actually) are working on a local version that you run on your PC and connect locally.

It works like this:

Every time the extension gets a position message from the game, it sends it to that proxy at zezo.org. The proxy checks if it's got TCP connection from the same IP and sends NMEA formatted message to it. So if everything works you should have exactly the same data in Adrena as in the extension position log.

About the telnet stuff - Adrena gets what telnet gets, at least if they are connected one by one. It's a bit different with two simultaneous clients.

Telnet gets disconnected because there has to be a game update _after_ the TCP connections, so the game data can be correlated to the NMEA feed. Once the two connections are established the NMEA port will retransmit the same data every 30 seconds, until it gets a new position message from the game/extension.

Now, if you have something connected and receiving NMEA, another connection from the same host won't be disconnected. It will start receiving the NMEA feed within 30 seconds instead.

Post by iconPost by zezo | 2020-05-30 | 08:27:38
P.S. You're not posting from IP address where Adrena is running, so I can't check the logs. Please send me a message from the feedback form on the Contact page, from the same broswer running the extension.

I suspect Adrena may be closing and reopening the extension after the timeout it gets.

Also, closing the port is a protection against network scans, so a simple scan wont result in a denial of service attack. But it's not a very good implementation right now. It would be better to use the existing websocket connection as a key to the tcp. That way the connect order would be defined as extension, nmea and there will be immediate feed.
Post by iconPost by Ultimate Victory | 2020-05-30 | 09:39:38
Here is a reply from the machine running the extension
Post by iconPost by zezo | 2020-05-30 | 09:47:41
Thanks. Yes, it's reconnecting all the time. I'll make a little change now so new connections get nmea data right away. Please leave everything running.
Post by iconPost by Ultimate Victory | 2020-05-30 | 10:20:00
Thanks a lot. It works way better now. I can see from the logs that Adrena is checking every 2s which I don't know how to control. Does the extension call the server each time or only when data has changed ? otherwise this can become quickly a DoS with plenty of users.
Post by iconPost by GeGaX | 2020-05-30 | 09:00:20
Hi Cvetan 😉,
The subject interests me I was going to ask Michael something similar.

I do not understand the interest of wanting to route via real software (Adrena / MXTZ / Simsail / OpenCPN / QtVlm / Squid / SailGrib / Scannav / Expedition / etc ...)
• The winds are pure GFS 1° (no U&V conversion)
• TM003 is not present on VR
• Wind interpolation is not the same as on VR
• The mapping is not the same as that of VR
• On some, the application of penalties is not possible, on others it is in the form of boat lengths

It can give a trend but not something that we can apply to VR, moreover many of these routers are paid (even if we can find some cracked ...) so not accessible to everyone.

I use a router dedicated to VR, would it be possible to have the JSON message on http://127.0.0.1:(10000 + raceId) ?
Post by iconPost by zezo | 2020-05-30 | 09:12:35
It could be useful to keep currency with your software while not at sea. They are pretty complex beasts, you know. And there are some payers who own legal versions for use IRL.

About the json - Michael is doing it right now, plus a small python script for the proxy. Same port because you can discriminate by race_id, but ideally I'd like to have everything configurable - what to send json or directly nmea, and if to do it over HTTP POST or websocket.

Configurable host and port, and on/off switch for each race. Maybe dead reckoning to make the software happy (if that's the actual problem with Adrena, and not just the timeout)

Post by iconPost by GeGaX | 2020-05-30 | 09:24:10
Yes I know the routers well since I install them in my work (Most often Adrena / MXTZ on PC and Weather4D 2.0 / AvalonOffshore on tablet) 😉

This is the POST method I had in mind to transmit the JSON in localhost

The configuration could be done via an "Option" page of the extension, right?
Post by iconPost by zezo | 2020-05-30 | 09:34:24
Yep, I was referring to your job above.

It could be useful if you can provide some live data captures from real instruments / wifi multiplexors to see what goes down the bus in the real world.
Post by iconPost by GeGaX | 2020-05-30 | 09:59:20
I could log nmea frames on a multiplexer (Miniplex 3Wi -N2K) from a simple Raymarine installation.
• Wind vane / Anemometer (AWA / AWS)
• Magnetic cap (HDG)
• GPS position (GPS pos)
• Date / time (Date Time)
TWA, TWD and TWS being calculated (COG / SOG + AWA / AWS)

With 2 nmea sentences we must have everything I think (RMC - MWV)
Post by iconPost by zezo | 2020-05-30 | 10:17:27
RMC and MWV is what I'm sending now. I don't really need the log, it's more about curiosity.
Post by iconPost by GeGaX | 2020-05-30 | 10:29:46
Sorry i must have misunderstood
Tell me what you want and I'll do it on Tuesday 😉
Post by iconPost by zezo | 2020-05-30 | 10:31:29
No, you got it right. It would be interesting to look at some live boat feed because I don't have a boat at hand. Nothing more than that.
Post by iconPost by GeGaX | 2020-05-30 | 10:44:04
Like nmea sentences frequency ?
If yes it's "fast" 4800 bauds except AIS 38400 bauds (NMEA 0183)
Post by iconPost by zezo | 2020-05-30 | 10:57:53
No, not the physical layer.

I still have an old Magellan GPS 315 with physical (almost) NMEA port, and oscilloscope too. Also eTrex with NMEA over usbserial, and the Chinese Android phone sends NMEA over TCP when running the built-in testing app.

But they don't have fluxgates and anemometers ;-)

Well, the phone has a magnetometer of course, but the chipset only sends $G messages.
Post by iconPost by GeGaX | 2020-05-30 | 11:08:19
Ok understand I'm doing this to you on Tuesday 😉
Post by iconPost by zezo | 2020-05-30 | 10:20:30
@Ultimate Victory

Mystery solved. It seems that Adrena gives up after 3 seconds of silence on the port and tries to reconnect.

Modified the script to send data every 2 seconds and seems that it makes it happy. Watch it for a while and see if the user interface side is happy too ;-)

Receiving empty lines also makes it happy, btw. There just has to be traffic on the bus. Will have to check how other software behaves and if skipping the RMC and sending only the wind will be OK.
Post by iconPost by zezo | 2020-05-30 | 10:25:59
@Ultimate Victory

The extension is passive - it only listens to game data, does not interact with game server in any way.

Then it sends the server data to my proxy every 5 minutes.

Then the proxy formats it to nmea and sends every 2 seconds. Not a big deal to send 48 bytes/second to few clients.
Post by iconPost by Ultimate Victory | 2020-05-30 | 12:41:57
Adrena seems happy now. No more GPS lost and trace is updated every 5mn.
Thank you so much for solving this.
Post by iconPost by Ultimate Victory | 2020-05-30 | 18:59:53
Does anything has changed on the server side ? it has stopped to work right after I loaded the game. Works perfectly all day since your change until now .

EDIT : Forget about it back to normal after reloading the game few times

Post by iconPost by stufishing | 2020-05-31 | 08:17:44
Has anyone got this working with OpenCPN. I put telnet zezo.org in network path and 10461 in Port. But it doesn't seem to send any message? There is absolutely nothing in the log. Surely OpenCPN needs to send the first request?
Post by iconPost by zezo | 2020-05-31 | 08:57:25
Shoud work with

Connection type: TCP
Address: zezo.org
Port: 10461


Post by iconPost by zezo | 2020-05-31 | 08:59:36
@Ultimate Victory, I think your Adrena is configured to send data on the NMEA bus too.

$GPBWC,085010,1451.600,S,14842.100,W,219.1,T,209.3,M,999.0,N,Mataiv,A*4C
$GPRMB,A,29.93,L, ,Mataiv,1451.600,S,14842.100,W,999.0,219.1,000.0,A*16
$GPXTE,A,A,29.93,L,N*5F
$GPZTG,085010,995959,Mataiv*58

It's not a problem here, but the current client does not read the data and the client's network buffers will fill up sooner or later. Which also may or may not be a problem.
Post by iconPost by Ultimate Victory | 2020-05-31 | 16:04:40
Thanks, I will look at the settings.
Post by iconPost by Hardtack | 2020-05-31 | 16:14:49
I've uploaded a VRDashboard version that uses a local NMEA proxy. The proxy requires Python3.

* Download http://bitweide.de/vrdashboard/VRDashboard.zip
and install as described by Cvetan above.
* Please follow the instructions from the manual http://bitweide.de/vrdashboard/manual.html

Please let me know if it works. I think I'm formatting NMEA messages according to the doc but the look slightly different from Cvetan's:

$GNRMC,154939,A,0310.05,N,13642.20,W,14.0,,31052020,,*09
$INMWV,246.3,T,14.1,N,A*0B

Post by iconPost by CoreTeam | 2020-05-31 | 16:37:36
Hi! I used the original from Cvetan's and worked ok for a moment and then stopped working. Tried everything and still not working.
Now I tried your 3.9.0 version and also not working. Looks like no NMEA info received in qtVlm.
What could be not working? Looks like the extension is not sending my boat info to the server? could be?


----- Never mind.... started working again..... maybe the server was down or something... thanks!!!
Post by iconPost by Hardtack | 2020-05-31 | 17:13:56
$ python3 nmea_proxy.py
Listening on port 8081

- Check if you enabled NMEA output in the dashboard. You should see the NMEA proxy print messages like

Creating connection for 461
Creating socket for 461
Accepting on <socket.socket fd=5, family=AddressFamily.AF_INET, type=2049, proto=0, laddr=('127.0.0.1', 10461)>

- If you see messages like

Accept on <socket.socket fd=5, family=AddressFamily.AF_INET, type=2049, proto=0, laddr=('127.0.0.1', 10461)>failed: [Errno 11] Resource temporarily unavailable

then no client is connected to the indicated port (10461 in this case)

- To check if the NMEA feed is running, open another command shell and type

$ telnet localhost 10461

You should see NMEA messages printed every 10 seconds.



Post by iconPost by Shelisteam | 2020-05-31 | 19:46:34
Not work correctly. Bad enmea sentence.
To complicated to install.

Zezo solution work ok now


Post by iconPost by Hardtack | 2020-05-31 | 19:58:39
Sorry about this. As I don't use NMEA myself I went by a spec that turned out to be outdated.

Meanwhile Cvetan provided my with a web page to check the GNRMC message and it should be fixed now.

Please download again.

Post by iconPost by zezo | 2020-05-31 | 20:20:26
Please stop acting like we owe you something.

We are doing this stuff for fun and for free. You want 24/7 support - hire someone to do it for you. The source is available anyway.
Post by iconPost by CoreTeam | 2020-05-31 | 19:11:55
I will try to install python then. That could be the local problem.
Anyway, why stopped working from zezo server? some times it works, some times it doesn't. How can I check if dashboard is sending info ok to server? (my ip and user id I believe). Because I don't get anything from the server zezo.org port 10461
Post by iconPost by Hardtack | 2020-05-31 | 19:37:57
Note that only Cvetan's version sends data to zezo.org.

You can check by pressing F12 on the Dashboard tab. This opens the Chrome debugger. Select 'Network' in the menu bar and filter for 'WS' (websocket) in the third row.

On the other hand, my version linked above (2020-05-31 | 16:14:49) only works with the local proxy, it does not send data to zezo.org.
Post by iconPost by CoreTeam | 2020-05-31 | 20:03:33
All clear... thanks!
Post by iconPost by zezo | 2020-05-31 | 21:20:25
My version is somehow untested and the proxy crashes occasionally. Then someone drops me a note and I restart it.
Post by iconPost by GeGaX | 2020-05-31 | 21:30:10
Hi 😉,
I installed the latest version (v3.9.1)
I tested the LA - Tahiti race on QtVlm (just to see)



• HDG -> OK
• COG -> OK
• SOG -> OK
• TWS -> OK
• TWD -> NOK
• TWA -> NOK

Post by iconPost by Hardtack | 2020-05-31 | 21:35:46
Thanks!
I'll have a look at TWD (TWA is wrong because it's derived from TWD, I think).


Post by iconPost by GeGaX | 2020-05-31 | 22:19:41
If you want, send me the corrected version by email before putting it here, I would test it 😉

PS: it would be possible to have the raceId in brackets next to the name of the race like this ?

Post by iconPost by Hardtack | 2020-05-31 | 23:30:12
Yes, good idea. Can you grab the latest version from my web server? Uploading is faster than hiding the ZIP from the mailer checks...

http://bitweide.de/vrdashboard/VRDashboard.zip

I'll add the race id in the next version.
Thanks for testing!
Post by iconPost by GeGaX | 2020-06-01 | 07:25:56
Hi Michael 😉,
I installed the latest version (v3.9.2)




• Postion GPS -> OK (just a problem of display on QtVlm)
• COG / HDG -> OK
• SOG / BoatSPD -> OK
• TWS -> OK
• TWD -> NOK
• TWA -> NOK

I found this code (C ++) given by Maitai (Designer of QTVLM) on the web

AWA / AWS knowing SOG, TWA, TWS

double Y = 90.0 - twa;
double a = tws * cos (degToRad (Y));
double b = tws * sin (degToRad (Y));
double bb = b + sog;
aws = sqrt (a * a + bb * bb);
awa = 90.0 - radToDeg (atan2 (bb, a));

The reverse, ie calculate TWS, TWA knowing SOG, AWS, AWA

double Y = 90.0 - awa;
double a = aws * cos (degToRad (Y));
double bb = aws * sin (degToRad (Y));
double b = bb - sog;
tws = sqrt ((a * a + b * b));
twa = 90.0 - radToDeg (atan2 (b, a));

Post by iconPost by zezo | 2020-06-01 | 07:32:20
There should be no need to calculate the AWA/AWS - the MWV sentence with a T(rue) indicator seems to work ok directly with the game data. Only the angle has to be normalized to 0..360 instead of -180..+180
Post by iconPost by GeGaX | 2020-06-01 | 08:02:48
Right, the angle must be on 360 °. 😉


PS Did you see my email?
Post by iconPost by GeGaX | 2020-06-01 | 08:49:40
I modified the code for MWV and it seems to me that it works correctly now


function formatINMWV (m) {
// $INMWV Wind Speed and Angle (TWA not TWD)
var s = "INMWV";
s += "," + ((m.twa > 0) ? pad0(roundTo(m.twa, 2), 6) : pad0(roundTo(m.twa + 360, 2), 6)) + ",T";
s += "," + pad0(roundTo(m.tws, 2), 5) + ",N";
s += ",A"
return s;
}
Post by iconPost by Hardtack | 2020-06-01 | 10:24:36
What, a TWA value normalized to 0..360? Okay... :-)

Uploaded another version:
http://bitweide.de/vrdashboard/VRDashboard.zip
Post by iconPost by GeGaX | 2020-06-01 | 10:36:30
@Michael:


😉
Post by iconPost by Hardtack | 2020-06-01 | 11:48:59
Fixed. That's what you get when you do things in passing.

There are a few other problems still - for example, NMEA output is decoupled from VR messages and runs every 10s. This means there can be a delay of up to 10s until a message is forwarded. There is no dead reckoning yet.
Also the proxy does not exit cleanly and you may not be able to restart it immediately.

There are probably other issues as well. I'll wait for some more feedback before putting it in the 'official' version.
Post by iconPost by zezo | 2020-06-01 | 12:50:48
It looks like there is no need for dead reckoning. But Adrena needs activity on the bus at least every 3 seconds, otherwise declares the connection dead, closes it and reconnects.

That as a problem with my initial version because there was no answer at the initial connect, only at dashboard message, so it timed out immediately. Now I'm sending every 2 seconds, and don't cleanup the stored NMEA message from the client socket object.

It will probably be happy with the INMWV sentence only, but that has to be tested.
Post by iconPost by GeGaX | 2020-06-01 | 13:30:25
With OpenCPN at 10s the connection does not work, I passed it to 1s and everything is fine.
At the end of the afternoon, I would test under the other routers (Adrena / MXTZ / Simsail / Expedition and Squid)
Post by iconPost by zezo | 2020-06-01 | 13:57:02
You are the man! ;-)

The usual GPS update is at 1s, so that's expected.

It would also be interesting if only the INMWV keeps the connection, and if a VTG or VHW will make them move the boat without a GPS fix.

Post by iconPost by GeGaX | 2020-06-01 | 16:37:25
I added the TCP port on my version (which is more practical than going to look for it in the console)



function addSelOption(race, beta, disabled) {
var option = document.createElement("option");
var TxPort = 10000 + parseInt(race.id.substr(0, 3), 10);
option.text = race.name + (beta ? " beta" : " ") + " (" + TxPort + ")";
option.value = race.id;
option.betaflag = beta;
option.disabled = disabled;
selRace.appendChild(option);
}


I will test the routers but I am confident if it works on 2 routers I think it will work on the others
Post by iconPost by Hardtack | 2020-06-01 | 18:40:10
Alright, I'll prepare the Dashboard and proxy to send every second. I see VHW and VTG described here https://gpsd.gitlab.io/gpsd/NMEA.html#_vhw_water_speed_and_heading
but it seems the specs are not always complete. Are there any additional constraints?
@GeGaX, I prefer to display the race ID in the selection box. NMEA users should be able to figure out the port, but the port number is meaningless to the other 95% of users.

Post by iconPost by GeGaX | 2020-06-01 | 19:16:07
I didn't quite understand about
VHW (HDG + BoatSPD) or VTG (COG + SOG)...
Want to do without RMC ?
It will miss the GPS position (GGL)
GGL + VTG = RMC
🤔

@Michael, No problem you do as you want for your official version 😉

PS: I use https://gpsd.gitlab.io/gpsd/NMEA.html too
Post by iconPost by zezo | 2020-06-01 | 20:08:58
Yes, ideally one RMC and then 300 VTG/VHW.

While GPS is the most popular instrument now, classic routing software should be happy with a log and anemometer, and GPS black-out is not a reason to shut down your nav station.
Post by iconPost by GeGaX | 2020-06-01 | 20:19:31
OK understood
I don't know if it works, there may be a GPS alarm. (Position lost)
We'll see 😉
Post by iconPost by zezo | 2020-06-01 | 21:18:04
In a proper NMEA implementation transmitting exactly the same sentence should be roughly equivalent to not sending it all.

It should be ignored at some level because the timestamp is the same every time.

But repeating NMEA is not a behavior you should see in real world, unless a multiplexer decides to play it smart and mask gps outage, so there may be measures to detect it or there may be not.
Post by iconPost by Ultimate Victory | 2020-06-01 | 21:56:41
I've tried to use your version with Adrena but without success. I can get the telnet test working, however with Adrena thelog is :
127.0.0.1 - - [01/Jun/2020 23:44:48] "POST /nmea/461.1 HTTP/1.1" 204 -
Creating connection for 461
Accepting on <socket.socket fd=552, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 10461)>
127.0.0.1 - - [01/Jun/2020 23:44:58] "POST /nmea/461.1 HTTP/1.1" 204 -
Client 461 went away, closing connection
127.0.0.1 - - [01/Jun/2020 23:44:58] "POST /nmea/461.1 HTTP/1.1" 204 -
Creating connection for 461
Accepting on <socket.socket fd=552, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 10461)>
127.0.0.1 - - [01/Jun/2020 23:45:08] "POST /nmea/461.1 HTTP/1.1" 204 -
Client 461 went away, closing connection
127.0.0.1 - - [01/Jun/2020 23:45:08] "POST /nmea/461.1 HTTP/1.1" 204 -
Creating connection for 461
Accepting on <socket.socket fd=552, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 10461)>
127.0.0.1 - - [01/Jun/2020 23:45:18] "POST /nmea/461.1 HTTP/1.1" 204 -
Client 461 went away, closing connection

Any idea how to solve this ?
Post by iconPost by Hardtack | 2020-06-01 | 22:01:00
I tihnk that's the problem found by GeGaX& Cvetan, Adrena times out if it does not receive a message every second or two. Initially we thought 10s were enough, and that is what the Dashboard still does.

New version coming soon.

Edit:
Uploaded a new version. It sends NMEA messages once per second.
As the dashboard receives new info only every 5min, messages are repeated. It is still unclear if the NMEA software likes this.

Thanks for testing!

http://bitweide.de/vrdashboard/VRDashboard.zip


Post by iconPost by Ultimate Victory | 2020-06-02 | 07:37:35
I confirm it works well with Adrena. Let me test it over the day and validate it's reliable. Thanks for building this.
Post by iconPost by Ultimate Victory | 2020-06-02 | 10:07:15
Since now 20 minutes, Adrena went mad. The latitude shift by a number to the right, meaning that 12°N became 1°N !!!

Below is the log captured from Adrena, and this one looks ok.

12:04:20 $INMWV,229.98,T,08.25,N,A*0B
12:04:20 $GNRMC,100221,A,0122.2940,N,12652.0425,W,14.6,186.9,020620,,,A*40
11:58:20 $INMWV,229.98,T,08.24,N,A*0A
11:58:20 $GNRMC,095518,A,0123.9932,N,12651.8370,W,14.6,186.7,020620,,,A*4D

It only happens with this version and not the one from Cvetan.
Post by iconPost by Ultimate Victory | 2020-06-02 | 10:19:04
Back to the normal, seems to be a bug in Adrena. Very weird.
Post by iconPost by Hardtack | 2020-06-02 | 10:31:49
Could have been an error in my number formatting, but I don't see anything in the messages above.
Post by iconPost by Ultimate Victory | 2020-06-02 | 10:49:13
the latitude seems correct in the log with no digit truncation.
Post by iconPost by Hardtack | 2020-06-02 | 12:10:01
Found the error. I'll upload a new version tonight.

Post by iconPost by Ultimate Victory | 2020-06-02 | 13:47:33
Oh great. It just happen now on both latitude and longitude :-)
Post by iconPost by GeGaX | 2020-06-01 | 22:04:09
@Ultimate Victory
Try to change in file dashboard.js, line 7
var nmeaInterval = 10000;
to
var nmeaInterval = 1000;

Save the file, refresh the extension and restart by following the usual procedure.
Post by iconPost by Hardtack | 2020-06-01 | 22:11:41
The nmea_proxy will log like hell with the 1s setting.

Please use the updated nmea_proxy.py
http://bitweide.de/vrdashboard/nmea_proxy.py


Post by iconPost by GeGaX | 2020-06-01 | 22:47:16
@Michael,
It doesn't work as expected I think
I have this :


And I think that you want this :


nmeaGNInterval is declared but not used
Post by iconPost by Hardtack | 2020-06-01 | 23:00:34
I did prepare for sending message with different intervals, but that's not implemented yet.
I'm waiting for some more info which messages to send, and how often ;-)
Post by iconPost by GeGaX | 2020-06-02 | 06:15:03
I'm not a fan of info redundancies ...
• RMC => 300 sec
• VTG + MWV => 1sec
= RMC + VTG + MWV at 300sec

Perhaps a method should be explored
• GGL => 300 sec
• VTG + MWV => 1sec
= GGL + VTG + MWV at 300sec

When we connect the router to the server, if the RMC (or GGL) sentence has already passed we will have to wait 5 min to have the GPS position, this is not necessarily an improvement
Post by iconPost by Hardtack | 2020-06-02 | 18:50:19
I just uploaded a new version.
This should fix the error reported by Ultimate Victory. Here is the link once more: http://bitweide.de/vrdashboard/VRDashboard.zip

GNRMC and INMWV are still send once per second. If this isn't creating any problems, I wouldn't change it.

Post by iconPost by GeGaX | 2020-06-02 | 20:21:43
Works fine for me 😉

PS: I never had the zero bug on macOS but I saw it on 2 Windows I thought it came from their installation or use ...
One had it systematically, the other had it and everything returned to normal afterwards.
Post by iconPost by Ultimate Victory | 2020-06-02 | 21:49:07
Thanks. Testing it now, I will report any issues or not :-) tomorrow
Post by iconPost by CoreTeam | 2020-06-03 | 06:33:24
Tested Version 3.9.3.2 during last 12hs with qtVlm in Mac with local NMEA and works perfectly well. No problem at all. Thanks for the script!
Post by iconPost by Big LuD | 2020-07-22 | 11:55:29
Hi CoreTeam

I am new in this forum, I read all this thread.

I try tu run NMEA output on Mac (os x 10.11).
I downloaded the last version of VR Dashboard, Python (last version).
I run the nmea_proxy.py, but I just have these lines :
"Listening on port 8081
Creating socket for race ID 457
"
I don't have the line "Accepted....", and then I did not succeed to get any NMEa info on Qtvlm...
Do you have any suggestion ?

Thanks a lot, to everybody on this forum !
L
Post by iconPost by Hardtack | 2020-07-22 | 20:32:50
I am neither CoreTeam, nor do I use Qtvlm, but I can assert that Dashboard and NMEA proxy are working fine.

Looking at the Qtvlm manual, it seems that you shoud go to
Configuration
->NMEA Connectios
->Incoming
->Network Sources
and enter 127.0.0.1 as the server address and 10457 for the port.


Post by iconPost by Big LuD | 2020-07-22 | 22:41:24
Hi
Thanks for your answer. I think the issue is that there is no "accepted socket" but I don't know why...
In qtvlm I know how to configure.

Let me know if anybody get an idea.
Best
L
Post by iconPost by Ultimate Victory | 2020-06-03 | 16:26:54
same here and no issues to report. Thx GeGaX and Cvetan.
EDIT : and thx Hardtack, sorry I miss the thread here
Post by iconPost by Hardtack | 2020-06-03 | 16:48:47
Okay, thanks for testing. I'll still cleanup a little and make a new public version soon.

Post by iconPost by GeGaX | 2020-06-03 | 18:58:38
Like CoreTeam, I launched a guest boat this morning with the active track to confirm that everything was fine.
I just came back and it is the case a very fluid trace without problem
Thanks, Cvetan and you, for this superb improvement 😉
Post by iconPost by GeGaX | 2020-06-05 | 19:54:13
Hi all 😉

@Cvetan:
• Loch / Speedo + Wind vane / Anemometer - Raymarine Wireless (ex MicroNet TackTick) => NMEA 0183
• Plotter - Garmin => NMEA 2000
• AIS - Weatherdock => NMEA 2000
• Pilot - NKE => NMEA 0183

All centralized on a Miniplex 3WI - N2K - ShipModul

Some like to mix brands and protocols ...

=> https://www.youtube.com/watch?v=gEfEIqGBv0Q
Post by iconPost by Hardtack | 2020-06-06 | 14:39:48
NMEA output is now included in the Chrome web store version (3.9.4).
You may want to disable the local version and enable the web store version again. You can continue to use the nmea proxy from the local version. It is also available for download here: http://bitweide.de/vrdashboard/nmea_proxy.py
Post by iconPost by BooBill | 2020-06-06 | 15:34:14
Knots. When I was learning to sail I had to learn knots.

No one told me there would be math and coding on the final exam.
Post by iconPost by GeGaX | 2020-07-22 | 18:38:26
Hi all 😉,
@Hardtack:
Another sentence would be interesting (= APB).
When we put a Wpt, we can find it in the WS messages.
Interesting to visualize the drift (or not) of the boat.
=> https://www.gpsinformation.org/dale/nmea.htm#APB
Post by iconPost by Hardtack | 2020-07-22 | 20:27:53
Af far as i can see we don't have any of the information in APB except for the bearing/heading? And APB doesn't provide the waypoint location. Maybe you want WPL instead?
As for the drift, I think I can answer this: VR doesn't simulate drift.
Post by iconPost by GeGaX | 2020-07-22 | 23:16:34
I don't know where my head was when I wrote, I just said bullshit ...
It's the BWC sentence that would be interesting
https://gpsd.gitlab.io/gpsd/NMEA.html#_bwc_bearing_distance_to_waypoint_great_circle

For the drift, it was wrong too, it is with the programming that we could visualize it when the winds are not "consistent" (not the drift with current) but the programming does not produce a WS message ...

Post by iconPost by zezo | 2020-07-23 | 07:39:23
@Big LuD The reason there is no "Accepted" message is that nothing is trying to connect to the socket.

I'm not sure if current MacOS ships with telnet or netcat (nc), but you should be able to test the server with a simple tcp client like

nc localhost 10457
Post by iconPost by Big LuD | 2020-07-23 | 09:40:40
Thanks zezo
But it seems there is something connected to the socket cause I tested the server, and I got this :

GNRMC,093532,A,5253.0227,N,00601.1161,W,6.1,188.2,230720,,,A*74
$INMWV,035.61,T,09.77,N,A*04
$GNRMC,093532,A,5253.0227,N,00601.1161,W,6.1,188.2,230720,,,A*74
$INMWV,035.61,T,09.77,N,A*04
$GNRMC,093532,A,5253.0227,N,00601.1161,W,6.1,188.2,230720,,,A*74
$INMWV,035.61,T,09.77,N,A*04
$GNRMC,093532,A,5253.0227,N,00601.1161,W,6.1,188.2,230720,,,A*74
$INMWV,035.61,T,09.77,N,A*04
$GNRMC,093532,A,5253.0227,N,00601.1161,W,6.1,188.2,230720,,,A*74
$INMWV,035.61,T,09.77,N,A*04
... each second.

So why there is nothing connected to the socket ? weird

Post by iconPost by Hardtack | 2020-07-23 | 09:52:06
Your test client has successfully connected to the socket and is echoing the NMEA messages it receives from the NMEA proxy. In the NMEA proxy shell you should see an 'Accepted...' message now.

So the question is, why doesn't Qtvlm connect to the socket.

If the command line that Cvetan provided worked, but
nc 127.0.0.1 10457
doesn't work, then I think loopback is not configured properly
https://en.wikipedia.org/wiki/Localhost#Loopback


Post by iconPost by Big LuD | 2020-07-23 | 10:20:47
thx hardtack

Now I try to catch this on my phone, connected to the same network than the computer running VR dashboard, not easy...
Post by iconPost by Hardtack | 2020-07-23 | 11:17:13
I just noticed that nmea_proxy.py doesn't support multiple connection to a socket. I can change that, but for the moment please disconnect the client before connecting a new one on the same socket.

Post by iconPost by Big LuD | 2020-07-23 | 11:24:23
Yes, i noticed that, cause I switched beteween Qtvlm on Mac and Terminal for testing.
Do you have any idea to how I can access to this loopback from my smartphone android ?
Post by iconPost by Hardtack | 2020-07-23 | 11:42:01
Ah, good point. Localhost / 127.0.0.1 is local and can't be accessed over the network.
Your machine (where you run the proxy) should have an IP address. You need to replace 'localhost' with that address in nmea_proxy.py.
Post by iconPost by Big LuD | 2020-07-23 | 11:59:02
Yeaaah you're the master Hardtack !
Huge thanks for you and the team !!

;-)
Post by iconPost by Kwasi | 2020-12-07 | 22:46:44
Hi Big LuD,
can you explain in easy words me how you connected NMEA from the Crome Dashboard to qtVLM on a Mac?
Best regards, Nick
Post by iconPost by zezo | 2020-07-24 | 12:43:20
HOST = ''

should make the server listen to all local addresses - loopback, ethernet, whatever
Post by iconPost by Big LuD | 2020-07-23 | 10:11:45
@zezo
Ok, it works fine, with Qtvlm on Mac.
Now I try to catch the nmea tcp on my smartphone with Qtvlm onboard ;)
not easy ;)
Post by iconPost by gronux | 2020-08-11 | 05:27:12
Hi all,
telnet connection seem blocked
Post by iconPost by gronux | 2020-08-11 | 05:37:53
Trying 212.50.14.242...
telnet: Unable to connect to remote host: Connection refused

Post by iconPost by zezo | 2020-08-11 | 06:43:26
telnet zezo.org 8082
Trying 212.50.14.242...
Connected to zezo.org.
Escape character is '^]'.

Post by iconPost by gronux | 2020-08-11 | 10:10:38
Ok it's work
but telnet zezo.org 10437
Trying 212.50.14.242...
telnet: Unable to connect to remote host: Connection refused
Post by iconPost by Hardtack | 2020-08-11 | 11:37:24
Cvetan used his own server as the NMEA proxy in his original implementation, but when I built it into the Chrome store VRDashbaord version, we switched to a local NMEA proxy.

If there isn't a specific reason why you want Cvetans version, please use VRDashboard from the Chrome web store and follow the instructions from the manual:
https://bitweide.de/vrdashboard/manual.html
https://bitweide.de/vrdashboard/manual.html#nmea


Post by iconPost by gronux | 2020-08-12 | 07:34:58
it's work,
the problem was that I was using an old version of the zezo plugin
tks for help

Post by iconPost by Sunkist | 2021-03-02 | 18:33:04
I am totally not used to java or http interactions, just want to use java to connect MatLab to the dashboard to experiment with some routing. The problem ii encounter is that the first time I execute the code below I get the header and first NMEA message.
Afterwards it stays empty or transmits one row of 2s. After trying to read the dashboard code on github, and failed to find an answer. I hope I might get a hint of how to change to code :) thanks to anyone!

(happy to share my matlab code on github later .. trying to analyse the 31 GEFS ensembles to rate the quality of the GFS route, or to supply a cost map for GFS routing)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
import java.net.ServerSocket
import java.io.*

server_socket = [];
output_socket = [];

server_socket = ServerSocket(8081);
server_socket.setSoTimeout(5000);

output_socket = server_socket.accept;

inputstream = output_socket.getInputStream;

data_from_dash= [];
while inputstream.available >1

tmp= inputstream.read;
data_from_dash = [data_from_dash, tmp];

end

server_socket.close;
output_socket.close;

char(data_from_dash)


Post by iconPost by Hardtack | 2021-03-02 | 19:46:02
Did you try accepting the next request after you finished processing the first?
:^)

Post by iconPost by Sunkist | 2021-03-02 | 20:09:23
was trying:

output = PrintStream(output_socket.getOutputStream)

output.println('POST /nmea/441.1 HTTP/1.1');
output.println('Host: localhost:8081');
output.println();

but never managed to get the data
Post by iconPost by Hardtack | 2021-03-02 | 22:30:34
Sorry, this does not make any sense.
First decide if you want to run a HTTP server in Matlab and receive HTTP POST requests from Dashboard, or run a Telnet client in Matlab and receive plain NMEA messages from the nmea_proxy. Unless Matlab has builtin Socket support, do it in plain Java first, then hook up your Java program in Matlab. Try to find a tutorial - there are plenty out there, and Socket programming is a very popular subject.

Post by iconPost by BooBill | 2021-03-07 | 21:59:50
Tying myself in knots trying to get this to work. I started at the top of the thread and tried all the early methods. Host telnet zezo.org, port 10441. The NMEA output has some options, 8081, 2, ... Haven't figured out what that's used for.

Now, reading to the bottom you've got another solution that involves installing Python, but the instructions are only for Windows and Linux.

How would I do this on Mac OS?
Post by iconPost by Sunkist | 2021-03-08 | 13:29:23
The python script on my mac worked pretty much identical to Linux described above.

Though I opted against the python server, since I only need the NMEA position once every 10min-30min to validate my routing.

I love the dashboard hardtack and others wrote, great work, though I really do wish there would be a way to access all information displayed from an outside script ;)!
Post by iconPost by Hardtack | 2021-03-07 | 23:07:31
Yes, Cvetan implemented it first and he had the HTTP-to-Telnet server running at zezo.org. Later this was replaced by a Python script that runs locally on your machine. It spawns a HTTP server listening at port 8081 by default, and it forwards messages received from Dashboard to port 10xxx where xxx is the race number. The HTTP server is necessary because Chrome extensions can only send HTTP requests to a server. They can't act as a server or talk other protocols.

The HTTP port can be configured on both sides, because some users wanted to run multiple Dashboard/NMEA servers at once.

I don't have access to a Mac, so I can't provide instructions. Please have look at the docs for running Python on a Mac.


Post by iconPost by BooBill | 2021-03-08 | 17:12:34
Turns out macs come with Python pre-installed. However, looking at my binaries, the most recent might be v2.7. Although it has a file date of Sept 20, 2020.

Changed the command line instructions to just python, instead of python3, since it didn't recognize that.

Now getting,

$ python nmea_proxy.py --port 8081 --outport 10441
Traceback (most recent call last):
File "nmea_proxy.py", line 1, in <module>
import http.server
ImportError: No module named http.server

It's been 30 years since I've messed around with Unix shells, so please be easy on me ;)
Post by iconPost by Sunkist | 2021-03-08 | 18:41:42
do you have homebrew installed? In that case you should be able to quickly install python 3 with:
brew install python

Post by iconPost by BooBill | 2021-03-08 | 22:29:54
Whoo Hoo!

Creating socket for race ID 441
Accepted connection on port 10441

Thanks so much Sunkist and Michael! As always.


border
Topics list
Posts
border
5
border
border
Copyright 2009 by ZEZO.ORG. All Rights Reserved.