Pressure reading device guidance

Status
Not open for further replies.

av8or1

New member
Hi y'all-

I am attempting to develop a device that will read pressure values from an analog source (pressure transducer), display them to the user (LCD) and store them for later retrieval. It's that last part that has been an issue thus far in my development. As I have come to learn through tons of Google and forum searches, there really isn't a way to do mass storage with an Arduino, unless you manually remove the SD card that you log data to each time you want to retrieve that data. In my app, it would not be desirable to produce a device that had such a requirement. Instead, I would like for the user to simply plug in their USB (type A) male connector to the device, see the log files that have been saved to the SD card and copy what they want to their PC.

After a lot of work, fat16lib recommended that I look into the Teensy stuff because others have successfully used it to do mass storage and retrieval. However, I can't seem to find the information I'm looking for WRT the Teensy, such as "does it have an onboard ADC or do I need to supply an external one?" and the like. I'm sure that information is out there and I am simply missing it somehow.

Anyway, if Paul or someone could give me some guidance as to how I could configure such a device, I would appreciate it. Again, I need to read in an analog data stream, convert it to digital, display it, store it (referred to as "datalogging" in the MC world) and then retrieve it later via USB. There isn't a need to have the PC monitor the data in realtime, which as I understand it from fat16lib wouldn't be possible anyway due to the caching conflict between a PC/Mac and the Arduino read/write SdFat library.

Thanks!

Jerry
 
How much data are we talking about? What's your sample rate? How long will it record before retrieval?

I've done the ADC sampling, writing to sdcard, and then transfer the file over USB when it's done. Still rough around the edges, but it works. I'm limited to 128KB/sec over USB currently, but hopefully it'll be up to 1MB/sec soon. This is only a limit for me on the PC side cause of a java and serial issue.

I think you could also send it in real-time or near real-time as well, but I don't know how much data you're talking about. fat16lib is highly knowledgeable, so maybe I'm wrong there.
 
Sampling 1000 Hz (1000 samples/s), event cycles to last about 5-7 seconds with a max of about 15 seconds, though theoretically it could be more. Retrieval intervals would vary. Could be within a few minutes to indefinitely stored on the SD card until space is exhausted. I understand that this type of application doesn't necessarily need the largest of SD cards and further that logging the data at all is questionable. However my userbase has requested it, so I am trying to fill the request, if possible. But that kind of thing needs to be a part of the design from the beginning, not just some afterthought. Heck, I thought an Uno would do the job, but I am finding that it won't/can't. Doesn't even have the number of I/O that I need, let alone mass storage and retrieval.

fat16lib says this regarding the SdFat libs and PCs/Macs:

"...is not possible to share an SD with both USB access by a PC/MAC and read/write by an Arduino application.

The basic reason is that there is a cache in the PC/Mac file system and in the Arduino FAT library. I wrote SdFat which is also the base for the official Arduino SD library and it is not designed to have the PC/Mac also maintaining a cache.

I now realize that you probably don't need this type access. You could have two modes where either the PC has exclusive access to the SD or you are logging and SdFat has exclusive access."

So it appears to be a one-or-the-other type of thing, which is ok by me. It would of course be great if I could log and have the PC see the data in realtime, but not so, unless of course I want to broadcast the data over some wireless connection to a smart phone app or something. Not sure that the wireless stuff could keep up with a 1000 samples/s rate, be it the connection itself or the smart phone app receiving it.

Anyway, I would be very interested to hear more about your project, how you configured it, basically everything you've learned. And pictures would be a serious bonus!

THanks!
 
Try looking up any of my threads. I've littered this forum with all my mistakes as I go. :) Look up my posts.

I'm doing about 100K samples per second with a timer interrupt, and writing to alternating buffers that get written to the sdcard.

fat16lib optimized his code by writing in 512 byte blocks to pre-allocated blocks on the sdcard.

If possible, I would avoid having to read the data from the sdcard in real-time to send. I think it would be problematic with overhead and timing issues. Instead, just send it from the 512 byte buffers when it is going to be written to the sdcard.
So, your PC would see it updated approximately every 0.5 seconds. This should be easy over USB, but also doable over bluetooth (on my todo list).
 
However, I can't seem to find the information I'm looking for WRT the Teensy, such as "does it have an onboard ADC or do I need to supply an external one?" and the like. I'm sure that information is out there and I am simply missing it somehow.

The general overview of Teensy is the best place to start. Note in particular the comparative table showing Teensy 2.0, Teensy++ 2.0 and Teensy 3.0. All three have onboard ADC (10bit for the 2.0 and ++2.0, 16bit for 3.0; multiplexed to 12, 8 or 14 channels depending on the board). From there, the pinout, the schematic and MCU datasheet pages are good sources of information. You can of course choose to use an external ADC; parallel, or SPI, or I2C.

@Paul - the overview table says 12 for Teensy 3.0, but A0 to A13 is 14.
 
Last edited:
Status
Not open for further replies.
Back
Top