Teensy Audio USB type

Status
Not open for further replies.

alexan

Member
Hi all,

I have been trying to connect teensy to matlab in order to get realtime data but, if I use the "USB Serial type" comunication, the Serial.print instruction is very slow for my purpose. The point is that can't add a delay after the Serial.print because I will loose some parts of the incoming data and I need all of them.

I have realized that, if I configure the teensy as "Audio USB", the serial port prints data fast enough for me but, when I try to read those values in matlab using the "Serial.print", it does not work.

Does anybody know how can I solve this?

thanks!
 
Hi Paul,

Thank you for your response.
Unfortunately, the Serial continues being too slow. Maybe this is a dumb question but, is any intruction to make an "Audio.print" or something like that? I suppose that it is not going to be as easy as I would like, but maybe you can suggest me how can I proceed.

many thanks!
 
Serial USB should be as fast as the computer can handle - at least to a terminal program doing display or processing - typically the 12 Mbit interface results in 1 MByte/sec more or less depending on the Teensy. If it isn't working well - unless the sketch is full of delay()'s or other obstruction preventing the output, the T_LC or 3.2/3.5/3.6 can typically (nearly) overwhelm a receiving PC program that isn't efficient. I don't see indication of which Teensy - or how much data and how fast is 'too slow'. There may be a hardware hub/port problem - but likely the PC is just failing to take and process the data as configured.

Without some idea of the sketch involved and how it is structured it is hard to say other than that.
 
What sort of answer or help do you imagine anyone can give for a specific problem, when you provide pretty much no specific details about the problem?
 
Defragster is right, the overall bandwidth is about 1.0 to 1.1 Mbyte/sec with 12 Mbit/sec USB, after USB protocol overhead.

44.1 kHz stereo 16 bit audio uses approx 0.17 Mbyte/sec. So if your PC (or Mac... we don't even know that) is doing both input and output audio streams, then about 1/3rd of the total USB bandwidth will be consumed by the audio streams.

USB has 4 bandwidth allocation types. Audio uses "isochronous", where a set amount of bandwidth is guaranteed and more than that amount can not be used. Serial (for the USB Type options which actually have "Serial" in their names) uses "bulk", which is able to share all available bandwidth not currently in use by "isochronous" and "interrupt". So how much you can communicate with Serial depends on the left over bandwidth.

If other USB devices are consuming bandwidth, especially if you have other 12 or 1.5 Mbit/sec devices plugged into your PC or into the same single-TT hub, they may be taking up some of the bandwidth. Only Multi-TT hubs share upstream 480 Mbit/sec bandwidth properly among multiple slower devices.

We can't tell from your question how much non-audio data you're actually trying to transmit. But if it's more than ~600 kbytes/sec, then obviously you're facing the limits of Teensy's 12 Mbit/sec USB port. If it's substantially less, and if your USB bus isn't heavily loaded by other USB devices, then there's some other problem that may have a solution. But to have any hope of helping you solve such a problem, we're going to need to be able to see the issue, probably even be able to reproduce it. We're not psychic. We can't help when you keep us in the dark.
 
Audio transmits data as -audio- so you need to use the audio library and connect a audoconnection
on the PC-side you need to configure that, too, because it is handled as:audio. print will not help, it uses an other "channel" of USB (still serial). If you want to use Serial.print USB-Audio is the wrong choice, obviously.
To speed up transfers, dont use ASCII (Serial.print (200) = 3 ;bytes to transfer) , perhaps use Serial.write (Serial.write(200) =1 byte to transfer) instead, which transfers your Data binary (but human- unreadable)
 
Another problem that sometimes comes up, which may or may not be the case here, is when people try to do query-response using Serial. Then the USB latency comes into play, which involves many complex factors mostly outside of your control, like the PC operating system scheduling & driver latency, as well as USB controller issues.

But one thing is for sure - USB latency severely constrains bandwidth if you suffer it for every small message.

If you've built a program on your PC that's sending queries and waiting for a reply from Teensy before sending another, then you're going to have to restructure how you do communication. I've written about this many times on other threads...
 
Hi all,

Thank you for your responses and your suggestions. later I will post both codes (the one tat I am uploading to Teensy, explaining how I configure the USB, the sampling rate...) and the one from matlab to clarify a bit everything.

Again, thank you
 
The main idea is to read the ADXL345 accelerometer in order to compute the FFT in matlab and in Android. The idea to use the Audio USB device instead of Serial device is because, as I said, when I try to read the serial port in matlab, the incoming data rate is very slow (Seria monitor data seems to freeze) and, If I configure the USB type as Audio, the Serial monitor goes fast enough. Until now I have been taking the data manually from serial monitor and processing it in Matlab to get the FFT.

Because of this, during the weekend I have been taking a look into the Audio library but I am a little bit confused about how to proceed. Below you can check the code.

Code:
#include <Audio.h>
#include <Wire.h>
//GUItool: begin automatically generated code
//AudioSynthWaveformSine   sine1,sine2,sine3;          //xy=265.0000305175781,430.0000629425049
AudioSynthWaveform       waveform1;
AudioMixer4              mixer1;
AudioOutputUSB           usb1;           //xy=454.0000114440918,462.00001430511475
//AudioConnection          patchCord1(sine1, 0, mixer1, 0);
//AudioConnection          patchCord2(sine2, 0, mixer1, 1);
AudioConnection          patchCord1(waveform1, 0, usb1, 0);
//AudioConnection          patchCord4(mixer1, 0, usb1, 0);

Some Audio declarations, At first I tried to send over USB a Sine wave but I realize that, using a SynthWaveForm the results were better.

Code:
//**************************Definiciones para los registros del ADXL345*****************//
//Direccion del dispositivo
const int DEVICE_ADDRESS = (0x53); //Comprobado con el I2C Scanner
byte _buff[6];

//**************************Direcciones de los registros del ADXL345********************//
char POWER_CTL = 0x2D;
char DATA_FORMAT = 0x31;
char DATA_RATE = 0X2C;
char DATAX0 = 0x32;   //X-Axis Data 0
char DATAX1 = 0x33;   //X-Axis Data 1
char DATAY0 = 0x34;   //Y-Axis Data 0
char DATAY1 = 0x35;   //Y-Axis Data 1
char DATAZ0 = 0x36;   //Z-Axis Data 0
char DATAZ1 = 0x37;   //Z-Axis Data 1
uint8_t numBytesToRead = 6;

ADXL345 registers and declarations.

Code:
double alphaX = 0.80; 
double alphaY = 0.80;
double alphaZ = 0.80;
double gx,gy,gz;

Here I declare some variables in order to compensate the G force.

Code:
//Eje Z
double EMA_a_Z = 0.93;
double EMA_s_Z = 0;
double highpass_Z = 0;

//Eje Y
double EMA_a_Y = 0.93;
double EMA_s_Y = 0;
double highpass_Y = 0;

//Eje X
double EMA_a_X = 0.93;
double EMA_s_X = 0;
double highpass_X = 0;

More variables in order to make a high pass filter (still working on it)

Code:
void writeTo(int device, byte address, byte val) {
  Wire.beginTransmission(device);
  Wire.write(address);
  Wire.write(val);
  Wire.endTransmission(); 
}

//Funcion auxiliar de lectura
void readFrom(int device, byte address, int num, byte _buff[]) {
  Wire.beginTransmission(device);
  Wire.write(address);
  Wire.endTransmission();
 
  Wire.beginTransmission(device);
  Wire.requestFrom(device, num);
 
  int i = 0;
  while(Wire.available())
  { 
    _buff[i] = Wire.read();
    i++;
  }
  Wire.endTransmission();
}

Auxiliar functions in order to read and write from the ADXL345 registers.

Code:
void setup() {
   //AudioMemory(100);
   AudioMemory(12);
   Serial.begin(115200);
   //sine1.begin(WAVEFORM_ARBITRARY);
   //waveform1.arbitraryWaveform(myWaveform,172.0);
//   waveform1.frequency(440);
//   waveform1.amplitude(1.0);
   

  //descomentar estas dos lineas para teensy. comentar para arduino
  analogReadAveraging(32);
  analogReadResolution(10);
  
  Wire.begin();  
  
  writeTo(DEVICE_ADDRESS, DATA_FORMAT, 0x0A); //Lo he puesto en +/- 8 con el bit de resoluacion full
  writeTo(DEVICE_ADDRESS, POWER_CTL, 0x08);  //Poner el ADXL345 en modo medicion
  writeTo(DEVICE_ADDRESS, DATA_RATE,  0x0D); //Está en 400 (bandwith of 200Hz) (datasheet table 7)(el data rate más elevado, según el datasheet, requiere un tratamiento especial de los datos)
  

  

}

Main setup.


Code:
void loop() {

  //message = true;
  //delay(1);
  time_since_last_reset = millis();
  while((millis() - time_since_last_reset) < interval_one){
  uint8_t numBytesToRead = 6;
         readFrom(DEVICE_ADDRESS, DATAX0, numBytesToRead, _buff);
          //Leer los valores del registro y convertir a int (Cada eje tiene 10 bits, en 2 Bytes LSB)
        int16_t x = (((int)_buff[1]) << 8) | _buff[0];
                
        int16_t y = (((int)_buff[3]) << 8) | _buff[2];
       
        int16_t z = (((int)_buff[5]) << 8) | _buff[4];

        delay(1);

        EMA_s_Z = (EMA_a_Z*z) + ((1-EMA_a_Z)*EMA_s_Z);
        highpass_Z = z - EMA_s_Z;

        EMA_s_Y = (EMA_a_Y*y) + ((1-EMA_a_Y)*EMA_s_Y);
        highpass_Y = y - EMA_s_Y;

        EMA_s_X = (EMA_a_X*x) + ((1-EMA_a_X)*EMA_s_X);
        highpass_X = x - EMA_s_X;
        
//        
        //Compensación de la fuerza de la gravedad sin el filtro EMA
//      gx = alphaX * gx + (1 - alphaX)*x;
//      gy = alphaY * gy + (1 - alphaY)*y;
//      gz = alphaZ * gz + (1 - alphaZ)*z;

        //Compensación de la fuerza de la gravedad con el filtro EMA
      gx = alphaX * gx + (1 - alphaX)*highpass_X;
      gy = alphaY * gy + (1 - alphaY)*highpass_Y;
      gz = alphaZ * gz + (1 - alphaZ)*highpass_Z;
        


        //Datos de salida en m/s2 sin filtrado EMA 
//        acc_x_final = (x - gx) * 0.0156* 9.81;  
//        acc_y_final = (y - gy) * 0.0156 *9.81;
//        acc_z_final = (z - gz) * 0.0156 *9.81;

        
        //Datos de salida en m/s2 con filtro EMA
      acc_z_final = (highpass_Z - gz) * 0.0039 *9.81;  //8G normal res
      acc_x_final = (highpass_X - gx) * 0.0039* 9.81;  //8G normal res
      acc_y_final = (highpass_Y - gy) * 0.0039 *9.81;  //8G normal res
 

//
//        Serial.print(acc_x_final);
//        Serial.print("\t");
//        Serial.print(acc_y_final);
//        Serial.print("\t");
//        Serial.println(acc_z_final);

//         sine1.frequency(acc_x_final);
//         sine1.amplitude(acc_x_final);
//         sine2.frequency(acc_y_final);
//         sine2.amplitude(acc_y_final);
         waveform1.frequency(acc_z_final);
         waveform1.amplitude(acc_z_final);
//         Serial.write(acc_z_final);
//
//         sine1.frequency(0);
//         sine1.amplitude(0);
//         sine2.frequency(0);
//         sine2.amplitude(0);
//         sine3.frequency(0);
//         sine3.amplitude(0);

//Serial.println(acc_z_final);

        }

Sorry for the mess but I still working on the loop. What I do here is read the ADXL345 registers, cancell the G force in order to no read "9.8 m/s2" in the axisi and keep them as close to zero as I can to get the real acceleration. The I apply a high pass filter to smooth a little bit the signal.

As you can see, I am giving the amplitude and frecueny to my waveform1 to be able to send the incoming data as fast as I can (and yes, I have been modifying the Audio libraries in order to get the accelerometer data).

The problem is thet I am not sure if this is the best way to proceed.

I have configured the USB type as Audio and the CPU speed at 48Mhz.
 
What is "interval_one"? The timing of your code depends on this, but you don't show it to us!

I also don't understand this:

when I try to read the serial port in matlab, the incoming data rate is very slow (Seria monitor data seems to freeze)

Taken literally, this sounds like you've got the Arduino Serial Monitor window open and showing data scrolling, then your Matlab code tries to also open the port. I still have no idea if you're using Mac, Windows or Linux... but if this is what you're doing, it sounds exactly like what happens with Linux when 2 programs open the same port. Mac and Windows don't ever allow the 2nd port open to succeed. Linux does. Both programs can send, but neither reliably receives.

But again, this is still more guesswork! We're *still* in the dark about what you're actually doing on the PC (or Mac) side, or even which OS you're running (all 3 have different behavior when you push things to their limits), and on top of that, since you didn't show a complete program it's impossible to even estimate how much data you're really transmitting.

Can you understand how we want to help you, but you're making this process rather frustrating by withholding key info?
 
But I can comment on the use of a sine wave to transmit 2 parameters, with its amplitude & frequency.... now that I can see that part.

As a best case scenario, this can transmit at most ~344 messages per second, because the audio library updates with the new waveform parameters every 128 samples.

That's very slow. USB Serial can work so much faster than this. If you're attempting much faster than 344 messages per second, it can't possibly work the way you've shown. If you're sending at a slower rate, Serial is plenty capable. If Serial isn't working with a slow data rate, let's focus on that side. There's probably something simple wrong here if the data rate is low, maybe as simple as 2 programs on Linux opening the same port.
 
What is "interval_one"? The timing of your code depends on this, but you don't show it to us!

I also don't understand this:



Taken literally, this sounds like you've got the Arduino Serial Monitor window open and showing data scrolling, then your Matlab code tries to also open the port. I still have no idea if you're using Mac, Windows or Linux... but if this is what you're doing, it sounds exactly like what happens with Linux when 2 programs open the same port. Mac and Windows don't ever allow the 2nd port open to succeed. Linux does. Both programs can send, but neither reliably receives.

But again, this is still more guesswork! We're *still* in the dark about what you're actually doing on the PC (or Mac) side, or even which OS you're running (all 3 have different behavior when you push things to their limits), and on top of that, since you didn't show a complete program it's impossible to even estimate how much data you're really transmitting.

Can you understand how we want to help you, but you're making this process rather frustrating by withholding key info?

Hi Paul, Thanks for your reply.
"interval_one" is the time in which I send data over the Serial port (Or waveform1.frecuency and waveform1.amplitude) and then i use other varibale called "interval_two" to send a known data frame saying "I am in the second loop". This is just to know that I have been sending data during 5 seconds and the I go to the other loop for one second to print that message.

Actually I am using windows, sorry for not clarify it.
 
But I can comment on the use of a sine wave to transmit 2 parameters, with its amplitude & frequency.... now that I can see that part.

As a best case scenario, this can transmit at most ~344 messages per second, because the audio library updates with the new waveform parameters every 128 samples.

That's very slow. USB Serial can work so much faster than this. If you're attempting much faster than 344 messages per second, it can't possibly work the way you've shown. If you're sending at a slower rate, Serial is plenty capable. If Serial isn't working with a slow data rate, let's focus on that side. There's probably something simple wrong here if the data rate is low, maybe as simple as 2 programs on Linux opening the same port.

And, could it be possible to modify the Audio library to stream the accelerometer data as "audio"? I think this would solve my issue in this project. What I have realize is that the audio library takes the values from the "data_waveform" values and uses them to create the waveform, correct me if I am worong.
 
And, could it be possible to modify the Audio library to stream the accelerometer data as "audio"?

Possible, yes. Whether this is a good approach is another matter.

To answer your question, here's the info to get started creating your own custom features inside the audio library.

https://www.pjrc.com/teensy/td_libs_AudioNewObjects.html


Having said this, and *still* in the the dark about how many times per second your code tries to send data, I'm going to suggest that you're really going down a very wrong path. Well, wrong, in terms of the pragmatic goal of getting data from Teensy to Matlab. If you're interested in synthesizing data modulated waveforms and doing demodulation in Matlab, then maybe this is a fun side quest?

But if you simply want to get data transfer working, since there is a delay(1) inside the code you showed, you can't possibly be trying to send more than 1000 data pairs per second. USB Serial is plenty fast enough for 1000 per second, even printing the numbers as ASCII text.

I know you've concluded that USB serial isn't working, or Matlab's implementation of it doesn't work, and my point is I disagree. Many people have used Matlab with Arduino and Teensy for data transfer faster than you're attempting. Somewhere, somehow, you're doing something wrong, because USB serial is so much better than this.

But if you really, really want to try modulated audio waveforms, an approach far more difficult and complex than printing ASCII text with USB Serial, then go for it. Just consider if you ask for help here, notice the "Forum Rule" where we generally expect to see code that can be copied into Arduino and actually run. If you withhold details about what you're doing, if you aren't specific about details (like how you've still not said what the actual value of your "interval_one" variable really is so we don't know how many times per second), you're only hurting your own chances to get useful help.
 
Ok, in my previous post I tried to explain the code and that is why I Wrote it by parts. Here you have the whole code as It is now.
Also, I have connected the ADXL345 accelerometer via I2C to the teensy 3.2 board.

the intervals are for sending the data from the accelerometer during

Thanks!

Code:
#include <Audio.h>
 #include <Wire.h>
 //#include "arduinoFFT.h"
 #include "audiostream.h"
 //arduinoFFT FFT = arduinoFFT();
 
 //GUItool: begin automatically generated code
 //AudioSynthWaveformSine   sine1,sine2,sine3;          //xy=265.0000305175781,430.0000629425049
 AudioSynthWaveform       waveform1;
 AudioMixer4              mixer1;
 AudioOutputUSB           usb1;           //xy=454.0000114440918,462.00001430511475
 //AudioConnection          patchCord1(sine1, 0, mixer1, 0);
 //AudioConnection          patchCord2(sine2, 0, mixer1, 1);
 AudioConnection          patchCord1(waveform1, 0, usb1, 0);
 //AudioConnection          patchCord4(mixer1, 0, usb1, 0);
 
 //extern const int16_t myWaveform[256];
 
 AudioOutputI2S out1;
 //GUItool: end automatically generated code
 
 
 //************************//
 //**************************adxl345 address*****************//
 //Direccion del dispositivo
 const int DEVICE_ADDRESS = (0x53); //Comprobado con el I2C Scanner
 byte _buff[6];
 
 //**************************ADXL345 registers********************//
 char POWER_CTL = 0x2D;
 char DATA_FORMAT = 0x31;
 char DATA_RATE = 0X2C;
 char DATAX0 = 0x32;   //X-Axis Data 0
 char DATAX1 = 0x33;   //X-Axis Data 1
 char DATAY0 = 0x34;   //Y-Axis Data 0
 char DATAY1 = 0x35;   //Y-Axis Data 1
 char DATAZ0 = 0x36;   //Z-Axis Data 0
 char DATAZ1 = 0x37;   //Z-Axis Data 1
 uint8_t numBytesToRead = 6;
 
 //**********alpha gravity**************//
-
-double alphaX = 0.80; 
-double alphaY = 0.80;
-double alphaZ = 0.80;
-double gx,gy,gz;
-double acc_z_final;
-double acc_y_final;
-double acc_x_final;
+//
+//double alphaX = 0.80; 
+//double alphaY = 0.80;
+//double alphaZ = 0.80;
+//double gx,gy,gz;
+//double acc_z_final;
+//double acc_y_final;
+//double acc_x_final;
+//unsigned long time_since_last_reset = 0;
+//int interval_one = 5000; //5 seconds. 
+//int interval_two = 5000; //5 segundos.
+//double final_data[3];
+//short bufSize = 6;
+//bool message = true;
+
+float alphaX = 0.80; 
+float alphaY = 0.80;
+float alphaZ = 0.80;
+float gx,gy,gz;
+float acc_z_final;
+float acc_y_final;
+float acc_x_final;
 unsigned long time_since_last_reset = 0;
 int interval_one = 5000; //2 seconds. Loop principal de muestreo (por defecto estaba a 20 o a 10)
 int interval_two = 5000; //5 segundos. Loop secunedario de muestreo.
-double final_data[3];
+float final_data[3];
 short bufSize = 6;
 bool message = true;
 
 //Filter
 
 //Eje Z
-double EMA_a_Z = 0.93;
-double EMA_s_Z = 0;
-double highpass_Z = 0;
+//double EMA_a_Z = 0.93;
+//double EMA_s_Z = 0;
+//double highpass_Z = 0;
+
+float EMA_a_Z = 0.93;
+float EMA_s_Z = 0;
+float highpass_Z = 0;
 
 //Eje Y
-double EMA_a_Y = 0.93;
-double EMA_s_Y = 0;
-double highpass_Y = 0;
+//double EMA_a_Y = 0.93;
+//double EMA_s_Y = 0;
+//double highpass_Y = 0;
+
+float EMA_a_Y = 0.93;
+float EMA_s_Y = 0;
+float highpass_Y = 0;
 
 //Eje X
-double EMA_a_X = 0.93;
-double EMA_s_X = 0;
-double highpass_X = 0;
+//double EMA_a_X = 0.93;
+//double EMA_s_X = 0;
+//double highpass_X = 0;
+
+float EMA_a_X = 0.93;
+float EMA_s_X = 0;
+float highpass_X = 0;
 
 
 void writeTo(int device, byte address, byte val) {
         
 //        
         //G force without the EMA filter
-//      gx = alphaX * gx + (1 - alphaX)*x;
-//      gy = alphaY * gy + (1 - alphaY)*y;
-//      gz = alphaZ * gz + (1 - alphaZ)*z;
+      gx = alphaX * gx + (1 - alphaX)*x;
+      gy = alphaY * gy + (1 - alphaY)*y;
+      gz = alphaZ * gz + (1 - alphaZ)*z;
 
         //G force with the EMA filter
-      gx = alphaX * gx + (1 - alphaX)*highpass_X;
-      gy = alphaY * gy + (1 - alphaY)*highpass_Y;
-      gz = alphaZ * gz + (1 - alphaZ)*highpass_Z;
+//      gx = alphaX * gx + (1 - alphaX)*highpass_X;
+//      gy = alphaY * gy + (1 - alphaY)*highpass_Y;
+//      gz = alphaZ * gz + (1 - alphaZ)*highpass_Z;
         
 
 
         //m/s2 output withouth EMA
-//        acc_x_final = (x - gx) * 0.0039* 9.81;  
-//        acc_y_final = (y - gy) * 0.0039 *9.81;
-//        acc_z_final = (z - gz) * 0.0039 *9.81;
+        acc_x_final = (x - gx) * 0.0039* 9.81;  
+        acc_y_final = (y - gy) * 0.0039 *9.81;
+        acc_z_final = (z - gz) * 0.0039 *9.81;
 
         
          //m/s2 output with EMA
-      acc_z_final = (highpass_Z - gz) * 0.0039 *9.81;  
-      acc_x_final = (highpass_X - gx) * 0.0039* 9.81;  
-      acc_y_final = (highpass_Y - gy) * 0.0039 *9.81;  
+//      acc_z_final = (highpass_Z - gz) * 0.0039 *9.81;  
+//      acc_x_final = (highpass_X - gx) * 0.0039* 9.81; 
+//      acc_y_final = (highpass_Y - gy) * 0.0039 *9.81;  
  
 
 //
 //        Serial.print("\t");
 //        Serial.print(acc_y_final);
 //        Serial.print("\t");
-//        Serial.println(acc_z_final);
+        Serial.println(acc_z_final);
+        delay(5);
 
 //         sine1.frequency(acc_x_final);
 //         sine1.amplitude(acc_x_final);
 //         sine2.frequency(acc_y_final);
 //         sine2.amplitude(acc_y_final);
-         waveform1.frequency(acc_z_final);
-         waveform1.amplitude(acc_z_final);
+//         waveform1.frequency(acc_z_final);
+//         waveform1.amplitude(acc_z_final);
 //         Serial.write(acc_z_final);
 //
 //         sine1.frequency(0);
 
         }
 
-        time_since_last_reset = millis();
-        while((millis() - time_since_last_reset) < interval_two){
+        //time_since_last_reset = millis();
+        //while((millis() - time_since_last_reset) < interval_two){
 //  if(message)
 //{ message = false;
 
-       waveform1.frequency(160);
-       waveform1.amplitude(1.0);
+       //waveform1.frequency(160);
+       //waveform1.amplitude(1.0);

 //    delay(1);
 //
 ////}
 //time_since_last_reset = millis();
-}
+//}
 
This code looks like you're attempting to send only 2 numbers once every 5 seconds.

USB serial is capable of printing *many* thousands of numbers per second. Printing 2 reading at only 0.2 Hz is very, very slow. I just can't understand how you're experiencing a problem described as "Serial.print instruction is very slow for my purpose".
 
Why must it always be USB? Can you young people with long hair and electric music not simply connect your midi stuff with traditional DIN plugs? ;)
 
I still don't get why "audio" is needed to transfer accel-data. And why the program uses audio?

And if you use matlab - why don't you use it to do all these calculations? - esp. "double" is very very slow an Teensy. But this shouldn't make your prints slow. In the skecth above (which will *still* not compile because of all the "+" and "-" in the code) you're using waiting-loops - so what do you expect?

In most cases, it helps to write a super-simple-program:
Code:
void setup() {}

void loop() {
 Serial.print("Hello World ");
 delay(50); //<- this has a reason
}
I had to insert the delay, because without my PC is not fast enough... (Arduino-Serialmon is too slow)
With the delay, it prints the message in 50 millicsond intervals. Please try that, and you'll see: It's not slow. (And does not use "audio"..)

@Paul: Error-message: Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
 
Last edited:
Do it simple, in several steps:

1) write a simple program like the one above and test if matlab is fast enough to receive all data in time. In the above example, even the Arduino monitor on my PC in NOT fast enough (without the delay)
2) Remove all the audio-stuff and modify your program to make 1000 reading of the ADXL and measure the time. Use micros() to measure it. You now have the fastest possible print-speed (x1000 to get an average) . If it is too slow, not the printing is the problem - it's the ADXL or I2C Speed.
If too slow:
- Read the ADXL-datasheet to find a way to make it faster.
- Try to increase the I2C Speed - it defaults to only 100kHz - not much. Most chips can do 400kHz or way more - again, read the Datasheet for the ADXL.
3) print the raw data without any calculations. Add the calculations if the printing is fast enough now.

4) Don't use delays... as long as the ADXL does not need it. Or try to do the calculations and prints during the needed pause.

And most important: Tell us how fast you need it - and how fast it is (I don't think that program above is your real program - it prints, as Paul says, in 5 seconds intervals)

Edit:Errr.. wrong - the code does not reset "time_since_last_reset" - it's commented out.

0) FIRST, POST A WORKING PROGRAM - really, we can not help you if you're not doing this. We want, but we need solid information to work with.
 
Last edited:
I now saw in your code some posts above that you're setting the ADXL to a frequency of 200Hz.
Code:
void setup() {}

int i = 0;
void loop() {
 Serial.println(i);
 i++;
 delay(5);
}
The Arduino-Monitor shows all data and it seems to be correct. Now use matlab and check if it is fast enough to receive the data.
 
Status
Not open for further replies.
Back
Top