Re: Navigation board @ Pulster shop
Am Samstag 18 Juni 2011, 14:51:05 schrieb Daniele Forsi: > 2011/6/17 Christoph Pulster wrote: > > I think the Open Source community is missing to link and interaction > > between projects. Add-on products like navigation-board can cross the > > gap, for exaple it is useful for Openmoko, Qi Nanonote and Pandora. > > indeed > > can someone recommend an USB<->i2c interface to use the navigation > board externally, for those who don't feel like touching their > Freerunner with a soldering iron or have a netbook? I don't have experiences with USB-I2C interfaces but anyone should work. Be sure to add a 3V voltage regulator (LDO) if you want to power the board from USB which supplies 5V. If you want you can build your own adapter using an old VGA cable. The I2C bus is used for DDC. If you have a spare VGA or DVI connector on your computer you could use it to connect the FRNB (http://en.wikipedia.org/wiki/VGA_connector pin 12 and pin 15). To power the board you could try pin 9 which should carry 5V. Use a LDO regulator to get 3.3V or 3.0V which is needed for the sensors. The I2C bus needs level translation too. Fortunately, if you have a complete board, the needed chip is already included. I will add a section to the wiki about how to connect the board to a 5V I2C bus. Pinout and more documentation will be added too. Hope that helps, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA04A3 test progress
Hi, finally here is a status update on the GTA04A3 board. That's what I've done until now to test it: - attach power, serial console works - boot from sd card (works) - revert I2C-fix from u-boot and kernel -> works without: the hardware is ok, the power supply issues are gone. - test switches and LEDs (seems ok) - turn GPS on and off (works, didn't wait for a fix yet) - attach an external GPS antenna (was not recognized, maybe my antenna is broken) - boot debian and lxde (works) - test touch screen (works) - attach an USB cable (gives errors in dmesg, GTA04 is not recognized as USB device, usb host not tested yet) - add driver and firmware for WLAN (chip is recognized, driver seems to be buggy, does not execute commands) - enable bluetooth (without success yet) Enough for today, I will continue tomorrow. Good night, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04A3 board boots
Am Freitag 17 Juni 2011, 00:10:49 schrieb WB: > --- On Tue, 14/6/11, Dr. H. Nikolaus Schaller wrote: > > Christoph and Rene > > will be the first ones to test them starting on Thursday. > > Eh, not being impatient or anything... but is there news ? :-) > _Looking forward, Boudewijn__ The board is here. The required RS232 cable is still missing. I will pick it up today and start my tests in the evening. Best regards, a lucky bastard ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner Navigation Board v3 - Power management
Am Sonntag 22 Mai 2011, 11:44:24 schrieben Sie: > Hi, > > 2011/5/21 Christoph Mair : > > Hi, > > > > Am Samstag 21 Mai 2011, 16:41:06 schrieb Martix: > >> How much of power Navigation Board v3 consume, both in operational > >> state (all sensors are active) and in idle state (all sensors are > >> powered down)? Can I power down whole board from software? > > > > All sensors support a sleep state which reduces power consumption fo a > > few µA. I will add exact numbers to the wiki page. The sleep state is > > activated automatically after power-on. Therefore you have to talk to > > the sensor to activate it. The only exception is the gyroscope ITG-3200. > > This sensor needs the kernel module which will switch it of immediately > > after the module was loaded. If you forget to do this, it will consume > > about 6mA, IIRC. See http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3#Power_consumption > >> could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, > >> Navigation Board could use free power line from PMU, if it's available > >> or share power line with one accelerometer or GPS. > > > > I don't know much about the PMU, but I tried to connect the board to one > > accelerometers VCC pin. It works, but I would not recommend it, because > > the I2C lines are pulled up when idle. If the chips do not get powered, > > some current may flows from the bus lines to ground. This could be more > > that the "normal" standby current. But I have to admit that I did not > > thest this yet. > > Ok, I understand, current can leak through accerometer to GND. But, > this can also happen with VCC connected to AUX, when AUX LED is on. > This could be explanation for NOR u-boot problem. > http://wiki.openmoko.org/wiki/I2C#Powering_additional_I2C_devices I mostly use power from the AUX switch. With the FRNBv3 I did not encounter the NOR u-boot problem yet. Everything seems to work fine. If someone encounters a problem, there are solderpads for additional capacitors on the bottom side to fix evantual issues. > According to > http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board#Installation the > AUX power is disabled in suspend. Is this PMU behavior > configurable from software? For example, if I want to wake up Neo > FreeRunner from suspend by IRQ interrupt from Navigation Board. You got that wrong. The AUX power is always available, just the power to the accelorometers is shut down in suspend. If you grab your VCC from the decoupling cap of the accel, all sensors will be switched off. If you want to weak the FR using a IRQ triggered from the FRNB, you need an additional wire to connect one sensor to a IRQ line on the FR. Since v3, all interrupt outputs of the sensors are available on (tiny) testpoints. > Fortunately, I've found free PMU power output LDO3OUT alias test pin > H-TP1702, which is proper solution for powering expansion > devices/board like this. On the other hand its not easily accessible > as AUX button or accelerometer, because its located near PMU under EM > shielding, but its not impossible to wire it out. I did not try this yet. > (Please, keep this > in mind during GTA04 design process and wire at least one 3V3 power > line outside shielding.) Depending on measurement results, we may do not need a shield and there are testpoints which you can use to power additional electronics. > >> PS: It would be nice to have some informations regarding power > >> management documented on the wiki: > >> http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 I will add more information when I can test the first machine assembled board. Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner Navigation Board v3 - Power management
Hi, Am Samstag 21 Mai 2011, 16:41:06 schrieb Martix: > How much of power Navigation Board v3 consume, both in operational > state (all sensors are active) and in idle state (all sensors are > powered down)? Can I power down whole board from software? All sensors support a sleep state which reduces power consumption fo a few µA. I will add exact numbers to the wiki page. The sleep state is activated automatically after power-on. Therefore you have to talk to the sensor to activate it. The only exception is the gyroscope ITG-3200. This sensor needs the kernel module which will switch it of immediately after the module was loaded. If you forget to do this, it will consume about 6mA, IIRC. > could be board VCC connected somehow to the PMU (PCF50633)? Perhaps, > Navigation Board could use free power line from PMU, if it's available > or share power line with one accelerometer or GPS. I don't know much about the PMU, but I tried to connect the board to one accelerometers VCC pin. It works, but I would not recommend it, because the I2C lines are pulled up when idle. If the chips do not get powered, some current may flows from the bus lines to ground. This could be more that the "normal" standby current. But I have to admit that I did not thest this yet. > I know about test > pins with 0R resitors on PMU power outputs used for external current > measurement, VCC could be provided from one of these pads. I'd like to hear more about these 0Rs.. > Did anybody considered PMU power management approach with Navigation Board? It should not be needed and could even be a bad idea. See above. > PS: It would be nice to have some informations regarding power > management documented on the wiki: > http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 I will add some more info. The wiki page lacks a few other updates too.. pinout and new pictures, for example.. I will try to fix this tomorrow. Best Regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v3 (FRNBv3)
Dear List, I already announced it (http://lists.openmoko.org/pipermail/community/2011- February/064474.html), now I'm ready to start production: The Freerunner Navigation Board v3 is finished! It features a compass, a gyroscope and an accelerometer. All of them work in three dimensions. Together with the included pressure sensor you get a 10 degrees of freedom sensor board which should be usable for inertial navigation, as flight controller or recorder for drones such as quadrocopters and possibly a lot of other gadgets. To be compatible with as many embedded boards as possible, the supply voltage and the I/O voltage of the I²C bus can be different. A 3V - 3.6V supply voltage (VCC) is recommended for the sensors, while the I/O voltage can be anything between 1.8V and VCC. This feature enables connectivity to your Freerunner as well as to most other embedded devices such as the OpenPandora (there is enough space inside the case) or devices from Always Innovating. If you want even more functionality: the bottom side contains: - the MPR121 touch sensor controller - a 38kHz fixed frequency oscillator for IR remote control applications - the TCA6507 7 channel LED controller - a I2C level shifter to connect even more sensors with different I/O voltages - a I²C EEPROM which is also accessible through 13.45MHz RFID. Preliminary documentation is available on the wiki page http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v3 It will be improved within the next two weeks. Schematic and PCB-Layout are available from https://gitorious.org/frnbv3/frnbv3-hardware (Cadsoft Eagle file format) Preorders can be placed on http://www.handheld- linux.com/wiki.php?page=Navigation%20Board General availability is scheduled for mid-may. I hope you find this little device useful for your projects. If there are any questions, please let me know. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FRNBv2 is dead. Long live FRNBv3!
HI Boudewijn, Am Dienstag 01 März 2011, 13:13:08 schrieb W. B. Kranendonk: > Which software do you use for the layout? I've tried both pcb (gEDA) and > pcbnew (KiCAD), but neither shows anything after opening the files at > chonyota.net (complaints about missing components; I don't have the > details at hand). Due to my lack of knowledge of open source EDA tools I used EAGLE from CadSoft (http://www.cadsoftusa.com) It runs on Linux, Mac and Windows and you can use the freeware version to view and edit the schematic and the layout. I'd like to switch to OS EDA software for future projects. KiCAD is already installed, I just did not have enough time to play with it yet. > Do I need additional libraries? No, everything is included in the two files. Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FRNBv2 is dead. Long live FRNBv3!
Dear list, unfortunately the compass chip included in the FRNBv2 is no longer available. Thus, I am not able to produce the FRNBv2 anymore. For those of you who still want the board I am designing the FRNB version 3. The discontinued chip HMC5843 will be replaced with it's successor HMC5883 which is slightly smaller and therefore requires a new PCB layout. A new feature of the FRNBv3 will be the support for different supply and I/O voltage levels. The sensors need at least 3V to work properly while the voltage for the I2C bus can be as low as 1.8V. This allows you to connect the board to your Freerunner (using 3.3V for supply and I/O) as well as to other hackable devices such as most devices using a TI SoC (Beagleboard, Pandaboard, AI SmartBook ect.). The top side of the new board which contains all sensors is already finished. For the bottom side I'd like to hear your opinion: what should be included? Currently, the board contains the following parts: Top-Side: - HMC5883 Compass - ITG3200 Gyroscope - BMP085 Pressure sensor - BMA180 Accelerometer (new!) Bottom-Side: - MPR121 Touch Sensor - 38kHz Fixed Frequency Oscillator with ~10% duty cycle for IR remote control applications. I hope this works better than the last approach. - TCA6507 7 channel LED Controller - I2C-Level-Shifter to connect additional electronics with I/O voltages bewteen 1.8 and 5V And there is still some space left (about 50mm²) which I'd like to fill up with other nice gadgets. Suggestions? Best Regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: barom - an altimeter/weather utility for freerunner
Hi Ben! Am Samstag 05 Februar 2011, 23:56:18 schrieb Benjamin Deering: > This project uses the bmp085 barometer to show either weather or > altitude. The bmp085 is part of the freerunner navigation board, is to > be part of the GTA04, and can be installed separately. I don't think I > have an account to edit the openmoko wiki, but this could go under > userspace software in the Freerunner Navigation Board page. I'm showing the application here at FOSDEM and it attracts quite a few people. Nice work! Many thanks for it! Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
Am Montag 13 September 2010, 01:14:43 schrieb jeremy jozwik: > indeed, is there any software in the works to take advantage of this? > i think i might have to snag one and add it on when i tear open my > phone to fix the sd card... Kernel drivers for most chips are available from [1]. Each sensor (except the touch/proximity sensor) is supported by the sensor-monitor application [2]. Better overall integration is planned. Mickey agreed to add dbus interfaces to FSO. I am trying to get the drivers merged into official kernel repositories, but most of them lack documentation and proper error handling. I will try to get these drivers merged into the SHR and/or QtMoko kernel repositories, but I'll have to find out if the maintainers would accept these "beta"-drivers until I get them ready for kernel.org. Meanwhile you have to compile them yourself or bug me to do it for you (should not be a problem, except that I have to do it again when the kernel version string changes). Other software that is available or planned: * Compass (HMC5843): A kernel driver (not mine) was merged upstream (into staging/iio) a few weeks ago. It should be rather easy to enhance fso-gpsd to use magnetic measurements. * Gyroscope (ITG-3200): There is no software support that I'm aware of. I will try to implement an inertial navigation solution but you are probably faster if you try yourself instead of waiting for mine. * Pressure sensor (BMP085): My kernel driver was merged upstream. There are no other userspace applications available till now. * LED controller: The kernel driver was initially written for the GTA03 (found it somewhere on the internet). I did not push it to my repository yet but I will do it during this week. Maybe the FSO team adds support for this.. * A/D: Missing userspace applications (except the sensor monitor) * Oscillator: Still buggy. If I can fix the bug I will implement a LIRC driver to use it as a remote control. Of course, the lack of applications means that you should do something to improve the situation! Either add new Ideas to the wiki page or start hacking on something ;-) Christoph [1] http://gitorious.org/freerunner-navigation-board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board#End_user_software ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v2 is finally available
Dear list, after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! The team from handheld-linux.com [1] kindly offered to handle orders and shipping. The second version of the Navigation Board includes some features which go well beyond of what is needed for navigational purposes. The board comes in two assembly variants "standard" and "complete". See below for a feature description/comparison. The most recent documentation as well as possible use cases and bug descriptions can always be found on the wiki page [2]. Features supported by any board: * 3D magnetometer The magnetometer measures magnetic forces on three axes. With some math it can be used as a compass. Alternatively, use it to measure the magnetic fields generated by trains while accelerating (e.g. underground lines). * 3D gyroscope A gyroscope measures angular velocity. It can determine how fast you spin your Freerunner around its three axes. Usable to support the integrated accelerometers for inertial navigation (navigation without GPS) or to create a wireless game controller (like the wii). * Barometric pressure sensor The change in ambient air pressure is a good indicator for changing weather conditions. If the weather is relatively stable and the barometric pressure changes, it usually indicates that the height above sea level changed. If this value is known the absolute height can be calculated without using the GPS. * Four channel LED controller This LED controller can dim and make blink up to four LEDs (e.g. RGBA). It works autonomously, even if the main CPU is suspended. This may for instance be used to indicate unread messages. Large blinking intervals and duty cycles enable short flashes to save battery power. Alternatively one could connect a high brightness LED and use the Freerunner as a dimmable torch. * Seven channel touch controller The chip could actually control twelve channels, but due to space restrictions only seven are available on the FRNBv2. They can be used to add touch buttons to your Freerunner or act as proximity detector. E.g.: disable the screen lock if you pick up the phone. (*) Four channels can also drive LEDs, if you don't need them for something else. Additional features of the "complete" boards: * 12-Bit analog to digital converter This chip is very similar to the one used on the Freerunner Navigation Board v1 to digitize the output of the gyroscopes. The FRNBv2 does not use it for own purposes, it's completely under users' control. A possible use cases would be an ambient light sensor. Or use it to measure the current consumption of the FRNBv2 ;-) * Programmable oscillator Do you need to generate a rectangular signal with programmable frequency between 1kHz and 68MHz? Then this chip is made for you. What can you use it for? I thought about a 38kHz oscillator which can be enabled and disabled using a GPIO pin. This could be used as generic infrared remote control. If you really need these two last features, order a "complete" board or add the chips yourself to any "standard" board. They come in leaded packages and are hand solderable if you have some soldering experience. (*) This feature was not tested yet due to a missing kernel driver. I'm not sure if it will work as expected. (**) The programmable oscillator does not work due to a strange bug. See the wiki [2] for details. Have fun! Christoph [1] http://www.handheld-linux.com/wiki.php?page=Navigation%20Board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
Am Freitag 13 August 2010, 11:47:26 schrieb sam tygier: > On 13/08/10 10:37, Matthias Apitz wrote: > > Give me UNIX or give me a pencil :-) > > +1 > > with emphasis on being about to modify I won't buy something without documented test/solder pads for hardware extensions. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Am Mittwoch 21 Juli 2010, 11:22:20 schrieb Dr. H. Nikolaus Schaller: > Am 21.07.2010 um 10:55 schrieb Helge Hafting: > > On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: > >> On 3 May 2010 11:04, Dr. H. Nikolaus Schaller wrote: > Having navigation work inside tunnels > would allow mapping them accurately for openstreetmap. And also have > underground navigation - some tunnels have got > intersections/roundabouts inside, with several possible exits. > >> > >> Would navit, tangogps, etc. need a new interface to access the > >> sensors, or could the existing libraries be adapted to "correct" the > >> GPS data with additional information from the extra sensors before > >> handing it on to the GUI? > > > > The natural place for such software seems to be in gpsd itself - it > > already supports having several gps (position) devices. (Or possibly in > > a front-end to gpsd - depends on what the gpsd developer wants.) But too > > many processes / software layers is not good - it causes delays. > > Well, for 1 position per second delays it may be neglectable, but you are > right - having everything in one "middle-man" daemon (gpsd) appears to be > the best architecture for me. So it hides the complexity from the > user-applications, and should be easily expandable. > > As far as I know, the kernel driver for the BMP085 barometric altimeter is > already in some upstream kernel release candidate. So altitude information > can be mixed between GPS and altimeter as well. Well, not in a release candidate. The patch waits in Andrew Morton's MM tree to be sent upstream. This will probably happen after 2.6.35 has been released. In the meantime I will send patches against the SHR kernel to the shr-devel mailing list. Hopefully they will be included by default when the navigation board v2 becomes available. I started to document the features of the new board: http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 This might be the right place to collect ideas or suggestions on how to use the new possibilities. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2
Hi Tim, Am Sonntag 20 Juni 2010, 18:52:06 schrieb Tim Abell: > How about an altitude (pressure) sensor? > > That would make up for the accuracy of GPS height data. As I wrote below, the pressure sensor BMP085 from Bosch Sensortec is already included. This was one goal of the redesign. Christoph > Christoph Mair wrote: > > Hi all! > > > > Thanks to a new triaxial gyroscope chip which became available a few > > weeks ago I started to work on a new navigation board for the > > freerunner. The new chip reduces the complexity which results in a > > single layer board containing the triaxial gyroscope ITG3200, the > > triaxial compass HMC5843, and the pressure sensor BMP085 and about seven > > passive components. > > > > The layout is done a final test is still pending. All drivers are tested > > and they work. > > Currently I'm waiting for a quote about how much it would cost to > > assemble the boards. It should be possible to get the assembled boards > > including all costs for components, PCB and assembling for about 75€ to > > 80€. > > > > If there is enough interest I'll try to get a first "production run" > > done. > > > > Since the backside of the board is still empty, the new navigation board > > won't replace the same amount of embedded air as the first version did. > > Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a > > digital humidity sensor (from which I have a working sample) but the > > general availability is still limited. > > The price difference between a single and a dual layer board is > > negligible, therefore it's possible to include at least a footprint for > > new hardware, or simply a lot of solder pads for easier expansion. > > Suggestions? > > > > Cheers, > > > > Christoph > > > > ___ > > 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: [gta02-core] Openmoko Beagle Hybrid
Hi Joerg! Am Mittwoch 16 Juni 2010, 21:51:53 schrieb Joerg Eesmann: > Hi Nikolaus, > Very good stuff, an open phone with OMAP3530-Power, my dream... > > I am a little off topic here, but I take the chance to ask eitherway. > I am thinking about a little simpler NaviBoard. > The actual Naviboard has 2x2 ADC with I2C and one 2axis Gyro(analogue) > and one 1-axis gyro(analogue). A few weeks ago Sparkfun announced a new > 3-axis gyro with I2C (IDG3200), which would make the Naviboard much > simpler, I guess, and give the chance to add the pressure sensor > (BMP085) to the PCB. I'm working on this. See my announcement mail. :) > I have one of these gyro on a breakoutboard in my hands, the chip is > really tiny with a tiny tiny footprint. > I think I will be able to solder the pressure sensor with a reflow oven > in future (when my reflow oven is finished), but this gyro and the > honeywell mangneto sensor. How do I solder them? > How do I apply the solder paste to such a fine grid with no special > epipment? > You said, you also have at least one chip with BGA (0.5 pitch I guess) > on your board, how did you manage to solder this during prototyping? > Any tipps? > Anyone? Well, I reflow soldered the HMC5843 which is a 0.5mm pitch QFN. The steps are rather simple: - get a good PCB with the right footprint and soldermask - if you want to use solder paste, just apply an amount on the pcb and melt it with your solder iron. This should result in small dots of solder on the PCB. It's like a BGA, but with the balls mounted on the board. Working with solder paste but without stencil mask won't work for fine pitch applications. Just use normal solder wire for this task. It works equally well. - flux should not be necessary, but YMMV. - carefully place the QFN onto the solder drops. Make sure it aligns with the pads. Very small alignment errors will automatically be corrected during the reflow process. - place everything in your oven - recheck the alignment - heat the oven up until the solder melts. I used a piece of solder wire next to the board to see if the melting point was reached. - switch the oven off when you think it's done. The extra solder wire should look like a ball now and the chip should be sunken onto the surface of the PCB. Don't wait too long! That's it! good luck! Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ANN: Freerunner Navigation Board v2
Hi all! Thanks to a new triaxial gyroscope chip which became available a few weeks ago I started to work on a new navigation board for the freerunner. The new chip reduces the complexity which results in a single layer board containing the triaxial gyroscope ITG3200, the triaxial compass HMC5843, and the pressure sensor BMP085 and about seven passive components. The layout is done a final test is still pending. All drivers are tested and they work. Currently I'm waiting for a quote about how much it would cost to assemble the boards. It should be possible to get the assembled boards including all costs for components, PCB and assembling for about 75€ to 80€. If there is enough interest I'll try to get a first "production run" done. Since the backside of the board is still empty, the new navigation board won't replace the same amount of embedded air as the first version did. Any ideas on how to fix this 'design flaw'? I'm proposing the SHT21 a digital humidity sensor (from which I have a working sample) but the general availability is still limited. The price difference between a single and a dual layer board is negligible, therefore it's possible to include at least a footprint for new hardware, or simply a lot of solder pads for easier expansion. Suggestions? Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Monday 03 May 2010 11:10:40 Jeffrey Ratcliffe wrote: > On 3 May 2010 11:04, Dr. H. Nikolaus Schaller wrote: > >> Having navigation work inside tunnels > >> would allow mapping them accurately for openstreetmap. And also have > >> underground navigation - some tunnels have got > >> intersections/roundabouts inside, with several possible exits. > > Would navit, tangogps, etc. need a new interface to access the > sensors, or could the existing libraries be adapted to "correct" the > GPS data with additional information from the extra sensors before > handing it on to the GUI? I don't know exactly how all these programms get their gps data so the following is just a wild guess, but I think it should be rather easy to integrate them into (fso-)gpsd if a inertial navigation system has been developed. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
On Sunday 02 May 2010 19:57:02 Alfa21 wrote: > hi, > first of all, congrats for your work :) > > now my question: > why to add two more gyroscope sensors (so now we have 4 of them in our FR > O_O) The Freerunner has two accelerometers, but no gyroscope. > and not just merge a compass to the pressure sensor seen on the wiki I'll think about it. > (and it has also temperature)? The pressur sensor needs to measure the ambient temperature to deliver accurate results. The temperature sensor is integrated and can be read using my driver. Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sunday 02 May 2010 17:57:49 Stefan Schmidt wrote: > Hello. > > On Sun, 2010-05-02 at 17:42, Christoph Mair wrote: > > Unfortunately the NOR bootloader does not work when both, pressure sensor > > and navigation board, are connected (somebody knows why?). :) > > Wild guess. You are not (ab-)using the H-TP4711 testpad which is pin 32 on > the debug connector? That one is the write protect disable pin for the > NOR. No, during my tests I just connected both devices to the aux-switch (for power) and to to the I2C bus. Then the NOR u-boot did not start when I pressed the aux key (at least it did not enable the display). Disconnecting one of the bus lines (SCL or SDA) or the power supply fixed the problem. I guess this may be because NOR u-boot uses a slower frequency than the linux kernel, but I can't come up with a meaningful expanation for this. I even increased the bus capacitance for one line by adding a 400pF capacitor between SCL and GND. Normally this is the stupiest thing to do, but it "fixed" the NOR u-boot with the tradeoff that Linux did not boot. :P The wiki mentions possible problems (http://wiki.openmoko.org/wiki/I2C#Powering_additional_I2C_devices), but excludes the NOR u-boot. Best regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Sunday 02 May 2010 17:06:55 Dr. H. Nikolaus Schaller wrote: > But seriously, one Freerunner did go to (inner) space on a research > rocket (altitude was approx. 100 km): > > http://freeyourphone.de/portal_v1/viewtopic.php?f=20&t=1430&p=14569&hilit=d > lr#p14569 And a second Freerunner will follow: http://www.mail-archive.com/openmoko- ker...@lists.openmoko.org/msg10526.html > I don't know exactly why Christoph & Michele developed this, but I can > imagine some areas (who finds other ones?) what that these sensors > could be used for. You develop new user interfaces (3D gaming :) and > generally improve portable navigation. > > For car navigation, GPS is in most cases sufficient since a car goes > fast enough so that GPS can tell about the direction of movement. But > if you have a handheld device, only a compass and/or gyroscope can > tell that you are rotating the device. While the LIS302 accelerometers > can detect that you shake the device. This gives several new inputs > for gesture recognition. The arena is open for creativity... In fact, inertial navigation was my primary goal. I'd like to use the freerunner to find the right exits within the much underground lines :) Michele wants to do some research on how context aware applications could work on top of this. In general we are very interested to see what the community will do with it. > And, I think one can use the pressure sensor either as a weather > station (during hiking or skiing) - or to get the altitude and detect > ascent/descent better than with GPS. I think all these fine things can > augment and integrate with the GPS system. The pressure sensor was a quick "relax from other developments" project. I like playing with new hardware and this device was rather easy to integrate, but as for now it is a nice addon for the navigation board. Unfortunately the NOR bootloader does not work when both, pressure sensor and navigation board, are connected (somebody knows why?). :) Cheers, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Saturday 01 May 2010 14:56:52 omcomali@porcupinefactory.org wrote: > On Sat, 1 May 2010 13:48:58 +0200 > Christoph Mair wrote: > > we are proud to release a hardware extension for our beloved Freerunner: > > a navigation board! > > Great work! > > Are you going to distribute it? If yes, what's the price of one? If no, > what's the cost of the modules needed to assemble one (pardon me if this > question is stupid)? The price for all parts is about 70€ without shipping costs. The PCB is 3€, in case you want to buy everything else yourself. Most parts are available from digikey. The gyroscopes can be bought from http://invensense.com or from a distributor near you. If you want a DIY-kit, I can send you everything needed to build it. Soldering experience is definitively required. The QFN chips (gyros and compass) are somewhat difficult to handle, but you can "reflow"-solder them in a pizza oven. I could assemble one for you, but this solution does not scale. It took me about 5 hours to finish the first one, and an additional hour to find and remove all the short circuits. :P If there is enough interest I'll try to find someone which builds and sells ready made modules. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On Saturday 01 May 2010 16:09:05 Werner Almesberger wrote: > Christoph Mair wrote: > > we are proud to release a hardware extension for our beloved Freerunner: > > a navigation board! > > Very impressive. Congratulations ! Thank you! > I guess the next level would be to make a board that fits into one > of the Embedded Air (tm) pockets also have some RF transceiver ;-) Well, I've got a lot of other crazy ideas to fill these pockets, I just don't have enough time to realize them all. I'll try to do a RF transceiver during this summer (it has been on my list for several month already), so expect the first prototypes for autumn. Do you have any specific requirements which I should take into account? :) Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Introducing the Freerunner Navigation Board
Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. How can we test it? In order to test the functionality of the sensors we developed a monitor application for sensors written completely in Vala. For more detailed information on both, Freerunner Navigation Board and Sensor Monitor, please refer to http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board What can we do with it? No idea. Perhaps someone of you can find an appropriate use :p We are looking forward to get feedback and comments. Cheers, Christoph & Michele ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] UBI success story
[sent again to reach the mailing lists] On Sunday 03 January 2010 13:11:52 Martin Jansa wrote: > On Sat, Dec 26, 2009 at 09:25:57PM +0100, Christoph Mair wrote: > > Hello, > > > > I tried to use SHR the ubi images on my freerunner, but they did not > > work. Does someone know the parameters which are passed to mkfs.ubifs? I > > think that the ubi fileystem is created for NAND flashes with subpage > > support, but this feature does not work on the freerunner. Passing -s > > 2048 should create a working image (but I did not verify this yet). > > Params are in: > http://git.openembedded.org/cgit.cgi/openembedded/tree/conf/machine/om-gta0 > 2.conf > > MKUBIFS_ARGS = "-m 2048 -e 129024 -c 2047" > for mkfs.ubifs > > UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512" > for ubinize > > So I don't see param for subpage setting for mkfs.ubifs, its only in > ubinize, but it didn't help for my NAND, even when I prepare ubi volume on > neo with -s 2048 -O 2048 and then try to updatevol with full image (small > image like initramfs-kexecboot works for me just fine). That's why I > didn't push patch for setting it in UBINIZE_ARGS. Yes, my fault. mkfs.ubifs does not care about subpages. The critical point here is the logical eraseblock size: Quote from http://www.linux-mtd.infradead.org/doc/ubi.html#L_subpage: "Indeed, let's consider a NAND flash with 128KiB eraseblocks and 2048-byte pages. If it does not have sub-pages, UBI puts the the VID header at physical offset 2048, so LEB size becomes 124KiB (128KiB minus one NAND page which stores the EC header and minus another NAND page which stores the VID header." Therefore the params should be: MKUBIFS_ARGS = "-m 2048 -e 126976 -c 2047" With these parameters, I successfully wrote a ubifs image to a ubi volume: flash_eraseall /dev/mtd6 ubiattach /dev/ubi_ctrl -m6 -O 2048 ubimkvol /dev/ubi0 -m -Nrootfs ubiupdatevol /dev/ubi0_0 test.ubifs mount -t ubifs ubi0_0 /mnt/ The first step (flash_eraseall) is optional and only needed if ubiattach fails. IMHO the ubinize params should be UBINIZE_ARGS = "-m 2048 -p 128KiB -s 2048" but until now I did not get this to work. I can write the image (sometimes it needs a few tries) but mount does not work. > > To fix this, we need to tell the kernel that the mtd partition 6 contains > > a ubi volume which contains the ubifs rootfs: rootfstype=ubifs > > ubi.mtd=6,2048 root=ubi0:rootfs. > > For a "normal" boot qi passes rootfstype=jffs2 root=/dev/mtdblock6 to the > > kernel. Just changing the boot params within the kernel configuration > > does not work. Therefore I patched qi :) > > Ah great!, thanks Remember that ubi0:rootfs specifies the volume name. The current ubinize.cfg sets this name to om-gta02-rootfs, so change this to ubi0:om-gta02-rootfs Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
UBI success story
Hello, I tried to use SHR the ubi images on my freerunner, but they did not work. Does someone know the parameters which are passed to mkfs.ubifs? I think that the ubi fileystem is created for NAND flashes with subpage support, but this feature does not work on the freerunner. Passing -s 2048 should create a working image (but I did not verify this yet). Using the ubi filesystem on the freerunner is not an easy task. A ubi image can't be flashed using nandwrite. I'm not sure about dfu-util, but probably it uses the same technique as nandwrite and therefore won't work too. I did a manual installation (untar SHR into a mounted ubifs) using archmobile installed on SD. If the SHR ubi image is created with the right parameters ubiformat or ubiupdatevol could be used to install the image. For a easy installation with dfu-util, u-boot would need support for ubi images. I used the newest kernel (om-gta02-2.6.32), but a older one should work too. Step-by-step, I did: - Prepare a SD card with archmobile. Any distro should work as long as it provides the mtd-utils package (ubiattach, ubimkvol, ..) - Copy the kernel to the SD-Card. I used the same kernel to create the ubi filesystem which will be used to run shr. This should not be necessary, but YMMV. - Boot from SD - ubiattach /dev/ubi_ctrl -m 6 -O 2048 If this does not work, try to run ubiformat /dev/mtd6 -s 2048 -O 2048 first. If this fails too, erase the flash with flash_eraseall /dev/mtd6. Now ubiattach should succeed. - ubimkvol /dev/ubi0 -N rootfs -m - mount -t ubifs ubi0:rootfs /mnt - tar -xzf -C /mnt - umount /mnt - ubidetach /dev/ubi_ctrl -m6 If everything worked you end up with a ubifs containing SHR, but it won't boot. ;) To fix this, we need to tell the kernel that the mtd partition 6 contains a ubi volume which contains the ubifs rootfs: rootfstype=ubifs ubi.mtd=6,2048 root=ubi0:rootfs. For a "normal" boot qi passes rootfstype=jffs2 root=/dev/mtdblock6 to the kernel. Just changing the boot params within the kernel configuration does not work. Therefore I patched qi :) - Download a git snapshot and modify src/cpu/s3c2442/gta02.c. The interesting lines are at the bottom of the file. - Compile: make CPU=s3c2442 - Flash: dfu-util -a u-boot -R -D image/qi-s3c2442-master_*.udfu Do not forget to flash the kernel, if needed. Reboot. Good luck! Christoph P.S. My SHR is not working yet. There are some issues with kernel 2.6.32, but that's a different story. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal pressure sensor
Am Sonntag 04 Oktober 2009 17:14:43 schrieben Sie: > eg rfid: nokia announces it since years, but FR could be > fo fast...im sorry, maybe im just to optimistic... I was thinking about adding a rfid reader but could not find an antenna which is small enough. Probably there were other problems too.. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal pressure sensor
Am Donnerstag 01 Oktober 2009 16:57:18 schrieben Sie: > On 30 Sep 2009, at 22:18, Christoph Mair wrote: > > ... > > I successfully added a pressure sensor to my Freerunner. The BMP085 > > chip from > > Bosch Sensortec is a small (5x5x1.5mm) chip which includes a > > pressure and a > > temperature sensor. Power and I2C is enough to get it working. I > > glued it next > > to the BT antenna. The wiki page contains some pictures: > > http://wiki.openmoko.org/wiki/I2C_Pressure_Sensor > > Sourcecode is available from http://gitorious.org/freerunner-navigation- > > board/bmp085 > > Cool! How accurate do you find it? I think I can get about 0.5m (the datasheed speaks from 0.25m and better with software averaging), but it seems that the temperature compensation is either buggy or does not work good enough. The running phone (means: not suspended) heats the sensor up and the measured pressure increases slowly. I'll try figure out what to do. > This makes the Freerunner a nice mobile for glider / hang-glider / > paraglider pilots. They most always carry a varioaltimeter with them, > and last time I flew (some years ago) GPS was beginning to have a > significant impact upon that (niche) market. The combination of > barometric pressure with groundspeed allows one to easily find the > optimal speed-to-fly, allowing for head- or tail-wind on a glide > between lift sources (thermals). Unfortunately I'm not a pilot, but this seems to be rather useful. > I'm sure that this sensor must be at least as accurate as those used > in the cheap commercial ($250) varioaltimeters of 10 years ago, so it > looks really good for this sport, if someone has the time to make a > nice interface. I know some Qt and could probably hack a simple but ugly interface, but right now I'm busy with other stuff. > It would be interesting (for me, anyway) to test by climbing a small > hill and see if the pressure difference is reflected accurately. 30m > should be a good initial test. I will do this as soon as I can find a hill ;) First I need to figure out where the temperature dependency comes from. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Internal pressure sensor
Am Donnerstag 01 Oktober 2009 06:42:24 schrieben Sie: > On Wed, Sep 30, 2009 at 4:18 PM, Mikhail Umorin wrote: > > On Wednesday 30 September 2009 16:18:51 Christoph Mair wrote: > >> Hi, > >> > >> I successfully added a pressure sensor to my Freerunner. The BMP085 chip > >> from Bosch Sensortec is a small (5x5x1.5mm) chip which includes a > >> pressure and a temperature sensor. Power and I2C is enough to get it > >> working. I glued it next to the BT antenna. The wiki page contains some > >> pictures: http://wiki.openmoko.org/wiki/I2C_Pressure_Sensor > >> Sourcecode is available from http://gitorious.org/freerunner-navigation- > >> board/bmp085 > >> > >> Christoph > >> > >> ___ > >> Openmoko community mailing list > >> community@lists.openmoko.org > >> http://lists.openmoko.org/mailman/listinfo/community > > > > Cool! > > > > can be very helpful during mountain hiking (not that GPS does not help > > already -- but it may not be always available) > > I'm wondering how much battery it draws probably not much but for > backing trips it might not be all that useful. >From the datasheet: The sensor uses about 0.1µA in standby and 12µA for one sample per second. If you don't need the highest resolution this gets down to 3µA per sample per second and scales linear with the sample rate. Regards, Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Internal pressure sensor
Hi, I successfully added a pressure sensor to my Freerunner. The BMP085 chip from Bosch Sensortec is a small (5x5x1.5mm) chip which includes a pressure and a temperature sensor. Power and I2C is enough to get it working. I glued it next to the BT antenna. The wiki page contains some pictures: http://wiki.openmoko.org/wiki/I2C_Pressure_Sensor Sourcecode is available from http://gitorious.org/freerunner-navigation- board/bmp085 Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
Am Mittwoch 30 September 2009 07:51:26 schrieben Sie: > On Wed, Sep 30, 2009 at 6:51 AM, Jed wrote: > >> I glued a infrared led into the aux key for this purpose. Did someone > >> already try to compile lirc for the FR? My attempt to just 'bitbake' it > >> failed (missing kernel configuration). > > > > LOL, if I want IR that badly I'll just find a similar device that does > > have IR integrated. > > Would it be possible to solder a led onto a USB connector, and use the > USB port (and its power) to blink the led? Ofcourse, this all depends > on how low-level you can go on that connector... It is possible. But you need some additional electronics, probably a MCU which handles the USB protocol. Do you just want a blinking led? Then a dedicated led controller chip with I2C interface should do the job (for example the TLC59208F, http://focus.ti.com/docs/prod/folders/print/tlc59208f.html). For a external, detachable solution, USB and a MCU may be the better option. Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
Am Dienstag 29 September 2009 16:09:05 schrieben Sie: > On Tuesday 29 September 2009, Jed wrote: > > Hi All, > > > > I was wondering if there's any good Universal Remote software for CE &or > > HA being developed in this ecosystem? > > > > Does anyone know of anything under way or a related Linux project that > > could be re-adapted to it? > > > > I have something "roughly" like this visualised... (see attached txt > > file) > > > > I have an old Axim X50v which android is being ported to atm... > > But progress is slow so I may have to find a better supported device > > soon. > > > > Any thoughts/ideas/advice greatly appreciated! > > I couldn't understand your plans from what I saw in the text file. > > Since we don't have an infrared port we can't do a direct Universal Remote > app. I glued a infrared led into the aux key for this purpose. Did someone already try to compile lirc for the FR? My attempt to just 'bitbake' it failed (missing kernel configuration). Christoph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Freerunner CAD model as eDrawing
Hello, a friend of mine created a eDrawing from the CAD models published by Openmoko. This is a *.exe file (Windows only, sorry, but runs with wine if you are lucky) which displays the CAD model without additional requirements. You can take virtual cuts through the case and measure distances between points. Useful if you plan to add hardware or to modify the case. Just try it and let me know if it worked for you: http://chonyota.net/freerunner/gta02-mme01.exe The user interface is in german, but I think you can figure out how to use it. There are some components which are obviously misplaced. Just hide them, as far as I can tell, they are optional :) Christoph P.S.: When closing the software, a dialog asks if you'd like to permanently install the eDrawing application. Just deny if you don't want to. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
