Re: GTA02: NavBoard V3 causing GPS interference

2013-02-07 Thread Jiří Pinkava

Dne 7.2.2013 18:00, Hrabosh napsal(a):

A few comments inside:

Pascal Gosselin píše v Čt 07. 02. 2013 v 08:36 -0500:

Yesterday I was able to confirm that the installation of the Golden
Delicious NavBoard V3 very seriously degrades the performance of GPS
when using the built-in GPS antenna.  Getting a 3D fix is taking over 20
minutes on average using the built-in GPS antenna.  When using an
external GPS antenna, the issue goes away and an unaided GPS cold start
can be achieved in about 41 to 44 seconds.

I suspect that the use of unshielded cabling between the GTA02 is a
likely cause.  Being in the Avionics business, I am familiar with the
use of shielded twisted pair wiring, but generally in large 22AWG (will
have to figure out where to source very thin STP cabling).  The wires we
use to perform this mod is solid core, probably 30 AWG.  In avionics,
when it is desired to keep a signal from radiating outside a cable (such
as Headphone/Microphone wiring), then the shield of only a single side
of the cable is terminated to a good grounding point.  When instead it
is desired that the signal inside a cable be protected from EMI/RFI from
the outside, then the shields on both sides of the cable will be
terminated to ground

We are usually trying to refrain from connecting shileding to ground on
both sides as a prevention of grounding loop.


I theorize that only the SCL/SDA would need to be shielded (together in
a shielded twisted pair cable ?), Power and Ground may not need to be

We have never twisted two differnet signals together. What about
cross-talks? The only type of signal we are twisting together are for
example positive and negative leg of RS422 bus. Or A429 (you may be
familliar with).

Just ground betwen all data lines is common solution to this.


Emited radiation is equal of surface of closed loop betwen GND and 
signal line.

This issue seems very similar to the SD Card access/GPS issue of the
earlier GTA02s, so I also wonder if a capacitor fix should be looked at
in this case as well.



Openmoko community mailing list

Openmoko community mailing list

Openmoko community mailing list

Re: Stripped down GTA04A5 - interested?

2013-01-22 Thread Jiří Pinkava

Dne 22.1.2013 10:18, Dr. H. Nikolaus Schaller napsal(a):
* no Sirf IV GPS receiver (but internal Antenna with GPS receiver 
inside UMTS module will be available) *
What about no UMTS version, I does not use phone functionality on my 
GTA02, I'm looking for devices with really good WiFi, but GPS is 
essential for my.

I assume that create custom version is not as easy as tell the machine 
not solder few parts on board (or is not easy to tell the machine not to 
do so). There is also lot stuff with ordering and so on. Am I correct?

Openmoko community mailing list

Re: Pictures of new alu case

2012-12-07 Thread Jiří Pinkava

What is the weight of this case (compare to plastic cover)?

Is there posible some tweaking and make this case even more lightweight?

Pinkava J.

Dne 7.12.2012 11:41, Radek Polak napsal(a):

in june i posted pictures of my 3d printed case on my blog. One of the
responses was from Vladimir Zima. He offered to model up case milled from ALU
and here are first photos of his work:

The surface can be further improved by eloxing [1]. All parts are reported
to fit perfectly together and the result should be very durable. As you can
see from pictures the phone is basically working.

Vladimir plans also to do a video and release his 3d models.




Openmoko community mailing list

Openmoko community mailing list

Re: QTMoko website

2012-10-03 Thread Jiří Pinkava


GPSD is usefull for dealing with many kinds of differenet devices etc. 
In case of one specific GPS device in GTAxx, full potential of GPSD 
cannot be utilised. But GPSD still have few very usseful features, one 
of them is data export trought socket/network. This way can be GPS data 
easilly accessible by other applications (eg. experimental application 
in python or tunneled trought network into PC).

I have in past did some dirty hack wich create socket and when someone 
start reading it QWhereabouts starts GPS and act as proxy (and close GPS 
again when noone reads anny more). This code is not usable now, but this 
feature might be ussefull for hacking.


On 10/03/2012 12:03 PM, Radek Polak wrote:

On Tuesday, October 02, 2012 08:01:03 PM Neil Jerram wrote:

Attached is a patch to make QtMoko's GPS framework (Q*Whereabouts) use
gpsd instead of reading directly from /dev/ttyO1.  The benefit of that
is that multiple clients, both Qt and non-Qt, can all use GPS at the
same time.

Nice, i was trying to do something like this too, but without any results.

But I wonder how much is gpsd useful for us now. We have lightweight
Whereabouts framework which now works good on GTA02 and GTA04. On GTA02 it
even handles supplying AGPS data.

I wonder what GPSD can do for us. It's another program running in background
eating system resources. The programs that will use GPSD will be poorly
integrated in QtMoko - i.e. not showing the fix status in title bar, no
blinking with LED to indicated NMEA activity, no AGPS.

This leads us to question - how many programs will use the GPSD. Navit can be
quite easily adjusted to use QWereabouts, i think the same can be done with
Monav and Marble.

And one more thing - i hate GPSD because they are breaking API compatibility
and we have no control of it. I want now to do some wheezy/armhf experimental
release for GTA04 and if wheezy/sqeeze gpsd are not compatible then it's quite



Openmoko community mailing list

Openmoko community mailing list

Re: [qtmoko] Setting the clock from GPS time

2012-08-27 Thread Jiří Pinkava


yes, Neron GPS has this ability.

On 08/27/2012 05:07 PM, Gilles Filippini wrote:


Is there a way to set the clock from GPS time with qtmoko?

Thanks in advance,


Openmoko community mailing list

Openmoko community mailing list

Re: [Shr-Devel] About the future of the middleware

2012-08-03 Thread Jiří Pinkava

On 08/03/2012 05:15 PM, Denis 'GNUtoo' Carikli wrote:

On Fri, 2012-08-03 at 16:47 +0200, Neil Jerram wrote:

Denis 'GNUtoo' Carikli writes:

On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote:

  - GPS: it seems clear now that it was a mistake to pull that under
FSO umbrella, and that mobile devices should just use standard gpsd

However I was told that adding support for AGPS and GTA02 UBX would not
be straingtforward in gpsd.

AGPS is very usefull to save/restore the AGPS data offline in order to
speedup the fix.

All that works on ogps.

Hmm.  I should probably concede here because I don't know any of the
details or history.  Technically, however, I'm surprised if there was no
feasible way of doing this with gpsd.

yes there is, I'm trying to use the hooks right now(I already fixed the
permissions for doing that).
Would you be so kind and point out how to hack A-GPS with gpsd or where 
to start. I have spend some time and found no way to do this with gpsd. 
Extra software was always needed. Especialy for heuristics which tells 
to GPS the current time and position and its precision.

Jirka P.


Openmoko community mailing list

Openmoko community mailing list

Re: problems with qtmoko continuously re-starting

2012-06-10 Thread Jiří Pinkava
Thats solves my problem too. I have disabled bluetooth (and GSM) in my 
GTA02 in init script, left device some time unused (and forgot about 
this small change) and then woder why crashes.

Dne 10.6.2012 23:24, Radek Polak napsal(a):

On Sunday 10 June 2012 18:25:56 Neil Jerram wrote:

Presumably, then, the right fix for this is either to ensure somehow
that the rfkill block bluetooth happens after QtMoko startup, or to
make QtMoko start up even if bluetooth is off.  The latter would be
better, because someone might have switched bluetooth off and then
choose to Restart QtMoko.

Sure, if i find some time, i'll try to fix this for v46.



Openmoko community mailing list

Openmoko community mailing list

Re: [dfu-util] who use it for flashing FR?

2012-05-07 Thread Jiří Pinkava
I'm using dfu-utils time to time. I have stable version of QtMoko on 
flash and testing on MMC card.

Dne 7.5.2012 14:58, Patryk Benderz napsal(a):

Hi all,
regarding recent discussion on [1] I am asking,
how many of you are still using dfu-util for flashing your FR's internal
I also would like to inform you about new dfu-util release.[2]



Openmoko community mailing list

Re: Freerunner looses the date when battery is away for short time

2012-04-09 Thread Jiří Pinkava


your backup baterry is probably dead. Have you read (1)?

Pinkava J.


Dne 9.4.2012 11:38, Hrabosh napsal(a):

Frank píše v Po 09. 04. 2012 v 10:02 +0200:

Am 09.04.2012 08:59, schrieb Matthias Apitz:

When I remove the battery from my FR, for example to change the SIM, it
looses now(?) the date in hwclock and starts with 01.01.2000; I have to
set the date and time again with



That seems to be normal.
My FR also looses time when the battery is removed for a short time.

AFAIR there is a backup (button cell) battery on the FR mainboard.

PS .. My FR keeps date, time and all the settings after replacing SIM or
SD card...

Idea: Buffer it with USB-Power?

Openmoko community mailing list

Openmoko community mailing list

Re: microSD ext3 file system

2012-04-02 Thread Jiří Pinkava


after umout is the filesystem broken? I have experience where are writen 
some pseudorandom data, which overiwrite even forst sector (after 
restart disk partition are not show, SD card is unformated).

Is this you case?

Pinkava J.

Dne 2.4.2012 19:52, Matthias Apitz napsal(a):


After some hours of testing I'm now totally lost with creating an ext3
file system on a (new) 4GB micro SD card.

Using my FR (running SHR) I created one new partition on the SD with
fdisk(1) and it looks like this:

root@om-gta02 ~ # fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 3953 MB, 3953131520 bytes
4 heads, 16 sectors/track, 120640 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disk identifier: 0x0aecb0ac

 Device Boot  Start End  Blocks   Id  System
/dev/mmcblk0p1   1  120640 3860472   83  Linux

Then I created the ext3 file system on it with:

root@om-gta02 ~ # mkfs.ext3 /dev/mmcblk0p1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
241440 inodes, 965118 blocks
48255 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=989855744
30 block groups
32768 blocks per group, 32768 fragments per group
8048 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

now mounting against the /etc/fstab line failes:

root@om-gta02 ~ # mount /media/card
mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so

mounting with -t ext3 works and after this as well mounting with the
normal line in fstab(5) works too:

root@om-gta02 ~ # mount -t ext3 /dev/mmcblk0p1 /media/card
root@om-gta02 ~ # umount /media/card
root@om-gta02 ~ # mount /media/card
root@om-gta02 ~ #

and it is really mounted:

root@om-gta02 ~ # mount
/dev/mmcblk0p1 on /media/card type ext3 (rw,errors=continue,data=ordered)

now I create a dir and copy over some files from the host connected via

root@om-gta02 ~ # mkdir /media/card/dic


$ scp -rp stardict-duden-2.4.2 root@miko:/media/card/dic
duden.ifo 100%  155 0.2KB/s   00:00
duden.idx 100% 2360KB 786.7KB/s   00:03 100% 6719KB 559.9KB/s   00:12
scp: /media/card/dic/stardict-duden-2.4.2/ Read-only file system
scp: /media/card/dic/stardict-duden-2.4.2/duden.idx.oft: Read-only file system
scp: /media/card/dic/stardict-duden-2.4.2/duden(2).idx.oft: Read-only file 

the SCP fails and magically now the SD in the FR is mounted read-only:

root@om-gta02 ~ # mount
/dev/mmcblk0p1 on /media/card type ext3 (ro,errors=continue,data=ordered)

What is wrong or what do I wrong with this SD card?


Openmoko community mailing list

Re: ROS on Freerunner

2011-04-19 Thread Jiří Pinkava

Dne 19.4.2011 10:55, Jan Tuennermann napsal(a):

I think ROS would not be a benefit for the OpenMoko as a phone, it makes
it very attractive for application in robotics or other controlling

The minimal processing power is a problem when compiling. Compiling the
base system took a whole night and when ever I compile a new ROS
package, ROS will automatically compile any packages the wanted want
depends on and make the phone unusable for hours while compiling. I
think I need to look into cross-compiling.

Cross-compiling might be painfull, suggest use of qemu on powerfull machine.

I also think there are some optimizations on the ROS side possible. For
example, there is a lot of logging going on. I think it can be turned

A slim linux would be good, but it must be ensured that all the base
dependencies can be satisfied (boots, OpenCV, etc.). Also one of the
advantages of ROS is, that there are thousands of communities packages
available that have individual dependencies. For example, the
gpsd_pacakges I tried to install will tell the rosmake tool that it
depends on gpsd and (on debian) it will automatically you apt-get to
pull and install the package. (However, this did not work for unknown
reasons on the QtMoko installation, which I had switched to debian
squeeze source).
I also needed to override the OS identifcation with an environment
variable 'export ROS_OS_OVERRIDE=debian:squeeze', because QtMoko was
providing some other identification.

So I think it should use the debian repos, to make as many packages
available as possible.

A good thing would be a pre-compiled version already installed properly
in the file system ready to copy on SD, boot and go! All the phone
functionality could be stripped out, just starting a blank Xserver where
graphical ROS-nodes can show there widgets. I would have one phone SD
and one robot SD card then, and never again the phone would ring while
it drives around on the robot ;)


Am 19.04.2011 10:27, schrieb RANJAN:

Will be really an awesome and exciting idea..But having to port it
properly and use the minimal processing power on FR and to decide
whether one should design a minimal linux specifically to support ROS
etc would be some key points to begin with..


On Tue, Apr 19, 2011 at 1:10 AM, Dr. H. Nikolaus Schaller wrote:

I think this can also be of interest to the Openmoko community.

Am 19.04.2011 um 09:46 schrieb Jan Tuennermann:


thanks for forwarding. ROS (Robot Operating System) is a kind of
meta operating system. It does not really handle OS functions,
also it is not real time. It's a great concept that boosts
development in the robotic area. It is based on a publisher /
subscriber paradigm; you implement your software as node which
will publish and receive messages. For example, if you wrap a
face detection algorithm or something in a ROS-node, it would
subscribe to image messages and probably publish a custom message
with coordinates of a face, or maybe another image with the face
marked. This node can now receive images from any node that
publishes images. For example, a webcam-node. Or a node that
loads test-data from hard drive or maybe from a 3D-Simulator.
Also, there are a lot of components that already come with ROS.
So if we wanted to display the image with the face marked in it,
we would just need to make an image_view node (comes with ROS) to
subscribe our images. More complex components can display 3D
point-clouds (for example from a laser range finder), etc. ROS
nodes register with a master and they don't need to be on the
same machine, as they can communicate over network.

Right now I'm trying to get a gpsd_client node to run on the
OpenMoko. On a remote PC a gpsd_viewer node will run, subscribing
gpsFix messages which it will use to display the Moko's location
in a map from the OpenStreetMap project. I'm planning to connect
the Moko to a micro- controler which then controls a RC-car. I
tested this before, so I'm optimistic that I will get it working.
When it works I might add a X-Box kinnect, which is already
supported by ROS to capture 2D and 3D visual information to
enable the RC-car for autonomous driving.

best regards,

Am 19.04.2011 01:14, schrieb Ron K. Jeffries:

sending this item along seen on the ROS list.

Not sure if OpenMoko folks have already seen it.

A future board similar to SIE nee SAKC would
benefit from a real time OS. This one [ROS]
appears to be open and free and widely supported.

-- Forwarded message --
From: Jan Tuennermann
Date: Mon, 18 Apr 2011 09:28:02 +0200
Subject: [ros-users] ROS running 

NeronGPS - fixes, map cache

2011-03-17 Thread Jiří Pinkava


what is status of NeronGPS? Is sthi project (somewere? in Radek's 
repositery?) alive?

NeronGPS sometimes segfault or just exits, where I should send patches 
(if I do anny :)?

In latest QtMoko v33 I does not found how to download map to cache (I 
used original app from to do this) 
I'm miss something?

Pinkava J.

Openmoko community mailing list