Hardware:AGPS - Revision history

JOERG: chipset can't do high velocity GPS

2008-10-07T04:08:09Z

chipset can't do high velocity GPS

Kempelen: Category: -Hardware, (It's in sub 'GPS')

2008-09-15T20:29:05Z

Category: -Hardware, (It's in sub 'GPS')

Kempelen: Category: -Hardware, (It's in sub 'GPS')

2008-09-15T20:28:51Z

Category: -Hardware, (It's in sub 'GPS')

Kbjorgensen at 11:56, 4 September 2008

2008-09-04T11:56:47Z

Dolfje at 09:20, 19 August 2008

2008-08-19T09:20:11Z

MartinBudden at 17:48, 26 July 2008

2008-07-26T17:48:17Z

Mike1024: /* Q: Is an open-source GPS daemon able to be distributed by FIC? */

2008-07-19T17:25:30Z

‎Q: Is an open-source GPS daemon able to be distributed by FIC?

Abdel: typo

2008-07-14T13:51:38Z

typo

Abdel: WAAS, EGNOS, MSAS

2008-07-14T13:50:16Z

WAAS, EGNOS, MSAS

Abdel: correct almanac and ephemeris validity duration

2008-07-14T13:29:56Z

correct almanac and ephemeris validity duration

← Older revision		Revision as of 04:08, 7 October 2008
Line 102:		Line 102:

	The chipset is too dumb. It does not know the position or the velocity. This is only computed in the host CPU. --[[User:Speedevil\|Speedevil]] 06:17, 25 March 2007 (CEST)		The chipset is too dumb. It does not know the position or the velocity. This is only computed in the host CPU. --[[User:Speedevil\|Speedevil]] 06:17, 25 March 2007 (CEST)
		+
		+	The chipset has to be able to correlate signals in a much shorter time at high velocity. This can't be done by sw-driver. Even if you could post-process raw data in sw, it would never yield the up to date velocity and speed, and for DOD it's not critical if the device can tell where and how fast it was 30sec ago, as you can't guide missiles this way.
		+	Exactly that's why the chipset isn't restricted by this law - DOD regulations would never allow to sell "dangerous" hw that's "secured" by a security-by-obscurity-driver only. Otherwise atomic bombs would be free to sell, as long as you don't deliver the activation code ;-) <br>
		+	The whole crux around closed source drivers is same as it ever was: royalties and warranty. (even GSM fw is closed mainly due to warranty reasons)<br> --[[User:JOERG\|jOERG]] 06:00, 2008-10-07 (CEST)

← Older revision		Revision as of 20:29, 15 September 2008
Line 144:		Line 144:
	'''This is unlikely to be an issue in the GTA02''' as the GPS receiver module should take care of it. The GTA02 uses a [http://www.u-blox.com/products/atr0635.html ATR0635] and on page 9 of the datasheet (Table 3-1: Performance Specification) states the module is limited to "Altitude 18,000 m Velocity 515 m/s One of the limits may be exceeded but not both." - in other words, the chip solves the GPS equations, and if the user's speed and velocity exceed the ITER-imposed limits it will stop outputting a fix. The datasheet does not specify exactly how the chip will behave in this situation, but most likely the [http://www.gpsinformation.org/dale/nmea.htm#GGA serial NMEA data output] will change the 'fix quality' value to 'invalid' and zero or stop updating the other parameters in the NMEA data. The practical upshot of this is: The closed-source GPS module's software takes care of ITAR compliance. [[User:Mike1024\|Mike1024]] 17:25, 19 July 2008 (UTC)		'''This is unlikely to be an issue in the GTA02''' as the GPS receiver module should take care of it. The GTA02 uses a [http://www.u-blox.com/products/atr0635.html ATR0635] and on page 9 of the datasheet (Table 3-1: Performance Specification) states the module is limited to "Altitude 18,000 m Velocity 515 m/s One of the limits may be exceeded but not both." - in other words, the chip solves the GPS equations, and if the user's speed and velocity exceed the ITER-imposed limits it will stop outputting a fix. The datasheet does not specify exactly how the chip will behave in this situation, but most likely the [http://www.gpsinformation.org/dale/nmea.htm#GGA serial NMEA data output] will change the 'fix quality' value to 'invalid' and zero or stop updating the other parameters in the NMEA data. The practical upshot of this is: The closed-source GPS module's software takes care of ITAR compliance. [[User:Mike1024\|Mike1024]] 17:25, 19 July 2008 (UTC)

−	[[Category:~~Hardware~~]]	+	[[Category:GPS]]

← Older revision		Revision as of 20:28, 15 September 2008
Line 145:		Line 145:

	[[Category:Hardware]]		[[Category:Hardware]]
−	~~[[Category:GPS]]~~

← Older revision		Revision as of 11:56, 4 September 2008
Line 145:		Line 145:

	[[Category:Hardware]]		[[Category:Hardware]]
		+	[[Category:GPS]]

← Older revision		Revision as of 09:20, 19 August 2008
Line 145:		Line 145:

	[[Category:Hardware]]		[[Category:Hardware]]
−	~~[[Category:Chip\| ]]~~

@@ Line 144: / Line 144: @@
 '''This is unlikely to be an issue in the GTA02''' as the GPS receiver module should take care of it. The GTA02 uses a [http://www.u-blox.com/products/atr0635.html ATR0635] and on page 9 of the datasheet (Table 3-1: Performance Specification) states the module is limited to "Altitude 18,000 m Velocity 515 m/s One of the limits may be exceeded but not both." - in other words, the chip solves the GPS equations, and if the user's speed and velocity exceed the ITER-imposed limits it will stop outputting a fix. The datasheet does not specify exactly how the chip will behave in this situation, but most likely the [http://www.gpsinformation.org/dale/nmea.htm#GGA serial NMEA data output] will change the 'fix quality' value to 'invalid' and zero or stop updating the other parameters in the NMEA data. The practical upshot of this is: The closed-source GPS module's software takes care of ITAR compliance. [[User:Mike1024|Mike1024]] 17:25, 19 July 2008 (UTC)
-[[Category:Hardware ]]
+[[Category:Hardware]]
 [[Category:Chip| ]]

@@ Line 141: / Line 141: @@
 I would choose to implement "artificial" software design limits, i.e. choose data types/data rages that only allow for lets say 32'000 feet height or 512 knots per second. That would not break daily use (512 knots = 589 Miles or mach 0,8) and no "function" to circumvent the limits would be documented with the product or the product source. A "hacker" would be needed to change the source, recompile, relink and repackage it, not mentioning the possible breaking of some/all apps. Assuming that "designed for" does not mean you have to actively protect against missusage, like using a magic key in the bus protocol, you should be compliant to to the law if you keep the source code straight, i.e. do not point this out.
 --[[User:Memed|Memed]] 22:46, 2 February 2008 (CET)
 [[Category:Hardware ]]
 [[Category:Chip| ]]

@@ Line 63: / Line 63: @@
 * MSAS for India
-Thanks to a much better ionospheric model, an SBAS enabled GPS reciever will offer a much more accurate position than GPS in standalone mode (down to 1 meter accuracy). As with GPS, the GEO satellites have unique identifier called PRN or SVID. GPS satellites PRN are numbered from 1 to 50 (current maximum is 32) and GEO satellites start at PRN 120. The reception of SBAS messages requires that the device locks one of the GEO satellites. In theory it is possible to get those SBAS messages (i.e. in the internet as for Almanacs and Ephemeris using A-GPS) but this method is not standardized and the Neo Ublox AGPS is most certainly not able to work that way. If such a technique was implemented, it would enter the definition of A-GPS but A-GPS is not directly related to WAAS.
+Thanks to a much better ionospheric model, an SBAS enabled GPS receiver will offer a much more accurate position than GPS in standalone mode (down to 1 meter accuracy). As with GPS, the GEO satellites have unique identifier called PRN or SVID. GPS satellites PRN are numbered from 1 to 50 (current maximum is 32) and GEO satellites start at PRN 120. The reception of SBAS messages requires that the device locks one of the GEO satellites. In theory it is possible to get those SBAS messages (i.e. in the internet as for Almanacs and Ephemeris using A-GPS) but this method is not standardized and the Neo Ublox AGPS is most certainly not able to work that way. If such a technique was implemented, it would enter the definition of A-GPS but A-GPS is not directly related to WAAS.
 == Q: Is an open-source GPS daemon able to be distributed by FIC? ==

@@ Line 56: / Line 56: @@
 == Q: What is WAAS, can WAAS and A-GPS work together? ==
-A: [http://en.wikipedia.org/wiki/WAAS WAAS] is a recently-introduced technology that performs a similar role to DGPS - providing information that allows a receiver to calculate a more accurate position. It differs in that the correction signals are transmitted by other GPS satellites (in geostationary orbit rather than the normal 12-hour orbit), rather than by terrestrial radio stations.
+A: [http://en.wikipedia.org/wiki/WAAS WAAS] stands for Wide Area Augmentation system; it is the US implementation of a DGPS technique that works over continental wide areas: SBAS or Satellite Based Augmentation System.
+SBAS differs from local DGPS in that the correction signals are transmitted by other GPS-compatible geo-stationary satellites (nicked named GEO).
-(If you can answer the second part of the question, please edit this note. I don't know. [[User:Mmontour|Mmontour]] 17:08, 17 August 2007 (CEST))
+To date, there are three implementations of SBAS:
+* WAAS for the united states
 == Q: Is an open-source GPS daemon able to be distributed by FIC? ==

@@ Line 20: / Line 20: @@
 * ''ephemeris'' = precise position of satellites
-The almanac is broadcast in a loop of 12.5 minutes and valid for at least six weeks. The ephemeris is broadcast in a loop of 30 seconds and valid for ~2 hours.
+The almanac is broadcast in a loop of 12.5 minutes and nominally valid for a week but could in general be used for several weeks. The ephemeris is broadcast in a loop of 30 seconds and valid for 4 hours, 2h before and after the time of applicability.
 Receiver chipsets store this data in flash and load it from there onto the chip in order to _assist_ the hot or warm start.