Twocan - a new Plugin

[stevead]

Thanks Pavel,

I was actually thinking of replacing all of the epoch time bits of code with a single function call, so please don't take offence if I don't incorporate your PR. Several years ago when I initially started playing with the NMEA 2000 stuff I wanted to make it clear to myself or someone else reading the code that the NMEA 2000 time calcs are based on an epoch of 1-1-1970 rather than just blatantly relying on 0, which is appropriate for Unix like systems, but perhaps not others. (IIRC the Windows epoch is 1601 ?)

Manfred,

I've been replaying the log for quite some time with no errors, but it is quite possible the fault only occurs with live data from the NMEA 2000 network. The other things I can think of are:
On a Raspberry Pi, which ordinarily doesn't have a real time clock, the plugin could be performing an invalid date comparison (perhaps set the date/time correctly before starting OpenCPN),
or
Something incorrect with the NMEA 2000 heartbeat. (perhaps disable/enable heartbeats to narrow down the problem).

[nohal]

Steve...
No problem, decreasing the redundancy of the code will indeed be even better. FWIW the only spot where I actually did really get the invalid wxDateTime assert was one of the

tm += wxDateSpan::Days(daysSinceEpoch);

after the initialization while replaying the pcap sample included with the plugin. But all this code in wxWidgets is quite version, platform and locale dependent, so it may not be reproducible elsewhere where the timestamp parsed from the string actually by accident makes sense and equals to 0.

The log message formatting stuff causing the asserts addressed by the PR gets pretty annoying in the debug build as it makes the app segfault on shutdown probably as there is no usable GUI to display the asserts anymore when the threads are finished and destroyed.

And, fortunately, it seems that even on Windows at least the standard public time_t stuff behaves as expected (https://docs.microsoft.com/en-us/cpp...-time32-time64)

[stevead]

Thanks Pavel for the helpful info.

Re the timespan calls I think one instance of that is protected by

if ((TwoCanUtils::IsDataValid(daysSinceEpoch)) && (TwoCanUtils::IsDataValid(secondsSinceMidnight))) {
...

but the few others aren't. It wouldn't be too onerous to add the defensive checks on the other instances.

One dumb question, which also arose when Dave pointed out some uninitialized variable errors in the Engine Dashboard. I thought asserts were only raised in debug builds and were not raised on release builds so most users would never see them. Is my understanding incorrect ?

[nohal]

Originally Posted by stevead

Thanks Pavel for the helpful info.

Re the timespan calls I think one instance of that is protected by

if ((TwoCanUtils::IsDataValid(daysSinceEpoch)) && (TwoCanUtils::IsDataValid(secondsSinceMidnight))) {
...

but the few others aren't. It wouldn't be too onerous to add the defensive checks on the other instances.

The cause of the assert was the original value of tm, not the daysSinceEpoch, at least in this case.

One dumb question, which also arose when Dave pointed out some uninitialized variable errors in the Engine Dashboard. I thought asserts were only raised in debug builds and were not raised on release builds so most users would never see them. Is my understanding incorrect ?

The wx asserts support is always built in, even in release builds, unless you explicitly disable it by defining wxDEBUG_LEVEL as 0.
But in release builds, which are built with NDEBUG define, the asserts do not produce anything unless you explicitly turn it on by calling wxSet(Default)AssertHandler.

[Aldebaran17]

Originally Posted by stevead

Thanks Pavel,

Manfred,

I've been replaying the log for quite some time with no errors, but it is quite possible the fault only occurs with live data from the NMEA 2000 network. The other things I can think of are:
On a Raspberry Pi, which ordinarily doesn't have a real time clock, the plugin could be performing an invalid date comparison (perhaps set the date/time correctly before starting OpenCPN),
or
Something incorrect with the NMEA 2000 heartbeat. (perhaps disable/enable heartbeats to narrow down the problem).

Turned off active mode, same error.
Turned off AIS (the only source of time data in the NMEA network): same error.

The time of the Raspi is set via SignalK using AIS data. So, time is usually accurate when OpenCPN starts.

In one of my screen shots the dashboard was showing CPUTime, in others it shows GNSS time. Both are identical. Well, maybe there are off by a little bit actually, due to rounding errors, or inaccuracies of the CPU time, or delays of AIS time data processing. Could this be the reason? That would be tricky.

Best,

Manfred

[CarCode]

@Manfred
If you look for the point where the assert is triggered you see in file datatime.h at the shown position line 1886 this:

inline wxDateTime& wxDateTime::Subtract(const wxTimeSpan& diff)
{
wxASSERT_MSG( IsValid(), wxT("invalid wxDateTime"));

m_time -= diff.GetValue();

return *this;
}

As I understand there is somewhere in your Twocan Plugin a place where time data is subtracted from another time data with the wrong time format.
That does not mean you will perhaps have different times but it means there is a wrong format for the subtracting function.

[Aldebaran17]

Last update on the assert issue:

was using OpenCPN all day with TwoCan not activated, reading NMEA data via Signal-K connection, dashboard running, all good. @Steve: I know you do not like SignalK, but AIS data on the screen, my home port has a lot of commercial traffic, so it's better to see what is around the corner.

On quit (at that point instruments and AIS off already, no NMEA data available) the following error messages popped up:



Looks similar or related to the previous messages.

The backtrace info is this:

ASSERT INFO:
/usr/include/wx-3.0/wx/datetime.h(852): assert "IsValid() && dt.IsValid()" failed in operator<=(): invalid wxDateTime

BACKTRACE:
[1] wxDateTime:perator<=(wxDateTime const&) const
[2] ActiveTrack:oExtendDaily()
[3] MyFrame::TrackOff(bool)
[4] MyFrame::OnCloseWindow(wxCloseEvent&)
[5] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[6] wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&)
[7] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[8] wxEvtHandler::TryHereOnly(wxEvent&)
[9] wxEvtHandler:oTryChain(wxEvent&)
[10] wxEvtHandler::ProcessEvent(wxEvent&)
[11] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[12] wxWindowBase::Close(bool)
[13] MyFrame::OnToolLeftClick(wxCommandEvent&)
[14] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[15] wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&)
[16] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[17] wxEvtHandler::TryHereOnly(wxEvent&)
[18] wxEvtHandler:oTryChain(wxEvent&)
[19] wxEvtHandler::ProcessEvent(wxEvent&)
[20] wxWindowBase::TryAfter(wxEvent&)
[21] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[22] wxMenuBase::SendEvent(int, int)


Manfred

[Aldebaran17]

I figured that the issue reported here is due to handling tracks when language is set to german. Not related to TwoCan. See new thread.

Manfred

[CarCode]

Maybe you should abandon using RaspPi? Seems not to be the best choice for OpenCPN.

[250224]

Maybe you should abandon using RaspPi? Seems not to be the best choice for OpenCPN.

bull$hit -- pls don't post such advices/claims if you clearly have no idea; it's unhelpful & misleading

[Aldebaran17]

Originally Posted by Aldebaran17

I figured that the issue reported here is due to handling tracks when language is set to german. Not related to TwoCan. See new thread.

Manfred

and fixed in the new version 5.6.2. as reported in the other thread dedicated to this issue.

Happily switching back to TwoCan.

Manfred

[stevead]

Thanks for the feedback.

Will hopefully get the next release out in a week or two (finger crossed).

[stevead]

Announcing the release of TwoCan Version 2.1.

Apologies for the delay, unfortunately travel restrictions brought about by the Covid pandemic separated me from my boat on which I performed much of my testing and from my Mac Mini. As many of you may know, a key change in the last OpenCPN release was the adoption of wxWidgets version 3.15 for Mac OsX and not having access to my Mac meant I couldn't build/test or release this new version until now.

This release contains a mix of bug fixes and new features.

Bug fixes.

1. NMEA 193 APB sentences were always sent irrespective of the settings due to a missing flag check.
2. Random fluctuation of depth values when converting NMEA 183 depth sentences to NMEA 2000 PGN 128267 Depth messages due to an incorrect PGN value.
3. PGN 127489 alternator potential was not being generated (no pun intended) due to an incorrect flag check.
4. Locale independent mechanism to parse NMEA 2000 dates. It was thought this was causing an assert problem, but actually might have been a red herring.
5. Fixed route and waypoint name parsing in PGN 130074.
6. Not really a fix, but for MacOSX, updated drivers for the Kvaser and Rusoku Toucan adapters using updated versions of the MacCan libraries developed by UV Software.

New features
Extending the conversion of PGN 130312 to support Exhaust Temperature. If the temperature source indicates exhaust temperature, it will generate the following NMEA 183 v4.11 XDR sentence

ERXDR,C, temperature value,C,EngineExhaust#n

where n indicates the engine instance number. This sentence can also be displayed in the recently release of Engine Dashboard v1.4.2.0.

Support for PGN 129808 Digital Selective Calling (DSC) messages. Bi-directional support between PGN 129808 messages and NMEA 183 DSC sentences. Hopefully this faithfully converts all DSC messages including DSC Expansion messages. It has been difficult to test as there are few (OK, none in my possesion) real life NMEA 2000 DSC Distress logs. Also support for PGN 129808 messages in the chartplotter I had access to was limited and I also believe it may erroneously parse PGN 129808 MMSI addresses.

Note that the current release of OpenCPN only supports a subset of NMEA 183 DSC sentences (Distress alerts & Position reports), although Hakan has coded some additions in preparation for a future release.
I must thank Richard from Seattle who kindly provided the initial DSC position report logs. I hope he has also received a firmware fix for his Icom AIS after we discovered a bug in its AIS AToN station name parsing!

Support for PGN 127233 Man Overboard Notifications. Bi directional support between PGN 127233 and NMEA 183 MOB sentences. This is one of those solutions looking for a problem. OpenCPN does not consume NMEA 183 MOB sentences, so the generation of a NMEA 183 MOB sentence is meaningless to OpenCPN.

Instead the the plugin drops a waypoint with the MOB symbol but without the normal OpenCPN MOB alert being generated. On the other side of the coin, the plugin does process the OpenCPN notification when the MOB button is pressed and generates the corresponding PGN 127233 message however I am not aware of any 3rd party chartplotters that support this PGN so this feature is totally untested! Perhaps this PGN may also be transmitted by those new-fangled personal MOB devices.

Support for PGN 130074 Route - Waypoint List. When this option is enabled, OpenCPN will create a waypoint on reception of a PGN 130074 message. For example B&G chartplotters have the option to transmit this PGN when a waypoint is created, thereby simultaneously creating the waypoint on OpenCPN. Unfortunately OpenCPN does not have a mechanism to notify a plugin that a waypoint has been created so the reverse cannot be performed. However stay tuned for a future post regarding TwoCan Toys.

Deprecation of TwoCan proprietary NMEA 183 XDR transducer names for PGN's 127488 (Engine Dynamic), 127489 (Engine Static) and 127505 (Fluid Levels) in favour of NMEA 183 v4.11 standard transducer names. These standard names been supported in the Engine Dashboard since version 1.4 and by most of the third party gateway vendors, Actisense, Shipmodul etc.

For the uber geeks, the ability for a plugin to compose and transmit a NMEA 2000 message onto the network. For example to set a Garmin GMI20 dislay into Red/Black night mode, send the following OpenCPN plugin message:
Message ID: "TWOCAN_TRANSMIT_FRAME"
Message Body (in JSON),

{
   "nmea2000":{
      "pgn":126720,
      "destination":255,
      "source":10,
      "dlc":11,
      "data":[
         229,
         152,
         222,
         5,
         5,
         5,
         0,
         0,
         13,
         0,
         3
      ]
   }
}

if you were to code this using wxJSON it would look something like this

// Snippet of wxJSON
wxString message_body;
wxJSONValue root;
wxJSONWriter writer;

root["nmea2000"]["pgn"] = 126720;
root["nmea2000"]["source"] = 1;
root["nmea2000"]["destination"] = 255;
root["nmea2000"]["priority"] = 7;
root["nmea2000"]["dlc"] = 14;
root["nmea2000"]["data"][0] = ; //0xE5 0x98 encodes as manufacturer code Garmin, Industry Code 4 (marine)
root["nmea2000"]["data"][1] = 0x98;
root["nmea2000"]["data"][2] = 0xDE;
root["nmea2000"]["data"][3] = 0x05;
root["nmea2000"]["data"][4] = 0x05;
root["nmea2000"]["data"][5] = 0x05;
root["nmea2000"]["data"][6] = 0x00;
root["nmea2000"]["data"][7] = 0x00;
root["nmea2000"]["data"][8] = 0x0D; // Colour Mode command
root["nmea2000"]["data"][9] = 0x00; 
root["nmea2000"]["data"][10] = mode; // 0-Day Full Colour, 1, Day High Contrast, 2-Night Full Colour, 3- Night Red/Black, 4-Night Green/Black

writer.Write(root, message_body);

As always please report any bugs to the forum or via email to twocanplugin at hotmail.com

[Aldebaran17]

Originally Posted by stevead

Announcing the release of TwoCan Version 2.1.

New features
Extending the conversion of PGN 130312 to support Exhaust Temperature. If the temperature source indicates exhaust temperature, it will generate the following NMEA 183 v4.11 XDR sentence

ERXDR,C, temperature value,C,EngineExhaust#n

where n indicates the engine instance number. This sentence can also be displayed in the recently release of Engine Dashboard v1.4.2.0.

Dear Steve,

test of Exhaust Temp was successful. Test performed on a RPi4, Buster, OpenCPN 5.6.2 and the newest versions of TwoCan and DashBoardEngine.

Thanks a lot,

Manfred

[stevead]

For users of the flatpak versions of OpenCPN, you need to give permission for OpenCPN to access the canbus in order for the TwoCan plugin to access the NMEA 2000 network.

By default, the flatpak sandbox does not permit access to the canbus. You will find an error message similar to the following in the opencpn logfile:

ERROR twocandevice.cpp:300 TwoCan Device, Error loading driver CAN0: 1680343040
ERROR twocanplugin.cpp:643 TwoCan Plugin,  TwoCan Device Initialize Error: 1680343040

which essentially means the plugin failed to open the canbus network socket.

Use the following command to grant access for OpenCPN to access the canbus:

flatpak override --user --allow=canbus org.opencpn.OpenCPN