Error sending SSR to NtripCaster about ginan

[polytopes-design]

Hello jiargei,
The configuration you have has a fatal_message_level set somewhere. If that level is exceeded the pea will exit (and Seg fault apparently). Removing this config will allow the pea to continue through errors.

The error seems to be due to a downloading stream rather than an uploading stream, please check all of your usernames, passwords, http/https and ports. Sometimes a stream will drop and reconnect, depending on latency and internet connections.

Otherwise, check that mongo is enabled, and output_ssr_precursors is enabled

Also, you may have fixed this already, but the messages to be output require a udi to be filled in for each message type. eg

            url: "BCEP00ISG0"
            messages:
                rtcm_1042:
                    udi:        10

[jiargei]

Dear @polytopes-design !

Thank you for your answer! Yes, i fixed the udi and updated the mongo and fatal_message_level values. Still, no output.

I'm not sure about the solution either. I have AMBIGUITY, REC_POS, TROP, IONO, CLOCK values in the Network TRACE but the bias value for each satellite in Mongo is zero {"Bias": 0}.

Furthermore, i do not understand the ambiguity values the look too small. Since one L1 or L2 wave is arround 0.2 meters and a distance of 29e6 meters the ambiguity value should be arround 125e6. Right now I see float values < 100. Is there any scaling or are these relative ambiguities to a certain level?

kind regards, Jürgen

[polytopes-design]

Hi Jürgen,
There is a config that sets which bias value is output to mongo. code_bias_sources. Its default is PRECISE, which means from a bias file. Changing or that config to [KALMAN] should allow those values to be taken from the network filter.

It sounds like your network filter also does not have the CODE_BIAS state, as you've listed a lot of others but not that.
It can be configured similarly to the code_bias parts of the estimation_parameters section in theprocessing_network.yaml example file.

The ambiguity values are constant values of whole wavelengths that are remainder after all other modelled effects have been subtracted from the range equation, not the entire range.

If you have output_residual_chain enabled then you can see the computed measurement equation in the station trace files, something like 0 = - Phi + rho + Cdt_r - Cdt_s - E.dR_r - E.PCO_r + E.PCO_s + PCV_r + PCV_s - E.dT1 - E.dT2 - E.dT3 + rel1 + rel2 + sag + -0.162372.I + 1.456330.T + phi + 0.190294.N where the ambiguities here use the letter N

There will be a moderate update hopefully toward the end of the week, which may include better realtime/ssr operational capability. (Though it will require many configuration changes)

[jiargei]

Thanks for the explanation. Still no output of SSR on Ntrip. PEA connects to the Caster but it is not sending any data.

[jiargei]

Could anyone provide an working example on Real-Time CORS-RTCM-MSM Input and Real-TIME SSR output?

[polytopes-design]

Jiargei,
For real-time input example, please refer to the rt_ppp_example.yaml that was included in the recent V3.0.0 release on github.

I was able to get very basic SSR output working by adding this yaml to the outputs section of that file

outputs:
    streams:
        root_url: "http://<USER>:<PASS>@ntrip.test-data.gnss.ga.gov.au/"
        labels:
            - BCEP
        BCEP:
            url: "BCEP00ISG0"
            messages:
                rtcm_1060:
                    udi:        5

    encoded_rtcm:
        output:             true

    ssr_outputs:
        ephemeris_sources:  [broadcast]
        clock_sources:      [broadcast]

as well as adding output_ssr_precursors: true to the mongo section, mongo is required.

The messages that are sent can also be viewed in json format in the outputs dir.

{ "type" : "ssrEph", "Mountpoint" : "BCEP00ISG0", "MessageNumber" : 1060, "MessageType" : "GPS_SSR_COMB_CORR", "ReceivedSentTimeGPST" : "2024-02-07 14:26:25.1", "EpochTimeGPST" : "2024-02-07 14:26:25.0", "ReferenceTimeGPST" : "2024-02-07 14:26:27.5", "EpochTime1s" : 311185, "SSRUpdateIntervalSec" : 5.0, "SSRUpdateIntervalIndex" : 2, "MultipleMessageIndicator" : 1, "SatReferenceDatum" : 0, "IODSSR" : 1, "SSRProviderID" : 0, "SSRSolutionID" : 0, "Sat" : "G01", "IODE" : 60, "IODCRC" : -1, "DeltaRadial" : -0.0, "DeltaAlongTrack" : 0.0, "DeltaCrossTrack" : 0.0, "DotDeltaRadial" : 0.0, "DotDeltaAlongTrack" : 0.0, "DotDeltaCrossTrack" : 0.0 }
{ "type" : "ssrClk", "Mountpoint" : "BCEP00ISG0", "MessageNumber" : 1060, "MessageType" : "GPS_SSR_COMB_CORR", "ReceivedSentTimeGPST" : "2024-02-07 14:26:25.1", "EpochTimeGPST" : "2024-02-07 14:26:25.0", "ReferenceTimeGPST" : "2024-02-07 14:26:27.5", "EpochTime1s" : 311185, "SSRUpdateIntervalSec" : 5.0, "SSRUpdateIntervalIndex" : 2, "MultipleMessageIndicator" : 1, "SatReferenceDatum" : 0, "IODSSR" : 1, "SSRProviderID" : 0, "SSRSolutionID" : 0, "Sat" : "G01", "DeltaClockC0" : 0.0, "DeltaClockC1" : 0.0, "DeltaClockC2" : 0.0 }

In this case, the source of the corrections was broadcast ephemeris, so the corrections with respect to broadcast are all 0.0, but will be different when a different ephemeris_sources or clock_sources is used

[javadtaghia]

could you please add some steps how to run pea using rt_ppp_example.yaml. Step by step please.