EdCa22 said:
I just find the USB bus overkill for a low speed sensor and don't want to have to add a hub. Add to this the effort of design (inc PCB layout) and adding and programming the extra micro (although, if I were to go that route then an AVR is what I'd choose
) and it's definently a turn off for me. I also suspect that by the time you've created the whole system (including PCB fabrication etc) and added a USB hub you will have cost more or less the same as buying one of those ready made $20 boards, as well as all that extra time.
...
I do conceed that most people would not be willing to do this, and that's fair enough. However, if you wanted to put one of the sparkfun boards externally using SPI/I2C then probably all you need is an EXT port connector and a case, assuming there is power available from the EXT port that is, and you've still got your USB free. You could also add a pass through connector so that you can still use the EXT for other things. I have to say that I will probably just get one of the sparkfun boards and put it inside though.
...
QUOTE
Cost is the main constraint here. I'm not sure the benefit of additional features is "worth it".
Depends entirely on whether you want a compass or not, surely? All I was saying here was that you could easily add a compass to any of these things we are talking about and still come to way less than the all-in-one chip solution I posted that costs $149. I am considering a small PCB based on SPI/I2C purely so that I don't have to fit 2 of those sparkfun boards (or similar) inside the pandora (one compass and one acc).
I'm starting to lean back towards an I2C solution. Plugged into the "AV" port for the masses, hardwired internally for the brave (see the Developer thread for availability of I2C bus). The one thing that I'd like to figure out how to do is to auto detect the plugging or unplugging of the external sensor. Any ideas about that?
QUOTE
QUOTE
Right, I was wondering the same thing - can't the gyroscopic effects be calculated from the accel data? That's what I'm a bit fuzzy about.
Technically, yes. You have to integrate the data, however drift is a big problem so you have to reset your integration frequently; it cannot be used to accurately calculate velocity or distance changes over any large time lapse. However, for small changes (e.g. moving the device in your hands and the movement of an on-screen ball is immediately shown) it's no problem. What I'm saying is, you can't use it for navigation, for example, or even for really finding the position displacement of the sensor within a fairly small space - you will very quickly get errors. However, combining it with another sensor and/or using a clever algorithm (e.g. kalman filter) will help a lot - e.g. for the Wii they have optical sensors, so that they can cancel out the drift periodically.
Ahh, now I get it! Thanks for that explanation - it clarifies things for me.
QUOTE
QUOTE
QUOTE
I'd be happy to write or help to write any drivers, though I expect there are some similar drivers around already.
It would be great to have your help with that. (
DAP if you're still reading along it would be great to have your help too - it sounds like you've worked with the hardware side of things). I'm a noob at hardware design - which is why I'm interested in the project. So additional help is much appreciated. However we'll have to figure out what the overarching goal is. I envisioned a relatively cost effective, easy to use device to encourage "motion based" user interfaces - thus I'm not looking at high-resolution g-sensors and while internal IS better in a LOT of ways there's the warranty/ease of use issues that are difficult to overcome.
Clearly the issue we have here is that we have different desires for similar aims, and I completely understand that a simple USB module has much greater mass appeal. I am coming at this from a 'how can I get an accelerometer into my pandora in the easiest and quickest way" perspective while you are thinking of a design or product for mass useage...I am also thinking about a compass, while it is likely many people wont need one. I do think you should consider using SPI or I2C on the EXT connector though...
Absolutely - this thread started with a poll meant to highlight I'm looking at a "mass market" (well, not really mass just greater than you can count on your fingers and toes). If it's only applicable to the pandora (because of the custom AV connector) then that's probably not such a bad thing. I really don't think a device such as this would take the PC world by storm.
It's really a case of KISS isn't it? I guess I was veering away from simple into stupid.
QUOTE
What we should be careful of is to create, or use an existing, standard API for software to read from these types of devices, either in kernel space or in a userspace library. If we have a unified interface then implementation differences will not matter from a software developer or user perspective.
Agreed.
Here's my current thinking (not an attempt at a spec just a collection of thoughts)
(1) A device plugged into the external port using an I2C chip. For ease of use it should be auto-detecting. For convenience it might offer a pass through connection.
(2) the sparkfun board (or similar) for anyone who wants to put one internal
(3) driver (kernel space) to make the device look like a joystick for easiest integration into games
(4) additional space on the pcb to add one or two additional I2C sensors (compass, gyro, coffee maker...) - a convenience for hobbyists and likely not difficult to allow for in the design.
(5) separate drivers for each individual I2C sensor
So, I'm off to read up on the linux i2c implementation.
Thanks to everyone for their input. Keep it coming. And of course I might still change my mind again (which is the whole point of getting input early on in a project, right?).
As I get closer to settling on a solution I'll likely do another poll to check some of my assumptions.
This is fun
