Skip to content

Commit

Permalink
Add reference to Navitec paper
Browse files Browse the repository at this point in the history
  • Loading branch information
carlesfernandez committed Sep 10, 2016
1 parent b9bf4f7 commit 152ebc8
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion _geniuss-place/01-design-forces.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ S.M.A.R.T. is an acronym mentioned for the first time in 1981[^Doran81]

Hence, KPIs are not universal but based on the very single project, product or service in which they are going to be applied. This page suggests a wide list of indicators derived from a list of Design Forces, defined below, to be considered when assessing the quality of a software-defined GNSS receiver. Its degree of _S.M.A.R.T.-ness_ in every particular context may vary.

The design of a GNSS software-defined receiver needs to resolve some design forces that could appear as antithetical, (_e.g._, portability _vs._ efficiency, openness _vs._ marketable product), and a "sweet spot" must be identified according to the targeted user and application. Hereafter, we identify 16 dimensions in which the performance and features of a software-defined GNSS receiver can be evaluated. Click on their names to see a discussion of the concept and some possible metrics, indicators and check points:
The design of a GNSS software-defined receiver needs to resolve some design forces that could appear as antithetical, (_e.g._, portability _vs._ efficiency, openness _vs._ marketable product), and a "sweet spot" must be identified according to the targeted user and application. Hereafter, we identify 16 dimensions in which the performance and features of a software-defined GNSS receiver can be evaluated[^Fernandez16]. Click on their names to see a discussion of the concept and some possible metrics, indicators and check points:


<html> <body> <table> <tr> <td id="forcetable">
Expand All @@ -46,6 +46,8 @@ The design of a GNSS software-defined receiver needs to resolve some design forc

## References

[^Fernandez16]: C. Fern&aacute;ndez-Prades, J. Arribas, P. Closas, _Assessment of software-defined GNSS receivers_, accepted at [Navitec 2016](http://esaconferencebureau.com/2016-events/16c10/){:target="_blank"}, to be held at ESA-ESTEC, Noordwijk, The Netherlands, 14-16 Dec. 2016.

[^Teasley95]: J. B. S. Teasley, [_Summary of the initial GPS Test Standards Document: ION STD-101_](https://www.ion.org/publications/abstract.cfm?articleID=2506){:target="_blank"}, in Proc. of 8th International Technical Meeting of the Satellite Division of The Institute of Navigation, Palm Springs, CA, Sep. 1995, pp. 1645–1653.

[^ION97]: Institute of Navigation, _ION STD 101 recommended test procedures for GPS receivers_. Revision C, Manassas, VA, 1997.
Expand Down

0 comments on commit 152ebc8

Please sign in to comment.