OpenCPN Radar Overlay PlugIn

[cowelld]

That's an interesting concept. I've found that my SIMRAD NSS unit with MARPA generates both TLL and TTM sentences. I haven't found a better definition for them than the following:

TLL - Target latitude and longitude

1 2 3 4 5 6 7 8
| | | | | | | |
$--TLL,xx,llll.lll,a,yyyyy.yyy,a,c--c,hhmmss.ss,a,a*hh<CR><LF>

Field Number:
1) Target number 00 - 99
2) Latitude, N/S
3) Longitude, E/W
4) Target name
5) UTC of data
6) Target status(see note)
L = lost,tracked target has beenlost
Q = query,target in the process of acquisition
T = tracking
7) Reference target=R,null otherwise
8) Checksum

TTM - Tracked Target Message

11 13
1 2 3 4 5 6 7 8 9 10| 12| 14
| | | | | | | | | | | | | |
$--TTM,xx,x.x,x.x,a,x.x,x.x,a,x.x,x.x,a,c--c,a,a*hh<CR><LF>

Field Number:
1) Target Number
2) Target Distance
3) Bearing from own ship
4) Bearing Units
5) Target speed
6) Target Course
7) Course Units
8) Distance of closest-point-of-approach
9) Time until closest-point-of-approach "-" means increasing
10) "-" means increasing
11) Target name
12) Target Status
13) Reference Target
14) Checksum

I'll look into the potential to display that along with the AIS info. What you're asking is definitely doable.

[cowelld]

Hi Stefano,
I've seen some of the effects you mention. I did an upgrade to my radar software and wondered if SIM/LOW hasn't made some changes to their protocol. (That wouldn't be true if OpenBR still works.) The other possibility is that I changed the hardware connectors and am using a hub. I'm seeing odd packets so there may be something there. I'll do a WS capture for what's coming out of O and see if it's still valid.
I've also just re-aligned my whole system to a newer PC with better graphics so can see some of the other effects. I don't know if I can fix them though since I just copied what was done on Gradar albeit with some simplification. Kees V. has established a GitHub for the source which I'll be updating whenever possible. I'll see if it'll hold a binary dll as well.

[nohal]

Dave...
Github unfortunately deprecated binary file storage and it's not very good idea to store the build products in the git repository. I created https://sourceforge.net/projects/opencpnplugins/ to host the downloads of the plugins that I write myself or build for the platforms the authors don't have access to. No problem giving you rights to upload your DLLs there, just send me your SF login name, there's probably not much point in having more than one place to download the plugins from...

Pavel

[Darum10]

Hi Dave,
OpenCPN for your work on the computer and radar overlay everything great that I could read to this day.
Since I'm new to the forum but would like to try to make a contribution.
That means I want to test a system. Where can I get the latest beta version
a radar plugin loading.
I would like to create MiniPC only to the work on board. Question here to WIN XP or Win7 (without outside influence - WLAN and so on)
How is the application at Opcpn radar with Win7,,,, With the migration from XP to Windows 7 per-I with the Navtex other programs via USB adapter, I noticed problems.
I hope that the donations continue to be more.
Malls still thank you for your good work and keep it up
best Regards
Darum10 "Bel Ami"

[cowelld]

Hi all,
I've been working on adding the TTM and TLL MARPA NMEA0183 messages to the BR24radar plugin. I think they'd be better off as a NMEA schema addition but I can't figure out the coding under which that part of O works. Since the data will be displayed as AIS targets with the BR name it probably doesn't matter. I'll probably add DSC functionality as well since the process and results are comparable.
I need some TLL and TTM messages to use for testing. If anyone has a VDR listing with those messages then I'd appreciate a copy. Please send to daviddotcowellatymaildotcom.
Of note to all you radar fans (MARPALETs) there's a book at Google Books:
Radar and ARPA Manual: Radar and Target Tracking for Professional Mariners ...

By Alan Wall, A G Bole, W O Dineley

It's only $83 US but you get to peruse some of the content on line.

[Shipraiser]

Hi,

I've been following the development of OpenCPN for many years and I must say that the new possibiities of radar integration are very exciting. I have postponed buying a radar since I'm not interested in MFDs, and finally we are starting to see alternatives. I'm going to buy a Simrad 4G and start testing....

Some things in this thread that I want to comment on;

1. The Navico BR24/3G/4G radars all share the same basic protocol, and can be supported with the same plugin. The 4G has additional features like dual range, 48RPM that must be sniffed using a NSE,NSO or Zeus MFD, but basic features are exactly the same. See also
http://www.simrad-yachting.com/Root/...0224-001_w.pdf

2. As this matures, it would be beneficial to split radar functionality into 2 different plugins. One that handles all drawing of radar data, plotting of Marpa targets, target correlation, heading correction etc. And another which is the actual "driver" for a specific radar hardware. In this way all radars would look the same in the software, and it wouldn't be necessary to keep updating several plugins to add new radar/chart functionality. It should be established a standardized internal radar protocol so that for every new radar someone wants to add, only the translation from a manufacturer-specific protocol into this generic protocol is needed, not a duplicate of the rest of the code.

3. Don't underestimate the need for fast and accurate heading. COG will be useless in all but the most optimal conditions and is IMO to dangerous to use for radar correlation. A good 10Hz rate-gyro, solid state gyro-compensated fluxgate compass is a must. Really fast boats should consider a GPS compass for usable radar overlay.

To enable those who not yet have a suitable heading sensor to still use the radar display it would be good to implement also a traditional radar screen without chart overlay using head-up/relative motion, and split the screen with a normal chart view on the side. This is much better than an overlay that stops working when you slow down, sail, or turn fast.


4. Please don't mix (M)ARPA and AIS targets. They are very different and should be handled separately. AIS has positive identification, but relatively slow update rate (especially Class B), while radar targets have very fast update rate, but uncertain identification. Target correlation between these two (getting AIS identity on ARPA targets) is NOT trivial even for the big ECDIS systems and must be done very carefully, if at all.

Radar targets are represented by circles, tracked targets with vectors from this circle. AIS targets are triangles. It would be great if OCPN could move towards a IHO S52-compliant symbology for all the presentation, Own ship, Arpa, AIS, routes, marks etc.



BR,

/Marcus

[dave777]

Originally Posted by Shipraiser

2. As this matures, it would be beneficial to split radar functionality into 2 different plugins. One that handles all drawing of radar data, plotting of Marpa targets, target correlation, heading correction etc. And another which is the actual "driver" for a specific radar hardware. In this way all radars would look the same in the software, and it wouldn't be necessary to keep updating several plugins to add new radar/chart functionality. It should be established a standardized internal radar protocol so that for every new radar someone wants to add, only the translation from a manufacturer-specific protocol into this generic protocol is needed, not a duplicate of the rest of the code./Marcus

Brilliant!

Originally Posted by Shipraiser

4. Please don't mix (M)ARPA and AIS targets. They are very different and should be handled separately. AIS has positive identification, but relatively slow update rate (especially Class B), while radar targets have very fast update rate, but uncertain identification. Target correlation between these two (getting AIS identity on ARPA targets) is NOT trivial even for the big ECDIS systems and must be done very carefully, if at all.

/Marcus

Hadn't thought of that, it's a good point.

[Darum10]

: Thumb: Super .. Finally, the right idea, a radar image separated from everything else.
Better than an imperfect overlay is always a program is safe if a failure happens

[cowelld]

Hi Marcus,
You seem to have more radar experience than I. There is good logic in having a common "skin" for the radar plugins but I don't really know what would be the advantage. It's not like someone will have multiple radar types at the same time (not in my financial bracket at least). I don't mean to be snide there but I'm not a good enough programmer to do that sort of thing. O has recently started using "Styles" which shows that it's getting more complex and the software shows it. I am not a programmer by vocation but just pick up whatever I need to do the most simple of tasks.
If you go to the BR24 plugin and do the "standalone" operation you get a simple PPI or HSI type display without the range rings, North up or even EBL, and without the chartplotter overlay. One of my attempts is to plagiarize the AISRadar olugin which IS exactly the old style of radar display. The current problem is that BR uses OpenGL (from Gradar and Dave Register) while AISRadar uses wxWidgets (from Johan van der Sman) and I'm not good enough of a programmer to get the two to work together. Somebody probably has the skills to do that in a few hours but for me it'll be a while.
AISradar plugin gives you a radar image with the standard triangle icons. Regular AIS is a part of O that gives the same icons on the chart display. My concept is to give both AIS displays a faked NMEA message that they would display rather than have a whole new layer of software that essentially duplicates that same function. Thanks for pointing out the differences in the icons. I think it would be easier to have the AIS section add a correct icon to represent the faked radar targets. I was going to use a type B AIS message 18 to transmit the data with a "RADAR TARGET" name and illegal MMSI. Both are displayed when you click on an AIS icon. I have to check to see what the software validates for display though since the only data available is via MARPA TLL and TTM NMEA sentences coming from you MFD. I don't think I can make a system that will generate targets although there's another Forum member who is attempting the same.
It's been a struggle but an enjoyable one. I will probably develop some programming skills doing all this but afterwards will forget them. Heaven help someone down the road who might ask me to explain what I did.

[nohal]

Dave...
Let's just teach OpenCPN display TLL and TTM - It's IMHO not a good idea at all to try to emulate it with AIS messages as it would decrease the clarity of the code... It will not be a big task. If you or someone else could record me a piece of NMEA stream with the whole target lifecycle, it would help as there are no radars where I am and will be sitting for the next couple of months...

Pavel

[rgleason]

I agree with Pavel, ...fake mmsi! Clever ideas for a hack, but such hacking should be put to better purpose so we end up with radar plugins that we can depend on! Pavel's offer is generous. Thank you.

[dave777]

Lowrance / Simrad / Navico are given an open source toolkit so their data can be shared. I'm not sure about radar specifically, but thought you all should know about this. Also, I'm not sure if it is tied somehow to their specific wifi router. They claim "open source" and that they'd also promote third parties apps.

GoFree (click on link for the toolkit)

By using the Lowrance WIFI-1 to create a powerful data bridge, the HDS system data can be shared via open source protocol to a range of third party PC and Mac navigational software and iOS apps. Open source protocol means app developers anywhere of any skill level can access the system data for display for FREE. Professional app developers have access to a GoFree development toolkit that allows for greater control of system data. Open source protocol adds up to an endless stream of boating applications. If you create an app that enhances the HDS Gen2 or HDS Gen2 Touch experience Lowrance will help you promote it.

NOte: I haven't downloaded the toolkit, but their release sounds promising.

[rgleason]

From GoFree Link above:

TheSimradGoFree-Tier 1
data networking standard is an open protocol designed to allow mobile
devices (tablets, smartphones and other wifi enabled devices) to display and process selectednavigation and instrument datafrom theSimradnetwork.In order to accessGoFree data, you need a Simradmarine network equipped with at least oneGoFree enabled Multifunction Display and a GoFree WIFIwireless access point.

Appears to require one Multifunction Display.

Tier 2 appears to detail how to get data in and out.

[dave777]

Originally Posted by rgleason

From GoFree Link above:

TheSimradGoFree-Tier 1
data networking standard is an open protocol designed to allow mobile
devices (tablets, smartphones and other wifi enabled devices) to display and process selectednavigation and instrument datafrom theSimradnetwork.In order to accessGoFree data, you need a Simradmarine network equipped with at least oneGoFree enabled Multifunction Display and a GoFree WIFIwireless access point.

Appears to require one Multifunction Display.

Tier 2 appears to detail how to get data in and out.

It would be much better if they shared data straight from the radar. The PC can't act as a backup to the MFD if the MFD goes out.

At least it is a step in the right direction, shows it's possible. It may also illuminate on their protocol.

Thinking out loud here ... they would likely prefer to lock in at least one MFD sale with their radar sales. Maybe they see this as a way to slow the inevitable.

And I'm not getting how it would require their specific wireless router.

[rgleason]

Rational, thoughtful. We will see. Thanks for your observations.