Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Teensy & Prop Shield lagging after being on for a short amount of time

  1. #1

    Teensy & Prop Shield lagging after being on for a short amount of time

    Hey guys,
    So i'm making a poi that makes sound as you swing it around. For those who don't know, a poi is pretty much just a weight on the end of a short tether, that is spun around the hand in various motions. In a nutshell what I have Is a teensy with a speaker on the end of a short rope.

    My problem is that I have the poi making sound and reacting to motion really well, but if I leave it turned on for more than a minute or two, the sound reactivity gets really laggy. This becoming worse the longer I leave it turned on.
    If you run my code on your own teensy you can see this by rotating and shaking the teensy, and hearing the sound react smoothly, then come back a few minutes later and the sound will no longer react smoothly and will be jumpy and laggy.

    My hardware setup is at its core this:

    18650 LiPo -> Sparkfun powercell -> Teensy with Prop shield -> Speakers

    I also have a few pushbuttons connected and an external usb port connected to the teensy and the Powercell for charging and programming

    Here is my code:
    Note that my actual code is way larger than this, but this is the smallest version of what I have that still replicates the lagging effect.

    #include <NXPMotionSense.h>
    #include <EEPROM.h>
    #include <Audio.h>
    #include <Wire.h>
    #include <SPI.h>
    #include <SD.h>
    #include <SerialFlash.h>
    // GUItool: begin automatically generated code
    AudioSynthWaveform       waveform1;      //xy=242,270
    AudioMixer4              mixer1;         //xy=456,258
    AudioOutputAnalog        dac1;           //xy=662,263
    AudioConnection          patchCord1(waveform1, 0, mixer1, 0);
    AudioConnection          patchCord2(mixer1, dac1);
    // GUItool: end automatically generated code
    NXPMotionSense imu;
    NXPSensorFusion filter;
    void setup() {
      // Initialize IMU and filter
      // Turn on amp
      dac1.analogReference(EXTERNAL); // much louder!
      delay(50);             // time for DAC voltage stable
      pinMode(5, OUTPUT);
      digitalWrite(5, HIGH); // turn on the amplifier
      delay(10);             // allow time to wake up
      //set waveform parameters
    void loop() {
      float ax, ay, az;
      float gx, gy, gz;
      float mx, my, mz;
      // Read motion sensors and filter the results
      imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);
      filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);
      //accel and gyro values added up to one value using pythagoreas
      float acc = sqrt(ax * ax + ay * ay + az * az);
      float gyro = sqrt(gx * gx + gy * gy + gz * gz);
      //accel and gyro added together to get overall motion of device
      //this number ranges from 0 at freefall to around 5000 at full motion
      //the reason for this is i want the teensy to be silent when not moving, and also silent when in freefall
      float both = acc * gyro;
      //motion based volume
      //view the floatmap function below to understand how this works
      mixer1.gain(0, floatMap(both, 100, 5000, 0, 1));
    //used for scaling max and min sensor values to synth values
    //I think this might be causing the lag but not sure
    //also I dont know how to scale values any other way
    float floatMap(float x,
                   float inMin,
                   float inMax,
                   float outMin,
                   float outMax) {
      // Set bounds
      if ( x < inMin ) x = inMin;
      if ( x > inMax ) x = inMax;
      return (x - inMin) * (outMax - outMin) /
             (inMax - inMin) + outMin;
    I'm suspecting it might have something to do with the floatmap function but I don't know for sure. It's the only thing that Isn't straight from the audio or NXp library as I got it from some random example on the internet.

    Any help would be greatly appreciated.


  2. #2
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Is the behavior any different if you just power teensy/propshield from USB (no lipo and no sparkfun)?
    With propshield hooked to USB, you could print out "both" and the floatmap() value, and see if the serial output changes abnormally.

    With my propshield and T3.2 hooked to USB, printing out "both" and floatmap() value and the max for each of those (resetting the max values to 0 every 10s or so), i do not see any noticeable difference over time .... (it's not hooked to a speaker)

  3. #3
    Hey there, thanks for the reply

    I did a side by side test with both my battery powered teensy and one powered by usb, running the same sketch for the same amount of time.
    Both of them ended up laggy after leaving them on for about 20 minutes. I didn't test with the values printing as I could just hear the difference through my speaker.

    Instead of having a smooth transition in volume when motion is applied, it would sound stuttered and jumpy. Its a little hard to notice at first, especially with such a basic sound, but the difference can be heard when you reboot the teensy and compare.

    I'm going to try a different method of mapping values, using the map and constrain functions, and i'll also do another side by side test with the serial values printing just to see if it's noticeable without a speaker.

  4. #4
    Okay so I did another test with both teensys, and this time I had the usb powered one printing out the values for 'both' and the floatmap value.

    After leaving them on for about 20-30 minutes the usb teensy was exremely laggy, and the serial print was also really slow and stuttery.
    Surprisingly though the battery powered teensy wasn't laggy at all.
    My laptop did go to sleep during the process as I wasn't watching it the whole time, so maybe it could be a power thing? Not sure.

    I'm going to keep trying new things but still pretty clueless. I might try a similar test tomorrow but with one of the nxp motion examples.

    I'm going to keep trying new thing

  5. #5
    The thing that strikes me is how fast the sensor weill be reading (1000 reads per second? Or perhaps more?) and comparatively how slow the human mind perceives change. I wonder if you are swamping things with all that data throughput, although I am not sure how that sould happen.

    In any case i think it would be a rare person who could perceive more than ten volume level changes in a second, i.e. once every 100ms or 10hz.

    I's try making the update rate something reasonable like 50hz.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts