Beta Test / Technical

[Hakan]

Hej
Could anyone tell why this text _("Marks") is not listed in the .pot file:

wxRect r3 = r1;
    if( m_bShowName ) {
        if( !m_pMarkFont ) {
            m_pMarkFont = FontMgr::Get().GetFont( _("Marks") );
            m_FontColor = FontMgr::Get().GetFontColor( _("Marks") );
            CalculateNameExtents();
        }

This Example comes from "RoutePoint.cpp" but there are more. I noticed this when I saw that "Marks" is present in the change font table but it's not translated.
First I thought I was on a far-fetched trace because the string where _( "Marks" ) instead of _("Marks") and I'm not quit aware of how wxWidget handle strings but it didn't helped. It's not copied into the pot.
Hints please
Håkan

[Hakan]

Originally Posted by Hakan

Hej
Could anyone tell why this text _("Marks") is not listed in the .pot file:
....This Example comes from "RoutePoint.cpp" ...

Well...Found it my self!
The file "RoutePoint.cpp" was for any reason not listed in "POTFILES.in" There may be more?. Will check
Håkan

[Hakan]

Any of our dear coders..
I'm playing to build a compass serving the HDM message. I'm sending it out on a com port(10) and can read it with other terminal windows but not in OCPN. The message seems fine reading it as text: "$HCHDM,225.5,M*29 " but O doesn't recognise it.
I'm trying to debug why not. But I'm not sure where in the code a com port message is treated for the first time it receives.
Please if someone can advice where I should look.
Thanks Håkan

[bdbcat]

Hakan...

Start looking around OCP_Datastreaminput_thread.cpp, line 597.

Then go to multiplexer.cpp, line 185

Good luck
Dave

[Hakan]

Thank you Dave..
Yeah I was there around but couldn't get a break to act. Strange....
Then I realized that my board (Arduino Uno) also received a RX-something when connected to OCPN? And was reset incessantly?? Then I made a virtual com port via VSPE and connected O to that. - Works!
My questions if you feel to discuss:
1. Is O sending anything to the port upon connection initialization? (There is no output stated for the port)
2. I'm not sure I got the "/r /n" correct in my message? See my screen capture. (The two ||)

[bdbcat]

Hakan...

1. O does not send anything to an input port on initialization. Just waiting for input.

2. crlf: Looks like there is a redundant set of crlf. No harm, really.

Good Luck
Dave

[Hakan]

Dave ..
I found some more for my Q #1 above.

--You are correct that the Arduino Uno is reset when the  DTR line is toggled.  
This makes programming an Arduino with the Arduino  IDE much easier since you no longer have to press the reset button  within a few seconds of hitting the upload button (the reset is now  triggered by the DTR line being toggled).  This allows the boot loader  to complete faster but causes trouble when using LabVIEW to connect to  the Arduino.--

So my board is reset whenever DTR is toggled. This is normally not a problem since most connections do this one time and then my pgm is running. This happens every time I connect a serial port to it. But-- OCPN seems to toggle DTR more then ones and continuously. Is there anything that gives you an idea for an explanation?

There is a hard way to solve this (using a capacitor) but I'm a bit curious why there is another behaviour when O connects than for other program?
Many thanks
Håkan

[bdbcat]

Hakan...

Is this windows or linux running O?

Dave

[Hakan]

Sorry--Always forget there is a another (better? world)
I'm on Win32-XP

[Hakan]

Hi - I'm out playing as usual
About Dashboard and the Compass instrument.
I've made me an electronic compass (the "Robot" stuff is nice!) for the moment sending HDM and HDG. (See pics.)
The OCPN "HDG Instrument" is fine and nicely updated but the Compass instrument is not. What I can see it's told to use HDT data input but no value is shown. I've tried to make HDT out of HDM using the now commented row in dashboard_pi.cpp (around row 600):

 else if( m_NMEA0183.LastSentenceIDReceived == _T("HDG") ) {
            if( m_NMEA0183.Parse() ) {
                if( mPriVar >= 2 ) {
                    mPriVar = 2;
                    if( m_NMEA0183.Hdg.MagneticVariationDirection == East ) mVar =
                            m_NMEA0183.Hdg.MagneticVariationDegrees;
                    else if( m_NMEA0183.Hdg.MagneticVariationDirection == West ) mVar =
                            -m_NMEA0183.Hdg.MagneticVariationDegrees;
                    SendSentenceToAllInstruments( OCPN_DBP_STC_HMV, mVar, _T("\u00B0") );
                }
                if( mPriHeadingM >= 1 ) {
                    mPriHeadingM = 1;
                    mHdm = m_NMEA0183.Hdg.MagneticSensorHeadingDegrees;
                    SendSentenceToAllInstruments( OCPN_DBP_STC_HDM, mHdm, _T("\u00B0") );
                    //SendSentenceToAllInstruments(OCPN_DBP_STC_HDT, mHdm + mVar, _T("\u00B0")); //<<<<<<<<<<This/Hakan
                }
                if( !wxIsNaN(m_NMEA0183.Hdg.MagneticSensorHeadingDegrees) )
                       mHDx_Watchdog = gps_watchdog_timeout_ticks;

But no success with that.
The funny thing is that looking in Debugger-NMEA Event the Hdt value is there. Obviously created of Hdm + mVar (See pic.)

Now I'm lost in the Dashboard source and my head is tired. Please if anyone has the patience to advice a hack to get a live Compass instrument. The HDM and the variation from WMM should in my opinion be enough!? And of course it should be nice to know if the shown value is "M" or "T". But basically the "M-(HDM)" itself would be fine for the compass instrument. That's what both my "normal" compass and the Simrad instrument shows?? (I've seen the "TODO" about a making this optional.)
Any viewpoints on this ?

Thanks Håkan

[bdbcat]

Hakan...

Is this issue really the same as FS#1310 : Use WMM for Variation to Calculate True Heading in Dashboard

Dave

[Hakan]

Dave..
Actually yes! That's the same thoughts. I didn't see that Flyspray before but your comment there is also an answer to my discussion here. So I was trying to fix a bug and not a hack then?

But still... What's your reason/opinion for showing the true(T) value instead of the (M) in the compass?
I can see the advantages of being spared from mental calculations. And I can surely learn to accept that my three compasses are showing different values. The physical(M), the Simrad(M) and OCPN(T). But then I think it's important that it's clearly displayed that the O compass shows the "T"-value?
Many thanks.../Håkan

[bdbcat]

Hakan...

You may be interested to try out the lastest github sources, addressing some of your concerns regarding True/Mag compass, etc..

Let me know how this goes for you, please.

Thanks
Dave

[Hakan]

Dave..
Of course I'll try and with pleasure.
I received a couple of errors during built. So I didn't succed to get cmake to release dashboard_pi.dll but VC10 did! The error logs are attached
I've installed my new compass in the boat so I'll take a ride there tomorrow to check out.
Håkan

[Hakan]

Dave...
Meanwhile I tested the VDR play including a VHW sentence with Mag_H but not True_H and the true heading was not created. See my capture:
But could it be that the build errors made the source not complete??

Håkan