sampling an IO-pin at 200 kHz, writing bitstream of 500.00 bits to SPI-serial flash?

StefanL38

Hello,


I have a question about a "high-speed" datasampling and storing

I would like to record IR-remote signal from IR-remotes with unknown carrier-frequency.
Assuming the carrierfrequency is in the range between 30-50 kHz.

One approach is to sample the IR-signal without decoding the carrier. So I would get a bitstream. I want to be able to record this bitstream even when a long press on a key serveral seconds long is done.

This results in a big amount of data. Then this data msut be stored away on external memory on the fly.

Is the prop fast enough to sample this bitstream at a frequency of 200 kHz? And as the bitstream has a sum of 500.000 bits to store it on the fly into a serial SPI-flash?

The bitstreams (carrier) frequency can vary from 20 to 60 kHz. So sampling seems the best method in this case.
The bitstreams frequency is constant during receiving one bitstream. So measuringthe frequency of the bitstream and then counting up high-bits and lowbits and just store frequency and number of continous highbits and lowbits might be an option too.

But I guess both need a lot of memeory for the samples. So a fast external memory is nescessary.
Would fast SPI flash be fast enough for this?

If the frequency could be measured quickly on the fly and reliably
decoding the data-bitstream might be possible then the amount of data is going down.

Any comments and maybe alternative concepts to record the IR-signal are very appreciated
keep the answers coming
best regards

Stefan

MagIO2

Why would you use the propeller to read a signal that it wants to store directly in the SPI?

Share the data-line of the SPI with the IR diode and the propeller. After the propeller setup the address, you simply enable the IR signal and let the propeller generate clock signals. As far as I remember earlier discussions about SPI there are RAMs with auto increment of the address.

But to be honest, I don't believe that this is necessary. A propeller should be capable of filtering the real data on the fly, should't it?

kwinn

If the protocol is known the propeller could easily filter the data on the fly. Even a 2MHz 8080 or similar chip could do that. What Stefan is trying to do amounts to a logic analyzer or very simple digital scope. The prop can handle the data rate (200KHz) easily. The problem is storing the data. If the entire hub ram were used 262,144 bits or 1.31072 seconds of the signal could be stored.

The data rate would be 25K Bytes/second, which should be possible using one of several memory types if more than 1.31 seconds of signal needs to be stored.

StefanL38

Hello MagIO2,
Hello kwinn,

thank you for your replies.
@kwinn: I have not worked with eternal memory yet. I just run the C3-demos testing the flash and the SD-card.

Can SPI-flash or SD-card when using the available SPIN-methods achieve this data-rate?
could one cog with PASM-code fill a buffer and another cog reading this buffer with SPIN-methods fast enough to write the buffered data into memory blockwise?

best regards

Stefan

kwinn

StefanL38 wrote: »

Hello MagIO2,
Hello kwinn,

thank you for your replies.
@kwinn: I have not worked with eternal memory yet. I just run the C3-demos testing the flash and the SD-card.

Can SPI-flash or SD-card when using the available SPIN-methods achieve this data-rate?
could one cog with PASM-code fill a buffer and another cog reading this buffer with SPIN-methods fast enough to write the buffered data into memory blockwise?

best regards

Stefan

Here is the listed speed for Kye's (Kwabena W. Agyeman) SD card driver.

File Sector (512 Bytes at time) Reading Speed - 241KBs
File Sector (512 Bytes at time) Writing Speed - 110KBs

This should be able to do what you want if you set up 2 512 byte buffers and fill one with data while you are writing the other to the SD card. The link to the driver is below.

http://obex.parallax.com/objects/619/