Slashdot Mirror


Logging Bluetooth Accelerometer Data on a PDA?

sessha asks: "I want to log data from a Bluetooth Accelerometer (actually 5) attached to different parts of the body. How one would go about logging the data onto a bluetooth compatible PDA. I know quite little about PDA OS's, but the main concern is functionality - it doesn't matter if it is PalmOS or Windows CE or whatever. The Linux and Windows directions for data logging are shown, but how would one best go about this on a PDA? Also, it would require at least 256 MB storage, preferably more, since this will be recording 300 of these ASCII strings a second for a number of days. Suggestions as to the best equipment and software to use for such an endeavor would be greatly appreciated."

10 of 24 comments (clear)

  1. Simple math by Merlin42 · · Score: 3, Informative

    lets see, 16 bytes / string at 300hz gives us
    16*300*60*60*24 = 414720000 bytes/day or about 400megs / day
    If instead you use a simple binary representation with 6bytes/record we get
    6*300*60*60*24 = 155520000 byets/day or about 150megs / day
    I bet the data would compress really well, but if a pda would have enough horspower to log and compress is an open question, I would guess yes.

    ps

    If you want to play with bits and save 2 more bits per record then we get:
    5.75*300*60*60*24 = 149040000 bytes/day

  2. Battery Life by Bronster · · Score: 3, Informative

    The other issue you'll want to look into is battery life. I was talking just today with someone from PalmOne about their models with an eye to finding something with a long enough battery life to be used for a week without charging in a 25% utilization scenario. They don't have such a beast. They spec them for about 10 hours of normal use, but heavy data logging isn't normal use - it's high memory bandwidth and that will cost you power. On the flip side, you don't actually need the screen running, so if you can turn that off it will help.

    Given that WinCE based devices are generally known for shorter battery lives, I'm not so sure that your request is practical with current technology.

    Now, what about an Ipod-style device? They have big hard disks, and they're designed to run for many hours. That's where I'd be looking - either that or those new-fangled 'wearable computer' things that have a hard disk and a bluetooth adaptor and can be thrown in your bag to allow you to access your personal storage at any computer.

    1. Re:Battery Life by RevAaron · · Score: 2, Interesting

      But there is no good way to get data into that iPod device. You could do a bunch of hardware hackage, sure- but that's is a lot of work. You'd probably be a lot better off with one of those PCMCIA HDs- the kind the iPod has- in a PDA, along with a huge battery extender. Either you are running your bluetooth off of the iPod's battery (thus killing the batt) or you have even more hardware hackage to do.

      WinCE would be the easiest thing to do this in. I've done a lot of PDA programming, and I'd take WinCE any day, over PalmOS or Linux. There are a lot of options for programming, you've got a real OS, stable bluetooth [1], lots of libraries, etc. My interest area is largely in programming a PDA on a PDA, with no desktop as a part of the developer process, but that is just me. No need to spend a ton of time writing a big, ugly and finnicky C/C++ app- WinCE has a lot of good scripting languages available, including Ruby, Perl, Python, Dialect [2], Scheme, Lisp, BASIC, and many others.

      [1] The Zaurus has some problems with the bt hardware available- maybe the new SL-6000 series would be good... but then again, just because the Zaurus comes with Bluetooth it doesn't mean it works, at least with Sharp at the helm of such a device. But there's a good chance it does.

      [2] Dialect is my personal fave, a prototype-based OOPL. Kind of a cross between NewtonScript (object model) and Python (syntax) with really good support for dealing with the underlying WinCE or regular Windows OS.

      --

      Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  3. cheap solution: sharp zaurus 5500 by torpor · · Score: 2, Informative

    the 5500 is a pocket linux workstation. it will run most linux software, particularly the non-gui/server oriented stuff, just fine.

    put a big CF storage card in it, and use any one of the various bluetooth hacking/logging tools to put all received packets into an onboard mySQL database, or just prune some /var/log/bluetooth_capture.log style files later when you get back to home base, where you can use rsync and such (over WLAN) to snarf the capture database/logfiles ...

    really an easy project, and cheap. the 5500 is an underground hit with linux folks for good reason ...

    --
    ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
    1. Re:cheap solution: sharp zaurus 5500 by Bronster · · Score: 2, Insightful

      the 5500 is a pocket linux workstation. it will run most linux software, particularly the non-gui/server oriented stuff, just fine.

      Pity it only has a battery life of an hour or so when playing MP3s according to the Unofficial Zaurus FAQ. I guess you might get another hour if logging strings, especially if your app is designed to do it without too much load on the system.

    2. Re:cheap solution: sharp zaurus 5500 by M1FCJ · · Score: 2, Informative

      wrong wrong wrong. Update to the latest Sharp ROM, turn the screen off while playing mp3. I get over 4 hours of heavy metal daily. It just works. I have an SL-5500 with 512MB CF card and it beats any mp3 player out there. For long drives I plug it into the car's stereo and it never ran out of battery. I think it would last more than 5 hours, I never had that much of uninterrupted time at the office.

  4. What might kill the deal... by HotNeedleOfInquiry · · Score: 4, Interesting

    Is indeterminate write times. You're most likely working with flash memory. Flash memory write completion times will vary depending on the device, the block size, and the wear-leveling algorithm used. You probably won't have much control over anything other than block size. You'll have to think about when to close and open the file as well. Frequent file commits will improve recovery from errors, but will also probably increase write times.

    This is really a job for an embedded computer engineer. If there's money, safety or reputation at stake, I urge you to find one to help you.

    --
    "Eve of Destruction", it's not just for old hippies anymore...
  5. Whoa!! Where can I get some of these!? by slithytove · · Score: 2, Insightful

    I've poked around the website linked from the story, but I see no mention of how/whether others can aquire these units. In particular, the FAQ is, well, lacking ;)
    I've been looking for something like this for a loooong time! The closest I've seen are serial devices in the $500+ range. These would be perfect for a number of applications I've envisioned.

  6. Simputer by $exyNerdie · · Score: 3, Interesting

    Simputer has a built-in Accelerometer and it runs Linux. Since this device already has built-in support for accelerometer, it should be relatively easy to add support for more using the SDK. Also, simputer can use USB flash memory. It also is one of the rare pda-size devices that has 2 USB ports (one master and one slave; most PDA's only have a slave USB where you can not plug any other usb device). It also has IR port. I am not sure how bluetooth would fit in but it shouldn't be too difficult with a device with such features...

  7. Compress that data by AlecC · · Score: 2, Insightful

    The data has 100% overhead from being in ascii, not hex. You can halve the data storage by converting it to binary immediately. You don't need to store \n - that is implicit in the fixed structure. The first field will generally be simply countin, so you can omit it completely if you can inser an extra code for skipped samples. What coherence is there between successive samples? If sampling rate is high, most samples will be quite similar to their predecessors, and can probably be mor compactly coded with a delta code not an absolute.

    I would have thought that you could cut the data to be stored by a factor of 10 by some thoughtdul, but not very complex, coding. Normally, I would advise againse excessive attempts at compression. But this is eactly the kind of bulk data application where compression works.

    --
    Consciousness is an illusion caused by an excess of self consciousness.