Keeping in mind that I currently own three, all of which are fairly "last generation": the ionics plug, the original globalscale plug, and a dockstar.

-   What do you really like?

It's a real linux box. Not some cut down embedded thing, I'm really running ubuntu, debian, and arch on my plug-variants.
Cheap. I'm currently messing with a dockstar for putting in my bike, and they're available at newegg for fifty bucks. The standard globalscale and ionics plugs are only 100 bucks.
Easy to work with
Great community on the forums here
It's incredibly powerful for the limited electricities it eats

-   What is a pain point? What are you complaints?

No wireless in any of the ones I own. I really wish it had built-in 802.11g and bluetooth.
The globalscale and ionics plugs only have one USB port. I had to hokey an extra USB hub in for my car's usage with the globalscale plug [http://icculus.org/obdgpslogger/sheevap5v/]
NAND internal memory blows. My application writes to the disk. A lot. I have to run external USB drives just to avoid burning the flash out. [I've already destroyed a couple SD cards]. I wish it had an internal hard drive [thankfully I'm really looking forward to the plugcomputer v3 from ionics, which totes a 1.8" spinning magnetic drive, which I might want to replace with an SSD if prices drop]. Also, 1/2G storage ain't much. [1/2G RAM is *plenty* though, for me - even the dockstar's 128M is plenty for my app]

-   What do you think Marvell is doing and can do to enhance the ecosystem that is building around plug computing?

I'd like more variety in distributions. The "sheevaplug installer" came out a long long time after the plug release, and I think it was mostly community-built
Before the sheevaplug installer came out, I was too cowardly to reflash the plug so I was suffering a really gimped system.
I'd really like debian to be properly supported with the installer [didn't see that anywhere yet].
Instead of just the cross-compile tools, I'd really, /really/ like to see a completely baked scratchbox 2 install [rather than just directions on the wiki].

Overall, Marvell have been doing a stellar job as far as I'm concerned, my issues are all minor. I would definitely like to see a clearer officially supported path for switching up the whole system on the plug though.

-   Any ideas and concerns you would like to highlight to the big guys.

Nothing I haven't already covered - but as I said, my issues are such small potatoes, it's pretty moot.

-   What are the other alternatives you had in this market – if any!

gumstix, beagleboard were the two I looked at. gumstix was a bit too slim hardware-wise and a pain to run stuff on, the beagleboard was too expensive and was a little too naked-electronics for my liking.
Gutted Eeeepc - again, a little too naked-electronics by the time I got it to the form factor I wanted. Even more expensive, and basically too big for my liking [I only have a teensy little car, and my bike's obviously even smaller]


To be honest, I accidentally ended up with the sheevaplug after helping someone else get my software running on his, and it all snowballed from there. I had been researching the alternatives a while before

Gary (-;

I would presume so, although I don't have a guruplug yet.

For what it's worth, the dockstar actually has a tool blparam. I don't know if it works for anything else, but it might be worth a gander.

Gary (-;

The default way to get into the plug is via ssh. The serial terminal on the JTAG is for messing with the bootloader, checking the serial console, and reflashing the device.

I have three plugs now; one of them [original globalscale] I used the JTAG serial to reflash and the SD port. I have an ionics plug that hasn't yet been booted with the jtag module attached, and I have a DockStar that doesn't offer JTAG. All three of these are in active use for all kinds of stuff.

The short answer is that "you probably don't need one". Out of the box you can ssh in and fidget with it, without needing JTAG.

Gary (-;

I sampled how much power my plug drinks in various states after I replaced the PSU. The results are at the bottom here:
http://icculus.org/obdgpslogger/sheevap5v/

The short version is "while powering a small USB hub, and with two USB devices, it draws about 6W from the outside."

Gary (-;

The best way is to use Scratchbox to compile for the plug [behind the scenes it's a real VM]. That's been documented how to do it on the plugcomputer wiki:
http://www.plugcomputer.org/plugwiki/index.php/Scratchbox2_based_cross_compiling

That being said, if you really want to cross-compile, I particularly like CMake. I'm cross-compiling on Linux with this cmake toolchain file:
http://svn.icculus.org/obdgpslogger/trunk/cmakemodules/Toolchain-sheeva.cmake?view=markup

You can do the same thing on windows with cmake by changing the paths in that file appropriately.

Of course, all that hinges on you using cmake to build your project - which I've been doing since this project began.

Gary (-;

I suspect it'll work - as a whole, anything that pretends to be "ELM327" and provide a decent serial-type interface should be good to go. I've heard

I do personally recommend going with any of the premium brands; obdpro, scantool.net, or obdkey are the three that I have personal, positive, experience with. I haven't tried much in the way of cheaper ones personally.

For bluetooth dongles, you use rfcomm to get the job done. Once you get everything set up right, it's as simple as telling obdgpslogger to use /dev/rfcomm0 as the serial device [or whatever you set up], and it should automatically connect when obdgpslogger tries to open the device.

Part of the question for bluetooth and the plugcomputer is how to trigger launching obdgpslogger; when I have USB devices, linux udev triggers the launch. When you have bluetooth, you'll want to use SysV init to launch obdgpslogger once you hit runlevel 3 [on the plug] [unless you have a keyboard or something]

I'm very interested to hear how it works out!

Gary (-;

Basically you'll have the ability to send and receive data [ie, "echo reset > /dev/pts/5", "dd if=/dev/pts/7 bs=1 count=5" and similar], but you won't be able to change terminal settings on the device ["stty -F /dev/ttyUSB0 ispeed 115200 ospeed 115200" or similar]. For example, speed cannot currently be set on the fly; obdftdipty connects at a specified speed and you can't change it.

If you reset and upload firmware to the arduino via regular commands, you should be ok.

All this isn't to say that using ftdi_sio isn't a technically superior solution, you get all the control that's possible by using a "real" driver as opposed to my mickey-mouse userland proxy, but... the proxy works great for my needs.

Gary (-;

Hrm. Well, before when I ran ntpd, it updated immediately. I'll look into flags, though

It went to the same wrong value; april first, 1940.

Gary (-;

Hrm. It just happened again. Apparently it can take a long time for gpsd->ntpd to actually get around to updating the time on the machine. Is it possible the batter on the board is almost dead ?

Gary (-;

Yeah, I've unplugged and replugged it several times since; it just seems that it happened the once.

That's a good idea to use gpsd to update the clock; gpsd has a '-n' option that works for exactly this, I hadn't thought of that.

Thanks!
Gary (-;

Currently I'm using my plug in an unconnected environment [my car]. It gets powered up and powered down without warning [as far as the plug is concerned]

Last night, for no reason out of the blue, my plug appears to have lost track of time; I connected it today, and it thought it was the second of april 1940.

This plug is fairly new, I'm pretty certain the battery on the motherboard can't have died yet. I brought the plug back inside, and "ntpdate-debian" fixed it immediately.

Any suggestions?

Thanks,
Gary (-;

1) In the default globalscale plug install, ftdi and pl2303 modules are missing; the first accounts for 75% of USB serial devices, and the second accounts for 20% of USB serial devices. The odds are good that it won't work.

2) But the plug installer neatly fixes that by installing a new kernel that supports them. It's worth noting that the ionics plug comes with working versions of both those modules.

3) I actually wrote an ftdi->pty userland proxy using libftdi. It's part of obdgpslogger. If you download and build it while libftdi-dev is installed, you'll find a program called "obdftdipty" that connects to your FTDI device, and opens a posix pty; you don't get quite as much control as you do with a "real" /dev/ttyUSB0 device, but you can communicate just fine.

Protip: Ubuntu 9.10 has [or had, I haven't checked recently] a badly broken ftdi kernel module; my userland proxy works around that, too.

Gary (-;

Go me! Excellent timing! I post this, and less than an hour later, I find it!

http://www.youtube.com/watch?v=_WeWBXRXUog

The other two guys that were at the show also have videos posted now:
http://www.youtube.com/watch?v=DJJrBPNKdJg
http://www.youtube.com/watch?v=jX4BEW6GRbU

Gary (-;

At CES, the plugcomputer winners were interviewed on video; has anyone seen those videos posted? My inner narcissist is interested :-)

Gary (-;

As part of obdgpslogger [the winner of the plugcomputer competition], I wanted a plugcomputer living in my car; powering on when the car powers on, logging data, and powering off when the ignition is cut.

I modified my plug to use a 12V-5V supply, and out of interest I took power readings in a few places. My writeup is here:
http://icculus.org/obdgpslogger/sheevap5v/

I dunno how much interest that will be to most people, but there you have it.

Gary (-;