Beta Test / Technical

[CarCode]

Originally Posted by Hakan

Gerhard..
Agree to your point.
What about creating a patch to default them No - track?
Håkan

Insert the code between "#ifdef __WXOSX__" and "#endif" in function GetTargetColumnData() in file OCPNListCtrl.cpp to get a list like the attached image:

wxString OCPNListCtrl::GetTargetColumnData( AIS_Target_Data *pAISTarget, long column ) const
{
    wxString ret;

    if( pAISTarget ) {
        switch( column ){
            case tlTRK:
                if( pAISTarget->b_show_track )
                    ret = _("Yes");
                else
                    ret = _("No");
#ifdef __WXOSX__
                if( ( pAISTarget->Class == AIS_ATON ) || ( pAISTarget->Class == AIS_BASE )
                   || ( pAISTarget->Class == AIS_ARPA ) || pAISTarget->b_SarAircraftPosnReport)
                    ret = _("-");
#endif
                break;

Gerhard

[Hakan]

Gerhard..
OK - nice but a Q
- ATON and BASE are obvious, they don't move, but why no tracks for SAR Aircraft, nor ARPA?
Håkan

[Hakan]

Gerhard..
This may be enough, works in Win. (Why a "-" in OSX?)

 if( pAISTarget ) {
        switch( column ){
            case tlTRK:
                if ((pAISTarget->b_show_track) && !(pAISTarget->Class == AIS_ATON) && !(pAISTarget->Class == AIS_BASE) )
                    ret = _("Yes");
                else
                    ret = _("No");
                break;

Håkan

[jongough]

Sean,
I am getting errors running OCPN under linux which seems to be due to a change in glChartCanvas:OnSize
I have attached a screen shot of the assert. The code was changed a couple of days ago to add

#else
    // OnSize can be called with a different OpenGL context (when a plugin uses a different GL context).
    SetCurrent(*m_pcontext);

at line 910.
I get this error with all plugins disabled as well as enabled.

Jon

[CarCode]

Revert the commit e3f48200346d90f051b8daaf7e7e6d983d01814c from 8.12.2015 "Switch to own OpenGL context in OnSize()."
Line 910 in glChartCanvas.cpp

    // this is also necessary to update the context on some platforms
#if !wxCHECK_VERSION(3,0,0)    
    wxGLCanvas::OnSize( event );
+ #else
+    // OnSize can be called with a different OpenGL context (when a plugin uses a different GL context).
+    SetCurrent(*m_pcontext);
#endif
    
    /* expand opengl widget to fill viewport */

Gerhard

[svcattales]

I recently opened two way connections between OCPN 4.0.0 (Build 2015-01-08) and Simrad AP26 autopilot. (Win 8.1) I like the functionality of coupling OCPN to autopilot in following an active route or "navigate to here" functions. Recently, I was navigating along an active OCPN route with autopilot tracking the course. When I clicked the tools button in main menu, the AP LCD screen showed a big correction and shortly after a "lost nav data" error. Cat Tales had changed course and no longer tracked the route. I duplicated this error several times with the same results. When AP is steering by compass input, there is no problem.

I tried clicking on tools button first and then coupling AP to OCPN route. The tools window stayed open and there was no error message this time, however when I clicked the X to close tools window, the AP showed a brief error message, but started following the route again shortly after.

Three pics show AP26 LCD screen: normal route tracking mode; initial deviation from track; and AP error message.

[transmitterdan]

What hardware interface are you using to get data from OpenCPN to the autopilot?

[transmitterdan]

I ran a short test tonight. When opening the options dialog there is a "brief" interruption in the pass-thru of data. Maybe the AP is upset that the data stream pauses for a short time. But I cannot figure out how it can make a random course change. If the AP is working right it should just stay on the same course until XTE data returns. I don't have a Simrad AP so don't have first hand knowledge but maybe it somehow changes mode during a brief interruption in XTE messages. Sorry I can't find a smoking gun.

Maybe knowing what interface you use I can find a better explanation.

[svcattales]

Originally Posted by transmitterdan

I ran a short test tonight. When opening the options dialog there is a "brief" interruption in the pass-thru of data. Maybe the AP is upset that the data stream pauses for a short time. But I cannot figure out how it can make a random course change. If the AP is working right it should just stay on the same course until XTE data returns. I don't have a Simrad AP so don't have first hand knowledge but maybe it somehow changes mode during a brief interruption in XTE messages. Sorry I can't find a smoking gun.

Maybe knowing what interface you use I can find a better explanation.

Thanks for the help.

The AP computer has 4 NEMA 0183 terminals (TX+, TX-, RX+, and RX-). I'm using a shielded cable from AP computer to an RS232 connector for connection to Dell laptop/OCPN. I tried to display the NEMA debug window when problem occurred, but it scrolled too fast and wouldn't stop when I clicked on the pause button.

I did give the AP some time to reacquire the route, but it didn't find it. The SIMRAD AP does have some built-in logic when it reaches a WP on an active route. If the next WP requires less than 10 degree course change, AP will automatically change course. If next WP is more than 10 degrees, AP will maintain original heading and sound alarm to press "nav" button to track to new WP. I would think this logic would allow it to reacquire the XTE sentence when it returns, but it's not doing it. Also, the route displayed on chart has not change during the error mode.

[transmitterdan]

Can you tell if the AP dropped out of "route" mode? Maybe it switched to another mode. But if it did that it would be abnormal behavior in my experience. But it would not be the first time I have heard of Simrad software having odd behavior.

[svcattales]

Originally Posted by transmitterdan

Can you tell if the AP dropped out of "route" mode? Maybe it switched to another mode. But if it did that it would be abnormal behavior in my experience. But it would not be the first time I have heard of Simrad software having odd behavior.

It appears to me that the AP sees a movement of the next WP location in the route and displays the correction needed on LCD window and starts to follow it. Within a few seconds (maybe 20-30) it realizes the WP is not valid and displays the "NAV data lost" message and sounds an audio alarm. I do believe AP drops out of route mode and seems to track the last correction prior to alarm. The last correction was not the same bearing as the displayed route. In other words, it chases a ghost input initially and then gives up and sounds the alarm. At that point I have to correct back to course, and push the "NAV" button to reengage the "route" mode.

Other than this "tools button" error, the route tracking has worked very well and makes smart course corrections. I really like the functionality.

[transmitterdan]

Originally Posted by svcattales

Other than this "tools button" error, the route tracking has worked very well and makes smart course corrections. I really like the functionality.

When will you be in a position to test again? I might be able to hook you up with a recent beta version so we could see if the problem is in that version. There have been some improvements in the options dialog that may have fixed this issue.

I doubt that OpenCPN is sending invalid waypoints. My guess is that the transmission of a XTE message was interrupted and the Simrad AP tried to use an unfinished message without checking the checksum. But that is just a guess.

[bcn]

And perhaps running VDR in addition to the debug window?

[svcattales]

Originally Posted by transmitterdan

When will you be in a position to test again? I might be able to hook you up with a recent beta version so we could see if the problem is in that version. There have been some improvements in the options dialog that may have fixed this issue.

I doubt that OpenCPN is sending invalid waypoints. My guess is that the transmission of a XTE message was interrupted and the Simrad AP tried to use an unfinished message without checking the checksum. But that is just a guess.

I plan to take another cruise starting around Jan 8th and would be happy to do more testing.

[transmitterdan]

Originally Posted by bcn

And perhaps running VDR in addition to the debug window?

I believe the VDR plugin will record all incoming NMEA data but not the specific outgoing messages to the AP. If I am wrong about that please correct my understanding.