Sample frequency help

Klap

I am not all that great at signal processing so I have a few questions.

I am writing a program that uses a cog (cog 1) to sample a piece of hardware. I am then using another cog (cog 0) to sample cog 1. Here is an excerpt from my code which may make this easier to understand.

' Sampling explained:
  '     There are two samples being taken; one by the top level program (this program, WiiToSdCard) and one
  '     by NunChuckInterface. NunChuckInterface activates a cog who's sole purpose is to sample
  '     accelerations from the Wii Nunchuck, the frequency this is performed at set by freq_s_Nun.
  '     ***Note: freq_s_Nun should not exceed 85 Hz otherwise errors build up!***
  '     WiiToSdCard (this top object) takes the values given to it by NunChuckInterface and writes them to the
  '     SD card at a certain speed (or sample frequency in this case set by freq_s). Thus
  '     NunChuckInterface samples accelerations at a frequency of freq_s_Nun and WiiToSdCard
  '     writes these values to the SD Card at a frequency of freq_s.

I need to have two dedicated cogs to perform this function due to the complexity and timing involved. I know that the frequency that cog 0 needs to sample at must be at least two times the natural frequency but how would I ensure this? Would having cog 1 sample at four times the natural frequency and cog 0 sample (or write to SD card) at two times the natural frequency ensure that?

Klap

This explanation is actually much better:

cog 1 reads vales from the nunchuck and stores them into a variable x. It does this at a sample frequency of freq_s_Nun.

cog 0 can "grab" (or read) this x value anytime it wants to, look at the value "inside" (that is stored to it), and write this value to the SD card. The frequency that is does this will be considered freq_s.

I know that freq_s must be at least two times the frequency of interest (the natural frequency) otherwise aliasing will occur. My question now is how does this serial sampling effect the rate at which each cog should sample their data?

Leon

Nyquist actually refers to bandwidth. For instance, signals between 20 MHz and 21 MHz only need to be sampled at a frequency > 2 MHz, not 40 MHz.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Klap

So how should I choose the sample frequencies for both of my cogs? Should I just randomly pick two frequencies?

virtuPIC

Klap said...
I know that freq_s must be at least two times the frequency of interest (the natural frequency) otherwise aliasing will occur. My question now is how does this serial sampling effect the rate at which each cog should sample their data?

Leon said...
Nyquist actually refers to bandwidth. For instance, signals between 20 MHz and 21 MHz only need to be sampled at a frequency > 2 MHz, not 40 MHz.

It's not that simple. Leon, Nyquist has certain precondition. Klap, this precondition is exactly that aliasing signals are filtered out before sampling.

However, for an acceleration sensor you usually have a lower frequency limit of 0 meaning that you'll need a sample rate of twice the upper frequency limit - but see below. Since the nunchuck is built for manual operation I would limit the bandwidth to some 50 Hz or so. The sensor chips might have a higher bandwidth but their mounts probably mechanically filter (dampen) higher frequencies. Or the carriage breaks if you shake it too fast.

This would mean a sample rate of 100 Hz. However, since the propeller has plenty of power you can also spend lessay 400 samples per second and add a digital low pass filter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Klap

Thank you very much for the help. 100 Hz would be great but unfortunately the way the program is writen the maximum sample frequency for the Nunchuch itself is about 85Hz (I could do some rewriting to make them faster but I doubt that it will increase the speed all that much). As for my original question: How much should I sample each one? One sample rate for the nunchuck the other for writing to the SD card. The limit for the Nunchuck is about 85Hz so should I make the sample rate of the "SD card writing" cog larger or smaller?

MagIO2

What I don't understand is, why is your SD card program sampling the values the Nunchuck program did sample? And if I understand you correctly you do the SD card samples on a higher frequency as the Nunchuck samples. What you need is not sampling but synchronizing.
As long as your SD-code is faster than the Nunchuck sampling, it's pretty easy:
Use a long in a dat section to synchronize. Nunchuck puts it's sample at a certain place. Depending of the size of the sample you can use a bit as flag which indicates that the value is new.
The SD program waits until it sees this flag, then writes the sample to SD card, resets the flag and continues waiting for the next.

If SD write is slower than the Nunchuck sampling there might be possibilities in modifying the SD driver itself. I guess the overhead of writing single bytes is bigger than writing a whole block.

Carl Hayes

Reading the thread, I'm mystified why you're doing two levels of sampling.· Why not use a single cog to take samples at some appropriate rate (say 200/sec), and just write those samples to your record?· I assume you're not recording movements of an actual nunchaku* -- since 85 hz would be mighty fast -- but taking and recording 200 samples/sec ought to be easy as π.· At worst you might need to use a second cog to handle the recording, but it needn't be sampling anything.

Or am I missing something?

_____________________

* As a teacher of Japanese martial arts, I'm repelled when anyone writes nunchuck for nunchaku.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net

Klap

Thank you very much MagIO2, using a flag is a great idea! This way I can make sure the data that cog 0 is writing to the SD card is up to date. In which case the sampling frequency of the cog 0 should match that of cog 1 which is 85Hz max.

Carl Hayes also makes a good point. I am recording movements of an actual Nunchuck so 85Hz is probably a much higher frequency then I will actually need. I will probably be sampling the Nunchuck at about 40Hz and writing the values to the SD card at about 40Hz, which won't be as accurate as the flagging method mentioned by MagIO2 but the errors would be much smaller than the errors inherent in the Nunchuck itself (The nunchuck is not a precise measuring devise by any standards).

I don't understand why this multi-sampling issue is so hard to understand. Isn't this the very reason the propeller was created in the first place? I could have used one cog do both the sampling of the Nunchuck and writing the values to the SD card but I could do that with my Basic Stamp so why would I even use the propeller? Wasn't the Propeller created to give users the ability to perform multiple tasks in parallel through the use of multiple "processors" or cogs? The old way of handling this is to do what has been suggested and write the code as follows: Do part one of process one, do part one of process two, do part two of process one, do part two of process two, .... and so on. Writing code like this is very time consuming, difficult to read and code, and is extremely slow. So instead I just have one cog (cog 1) perform the six stage process of reading the nunchuck values and another cog (cog 0) perform a four stage process of writing the values to the SD card. This way both of these processes can be performed simultaneously and the time it takes to get the values from the nunchuch onto the SD card is almost cut in half! The only hard part is coordinating the cogs to get the values from one to the other in an efficient way. I am passing the address of the variables from one cog to the other. So the only question I had was how to coordinate the sample rates for the two cogs (one samples the nunchuck the other writes the sampled values from the cog to the SD card at a sampling rate of its own). I could be totally wrong but I think the ONLY reason to use the Propeller is to do stuff like this (performing multiple processes in parallel by way of using more than one cog at a time; I know its the only reason I stopped using my Basic Stamp and started using the Propeller).

mpark

Klap said...
I will probably be sampling the Nunchuck at about 40Hz and writing the values to the SD card at about 40Hz, which won't be as accurate as the flagging method mentioned by MagIO2...

You're not going to use a flag? Why not? If it'll work at 85Hz it should work at 40Hz.

As MagIO2 said, it's about synchronization, not sampling. You have two parallel tasks, one producing data, the other consuming it. People are having a hard time with your multi-sampling approach because it does not make sense in this situation. Just synchronize the two tasks with a flag or whatever so that every sample gets written to the SD card.