SparkFun Forums

[bertrik]

Hi all,
I'm working on a digital bat detector using a Philips LPC2148 ARM based microcontroller.

As you may already know, bats use ultrasonics ('biosonar') to locate insects as they fly around. After playing around for many years with analog circuits to make these ultrasonics audible to humans, I'm now working on a digital bat detector. The basic idea is to use LPC2148's built-in A/D converter to sample the bat signal at high speed (250 kS/s) and process it for both real-time monitoring of bat calls and for recording it for later analysis on a PC.

Real-time monitoring is done by a very simple but powerful algorithm that simulates 'heterodyning' of the bat signal with a sine wave of adjustable frequency. This converts any bat frequencies near the sine wave frequency down to the human audible range.

The really cool part is that it can also record the bat call directly onto cheap, high-capacity SD cards. I plan to use a FAT file system. This will be combined with a USB mass-storage stack (the LPC2148 has a built-in USB controller for which I wrote USB mass storage firmware). Eventually the recordings can simply be accessed by a PC as a .WAV file on an USB disk drive (similar to a memory stick). On the PC, the raw wave data can finally be used to create a spectrogram to identify the exact bat species.

If you're interested, there's a project wiki, it's at http://wiki.sikken.nl/index.php?title=D ... atDetector

[npk]

Wow! Cool project. I've built an analog bat detector using the division method, which, as you know, loses amplitude information.

Good luck.
n

[bertrik]

One thing that has been bothering me for some time is the file system. I want to use a file system because it's so convenient, but I also want high-speed writing.

I'm thinking of letting the filesystem create a dummy file for me and telling me the start of the 'free area' (i.e. start of unused sectors at the end of the disk). Then, when recording, my application writes a large contiguous chunk of data to the free area. After recording, my application asks the filesystem to associate the recorded data with the file.

I'm now looking for a filesystem that can do this for me (or can be easily modified to do so). Is there anybody with experience with embedded file systems that can comment on this?

[npk]

What is the rate that you want to save to disk at? If I guess, you want to store a bandwidth of say, 100kHz. Suppose you have an 8bit ADC. You need to write at 100K/Sec. This seems reasonable.

n

[Philba]

there is FAT file system source code floating around somewhere. if you use an SD card, you will want FAT. One nice aspect of using an SD card is that you can read it with a PC if you use a FAT FS. I'm pretty sure your processor could handle it. google is your friend.

[bertrik]

Currently the A/D converter is running at 250 kS/s at 9 bits resolution, of which 8 bits are saved to the SD card. If possible, I'd like to go faster, but I think I'm approaching the limit of what the microcontroller can handle.

There are bats that generate ultrasonics up to 110 kHz. To record such frequencies I need to sample at least twice that frequency, so 250 kS/s is just enough.

I'm afraid that 250 kB/s is too much for the filesystem to handle, especially when it needs to read back some structures (like the FAT) during recording, or when it needs to interrupt a contiguous write (when switching from data writing to FAT writing). Non-contiguous writes on a SD-card take much more time than contiguous writes.

[teekay_tk]

problem with sdcard+fat is that you have to write 512bytes in a go and then read and update the clusters etc. I found that it took about 60ms to do this runing on a 8720 running at 12mhz.
i propose that you do the following,
1. use your main pic to gather the data into a fifo
2. make the 8720 to read 512 bytes of data from the fifo and write to the SD cards
3. if 8720 is not using any other preipheral but just spi to write to sd card, i have been able to overclock it to 64Mhz using the internal 4xPLL. this reduced the wriring time of 512bytes to around 20ms.

the reason for this is that while pic is writing to sdcard, there is nothing else you can do. so i propose this two pic version for you.

you can also use atmel mega series that runs at 64mhz (i presume) and have free sdcard librbry

[bertrik]

Yeah, SD card writing can be slow by itself. This is because internally an SD uses blocks that are larger than a 512 byte sector. So if you write a single sector, it has to read an entire block (perhaps 8k of data), update the new sector, erase the block and write it back.
For this reason I'm using the SD command WRITE_MULTIPLE to write a contiguous block, which does not do the read-modify-erase-write sequence, but just erase-writes. Now the SD-card hardly makes the microcontroller wait anymore.

Sampling data and writing it to the SD card already works on my setup, except it's not using a filesystem yet, just saving it in raw format starting at a fixed sector address. I am indeed using a FIFO (or ringbuffer): the A/D interrupt puts bytes into it, while the main loop continually checks if it has 512 bytes or more available so the main loop can start writing. So far this seems to work without overflowing the FIFO.