Skip to content
This repository was archived by the owner on Apr 13, 2021. It is now read-only.

WIP: Add Iono correction #686

Closed
wants to merge 29 commits into from
Closed

WIP: Add Iono correction #686

wants to merge 29 commits into from

Conversation

dt-unikie
Copy link

This adds iono correction.
Note, iono parameter decoder should be merged first https://github.com/swift-nav/libswiftnav-private/pull/8

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/890/

@ljbade
Copy link
Contributor

ljbade commented May 19, 2016

Not sure how far away the nav DB stuff is.

But in the meantime a static variable in pvt.c with appropriate mutex would be good enough to allow testing the ionosphere correction.

@dt-unikie
Copy link
Author

@ljbade yes, since NDB not merged yet I use store/read API in new file iono.c, by analogy to l2c capability.
My concern about at what stage I should add iono correction?
The idea is to add the correction to pseudorange into calc_navigation_measurement. Once we've got decoded parameters and had a fix we can calculate ionosphere delay using calc_ionosphere() and subtract it from pseudorange. What do you think?

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/891/

@ljbade
Copy link
Contributor

ljbade commented May 19, 2016

@dt-exafore Yeah there is a non raw pseudorange and carrierphase field of navigation_measurement (however before #651 the current carrierphase field is actually the "raw" value).

The non-raw field is for use with PVT calculations and includes other corrections such as the satellite clock error. The raw field is for RTK and should be left as is.

I can see two possible places to apply the correction either calc_navigation_measurement or calc_PVT (in pvt.c).

I think the best choice will be wherever it is easiest to pass in the prior PVT position solution which will be needed as input into the tropo and iono model.

@dt-unikie
Copy link
Author

dt-unikie commented May 23, 2016

@ljbade Could you please check the output of calc_ionosphere function I have using latest changes?
I'm not sure they are correct.
INFO Iono correction for channel 0: 8658123314.92751121520996093750 m
INFO Iono correction for channel 1: 8913394006.64842605590820312500 m
INFO Iono correction for channel 2: 8111396194.80219936370849609375 m
INFO Iono correction for channel 3: 5395831060.94595336914062500000 m

My expectation was about 30-40 meters.

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/914/

@ljbade
Copy link
Contributor

ljbade commented May 23, 2016

@dt-exafore that seems way too high, what are the alpha/beta parameter values?

{
assert(ch_id < NUM_TRACKER_CHANNELS);
assert(params != NULL);
memcpy(&iono_params[ch_id], params, sizeof(ionosphere_t));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will need a mutex to prevent store and read functions being called at same time.

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/915/

double az, el, iono_correction;
/* read iono parameters for the tracking channel if available */
if (gps_iono_params_read(&iono_params)) {
wgsecef2azel(nav_meas[i].sat_pos, position_solution.pos_ecef,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use nav_meas_tdcp

@dt-unikie
Copy link
Author

Latest tests results
INFO Iono correction for channel 0: 4.6536859986637741926074341
INFO Iono correction for channel 1: 3.1751344664971745679338255
INFO Iono correction for channel 2: 4.3321395864821621302098720
INFO Iono correction for channel 3: 4.7696433655641463644769829

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/922/

@dt-unikie
Copy link
Author

@nsirola, please also review.

@@ -491,8 +491,7 @@ static void solution_thread(void *arg)
/* correct carrier phase */
cp_correction = iono_correction * (GPS_L1_HZ + nav_meas_tdcp[i].doppler)
/ GPS_C;
log_info("CP corr %u: %30.20f", i, cp_correction);
nav_meas_tdcp[i].carrier_phase += cp_correction;
nav_meas_tdcp[i].carrier_phase -= cp_correction;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would also be wise to add a comment that the sign here is opposite to normal due to Piksi's unusual sign convention on carrier phase.

In case this confuses anyone.

@nsirola
Copy link

nsirola commented May 24, 2016

Looks good to me.

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/926/

@dt-unikie
Copy link
Author

Measurements during tests:
INFO Channel 0: IONO 5.71110030471377339012, TROPO 11.68359588241024660249
INFO Channel 1: IONO 5.84155407125674130953, TROPO 5.00802388949610044477
INFO Channel 2: IONO 5.48495403509538625997, TROPO 5.92363907484279472726
INFO Channel 3: IONO 6.58029111723088178110, TROPO 6.05548545450361253017

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/927/

@ljbade
Copy link
Contributor

ljbade commented May 24, 2016

When L2C tracking is completed, the iono corrections will need to be adjusted for the different carrier frequencies.

There is a formula to convert from the L1 Klobuchar correction, to any other frequency:
image
(from http://www.navipedia.net/index.php/Klobuchar_Ionospheric_Model)

Also the carrier phase adjustments will need to use the carrier frequency of each signal.

/* calculate tropo correction */
tropo_correction = calc_troposphere(&nav_meas_tdcp[i].tot,
position_solution.pos_llh[0],
position_solution.pos_llh[2],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should also be a note that we are currently using the ellipsoidal height as an approximation to the orthometric (or geoid) height due to lack of a geoid model.

@ljbade
Copy link
Contributor

ljbade commented May 24, 2016

Having some compile problems. The PR needs to be rebased on master. Also libswiftnav submodule needs to updated.

ionosphere_t iono_params;
double az, el, iono_correction, tropo_correction, cp_correction;
/* read iono parameters for the tracking channel if available */
if (gps_iono_params_read(&iono_params)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check should only wrap calc_ionosphere as calc_troposphere does not need the iono params.

Pasi Miettinen and others added 24 commits June 15, 2016 13:45
@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/1066/

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/1067/

@swiftnav-jenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
http://zazu.ci.swiftnav.com/job/piksi_firmware_Pull_Requests/1070/

@rge-exafore
Copy link
Contributor

moved to private (https://github.com/swift-nav/piksi_firmware_private/pull/16) and closed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants