OpenCPN Version 2.1.0 Beta

[bdbcat]

Hello again....

Observant testers will note that I removed the local help files from the 527a Windows Beta. The old help system was hopelessly outdated, and worse than useless.

Here is another contribution opportunity....Hint, Hint....

Thanks
Dave

[cagney]

Dave

146. Linux users now have the most modern gpsd libary support. If the library is available, the config process will detect it and link appropriately. Please test if you can. I think we will have some version dependency problems to iron out.

527 Works as usual with the "old" gpsd, but I cannot get it to work with 2.94 as supplied in Ubuntu 10.4.
Xgps work just fine, but opencpn does not connect to gpsd.

Version with old gpsd compiled with

cmake -DUSE_GPSD=off

Version with new gpsd, compiled with plain "cmake".
Will try new version with "-DUSE_GPSD=off" later.

Thomas

[manimaul]

Originally Posted by bdbcat

Will...

I added code to try to catch this elusive fault.

Checkout CVS.
Rebuild.
Run without ddd (it gets in the way of my SIGSEGV catcher)

The fault will be caught if it happens, and log info produced. You may see a corrupted chart render, and that will be your clue to exit and look at the logfile. You should not see SIGSEGV, at least in this particular place....

No affect on Windows. Fault catcher is not compiled.

Good Luck
Dave

Watching the log:
Significant "hang time" but no segfault.

05:20:41 PM:    VP Final Check: Georeference Chart_Error_Factor on chart /home/will/Documents/Charts/USA_NOAA/BSB_USA/18424/18424_1.KAP is 0.999975
05:20:41 PM:    Trying again with internally calculated georef solution 
05:20:41 PM:    Result: OK, Internal georef solution used.
05:21:02 PM:    Caught SIGSEGV on GetandScaleData, Factor < 1
05:21:02 PM:    m_raster_scale_factor:  nan   source.width: -2147483648  dest.y: 0 dest.x: 826 dest.width: 614  dest.height: 133 
05:21:02 PM:    i: 826  j: 0 dest_stride: 1440  target_line_start: 0x6939450  target_data_x:  0x6939dfe  y_offset: 0
05:21:23 PM:    Caught SIGSEGV on GetandScaleData, Factor < 1
05:21:23 PM:    m_raster_scale_factor:  nan   source.width: -2147483648  dest.y: 0 dest.x: 845 dest.width: 595  dest.height: 222 
05:21:23 PM:    i: 845  j: 0 dest_stride: 1440  target_line_start: 0x591f1e0  target_data_x:  0x591fbc7  y_offset: 0
05:21:30 PM: LOGBOOK:  2010-05-29 00:21:30 UTC  DR Lat   47.76250 Lon -122.41980

[amadeus]

Originally Posted by cagney

Dave
527 Works as usual with the "old" gpsd, but I cannot get it to work with 2.94 as supplied in Ubuntu 10.4.
Xgps work just fine, but opencpn does not connect to gpsd.

Version with old gpsd compiled with
Version with new gpsd, compiled with plain "cmake".
Will try new version with "-DUSE_GPSD=off" later.

Thomas

I can confirm this. Tried several versions from gpsd 2.92 and up. None works but xgps works without problem

[bdbcat]

amadeus....

gps library works fine for me on Ubuntu 8.04 LTS
gpsd is version 2.94 on localhost, libgps is .so.17

I do see one small problem with speed and course, easily fixed. But position comes across just fine.

Do you get any response at all? Any message boxes?

Can you do ddd debug? If so, you may want to trace thru these functions in nmea.cpp:

void libgps_hook(struct gps_data_t *data, char *buf, size_t size)
{
#ifdef BUILD_WITH_LIBGPS
   ThreadPositionData.FixTime = (time_t)data->fix.time;
   ThreadPositionData.kLat = data->fix.latitude;
   ThreadPositionData.kLon = data->fix.longitude;
   ThreadPositionData.kCog = data->fix.track;
   ThreadPositionData.kSog = data->fix.speed;
#endif
}

void NMEAWindow::OnTimerLIBGPS(wxTimerEvent& event)
{
#ifdef BUILD_WITH_LIBGPS
      TimerLIBGPS.Stop();

      gps_set_raw_hook(m_gps_data, libgps_hook);
      if(gps_waiting(m_gps_data)) {
         gps_poll(m_gps_data);

         //    Signal the main program

         wxCommandEvent event( EVT_NMEA,  GetId() );
         event.SetEventObject( (wxObject *)this );
         event.SetExtraLong(EVT_NMEA_DIRECT);
         event.SetClientData(&ThreadPositionData);
         m_pParentEventHandler->AddPendingEvent(event);
      }

      TimerLIBGPS.Start(TIMER_LIBGPS_MSEC,wxTIMER_CONTINUOUS);
#endif
}

Thanks
Dave

[bruce in oz]

Originally Posted by amadeus

I can confirm this. Tried several versions from gpsd 2.92 and up. None works but xgps works without problem

oh well look at that, i've been happily mucking about for a few hours trying to get gpsd 2.92 (revision svn)/localhost working in ubuntu 10.04 lts/openCPN 524a, concur xgps works fine.

well i'm glad its not something i've messed up!!

cheers

[cagney]

Originally Posted by bdbcat

Hello again....

Observant testers will note that I removed the local help files from the 527a Windows Beta. The old help system was hopelessly outdated, and worse than useless.

Here is another contribution opportunity....Hint, Hint....

Thanks
Dave

I think that it would be smart to merge the "OpenCPN Manual" wiki with the helpfile. In the future the helpfile could just be a snapshot of this wiki. This could be as simple as getting the "Printer Friendly Version".
This has been discussed before, by idpnd, netsurfer and others.
Suggestion to Dave and Manimaul:
1 Take a snapshot of the wiki now. Declare this as documentation for 1.3.6 give it it's own page on the wiki.
2 Declare that the wiki now must change, to reflect the situation in 2.1.0. Ask all contributors to update their pieces and everyone to fill in the blanks.
3 Later when this, hopefully, is quickly done, use a snapshot as helpfile for 2.1.0

This way we can avoid overlapping work and have a (constantly) updated helpfile.

Thomas

[cagney]

Dave
More about gpsd 2.94.

Will try new version with "-DUSE_GPSD=off" later.

Made no difference.

Fiddled with nmea.cpp and ddd.
As far as i could deduce "BUILD_WITH_LIBGPS
" was not set.
Looking in CMakeCache.txt

GPS_INCLUDE_DIR:PATH GPS_INCLUDE_DIR_NOT_FOUND

Looking for gps.h, I gather. This header was not installed.

$sudo apt-get install libgps-dev

took care of this.
I also noticed that

GPS_LIBRARY:FILEPATH = /usr/lib/libgps.so

this link dosen't exist on Ubuntu 10.4 so I did

$sudo ln -s /usr/lib/libgps.so.19.0.0 /usr/lib/libgps.so

for good measure.


And ...now comes the fun part, testing with OpenCPN after a recompile.
Surprisingly there is a new member in the "NMEA Data Source" list called "Network LIBGPS".(NETWORK GPSD is still a choice)
Choosing this option, red turned to green for the gps indicator, but everything else went to pots: No chart, black screen, speed = nan kts, course = nan deg.
Crash when trying to reload the chart database.

Later restarting without ddd, I get a more normal display with an active gps. Trying to center on own ship, brings up a message box saying: Call to gps_open failed'S:localhost. Clicking "OK" brought back a red gps indicator.
Trying a new restart resulted in a crash instead of a message box.

I hope this helps!

Thomas

[cagney]

Trying again, without changing any settings.
Using NMEA Data Source "Network LIBGPS".
The all black screen disappears after a few seconds, no crash, just working for a while, then the same OpenCPN Message as above. Loosing gps connection on clicking OK.
Restart bring up message box instantly.
Temporarily choosing "Network GPSD", and the again choosing "Network LIBGPS", brings back a working gps, for 6 - 8 minutes, then the message-box again.

Thomas

PS When using "Network LIBGPS". GPSD Data Server is stated as "S:localhost".

[bdbcat]

Hi guys....

New CVS available now, Build 529a Small changes, I hope.

1. cmake script: Relaxed dependencies on .debian package build..Needs test.

Will: Chart 18424 is a polyconic projection. Our logic was not ready for that. Fixed.

janp391: HDG message with no variation handled properly

Cagney: gps library produced NANs when it had invalid data. That propagated through to all position info, with predictable disastrous results. Easy fix. btw, I found the libgps/gpsd interaction to be touchy sometimes. Needed to restart gpsd on several occasions when errors occurred. Seems stable enough if opencpn acts like an honest citizen...

I think I will need to convert libgps to on-demand dynamic loading/linking. Here's why: If you (or I) build the debian release package with libgps enabled, then a user will need libgps in order to load opencpn. So, we would have to add gpsd to the dependency list. Not so good.... On the other hand, if we build debian package without libgps support, then no-one gets it, because opencpn won't know to load it. Also not good. Dynamic load/link seems to be the answer. This is my project for tonight.


btw, if someone could build a windows release .exe and make it available to janp391 for testing, it would be good. My wifi connection today is not good enough for a 6 MB setup upload. Sorry....


Thanks, all
Dave

[BluegillBoy]

"btw, if someone could build a windows release .exe and make it available to janp391 for testing, it would be good. My wifi connection today is not good enough for a 6 MB setup upload. Sorry...."

And if a windows exe gets made, I'd appreciate it as well for testing. cruising all weekend. lots of time.

thanks

[Viking Sailor]

Dave,

What do you use to package a windows release? I have NSIS but have not found a .nsi file anyplace.

Paul

[manimaul]

Are there any function that determine processor power in OpenCPN?

Reason:
Course up mode works quite a bit better for me if I turn up the refresh rate up to 250 in:

FrameCOGTimer.Start(g_COGAvgSec * 250, wxTIMER_CONTINUOUS);

Not sure how this would perform on weak processors though.

Also, perhaps we should "look ahead" in this mode by centering the chart every refresh 15% of the screen up the cog predictor line.

Will

[bdbcat]

Will...

What kind of a Cray processor are you running? COG-Up rotations every (15 * 250) msec, or about once every 4 seconds, is a huge processor load.... Also, we have had comments that updating this fast in real life will lead to "nervous chart syndrome", and may look a little twitchy.

Second point: Elaborate, please. I'm dense today.

Thanks
Dave

[bdbcat]

Viking Sailor....

I use Inno Setup Builder. The script is not on CVS. Any new effort here should focus on CPack.....

You can of course build a Release opencpn.exe with VS, and then simply drop the new .exe in Program Files/opencpn, or wherever.... It will use the existing data files.

Dave