too much bytes received on Teensy 3.1 ?

Status
Not open for further replies.

aleiks

Member
Hi everyone !

i create a project with Unity, Teensy 3.1 and his own bluetooth module. In Unity i've got an script that create an two bytes message (one for the pin's number and second for PWM intensity).

So in Update(), i've got create an test fonction

Code:
void Update()
    {
            for (int indiceTab = 0; indiceTab < NbLed; indiceTab++)
            {
                if ((brightness <= 0 || brightness >= 255))
                {
                    fadeAmount = -fadeAmount;
                }

                brightness += fadeAmount;

                TeensyNetWorkBT.analogWrite(pins[indiceTab], brightness);
            }
        }
    }

my fonction "TeensyNetWorkBT.analogWrite()" do that :

Code:
public static void analogWrite(int pin, int value)
    {
        byte[] message = new byte[2];
        message[0] = (byte)(pin);
        message[1] = (byte)(value);

        BtConnector.sendBytes(message); //une fois le message composé plus haut on l'envoie
    }

and my sketch analyse message like that :
Code:
void setup()
{
  Serial1.begin(9600); // ouverture de la connexion
}

void loop()
{  
  while (Serial1.available())
  {
    byte inputBytes[2];
    
    for(int n=0; n<2; n++) // on stock l'entrée dans un tableau
    {
      inputBytes[n] = Serial1.read(); // Then: Get them.      
    }
    
    analogWrite(inputBytes[0],inputBytes[1]); // ecriture sur le Teensy
  }
}


However I saw in debug console " Skipping profile frame. Receiver can not keep up with the amount of data send" appears and my Unity app crash ... so i know Teensy have 8 byte FIFO but even if I send per pack of 8 bytes with 0.1 sec wait it's the same problem my app crash after a random time.

anyone can help me ?

thanks for reply

A.
 
Actually I believe the Teensy 3.1 software wise has a 64 byte input queue. So I wonder if you are having more an issue with the BT communications or unity.

Sorry I don't know what unity is... So don't know if you have the option like on arduino to do the equivalent of a Serial1.flush to force the data out or if you need to do so.

Also there is the potential that your code could get out of sync. That is suppose you have only received one byte. Serial1.available will be true, but your second read could fail with a -1 value...

Many ways to fix, including first while: while (Serial1.available() >= 2).

At 9600 baud, in theory you can send about 960 characters per second, so you should easily be able to send your 80 bytes per second on the Teensy side. But again don't know how your BT works. On the Unity side does it try to send a complete packet for each 2 byte write you do? If so you may be overflowing at that side. You might want to try building a larger packet to send. Example your complete 8 byes...
 
You're receiving and using bytes in pairs.

What happens if the bluetooth module corrupts or misses one byte? Does you could forever use all subsequent bytes in the wrong order, until another error might occur, causing it to get back into sync?
 
Hi KurtE so Unity is an 3D / real time engine.

hi paul, i've didn't think to this possibility with the fact that bluetooth module can misses or corrupts one byte and if it done this mistake, i don't provide this possibility in my sketch.

I create a sketch which read only incoming bytes, that's all.

Have you got any ideas to increase my way to do for stop any crash ?
 
As a first step, I'd recommend running File > Examples > Teensy > USB_Serial > USBtoSerial.

You might change the code, so it sends every byte it hears from the bluetooth module to the Arduino Serial Monitor as HEX. For example:

Code:
        if (HWSERIAL.available()) {
                c = HWSERIAL.read();
                Serial.print((int)c, HEX);   // <--- send in HEX, so you can see in the serial monitor
                digitalWrite(led_pin, led_on);
                led_on_time = millis();
                return;
        }

Then you can watch the actual data Teensy is receiving from the module.

If there are problems with the data, hopefully you will be able to see in the serial monitor.

As you adapt your data format, perhaps to use 3 bytes so you can distinguish the beginning of a message, perhaps you'll also modify this code to use Serial.println(), so each message is a single line in the serial monitor.

Observing the real data will help you understand any problems and build a good solution.
 
Actually i can already read actual data of the Teensy send from the module with the two Serial.println()

Code:
void setup()
{
  Serial1.begin(9600); // ouverture de la connexion
}

void loop()
{   
  if (Serial1.available()>=2)
  {
    byte inputBytes[2];
    
    for(int n=0; n<2; n++) // on stock l'entrée dans un tableau
    {
      inputBytes[n] = Serial1.read();      
    }
    
    Serial.println(inputBytes[0]);
    Serial.println(inputBytes[1]);
    
    analogWrite(inputBytes[0],inputBytes[1]); // ecriture sur le Teensy
  }
}

and this is happens on serial monitor when i press on button which turn on the led 5 :
Code:
5 // <------ led
255 // <---- intensity

I think you're right when you said " use 3 bytes so you can distinguish the beginning of a message " but which byte can i use while i use it already from 0 to 255 ?

Do i send char before my message as byte for example ?
 
There are many ways to deal with this. Example the code the Arbotix people use for their Commander is their packets start with two 0xff bytes and they restrict their inputs such that in no other place can you have two 0xff bytes in a row... You could do something similar since I am pretty sure you don't have an analog output for pin 255...

With XBees in my DIY code base, I use it in packet mode, so I know that I have either received a full packet or not. I still have to do some verification as the packets could come faster than I can handle and I could overrun the input buffer and miss bytes... So again I do some verification.

You could add some verification, like for each pass the LED number will be > then the one sent before it...

But again I personally think your program failing on the unity side is not due to the teensy, not keeping up. But more with maybe how you are sending the data. If your program does not keep up with the input data coming in on the serial port, the additional data will simply be tossed in the input interrupt handler. So if I were you I would look into larger size packets and try to reduce how many are sent...

Kurt
 
Status
Not open for further replies.
Back
Top