Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Data Storage Wireless Networking Hardware

Logging Bluetooth Accelerometer Data on a PDA? 24

Posted by Cliff from the collecting-massive-amounts-of-information dept.
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."
This discussion has been archived. No new comments can be posted.

Logging Bluetooth Accelerometer Data on a PDA? More

Logging Bluetooth Accelerometer Data on a PDA?

Comments Filter:

  • Simple math (Score:4, Informative)

    by Merlin42 ( 148225 ) * on Tuesday April 13, 2004 @05:02PM (#8852908)
    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
    • Talk about screwing up simple math .... ugh i'm stupid today!

      its 14 bytes / string (including newline)
      so the first number should be 362880000 bytes / day

  • Battery Life (Score:4, Informative)

    by Bronster ( 13157 ) <slashdot@brong.net> on Tuesday April 13, 2004 @05:12PM (#8853046) Homepage
    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.

    • Re:Battery Life (Score:3, Interesting)

      by RevAaron ( 125240 )
      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 an
  • why don't you google for the sdk's?

    and you could as added bonus check if that linux software would work with zaurus+bt(in sd or whatever, can't remember if the newer one's ship with included bt).

    some big cf card to that and you're ready to go.

    though, remember the energy usage of such devices in continuous operation...
  • 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 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.
      • 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.
        • Five hours on a SL-5500?

          hahaha! good one!

          Not even my SL-C760 gets that battery life, and it has a battery that's twice as big.

          That said, the SL-5500 might be OK if you could get bluetooth to work. Judging by what I hear in #zaurus on freenode, a lot of folks can't get it working. And these folks are Linux nerds, not PalmOS converts who expect the Zaurus to "just work" like a Palm or PocketPC would.
  • My 5500 has bluetooth on CF and a SD slot for storage, It's linux so the logger should be simple to write. The newer units also support bluetooth on cf.

  • Windows Mobile 2003 SDKs... (Score:1, Informative)

    by Anonymous Coward
    All the tools and SDKs for doing this with a Microsoft Windows powered PocketPC are available for free download.

    Windows Mobile downloads [microsoft.com] - start here.

    In particular, the Windows Mobile 2003 SDK [microsoft.com] will be of interest, as will the eMbedded Visual C++ IDE & compiler [microsoft.com] (don't forget service pack 3 for it [microsoft.com]).

    There are a dizzying array of other tools and SDKs available from that site, so take some time to read everything. There's also a PocketPC emulator for Windows (not sure if that's included in the eMbedded V

  • What might kill the deal... (Score:5, Interesting)

    by HotNeedleOfInquiry ( 598897 ) on Tuesday April 13, 2004 @05:45PM (#8853436)
    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.

  • Whoa!! Where can I get some of these!? (Score:3, Insightful)

    by slithytove ( 73811 ) on Tuesday April 13, 2004 @06:15PM (#8853810) Homepage
    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.
    • The schematics, PCB design, parts list, and firmware (including source) are all on the site. I think the idea is that you build it yourself if you want one.
      • That is what it looks like after further poking. I just wanted to get my slashdot comment in quick enough to get a response. You know how that goes;)
        I'm most familiar with the DIY headphone amp scene, but from that limited experience, I would expect that someone interested in these would be taking orders so as to get the volume up in order to reduce pcb printing and part costs even if there is still some DIY involved.

  • Simputer (Score:4, Interesting)

    by $exyNerdie ( 683214 ) on Tuesday April 13, 2004 @09:51PM (#8855987) Homepage Journal
    Simputer [amidasimputer.com] 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 [amidasimputer.com](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...

  • Compress that data (Score:2, Insightful)

    by AlecC ( 512609 )
    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
  • Will the devices be on different channels or something? (/me is bluetooth dumb)

    I guess different devices might get different starting sequence numbers - if that sequence number changed on evry packet won't take long to loop and make a mess of things...

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close