[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)
From: |
Florian Kiera |
Subject: |
Re: [Question] gpsd, ntrip & C94-M8P (u-Blox) |
Date: |
Wed, 13 May 2020 12:26:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
Hey Gary!
Am 12.05.20 um 20:07 schrieb Gary E. Miller:
Yo Florian!
On Tue, 12 May 2020 11:06:35 +0200
Florian Kiera<address@hidden> wrote:
I am using gpsd to receive all informations from the rover and
check the gps_data_t => status (github: gps_fix_t.status).
No one receives all the informamtion.
All necessary informations at the very least.
Whatever that is...
Long/Lat/Alt/Status
ubxtool -p STATUS -p CONFIG -P XX
And I should have added "-v 2", but I can decode by hand.
Sorry
base_conf.txt->output of the ubxtool on my base
For some reason it is NAKing some things:
UBX-ACK-NAK:
NAK to Class x06 (CFG) ID x3b (PM2)
UBX-ACK-NAK:
NAK to Class x06 (CFG) ID x86 (PMS)
You have a time-only fix, but you are not surveyed-in:
UBX-NAV-SVIN:
version 0 reserved1[0 0 0] iTOW 204030000 dur 0
meanX 0 meanY 0 meanZ 0
meanXHP 0 meanYHP 0 meanZHP 0 reserved2 0 meanAcc 0
obs 0 valid 0 active 0
Everything got wiped :/
Your USB is blocking RTCM3 out. Are you getting RTCM3 from another port??
Nope, all through USB.
UBX-CFG-PRT:
PortID 3 (USB) reserved1 0 txReady 0x0
reserved2 [2256 9600]
inProtoMask 0x23 outProtoMask 0x1
reserved3 0 reserved4 0
inProtoMask (UBX NMEA RTCM3)
outProtoMask (UBX)
Do you intend to be moving base?
Stationary is intended. Moving base maybe for later date.
rover_conf.txt->output of the ubxtool on my rover
Looks good, except that it is 3D fix, not RTK fixed fix.
How are you getting the RTCM3 out of the base into the rover? The
base is blocking RTCM3 out on the USB port.
RTCM3 whereabouts: Before I used as mentioned in past emails the
RTKLib's str2str for Base->Caster and gpsd for Caster->Rover. No RTCM3
probably causes 3D fix?
Also ubxtool keeps resetting all my configurations anyways.
No. ubxtool does nothing that you do not explicitly tell it to do.
All data it sends to the receiver is displayed for you to double check.
gpsd without the "-b" will change things silently, but not ubxtool.
What are you sending to with ubxtool that is not doing what you think it
should?
As described below, I just used "gpsd -n /dev/ttyACM0" to get a running
gpsd and than used the ubxtool command "ubxtool -p STATUS -p CONFIG -P
20.30".
RTCM3 messages have been turned off and protocol out has been modified,
as well as the dynModel (I checked trivial settings through the u-center
before to compare it to ubxtool output. (protocol in/out, dynModel, rtcm
messages) I did not change anything in that process!)
You've got other
ideas that could improve it?
As in previous emails. Awaiting confirmation you fixed things as
previously recommended.
The only things you suggested me in view of the M8P's so far was
editing the dynModel (which was right all the time, might've mixed up
rover and base conf text files?) and using survey-in for the base,
which I applied before checking the gps_data_t.status.
Swapping the files would explain what I saw. But I do not see survey-in
in this set of files. And no RTCM3 out on USB is also a big problem.
That's what I saw too and make me believe ubxtool changed it because I
haven't touched a single setting until than (and it was streaming RTCM
before). I don't really know how to use the ubxtool to change the
settings of the M8P's either.
All this appeared after using "ubxtool -p STATUS -p CONFIG -P 20.30" and
I haven't changed any settings since the last time I sent them.
In gpsd versions before it changed the protocol output to UBX only, but
it let me change it back. That for I didn't paid more attention to it.
I've set them to work settings and reapplied dynModel (stationary),
RTCM3 messages (1005, 1077, 1087, 1230) for the base and its protocol
out (RTCM3 only), as well as the rover's dynModel (portable).
I will send the ubxtool output again.
I've got 2 rover outputs (one where I started gpsd with "gpsd -n
/dev/ttyACM0 -G ntrip://usr:pw@192.168.1.1:2101/BASIS", the other just
with "gpsd -n /dev/ttyACM0") since even parsing it with grep ended up in
a huge mess (a lot of messages regarding rtcm3) and the amount of
responded actual information didn't seemed that right. That for I send
both (the 2nd still should be able to ensure the configs are right, the
first might provide the status?)
Regards Florian
rover_gpsd_without_ntrip_ubxtool.txt
Description: Text document
rover_gpsd_while_ntrip_ubxtool.txt
Description: Text document
base_ubxtool.txt
Description: Text document
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Florian Kiera, 2020/05/04
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/04
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Florian Kiera, 2020/05/11
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Greg Troxel, 2020/05/11
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/11
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Florian Kiera, 2020/05/12
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/12
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox),
Florian Kiera <=
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/13
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Florian Kiera, 2020/05/14
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/14
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Florian Kiera, 2020/05/15
- Re: [Question] gpsd, ntrip & C94-M8P (u-Blox), Gary E. Miller, 2020/05/15