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."
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
Thoughts on tech, Software Engineering, and stuff
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.
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...
world was created 5 seconds before this post as it is.
the 5500 is a pocket linux workstation. it will run most linux software, particularly the non-gui/server oriented stuff, just fine.
/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 ...
...
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
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. --
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.
All the tools and SDKs for doing this with a Microsoft Windows powered PocketPC are available for free download.
Windows Mobile downloads - start here.
In particular, the Windows Mobile 2003 SDK will be of interest, as will the eMbedded Visual C++ IDE & compiler (don't forget service pack 3 for it).
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 VC4 link above, but it was included in eM VC3). All tools (including the IDE and compiler) are absolutely, 100% free.
Suck it down, Palm.
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...
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.
I suggest using a sensor node which has a mich smaller form factor and can transmit data wireless over to a PDA/desktop powerd from the wall.n _J_FINAL.pdf
Check out this application which also uses an accelerometer to build a conductor's baton. http://mantis.cs.colorado.edu/media/03_175_Carlso
Well I guess the orignial poster already considered that each module requires 13mA of power. If weight is a problem then it might make a good trade off for the constraint of the wires. In addtion if you just want a datalogger I would look at a small atmega from www.atmel.com or pic and write directly to a compact flash card yourself http://instruct1.cit.cornell.edu/courses/ee476/Fin alProjects/s2000/peterdan/final.htm.
however without knowing the weight, size, cost, and mobility it would be tough to give advise.
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...
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.
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...
Yes, but whats that got to do with the price of tea in D'ni?