[Gta04-owner] New hw-validation snapshot

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Nov 18 20:57:34 CET 2011


Hi,

Am 18.11.2011 um 14:16 schrieb Boudewijn:

> On Friday 18 November 2011 11:13:00 Christoph Mair wrote:
> > On Fri, Nov 18, 2011 at 11:08 AM, Neil Jerram <neil at ossau.homelinux.net> wrote:
> > > On 18.11.2011 09:35, Neil Jerram wrote:
> > >> On 17.11.2011 09:35, Christoph Mair wrote:
> > >>> Maybe its possible to boot use a initramfs to test the GPS reception.
> > >>> This would eliminate all activities on the mmc data lines.
> > >> 
> > >> I'm willing to try this, but I don't understand how to implement your
> > >> suggestion.  Could you provide more detailed guidance?  (Or just point
> > >> me to some existing reference.)
> > > 
> > > To be a bit more precise: I think I understand the idea of initramfs and
> > > how to create one, but
> > > 
> > > (1) I can't see (looking at boot.txt) how I can tell u-boot to tell Linux
> > > to use an initramfs
> > > 
> > > (2) I don't understand how this would eliminate MMC activity - because
> > > wouldn't the kernel and initramfs still be being loaded from the SD card?
> > >  (And I believe that MMC == SD, right?)
> > 
> > You're right. My thought was the following:
> > If the system is running from an initramfs the kernel won't touch the
> > SD card. If the rootfs is on the card it may uses it for whatever
> > reason (logging..).
> > 
> > Probably this could also be done with the u-boot test commands. If you
> > have access to the serial console, enter the u-boot command prompt and
> > type (from http://projects.goldelico.com/p/gta04-uboot/page/NewCommands)
> > $ gps init
> > $ gps on
> > $ gps echo
> > 
> > This dumps the raw GPS records to your serial terminal. If you get a
> > fix with this setup it could be possible that some other component
> > which is active when linux is running disturbs the gps reception (i.e.
> > mmc, display, ...)
>  
> It may be worth a go of course, but I think Nikolaus meant more in general that if there's a (hardware) problem with an easy workaround, that does not mean that the cause to the symptoms is easily identified.
> 
> In case of MMC: it's not only used for connecting SD/MMC cards, but for WIFI as well, isn't it? Of course the initramfs would have no need for WIFI either, and if ran from NAND it will exclude as many other factors as possible, but it's still prodding with a stick in the dark.
> 
> For wat it's worth, I just downloaded the new kernel and configs.. Who knows ;-)

I spent the afternoon comparing several of the prototype GTA04 boards
and a GTA02. Using an external antenna glued with tape to the window's
glass (it is a little too cold to open the window and place the antenna
under open sky).

WIth the GTA02 I did receive approx. 5-7 satellites. So no problem.

Except one observation: putting the Freerunner (not the external
antenna!) on the closed display lid of a switched off eeePC
dropped the number of satellites quite abruptly to 0. Picking up
the Freerunner and moving away approx. 30 cm made it receive
again. This is a strange effect I had not at all expected that putting
a metal plate under the Freerunner (with battery and closed) 
deteriorates the reception quality on an *external* antenna.

Now the GTA04 boards. They all appear to be quite deaf.
Independently of being powered from battery or from USB or both,
or having connected an internal, external antenna or both. And
no difference if we use the u-boot gps command or Linux.

After approx. 25 minutes one board (running Linux) did suddenly know the time.

Nov 18 18:52:27.411 cltest[723] NEMA: $GPRMC,002458.027,V,,,,,,,130806,,,N
Nov 18 18:52:28.348 cltest[723] NEMA: $GPGGA,185229.295,,,,,0,00,,,M,0.0,M,,0000
Nov 18 18:52:28.372 cltest[723] NEMA: $GPGSA,A,1,,,,,,,,,,,,,,,
Nov 18 18:52:28.418 cltest[723] NEMA: $GPRMC,185229.295,V,,,,,,,180806,,,N

And some seconds later it did know the date.

Nov 18 18:52:50.645 cltest[723] NEMA: $GPRMC,185251.295,V,,,,,,,180806,,,N
Nov 18 18:52:51.411 cltest[723] NEMA: $GPGGA,185252.295,,,,,0,00,,,M,0.0,M,,0000
Nov 18 18:52:51.434 cltest[723] NEMA: $GPGSA,A,1,,,,,,,,,,,,,,,
Nov 18 18:52:51.481 cltest[723] NEMA: $GPRMC,185252.295,V,,,,,,,181111,,,N

Again a little later:

Nov 18 18:53:10.450 cltest[723] NEMA: $GPGSV,3,1,12,04,89,179,26,20,56,046,,23,48,224,,27,37,090,

indicates that Satellite #04 had SNR of 26 dB at el=89 and az=179.

But that was the only satellite with a SNR different from 0 (empty string).

Does anyone know what a "reasonable" value of SNR should be?

So basically the GPS module is capable of receiving satellite data,
but appears to wear ear protectors :)

Therefore, I think we can already rule out the MMC (as it was on the GTA02),
because it is not running during the U-Boot gps command. And, it is
not a power supply issue nor something with big metal (battery)
near the GPS receiver.

This needs more study.

If all EA board owners could take the challenge and do some tests?
But please don't expect immediate results...

Nikolaus



 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20111118/e29b8788/attachment-0001.html>


More information about the Gta04-owner mailing list