Re: GTA02: NavBoard V3 causing GPS interference
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 shielded. 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. Like GND|DATA|GND|CLK||GND 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. -Pascal http://www.wi-flight.net/ Zbynek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stripped down GTA04A5 - interested?
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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Pictures of new alu case
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): Hi, 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: https://picasaweb.google.com/114961040002008630266/GTA04AluCase 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. Enjoy! Radek [1] http://cs.wikipedia.org/wiki/Eloxov%C3%A1n%C3%AD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Hi, 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. Pinky. 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 problem... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] Setting the clock from GPS time
Hi, yes, Neron GPS has this ability. On 08/27/2012 05:07 PM, Gilles Filippini wrote: Hi, Is there a way to set the clock from GPS time with qtmoko? Thanks in advance, _g. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
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 gnu...@no-log.org 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 the FSO umbrella, and that mobile devices should just use standard gpsd instead 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. Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
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. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [dfu-util] who use it for flashing FR?
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 de...@lists.openmoko.org [1] I am asking, how many of you are still using dfu-util for flashing your FR's internal memory? I also would like to inform you about new dfu-util release.[2] [1] http://lists.openmoko.org/pipermail/devel/2012-May/007245.html [2] http://lists.openmoko.org/pipermail/devel/2012-April/007243.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner looses the date when battery is away for short time
Hi, your backup baterry is probably dead. Have you read (1)? Pinkava J. (1) http://wiki.openmoko.org/wiki/GTA02_RTC_backup_battery 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 ... matthias 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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: microSD ext3 file system
Hi, 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): Hello, 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 USB: root@om-gta02 ~ # mkdir /media/card/dic host: $ 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 duden.dict.dz 100% 6719KB 559.9KB/s 00:12 scp: /media/card/dic/stardict-duden-2.4.2/duden.dict.dz: 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 system 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? Thanks matthias ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ROS on Freerunner
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 applications. 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 off... 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 ;) Jan 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.. Sincerely Ranjan On Tue, Apr 19, 2011 at 1:10 AM, Dr. H. Nikolaus Schaller h...@goldelico.com mailto:h...@goldelico.com wrote: I think this can also be of interest to the Openmoko community. Am 19.04.2011 um 09:46 schrieb Jan Tuennermann: Ron, 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, Jan 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 tuennerm...@get.uni-paderborn.de mailto:tuennerm...@get.uni-paderborn.de To: ros-us...@code.ros.org mailto:ros-us...@code.ros.org Date: Mon, 18 Apr 2011 09:28:02 +0200 Subject: [ros-users] ROS running
NeronGPS - fixes, map cache
Hi, 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 http://tvuillaume.free.fr/NeronGPS/ to do this) I'm miss something? Pinkava J. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
