Serial Com. Nasty Text Box Error!

trash4 trash3

Good evening - your advice worked great and now that value discussed above is correctly reading in and updating within the desired text box - THANK YOU! cross that off!
BUT, originally in the other lower text box the serial would come in in list form - basically the same way the snip of the code shows. now it comes in like a string, where the new text starts where the old text leaves off - attached are my function blocks.
is there a way around this where i could get this text to come in how its printed in the arduino IDE (again, previous to these changes, the text came in correctly - Serial.println would drop the code into a new line directly below the previous Serial.println text).

i'm sure this is also very simple and im just missing something!!!

howdy,
what you instructed me to do worked great for the sensor readings. originally my other text box listed incoming serial like such (text box dedicated to notifications)
Serial.println ("hello");
Serial.println ("world");

text box output before:
hello
world

text box output now:
hello world.

what am i missing here to keep each new line dropping under the next in the text box of Serial.println is called?
this bluetooth thing has kicked my hind end as you can tell.

Hi
In App Inventor, add a newline (\n)

You can have two value delimiters. Remember what I said about not checking for an *?

Original idea
sensor data | all other data \n

Two value delimiters
sensor data | other1 # other2 # other3 \n

Split @ | to get
[Item1] sensor data (now standalone value)
[Item2] other1 # other2 # other3

Now use Text Replace on [Item2] to replace all # with \n and set [Item2] in the TextBox

Just spotted an error in my code - "OtherDataList" should simply be a String, not a List

Good Evening!
I was able to get everything sorted out - I just wanted to say thank you for taking the time and having the patience to help - especially because i'm sure you have answered a variant of my question many many times.

I'm actually a fairly well known youtuber with 150,000 subs and 35 million views - I do tech and tuning how to with classic v8 engines and carburetors/ignition timing. my handle is ThunderHead289.

Good to know you got it sorted :sunglasses:

I have followed a number of You Tube guides to fix various bits and pieces of my old merc, but my origins are the aircraft industry. As a young man I worked on Concorde, then various other aircraft as a designer. Almost the whole Airbus family has my work on wing stringers, for which I wrote a program on an Amstrad word processor :joy:

I have been looking over a couple of your videos on carburetors -totally professional in every way. You should have a dedicated TV show. Keep up the good work.

1 Like

howdy Chris, I hope you are doing well!
I have gotten pretty far on my little side project as I have had a moment to pick it back up again, but I am having issues with one thing. this is my Bluetooth logic, at least as far as where I receive my serial data sent out from my microcontroller.
im printing the data in two different areas depending on what I receive, one being sensor readout, and the other being feedback for when BT commands are made or when automatic adjustments are made based on the setpoint target parameters (controller sends feedback after receiving BT command which is displayed)

the issue I am currently having is that when Im consistently receiving feedback info, my APP will lag behind on the serial data. for example, if I shut the controller off entirely during this period, the APP will continue to populate serial data for about 4 seconds - almost as if the phone had received it, but the APP couldn't keep up with printing it.
is there a way i could mitigate this to some degree - I attached my block logic. is this a loop time issue as if I have too much in my APP program? im just not sure.
any insight would be greatly appreciated!!

(I could slow my functions down in my controller so the data is sent less frequent, but i prefer the speed of its functionality as it currently sits)
serialprint_loop

What do you have in Clock1's Attributes for milliseconds per cycle?

It should be less that the other side's delay() milliseconds, to let AI2 keep up.

in clock 1 I have 100ms.
my sensor read out is just above that, which I don't seem to have any issues with - as soon as I shut the controller off, the APP immediately stops reading (I tested this theory by commenting out my adjustment feedback in the controller program just to see what would happen.)

now I only allow it to make one adjustment a second using the millis() function which gives process a second to even out after every adjustment - so thats what really throwing me about this.

is there something I dont understand about the time it takes to print the feedback into the text box - its not long by any means, but the feedback definitely more serial data then the sensor readout.

I recommend adding a logger to timestamp and record incoming messages into the .Elements of a List Picker, with the latest visible in its .Text field.

Here's some sample code ...
Clicked on log

logger_to_list.aia (2.6 KB) sample run when btnEnter Click
II don't have a BlueTooth rig, so I fed the sample from a TextBox and an Enter button.)

1 Like

let me ask this, does it take time to print multiple lines of serial data.
like say I have:

if (adjustment scenario) {
Serial.println("potato");
Serial.println("potato");
Serial.println("potato");
}

transmitted to the app.

now, the controller continues to loop after sending this data sending sensor data - the APP has to then print this data in a text box - looping each time for each .println Serial call.
is this where im burning up my time? - like the APP is falling behind with the multiple .println calls?

like mentioned above, it doesnt lag behind on the sensor data that transmits more often than any adjustment call since I have a one second delay per adjustment.

if I understand how the app processes the data, which i thin k i may be lacking something, i may be able to think of a work around!

Maybe timestamp each potato ?
That might help diagnose the timing.

hey, it turns out i'm the Serial.println ("potato"). LOL

I had a moment to really look into it today and think about how the APP runs the code and processes the bluetooth with the delimiter byte and everything.
it makes sense why it was lagging behind if for every adjustment I would print a few lines of serial data with pertinent info to each adjustment scenario.

set to 100 milliseconds, it took almost a half a second to print several lines. the sensor output is looping faster than that among other things, so its no surprise I was having this issue.

Big duh moment - thanks for responding to my thread. had we not talked, I would not have thought any deeper about it.

problem is SOLVED!!!

Glad you solved it!

Half the Bluetooth problems I see here are

  • Dodge the swinging blades and the other half are
  • Lucy and Ethel at the chocolate factory.
1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.