Re: ELM 327 Bluetooth OBD2
Jeff, I just went out and tested and the ELM327 does not charge my phone in host or device mode. It may be possible to use a Y usb cable to charge and talk to ELM327 at the same time if you need to log for longer than the FR battery will last. Using a Y cable in that way could also be dangerous though. I seem to recall seeing something about not using ELM327 with a plugged in computer, but you could try it with a meter first, then an expensive device. Ben On 06/04/2012 02:55 PM, Jeffrey Ratcliffe wrote: On 4 June 2012 01:23, Benjamin Deering wrote: to reprogram the battery's internal regulator. It had no problem powering the ELM327, but I would hope that is getting the power from the car's electrical system. I was hoping that the ELM327 could power the FR over USB from the car. Are you saying that didn't happen? Regards Jeff ___ 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: ELM 327 Bluetooth OBD2
On 4 June 2012 01:23, Benjamin Deering wrote: > to reprogram the battery's internal regulator. It had no problem powering > the ELM327, but I would hope that is getting the power from the car's > electrical system. I was hoping that the ELM327 could power the FR over USB from the car. Are you saying that didn't happen? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Phoenux, Phoneux, Phonux?
On Sat, Jun 02, 2012 at 05:03:55PM +0100, Nick Sheppard wrote:
> On 31/05/12 16:36, Dr. H. Nikolaus Schaller wrote:
> ...
> >
> > 4. Nomenclature OpenPhoneux/GTA04
> >
> > There may be some confusion what "GTA04" and "OpenPhoneux"
> > are and what makes them different.
> >
> > We define:
> > * GTA*: the next generation motherboard(s), i.e. electronics
> > * OpenPhonux: the future "independent mobile handheld" project
> > aiming at complete devices (i.e. GTA04 + case + components)
> >
> > Currently, we run the domains www.gta04.org and
> > www.openphoenux.org. The Openphoenux.org home
> > page will be made more prominent and content rich soon.
> >
>
> This was a really informative post - thanks! But how are you going to
> spell the new baby's name? I see Phoenux, Phoneux, and Phonux all
> within a few lines.
>
> If we were voting, I'd go for OpenPhonux, because it's roughly equal
> parts Phone, Phoenix and Linux which seems about right.
>
> Also, importantly I think, if you heard it spoken you'd probably be able
> to guess correctly how it's spelled, which helps with googling and
> word-of-mouth publicity. And it has the sound "phone" in it which helps
> tell people what it is ("Phoenux" doesn't, at least in English). And
> "Phoneux" looks as if it should be pronounced in French (or is that just
> me ...).
>
> But of course it's the parents who should name the baby, and I'm really
> only a bystander, though soon-to-be GTA04 owner ...
To make this naming even more confusing:
Today I've noticed webOS enthusiasts calling themselves
Phoenix International Communications
http://phxdevices.com/
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: WLAN connection problems w. static IP
On Sunday, June 03, 2012 10:07:56 PM Neil Jerram wrote: > If my reading of the QtMoko source is correct, QtMoko simply uses > 'udhcpc' to do client-side DHCP. So what you've described may be a > known bug with the Debian squeeze version of udhcpc (which is part of > busybox). > > Therefore, you might like to: > > - see if you can reproduce the same problem with Debian squeeze udhcpc, > running independently of QtMoko > > - investigate if that problem has since been fixed in busybox upstream > > - build and install a modified busybox package that adds that udhcpc > fix. Yes and it would be also nice if you could try connect to your router from command line. Something like: iwfconfig essid eth0 your_ap_essid udhcpc eth0 and you can also try with dhclient: iwfconfig essid eth0 your_ap_essid dhclient eth0 Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
On Monday, June 04, 2012 09:38:17 AM Neil Jerram wrote: > I wonder if it would be a generally useful idea to catch and show qpe's > output in cases like this, and then give the user the choice of > restarting or powering off? I think that might be less alarming that > seeing the UI restarting repeatedly. When this restarting last happened > to me, I was worried if it would be safe to force the phone to power off > - so it would be nice to have an explicit option for that. > > Alternatively, the top level loop could measure how quickly qpe is > restarting, and power off automatically if it restarts twice in less > than 1 minute. In that case it might also pop up a notice/explanation, > with a reference to where to look (on the SD card) to see qpe's output. > > What do you think? Are either of those worthwhile? In this case it's quite obvious bug - qtmoko should not segfault when bluetooth is not working. The bluetooth stuff needs to be done much better. The bluez bindings should be autogenrated from .xml dbus files - like it's done for FSO and oFono and they should handle the case when bluetooth is not working correctly. But if you'd like to implement this logic i wont have problem including it - if it's not too much complex. E.g. redirecting qpe output to /dev/tty0 in case it crashes should not be too hard. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: problems with qtmoko continuously re-starting
Radek Polak writes:
> On Thursday, May 17, 2012 12:55:13 AM Robin Paulson wrote:
>
>> it printed this, i'm not sure what it means:
>> QDBusObjectPath: invalid path ""
>> Method call "/->DefaultAdapter()" failed:
>> QDBusError("org.bluez.Error.NoSuchAdapter", "No such adapter")
>
> It looks like bluetooth adapter and bluez are not working. You can
> try: [...]
I wonder if it would be a generally useful idea to catch and show qpe's
output in cases like this, and then give the user the choice of
restarting or powering off? I think that might be less alarming that
seeing the UI restarting repeatedly. When this restarting last happened
to me, I was worried if it would be safe to force the phone to power off
- so it would be nice to have an explicit option for that.
Alternatively, the top level loop could measure how quickly qpe is
restarting, and power off automatically if it restarts twice in less
than 1 minute. In that case it might also pop up a notice/explanation,
with a reference to where to look (on the SD card) to see qpe's output.
What do you think? Are either of those worthwhile?
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
