Open jiargei opened 10 months ago
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
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
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)
Thanks for the explanation. Still no output of SSR on Ntrip. PEA connects to the Caster but it is not sending any data.
Could anyone provide an working example on Real-Time CORS-RTCM-MSM Input and Real-TIME SSR output?
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
could you please add some steps how to run pea using rt_ppp_example.yaml. Step by step please.
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
Expected behavior As soon as Output will be generated, PEA throws an Error:
Configuration files
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):