Hello,
My team is working on a project that involves transmitting sensor data from a data logger module to a mobile application via Bluetooth. I am interested in finding a relatively fast, reliable way to store the data that was collected by the data logger. Since we aren't guaranteed to always have a reliable Bluetooth connection between the mobile app and the data logger, we will need a way to mark which records are synchronized with the mobile application and which still haven't been sent up, so that the data logger can continue to collect data even when the mobile application is out of range. We collect data continuously at 4Hz, so I anticipate that we will have far too much data to use a flat file and manually traverse each record prior whenever the mobile application requests data. I am very new to embedded programming (almost no prior experience) but have prior mobile application development experience. My first thought is to store the data in a SQLite database table and include one column called "IsSynchronized" that can store a boolean value to indicate which datapoints have been synced. When the mobile application requests data, the records where "IsSynchronized == false" will be transmitted to the mobile app. Once successful, the mobile app will let the data logger know that the transmission succeeded and set the IsSynchronized column to true for each synchronized record. This is how I would do it if the data were traveling from a mobile app to a server, but I don't know if this is a good idea for an embedded database to a mobile application. Our data logger uses an Atmel-SAM4S microprocessor. We have 8GB of flash memory, so storage isn't an issue. Our RAM is very limited; we only have 160KB. We are working with an external vendor to design the data logger. They have developed an custom, handrolled operating system, but since it contains no Virtual File System, we aren't sure if SQLite will be an option for us. I've heard of other folks using uClinux or other Unix based Operating Systems on the SAM4S to accommodate SQLite (http://sqlite.1065341.n5.nabble.com/VFS-for-an-MCU-internal-flash-td83079.html), but I don't know how practical this is. My question is this: 1. First, am I on the wrong track by pursuing an embedded database to solve my data synchronization issue? 2. Are there other embedded database alternatives that might make more sense in my scenario. I've heard a lot about NoSQL DBs like BerkleyDB and UnQlite, but I don't know is they are practical for my case either. 3. If we do need to implement a VFS, does it make sense to use a unix-based embedded operating system? If so, are there any recommendations as to which one may be a good fit for my hardware 4. Last, are we wasting our time with the SAM4S processor to solve this problem? We would like to take advantage of existing code, the nice power-consumption characteristics of the SAM4S, and would rather not have to go through the time and expense of upgrading our processor, but, if our processor choice is a non-starter, it would be good to know sooner rather than later. To summarize, my question is regarding what direction I should ask the hardware vendor to take. Does it make sense for them to spend time optimizing the SAM4S for SQLite or should we consider another approach? Thank you, JJ OBrien _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
