Pluggin tracker?

[rgleason]

Would the mmsi Buddy features that Hakan implemented in O help? Thanks.

[nkiesel]

Originally Posted by rgleason

Would the mmsi Buddy features that Hakan implemented in O help? Thanks.

Good question. I will look into this.

[pa36651]

There are several stable telephone apps available developed for OpenGTS project. They send GPRMC. Would it be suitable that the server recieving and storing the data also write/publish all incomming GPRMC data with addition of boat name/GUID?
As simple as example below?
$GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,1 30998,011.3,E*62,boatname

[bcn]

Take a look at SignalK perhaps.

SK data come with source (=the MMSI or an identifier valid for SK) and the time stamp (complete one).

How to get this track data (series of positions) into OCPN is the main question.

Are arbitrary targets or objects interesting for OCPN? A Chart plotter and navigator..
(And I understand the idea of this thread - this is central for racing knowing what the competitors are doing).

So should this plug-in deliver an overlay perhaps? Like Draw or Radar.
Are there interactions required with the OCPN data objects - requests or interactions via the plug-in interface?

[nkiesel]

Originally Posted by bcn

Take a look at SignalK perhaps.

SK data come with source (=the MMSI or an identifier valid for SK) and the time stamp (complete one).

How to get this track data (series of positions) into OCPN is the main question.

Are arbitrary targets or objects interesting for OCPN? A Chart plotter and navigator..
(And I understand the idea of this thread - this is central for racing knowing what the competitors are doing).

So should this plug-in deliver an overlay perhaps? Like Draw or Radar.
Are there interactions required with the OCPN data objects - requests or interactions via the plug-in interface?

I still think that the correct "internal" representation of this data in OCPN is a "track": a sequence of positions with a timestamp (including date). Thus, all the data input (be it from AIS, from web sites, from CSV files received via email, from SK) should be converted into that format. This data conversion is actually (at least for me) the simpler part. What is more tricky is the mgmt and "nice" presentation:
- tracks should have a boat icon, and data (boat name etc) on mouse-over)
- grouping of tracks (divisions in a race)
- configuring data sources: looks like a sibling to "data connections" in my mind (defining sources, enable/disable, schedules, ...)

[nohal]

Originally Posted by pa36651

As simple as example below?
$GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,1 30998,011.3,E*62,boatname

Please, please, please, don't even try something like this.

RMC is a standardized NMEA sentence, there is no room for "improvements" in the format - no NMEA parser will ever implement your additions if it's author is sane.

That number 62 after '*' is a checksum of the sentence, after the checksum comes a newline. This is also defined in the standard, you can't simply add more fields there. And just by accident, the checksum also serves a purpose of checking integrity of the data received.

There really are many better options to do this correctly, just pick some from Norbert's list.

Pavel

[nkiesel]

Originally Posted by nohal

Please, please, please, don't even try something like this.

RMC is a standardized NMEA sentence, there is no room for "improvements" in the format - no NMEA parser will ever implement your additions if it's author is sane.

That number 62 after '*' is a checksum of the sentence, after the checksum comes a newline. This is also defined in the standard, you can't simply add more fields there. And just by accident, the checksum also serves a purpose of checking integrity of the data received.

There really are many better options to do this correctly, just pick some from Norbert's list.

Pavel

Yeah, looked at this but does not seem a good option because it does not have a "source" indicator (MMSI or boat name) in it, and no means to make it a 2nd sentence in a chain.

Current status: I have a simple "mouse rollover" for tracks (stealing from code that did this for routes). I will now add some parsing of tracking data to my plugin.

[nkiesel]

I need some design help.

I want to add "data sources" for tracking, initially using the yellowBrick web links like http://yb.tl/fastnet2015-expedition.txt and http://yb.tl/fastnet2015-boatids.txt.

My first idea was to add a new type "Web" to the Connections tab of options, allowing to select a protocol (e.g "YellowBrick"), a label (e.g. "fastnet2015" from above), and a reload frequency (dropdown containing "30 min", "1 hour", "4 hours"). Other protocols (e.g. Excel spreadsheets used by Vendee Globe) would be added later.

I have that basically working. However, this "Connections" is not a perfect fit because it's really a "NMEA connections" dialog right now.

So now I'm thinking if I should not better add a new tab named "Fleet" to the "Ships" options. I might get away with supporting just a single fleet (or is there really any need to track more than one fleet at a time)?

Yet another possibility would be to add a new standalone window. One advantage is that this could be encapsulated in a plugin instead of adding to core OCPN.

Recommendations?

[pa36651]

If you ask me....

• keep O as clean as possible => use plugin.
• tracking of one fleet only is enough.

[rgleason]

I"d like to keep track of two fleets, but one would be a great start. A plugin would be fine, but the ais functions are built in. However jon gough has developed a good api standard for messaging between plugins like ODraw and Watchdog and Weather_routing which involves adding the message format too the core OpenCpn. See his writeup of this Api in the Developer Manual - guidelines.
I think your plugin might use the same format with an extended sentence to add days. I don't know if you would then have to reinterpret for the opencpn ais module when displaying...

[rgleason]

I guess the reinterpret to use the AIS functions wouldn't work as Pavel points out the format is rigorous.

[nohal]

Norbert...
All this belongs to a plugin, don't touch the standard connections settings, please. It is already complex enough and will get more with SignalK support soon.
The plugins can add own tabs into the toolbox. For an example look at the chart downloader.

Pavel

[pa36651]

Originally Posted by transmitterdan

pa,

You can look at my AIS converter Python script. It creates the proper NMEA data that OpenCPN requires. Look on github.com/transmitterdan

I have looked into the script. If I understood correctly, I make on the webserver from the GPRMC data a textfile similar to the samples on Github. When the textfile is run by the Python script it convert text to AIS-data and make data available on internet via TCP or UDP, ready to be shown in OpenCPN.
Q. If MMSI-ID is missing, and only ship-ID is available, will O still show the AIS ship?
Q. Can the Python script be converted to php?

[Hakan]

Dan..
Many thanks for your "AISconverter" function. You've saved me from "reinventing the wheel". For my radar ARPA simulation tests I needed a function to have AIS targets running beside my ship. (We're testing a method to not draw an ARPA target where an AIS is already present.) Now I use my "send_NMEA_COM app to produce a text file for your Python app. Thanks to your code it works great. It's some bite tricks to produce the AVDM message.
If you by a change would be into your AISconverter code again and get an idea to add ships name I would very much appreciate to be noted by for example a @Hakansv tag on the commit. (I've not yet been into Python coding. For me it's full time to learn some C++. )
Again - Thanks (This is issued as well)
Håkan

[transmitterdan]

Hakan,

I think the ship name is already passed to OpenCPN. If you don't have a real MMSI then you can make a unique one from a hash of the ship name I guess.

Send me a text file of your sample and I will test it.

My next change will be to allow the AIS converter to accept input from STDIN so it can be used as a filter. Then it would be a simple matter to pipe from one program into the converter thus no need for an intermediate file and it would run in real time then. I just did not need that capability when first created.