Re: [gpsd-users] issues with u-blox m8l ADR

[Jorick Astrego]

Yo Gary!


On 04/25/2016 07:34 PM, Gary E. Miller wrote:
> Yo Jorick!
>
> On Mon, 25 Apr 2016 09:52:52 +0200
> Jorick Astrego <jorick@netbulae.eu> wrote:
>
>> On 04/24/2016 06:36 PM, Gary E. Miller wrote:
>>> Yo Jorick!
>>>
>>> On Sun, 24 Apr 2016 13:51:00 +0200
>>> Jorick Astrego <jorick@netbulae.eu> wrote:
>> Yo Gary! :-)
>>
>>>> The M8L supports the "UBX-NAV-HNR (0x01 0x37) High Rate Output of
>>>> PVT Solution", but gpsd only outputs at the normal rate. I could
>>>> add it to the code base but don't have a good feel on where all
>>>> the places are I need to make changes. I added the message to
>>>> driver_ubx.h but it feels a bit to easy ;-)
>>> Take a look at driver_ubx.c
>>>
>>> If you have the spec for that message send it to this list, plus
>>> some output from the GPS that has the message in it.  Say maybe a
>>> minute of raw data.
>> I have been looking at that and I guess I need to modify the
>> "ubx_msg_nav_sol" part?
> If the messages are very similar, then adding some compatibility to
> that function mmay be fine.  But if data is in different places in
> the packet best to make a copy for the new messages.
>   
The packets are not very similar as gpsd still uses the deprecated 
UBX-NAV-SOL, the UBX-NAV-HNR is looking more like UBX-NAV-PVT. So I'm 
currently working on getting UBX-NAV-PVT working as that is publicly 
documented (u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)_Public.pdf 
page 269).

Then it's easier to get the ADR specific code into place. I have another 
U-blox M8N without NDA and ADR so I could send you this raw data?
>> Sending the spec and raw output is a bit of a problem as we got the
>> ProtocolSpec under NDA from u-blox. I will first have to contact them
>> as it's not yet in the public domain :-(
> And any derived data may also be restricted.  We can't take a patch
> if it has any restrictions.  So beat on uBlox for us.
>   
Working on it ;-) Patches for UBX-NAV-PVT would be ok?
>>>> The second problem we have is that gpsd has the fix as 2D. This
>>>> way I cannot get the altitude that we need. 2D should be fine and
>>>> there is an elevation output in the tracklog .... but not in the
>>>> gpsd output. Any idea how I can get the elevation with the c++
>>>> client?
>>> If it is only a 2D fix, then you are not supposed to use the
>>> altitude.
>>>
>>> Some GPS output crazy data when the invalid flag is set.
>> It is a valid 3d fix in my opinion, I will try what happens after I
>> modify the code below to MODE_3D as we really need the altitude for
>> our project and from what I see from the elevation output it's nice
>> and stable and very much more correct then the normal 3D gps altitude.
> I have seen nice and stable altitude that is 2,000 feet wrong when the
> fix is 3D.  People risk their drones, and maybe their live, on knowing
> the altitude is rock solid.  You are certainly free to patch as you wish
> but gpsd would not accept any patch that passes altitude on 2D.
Ok no problem, we have a land based application with computer vision so 
can customize a bit for that.
>>      from "driver_ubx.h"
>>
>>        case UBX_MODE_GPSDR:    /* FIX-ME: DR-aided GPS may be valid 3D
>> */ session->newdata.mode = MODE_2D;
> If you can positively identify that condition, and back it up with
> uBlox documentation then we would love that patch.
I'll see what we can do.

>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>       gem@rellim.com  Tel:+1 541 382 8588





Met vriendelijke groet, With kind regards,

Jorick Astrego

Netbulae Virtualization Experts

---

Tel: 053 20 30 270	address@hidden	Staalsteden 4-3A	KvK 08198180
Fax: 053 20 30 271	www.netbulae.eu	7547 TA Enschede	BTW NL821234584B01

---