Open GeGaX opened 3 years ago
Hi Michael π,
I dug this limit story to 82 bytes.
This is actually a standard that says a maximum of 82 characters for one sentence. ("$", "*", 2 Hexadecimal characters included, <CR><LF>
excluded)
With this info it is possible to increase the precision of the transmitted VR values.
Add MilliSeconds, if VR changes anything in the Client <=> Server iterations, there will be no code changes as it will already be in place.
function formatHHMMSSSS(d) {
var s = ""
+ pad0(d.getUTCHours())
+ pad0(d.getUTCMinutes())
+ pad0(d.getUTCSeconds())
+ "."
+ pad0(d.getUTCMilliseconds(), 3);
return s;
}
6 decimals (fixed) for better precison.
function formatNMEALatLon(l, len)Β {
var deg = Math.trunc(l);
var min = pad0(((l - deg) * 60).toFixed(6));
var result = "" + deg + min;
return pad0(result, len);
}
Talker ID is GP not GN (I have never seen it, I will look more closely on my next installation). len Lat 9 => 11. len Lon 10 => 12. Replace roundTo() by .toFixed().
function formatGPRMC(m) {
var d = new Date(m.lastCalcDate);
var s = "GPRMC";
s += "," + formatHHMMSSSS(d) + ",A";
s += "," + formatNMEALatLon(Math.abs(m.pos.lat), 11);
s += "," + ((m.pos.lat < 0) ? "S":"N");
s += "," + formatNMEALatLon(Math.abs(m.pos.lon), 12);
s += "," + ((m.pos.lon < 0) ? "W":"E");
s += "," + m.speed.toFixed(5);
s += "," + m.heading.toFixed(5);
s += "," + formatDDMMYY(d);
s += ",,";
s += ",A";
return s;
}
Talker ID is II not IN. Remove pad0() and roundTo().
function formatIIMWV(m) {
var s = "IIMWV";
s += "," + (m.twa > 0) ? m.twa : m.twa + 360 + ",T";
s += "," + m.tws + ",N";
s += ",A"
return s;
}
Modify with right talker IDs
function sendNMEA() {
if (cbNMEAOutput.checked) {
races.forEach(function (r) {
if (r.curr) {
var rmc = formatGPRMC(r.curr);
var mwv = formatIIMWV(r.curr);
sendSentence(r.id, "$" + rmc + "*" + nmeaChecksum(rmc));
sendSentence(r.id, "$" + mwv + "*" + nmeaChecksum(mwv));
}
});
}
}
Here I saw things too easy ... Looks like there are at least 3 sentences ($WPL, $RMB & $RTE). I will log the sentences on a real installation then I will come back to you π
Thanks GeGaX! Please note, I removed the dev branch and created a new NMEAdev branch. Please use the NMEAdev branch for pull requests regarding NMEA improvements.
Hi Michael π, Ok I send a PR on NMEAdev branch tonight.
PR is merged in branch NMEAdev.
I also uploaded a zip file for testing the NMEA branch here. If you load it as an unpacked version it should identify as chrome-extension://ibdlpmbafnbppnfphmgjldnabjgioali/. The map should work. Please let me know if this is not the case. I'd like to test new stuff before releasing and I'm looking for an easy way.
Ok, can I distribute this version in my team? It will be tested on multiple routers, I am running with the modified official on which I no longer have the card (surely a restriction of the GMaps key, I suppose)
Yes, please distribute and test! Too bad the extension ID is not stable. If you need the map to work, please send me the IDs and I'll add them to the API key.
We will validate the NMEA, don't worry about it π I would see for the ID but with the DevVersion it should do it I don't look at it every day π
Do not use the NMEAdev version, a router is not functioning correctly (the NMEAparser I think), I will correct that Not all routers have to comply with the standard ...
I found the error, it's my fault a problem of managing zeros ... I correct tonight and send a PR for fix
Send PR to fix error in formatNMEALatLon()
Hi,
Talker ID is GP not GN (I have never seen it, I will look more closely on my next installation).
Talker ID is II not IN.
In fact it can be everything, in reality, it's brand related, II is used by Raymarine, IN by garmin...
Only satellite positionning system (global, not GPS) is not brand related, it start by a constellation code GN is for GNSS, GP is for GPS, GA for galileo, GB for beidu, ...
More informations here : https://gpsd.gitlab.io/gpsd/NMEA.html#_talker_ids
I merged Antoine's PR and uploaded the new version here. I'll test the NMEA branch a litte soon - maybe this year, maybe next year ;-) but I'm not a power user and I'd like to hear your comments if the branch is good to merge into master.
I test it tomorrow π
Hi Michael π
Happy new year 2021π
The archive above is not correct, it contains the error in formatNMEALatLon (, 9
is missing) and Antoine's sentences are not present.
A suggestion: could the NMEA merge be done in 2 steps? My improvements on the accuracy of the values ββare working correctly none of my team has complained of any errors. For me they can be put in the official version. Antoine's improvements are for a single router and fix a bug of this one. It would be wise to wait for a feedback from the developer of W4D to know if he intends to correct this bug or not.
@amoutiers : This is not to bother you but the redundancy of information in NMEA0183 is really not great, in my work (in real life) often (since the question does not arise with the NMEA2000) we avoid as much as possible this redundancy by removing sentences from the devices to be sure to avoid risks of collisions and saturation of the bus.
Hi Romain, there seems to be caching issue at my provider - the ZIP file was served even when I stopped my Webserver. I uploaded the file with a different name. Please try again: http://bitweide.de/vrdashboard/NMEAdev2.zip It still contains Antoine's PR. If that is really just a workaround for a bug in W4D I agree we should remove it.
Oh, and Happy new year everyone :-)
Hi Michael and Romain,
I don't think there's a problem with the sentenses, even if I don't work on boat, I've setup numbers of Garmin/B&G/Raymarine nmea. The real problem is when you have 2 hardwares sources for the same data, like a standalone GPS and your DSC VHF sending GPS data too, or 2 wind sensors, etc
But there, the data source where just the same, cause they have the same source, It's just multiples sentences with the same data. Not different source with different data.
A real exemple my Furuno GP32 is sending lat/lon 3 times with RMC, GLL and GGA, and I never got any problem with that. And Furuno GP32 is/was widely used on boat/race boat.
On my boat, I just got far more sentences than the 4 sentences sended by VRDashboard. And there's not any kind of data collision in our case, because, there's only 1 sender.
We are sending 21 bit each second the limit is 4800/38400. And that's for real copper wire nema, on wireless or ethernet, the limit is your network bandwith.
My 2 cents ;-)
Happy new year ! Antoine
Hi Antoine & Michael π, @amoutiers Do you have any news from the developer of W4D? I don't have the App handy but I would like to see something (that I don't see in the doc and I don't know if it is up to date) Can you send me a screenshot of NMEA Settings / NMEA In please ? Thanks π
Hi,
I've asked him on November 9, and he reply on real boat we get AWA/AWS. I think he will never fix that.
Here is some screenshots
Thanks for the screens π
It's not very cool of him because he does not respect the standard ...
Can you try something if you have the time ?
In dashboard.js, keep your sentence VWR
but put VHW
in comment and on W4D activate "STW Γ partir du SOG".
You will recover the boat speed and I would like to know if the COG is mapped to HDG if the info is not present (On B&G plotters, I sometimes activate this when the pilot's compass is faulty in troubleshooting)
I would like to know if TWA and TWS is calculated correctly or not.
If this is not the case I will send him an email, because this option can be practical in real life (and also for you in virtual).
I think i'll work, I've used it this option this summer, my paddle wheel speed sensor was dead. I'll try this evening
For the standard I agree with you, I think when you support a sentense, you must support all variations of this sentense, that's not the case here.
For heading (to get laylines) the VHW in true mode does not work... but HDT (which is only true) works. That's a strange behaviour.
This is not the first time that there are NMEA issues with W4D, I have already reported issues to him, twice, for the pilot and the AIS ...
I've reported some too. One was a feature of nema, you can send two time the same sentence in a raw with differents fields to avoid the 82 chars limit. That must compute. My Wifi gateway do that when processing Seatalk data (without option to avoid it) He never want to add that feature. I've bought a seatalk to nema converter to plug to the wifi gateway :-(
He's not very receptive as dev ... You should have chosen another Nav App ... like TZ iBoat (but not very receptive too) / AvalonOffshore (they are very attentive) And iNavx has not been as good since its takeover, I no longer recommend it to my clients.
I probably switch to another app a day. I've seen very strange things in the routing algorithm, like when descending the North Atlantic, the straight line (red boat) is better than the routed route (blue boat) ...
The W4D routing algorithm is not efficient, that of AvalonOffshore is much better π
@GeGaX, can you make a test for me in Avalon ?
I'm going to ask the dev and I'll keep you posted π
Ok, I'll prepare some grib files and polar to test, we perhaps can continue by email (more private) mine is amoutiers@me.com
Hi @mak08 and @GeGaX,
As suggested by Romain, I've remove VHW sentence, that is not needed (W4D has an option to get STW from SOG). Added HDT which is the Heading True, reported by VR to enable Laylines. PR is #41
Have a nice day
Okay, thanks! If there are no objections I'll merge everything into master soon. I made a mistake myself, started some refactoring but did it on the NMEA branch instead of master. I'll roll that back first.
What kind of refactoring ?
Hi Michael & Antoine π The more precise NMEA sentences the efficiency on β’ QtVlm β’ OpenCPN β’ AvalonVirtual β’ W4D I no longer test on MaxSea TZ, Adrena and SimSail because I exploded my Windows VM following a bad manipulation and not on SailGrib because I do not have any terminal under Android ...
@amoutiers I'll move a bunch of auxiliary function to a module. I'll also move the NMEA functions to a separate module.
@GeGaX thanks for all the testing!
Great idea for the NMEA sentences. More the code is splitted into diffrent files, more it's easy to maintain.
I've do not get much work on the VueJS approch I've told you in November, but try the hot reload it seems to work if the dahsboad has a devtools page. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Extending_the_developer_tools
VG has taken priority in the last couple of days :-) but I finished the refactoring now. Could somebody check if it still works as expected? Then I'll merge into master and publish the new version. Also, could you remind me of the NMEA-related changes that were made? I think we
Hi Michael π, I would like to suggest several points about NMEA:
β’ Send the HDG, TWA, TWS & SPD in raw VR values ( without roundTo() ) in sentences $INRMC & $INMWV. It works for me, on QtVlm and on another router. (If it works on these two, I think it works for all real routers). If the sentence does not exceed 82 bytes, it is valid.
β’ Send the NMEA sentence $INWPL (= Waypoints)
The projection could be dotted to visualize that it is a Wpt.