everything loops normal speed without any hesitations like this
(connected to BT, but BT input swapped for static string)
really? nobody knows what's goin on here with this?
Please have some patience.
I have posed a clear question, but that first copied response hits home - I run a youtube channel with over 50 million views (primarily teaching folks classic automotive tuning tech) as well as a sizeable facebook page so folks can directly ask their questions.
sometimes I get impatient because I answer so many questions, yet its common for my own questions to go unanswered - like indefinitely.
my apologies for prodding. this has eluded me for awhile and I'm just really hoping for a solution.
Place a Label to see what you're getting on BT_INPUT.
Increase the timings in the Arduino code to see if it's a timing issue.
Send the data as String.
Im going to try a few things with how i send the data -
the BT chip seems to keep up on the receiving end no problem since i change the value in this test every 100ms and i see the values increment correctly in the app.
its something on the backend of "call bt.receivetext number of bytes -1" where it takes so long to pull that the app gets behind even though the timer is looping at 10ms. again, if i use a string vs that BT bit, the app doesnt chug.
I have no real hard knowledge of BT handling protocol, but it seems like somehow its taking awhile to pull from the phone buffer or write to the phone buffer.
might be the way im structuring the data im sending causing issues on phone/app side, BT chip has no problem receiving it - have a few things ill try here today to see how things respond.
slowing it down would defeat the purpose to a degree, although it would bandaid the issue - it could be my lack of knowledge on the subject, but i dont feel like "every 100ms" is too much to ask. I have to be hindering speed in some way in what im doing.
will follow up with solution if i solve it.
What does the F(text) function do on the sending side?
Also, I recommend concatenating arriving input with timestamps to a log, either a List or a multiline Label, to get a grip on timing.
Consider time stamping start and end of each Timer event, to see how long they take.
handles memory a little different where it doesnt burn up dynamic memory.
Im going to give this a try:
Serial.println(""+(vac)+" inHg"+(AverageAFR)+"*"+(AverageRPM));
not sure how that will play with the delimiter byte 10 unless the LN of Serial.println satisfies it.
Println() does indeed add a Line Feed (decimal 10) character, perfect for delimitting end of message.
Also, the more you decorate your numbers, the more work on the receiving end unwrapping the data. JSON is worth learning, but mind BlueTooth message length limits.
you make a good point - theres no reason i cant strip the labels and put them in after the string is read and parsed. dumb on my part to not already do that.
Ill give these things a try and report back - I very much appreciate your insight and help.
So this is an auxiliary app for reading serial data (not MIT App Inventor) - its picking up the same data clean without issue (no chugging and keeps up with the "every 100ms send data" scenario)
I hadnt changed anything at the time of this test.
im more and more convinced theres something on the app side that isnt happy.
going to give this a shot and see how it takes.
if (vacuum > 0) {
String vacBT = String(vac);
String AverageAFRBT = String(AverageAFR);
String AverageRPMBT = String(AverageRPM);
Serial.println("*"+(vacBT)+"*"+(AverageAFRBT)+"*"+(AverageRPMBT));
//Serial.print (F("*"));
//Serial.print (vac);
//Serial.print (F(" inHg"));
//Serial.print (F("*"));
//Serial.print (AverageAFR);
//Serial.print (F(":1"));
//Serial.print(F("*"));
//Serial.print(AverageRPM);
//Serial.println();
}
wow . . .
so not that anyone would care, but I did figure it out.
it is something in the app backend for sure, but not necessarily the app's fault.
I was using the HC-05 chip for all of this - which it itself is the problem.
I scrubbed everything from my app, except a very simple BT routine where every 250ms I was sending 4 digits together, scanning every 50ms for available BT input - so extremely simple.
was still irritatingly slow - ironically that near half second delay anomaly was STILL present.
tried a different chip - an HC-06 that i have probably had since 2019, and it was flawless.
throttled everything up, still flawless - so the BT chip IS the issue WITH app inventor (since it worked flawlessly on the terminal app in my image above.
So, I did some sleuthing online - it seems that im not the only one who has encountered this.
apparently theres a "new" chip on a lot of HC-05's that is "slow" for SOME people - probably depends on what they are using it with - in the case of App Inventor, its slow.
So, I dug an old HC-05 out of an old project and sure enough . . . no issue.
previous people noted a difference in the two chips on the front, the older HC-05 having both chips be the same width with the new HC-05 (that is slow) having one chip be wider.
if anyone knows what the difference is, id be interested just for the sake of knowing.
its something with how MIT App Inventor interacts with that particular BT setup - like everytime the chip sends data, its almost as if its waiting for a handshake that it never gets and has some override timeout, no idea.
1 Like
How many bauds do you have your HC-05 set to?
Now that's a solid suggestion - I'd completely beleive that some are set to 9600 and the new ones are on a different baud. I'll take a look - id like to get to the bottom of this so no one has to deal with what I did.
It was exceptionally irritating.
Dear @Reality_Bytes,
I agree that this is not the solution to your problem, but since I've used many times both HC06 and HC05 shields connected to UNO's or NANO's or MEGA's, what I suggest you is to:
- have a look to the annexed files (there are some hidden tricks that not always are known):
HC06 Connection_3_3VDC.pdf (714.6 KB)
HC-05 Datasheet.pdf (840.6 KB)
Please take care that some HC05's work, by default settings, @9600 and some others @38400 (but again this is not your problem, just for sake of knowing).
Anyway, by reprogramming them via AT commands, with both shields I've been able to work @115200 baud and to reach a continuous rate of communication without lags (down to <100 ms each frame of 34 bytes). ARDUINO being the sender: (client in terms of BT) and AI2 the receiver ((master BT). In other words, every 50 ms a clock in the AI2 app looks for an incoming BT buffer and reads it till the teìrminator (Ascii LF).
- second hint is:
evaluate to use an ESP32 board which has already on board the BT I/F. By considering the cost of a UNO or a NANO + a BT shield (whatever HC05, HC06 or HC08) it's cost effective to use a single board. The only cons is that the ESP32 works @3.3 Vdc, therefore the I/O must be connecetd with care, but as far as the space integration, Flash memory amount, RAM memory amount, number of I/O's, IMHO the ESP32 wins.
As I told at the beginning this is not the solution to your problem, but I hope it could be of some help for future projects... 
Wishing you success. 
Ill take a look - I have some tricks of my own.
people always say they wish they could auto connect to BT device. Aside from putting the address directly into the program, its simple to just parse out and save the address to tinyDB, and then if tiny DB has an address, on screen initialization it attempts to connect to that address.
also, while app is running, if connected once and then connection lost (can be tracked through a continued handshake), that address you were connected to is repinged every x amount of time.
Im taking a look here now to test different chips, i have some old HC-05, some new HC-05s, and an HC-06. one of the new HC-05s is even soldered differently to the backboard - so I expect to see some interesting things. (I picked the HC-05 originally since I always seemed to be able to rename them without trouble).
Dear @Reality_Bytes,
yes so do I, when a BT client fails for a while (i.e. a timeout) I try to reconnect it twice. If the fail persists an error popup is raised. My approach is: instead of having a "continuous" handshake the AI2 clock that fires every 50 ms, increments a counter if no characters have arrived from the BT. If the counter reaches 10 (the timeout) the app tries to reconnect the BT client . If not, after two attempts, the BT death is declared 
Typically I write the addresses of the already paired BT devices (i.e. arduino shields, or EOBD-BT interfaces) on a file, and at the start of the app, I retrieve them in sequence until one of them is linked.
Originally (a few years ago) I was using the HC06 : it was really easier to interface than the HC05. Less options, therefore less troubles.
Anyway, after some (tricky, though, at the end, working) experiences with the HC05, I decided to switch to ESP32 that features an integrated BT (and WiFi).
Best wishes.
depends how often you are sending telemetry - on the above project, when connected data should come in every 1/10 of a second - so same deal as you in this case. a true false connected bit, and a counter incrementing everytime no signal is present. if x on counter, then reconnect routine is active.
I would use something else, but im partial to the IDE and im on a custom PCB board in an automotive application scenario. really only an atmega chip is only arduino related component.
alright, confirmed i'm in fact not crazy.
Left HC-05 connects easy and clean, accepts AT commands - flawless with 0 issues, 10 strings per second no problem or lag. problems noted at beginning of post are non-existent.
Middle-Left HC-05: wouldnt work at all. characters are skewed, so its definitely a different baud rate - but wouldnt take AT commands?. notice its the same chips but the soldered connections as well as top board are different.
middle-right HC-05: same issues as noted at beginning of post - seems to momentarily freeze, and then Gatling gun the data every half second-ish or so. Baud is correct, takes AT commands no problem. notice again yet another back board config with this time completely different chips, although gold fingers soldered the same as the perfect board.
right HC-06: ah yes, the one everyone tells me to use and that NOT using it is causing my problems. well, it does literally the same as the board noted above (middle-right). visually its also the same as the noted HC-05 board - solder connections and all. only difference being the lack of pins and AT mode button due to being an HC-06. bottom chip is different brand but appears same (the chip that on the middle-right HC-05 has a gold checkmark.
anyway, theres some real funk going on here - all of these were tested with literally the same app program.
1 Like
Dear @Reality_Bytes , yes if effect the "electronics" is the proof that Holy Spirit exists, like my Electronics professor once said (approx 40 years ago, and it sems that it is still valid)... 
.
Nice to read that you've got rid of this trouble.
All the best, Ugo.