Wow. this is a big topic.. I really just want to start the conversation about a few things in MRL.  An open source DSP software library TarsosDSP was identified as a nice library to help implement these DSP like functions.  The library says that it is for audio processing, but lets consider that audio processing is just analog processing.  Arduino analog inputs are definitely analog and should be able to be pumped into any self respecting DSP library.

Ok, now I'm just rambling, but the idea is to blend some software based DSP technologies with MRL.  Who knows maybe we'll borg in some FPGA technologies to help with doing DSP like tasks.  

 
  • processing of analog signals.
    • Input (samplng audio or analog sources)
    • Output ( playback of the analog source.)
  • signal processing in the mrl environment
  • filters
    • low pass
    • high pass
    • band pass
    • notch filters  (band reject)
  • power analysis (rms & other signal metrics)
  • SENSOR DATA!!!!
  • FFT   ??!?!  :)
  • Transfer functions?!?!  
  • How does this relate to Impulse Response & PID controllers?

 

GroG

9 years 8 months ago

I've played with it a little bit - I did some of the pitch bending stuff.  Made myself laugh - It makes you sound like a keebler elf (supra high) or someone on the phone notifying you of a ransom demand (supra low).

I was more thinking of it for modifying sound, but you bring up an excellent point - Digital signal processing could be used on all our naughty sensors - to change their waveforms into something we like !

WOOHOO !

I'd like to identify all the places that we have analog type of signals in the system.  Currently,  I only can think of the following

1. Ear  (microphone input)

2. Audio playback  (speech/mp3/output)

3. Analog pins of Arduino  (input and output)

4. other sensors?  

Effectively,  i'd like to have some sort of a signal processing framework that we could chain together blocks (and feedback loops?)  I'm a little worried that the publish/subscribe functionality might be too heavy to handle the analog data streams (but maybe not?)   

 

Ya - I'm thinking HTML5 Oscope ! :)

I recently did some optimizations with the Serial service - it allows other Services to get right to the Port level when reading data - actually by-passing messaging queues, however in "remote" reading it will automatically fall back to the pub/sub queues.  

Also with the last rounds of refactoring I've done Queue Stats :

===stats - dequeued total 676000 - 1000 bytes in 223 ms 35 Kbps
===stats - dequeued total 677000 - 1000 bytes in 206 ms 38 Kbps
===stats - dequeued total 678000 - 1000 bytes in 221 ms 36 Kbps
 
Where its monitoring data transfer speeds - Currently I'm using it to monitor the actual serial line speed, but I intend to make it general an capable of monitoring all messaging (pub/sub included)
 
This is part of the "self-testing" systems recently added.  Lots of new toys added which might help.