On 30/12/12 10:06, bg@lysator.liu.se wrote:

In that case they are the first to do it to my knowledge.

None of the Motorola receivers did it as I recall it. Could be that the
price of the modules is now so low that the difference make sense.

Notice that producing higher navigational rate is easy if you have the
CPU power to do it, and todays receivers have higher CPU power than they
used to, so doing 10 Hz navigation rate isn't unfeasable, so it does not
need to be Kalman filter predictor results.

Cheers,
Magnus

and maybe that reflashing a 1uS nav receiver to have a 100nS timing
receiver is related only to firmware improvements. Accurate timing is
mandatory for accurate position/navigation. The CW12 timing receiver has a
position hold mode that can't be turned off but always gives the computed
position.

On Sun, Dec 30, 2012 at 12:50 PM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:

On 30/12/12 13:56, Azelio Boriani wrote:

Most probably. A possibility would be to have a bad running state, but
this should not be the case and then a firmware upgrade should be needed
anyway.

It would be interesting to see the release notes for the GPS receiver in
question, so that one could see if there was any major issue behind it.

Changed T-RAIM limit to prune out false-tickers more effectively?

It should be noted that a timing mode should be able to still produce
navigation solutions as a by-product, it's just that it is not allowed
to steer the time and "current" position of the receiver. Then again,
getting detailed pseudo-range information is even better if you want to
post-process.

I assume that carrier-phase smoothed code tracking is being used today,
rather than code tracking only. The new generation of receivers are much
more black box receivers compared to the traditional receivers.

Cheers,
Magnus

Hi

When asked about the difference, that's not what the people who wrote the code had to say about it….

Bob

On Dec 30, 2012, at 7:56 AM, Azelio Boriani azelio.boriani@screen.it wrote:

An update regarding the GPS module,
simply shielding it from air currents
improved the things:
http://www.flickr.com/photos/14336723@N08/8327229820/
At 48000s I swapped references, hence
the change in slope.

I think the poor receiver module
(Azelio, 20€, I think it can be
considered cheap :) is not to be blamed
too much, I mounted it raised  from the PCB,
and the only thermal contact were the few
pins used to connect to it, and it was
exposed to moving air.
But usually it will be sodered directly
on the PCB like an SMT component, and
enclosed into a box.

Il 2012-12-28 23:27 Fabio Eboli ha scritto:

Hi

If you go back far enough in the NIST papers done for the Frequency Control Symposium, you can find a number of them on GPS receivers. One that got a pretty full go through was the (now golden) Motorola timing receiver. They found a number of issues with it. The receiver did get better as the firmware was worked over.

Any receiver that has not been beat on for timing likely has issues. For what ever reason, the manufacturers of low cost modules don't have the time / equipment / money / interest / people / expertise  to really ring things out. Most firmware issues are found by customers. It is not uncommon to find that the firmware team has a fairly large wall covered with "fix requests". Which ones get worked on will always depend on the money behind the request. Timing is going to be pretty far down the list for most outfits….

Bob

On Dec 30, 2012, at 3:09 PM, Fabio Eboli fabioeb@quipo.it wrote: