What is the DelimiterByte in Bluetooth?
What clock interval do you use?
To test, receive the data as text, set a slower Arduino delay, delay(1000).
Check in this Community topics about Bluetooth.
Edit: Here is an example with a small Stepper Motor, in this case information is sent from the App to the Arduino.
Bluetooth HC-06. Arduino. Send. Receive. Send text file. Multitouch. Image - #14 by Juan_Antonio
Hello,
thank you for your reply.
MIT's current DelimiterByte is currently 0 (I admit I don't know what it's for yet)
How to receive data as text?
Thanks for the links, I'll go check it out.
Hi there,
Searching the internet, I found the solution.
I am sharing MIT blocks with Delimiter Byte value at 10 + Arduino code.
I haven't tried to display the position of a stepper motor yet.
But apparently after a quick test, it works very well for me to display the value of a potentiometer. 
Hello,
I managed to display the steps of a stepper motor in a label.
I am sharing some picture and video if it can help anyone.
However, one problem chases another...
In my Arduino code, I'm forced to put two things in there:
bluetooth.println(messageBT);
delay (…);
My new problem is that the addition of these two things slows down, see practically stops the rotation of the motor...
If someone has an idea…
I use the AccelStepper library.
From the experience of others with this problem, the recommended solution is to replace the delay() call with an extra variable, Last_Time_Transmitted_ms, which would hold the last System Time in Milliseconds from 1970 (default 0) when the Arduino issued a BlueTooth println(). In the loop(), each cycle you should check if (Current SystemTime in ms) - Last_Time_Transmitted_ms > 25 (whatever your delay was) .
If the difference > 25, do your println and reset the Last_Time_Transmitted_ms to (Current SystemTime in ms), else do nothing.
P.S. 25 ms might be too frequently for AI2 to handle.
(added to FAQ)
(added to FAQ)
Thank you for this lead, I will explore it.
Like this:
unsigned long lgUpdateTime;
void setup()
{
lgUpdateTime = millis();
}
void loop()
{
if(millis() - lgUpdateTime > 100) //Loop approx every 100 milliseconds
{
lgUpdateTime = millis();
//everything else here
}
}
Thank you for your answers.
Putting in a "millis" instead of a "delay" pretty much fixed the issue.
I share the code snippet that worked for me:
if (millis() - lgUpdateTime > 100) //Loop approx every 100 milliseconds
{
lgUpdateTime = millis();
messageBT = (String) pasMoteurZ + "," + (String) pasMoteurY + "," + (String) pasMoteurX;
Serial.println(messageBT);
bluetooth.println(messageBT);
}
However, we feel a (I don't know how to translate this word in English... in French: "à-coup", in English maybe "jerk", it's a slight delay, as if the code stops a few millis ) in the rotation of the motor every 100 millis.
I think (not sure) it came from the line: messageBT = (String) pasMotorZ + ", […]
Because for example when I write a single String (pasMoteurZ), the jerk is weak, and the more Strings I add (like pasMoteurY, pasMoteurX, …), the jerk is stronger and stronger…
I don't know if I was very clear in my explanations, don't hesitate to ask me for more information
Do you have an idea ?
Does Serial.println() block further code until it has finished?
Is there an asynchronous alternative, like buffering println() requests and having the buffer serviced through another process?
Maybe - strings should not be assembled at the microcontroller end, just send values to the App directly. If the values are arriving in the App and are as expected, comment-out the data send to the Arduino Serial Monitor, that alone will make a difference.
If the values are floats, use Serial to limit the decimal places.
Send the data to the App like so:
bluetooth.print(pasMoteurX);
bluetooth.print(",");
bluetooth.print(pasMoteurY);
bluetooth.print(",");
bluetooth.print(pasMoteurZ)
bluetooth.println(); //empty. tells App "End of Data" = LineFeed Ascii Char N° 10
I always recommend using the bar "|" as the value separator as it is most unlikely to be within a value and it's simply easier to see in the code, especially App Inventor code.
Also, with your Arduino loop set @ 100 milliseconds, Your App Clock Timer interval should be 80 milliseconds.
Hello,
thank you for your different answers.
I tried removing the :
I also tried as a replacement with this piece of code:
But unfortunately it still produces a microstop every 100 milliseconds.
However, this micro stop remains very light, and I don't think it will be a problem for the rest of my project.
Thank you all for your help! 
You can tweak the Sketch time interval and the App time Interval, maintaining the 20% difference - For example, try 60 milliseconds in the Sketch and 48 milliseconds in the App.
Thank you for your reply,
I tried 60 in the sketch, and 48 in the App, it had no effect (except that the micro stop is more often/faster).
Thanks for your proposition
Salut @Jon1 ,
si le délai est vraiment chaque 100 ms et la cause racine est vraiment le débit vers le BT, je te sugère d' accelerer la connexion de ton Arduino vers la carte HC05 (ou HC06?). Normalement j'utilise le baudrate @115200. Cette vitesse ne peut pas etre rejointe par la librairie Softwareserial, mais comme tu n'utilises plus le serial monitor tu peux utiliser la ligne Tx et Rx hardware (pins 0,1) qui peuvent etre utilisés à ce débit. N'oublie pas qu'il faut aussi coder le HC05 à la meme vitesse. Si tu regarde le site de @Juan_Antonio il y a beaucopu d'examples sur le sujet. Dans cette façon la vitesse de communication est 10 fois plus rapide (si maintenant ton débit est à 9600 bps). Tu peux essayer ça.
Bonne chance !
(je suis italien mais je parle un petit peux le français, mais si je n'ai pas été clair, je vais l'écrire en anglais )
That's a good idea Ugo, I already recommended shedding the burden of the Serial Monitor. Baud rate already is 115200 in the Sketch for Serial, possibly the HC05/06 has not been programmed to run @ 115200.
Hi @Chris,
Sorry I didn't reckon that the baudrate was already @115200. I just saw that Jon was using the SoftwareSerial library. As far as I know (i.e. in my experience) that library is working erratically over 38400 bps. Moreover, probably the library is waiting for the complete buffer flush before freeing the foreground code. Maybe the HW serial is using an interrupt sequence so it is less time consuming, but, anyway, the problem is really "interesting" and "challenging"...
Best, Ugo.