Howdy, I have been able to figure out a lot here, but i have finally hit a very annoying snag that i cant seem to get to the bottom of. see attached pictures, but basically I have tried to lead my serial string with a ( * ) to differentiate it from the rest of the incoming serial where I would then place this specific string in its own dedicated text box. ("*" currently not in serial string, but I have had it as the leading character).
this particular text box is to refresh for every time new data is to go into this field. clock is set to 50, which is much faster than the data is coming in.
now, where this gets strange is that i can print this data in my larger text box, where it runs perfectly - the only issue is when it clears the text box to keep printing the serial. basically when it clears it seems to miss some of the serial string - again, only when it clears the text box. (this is an issue because it can then print a part of the broken string into the wrong text box.
Don't know how you captured the Block Screenshot but it is very difficult to read.
Clearly, the error is not the Text Box, it is how the code processes the incoming text and in fact how that data is sent.
The issue is possibly because you are using a Clock Timer set too fast. The App must be set to process the data faster than it is received, but it needs a reasonable amount of time to process. It starts with the send speed determined by the Sketch loop. That should be as slow as possible. The App can then be set to be about 20% faster (elapsed time 20% less than Sketch loop elapsed time).
Sketch: Do not concatenate the data into one string, the commented-out lines are the best method.
Sketch: Make the last line an empty Serial.println();
Blocks: On Screen Init, set the Bluetooth delimiter byte to 10.
Blocks: BT receive text: Set number of bytes to -1. The "Bytes Available To Receive" Block is simply an indicator, not a record of total bytes available.
If connected, BT must be enabled - therefore just check that it is connected in the Clock Timer Block.
//ArduinoToApp.ino 29/10/2019 21:56:22
//Fake data stream to test App
// include the library code:
#include <SoftwareSerial.h>
//vars
unsigned int igUpdateTime;
void setup()
{
Serial.begin(9600);
igUpdateTime = millis();
}
void loop()
{
//Excute Serial Comms every 2 seconds
if(millis() - igUpdateTime > 2000)
{
igUpdateTime = millis();
if (Serial.connected())
{
//Data to App via Bluetooth
Serial.print("Hello");
Serial.print("|");
Serial.print("World");
Serial.print("|");
Serial.println();
//This last line tells App "End of Data"
// = Ascii LineFeed Char Number 10
//If the App uses Bluetooth Classic,
//set the Bluetooth Client Delimiter
//Block to 10 (math 10, not text 10)
}
}
}
Thanks so much for responding! it isnt enough for me to just use code - i like to try to understand what i am using as well. I have seen the delimiter byte scenario where a "new line" scenario prints out a "10".
it just seems like my methodology didnt track a "beginning or end" very well. is the delimiter where the the app logic knows "okay, this is the end of the incoming string". i tried to make my data a string originally to try to give it a clear cut "this chunk of data is what i want you to process together" scenario, but it didnt work. happy to remove the string as you suggest - waste of memory.
what does the "number of bytes -1" specifically do - what is the associated communication going on there.
im sorry for the seemingly novice question here, i very much appreciate your help - i can tell you really have a handle on whats going on here. !!!
awesome, that makes a lot of sense and seems to be what i have been pulling my hair out over. so i would assume this voids my ability have spaces in my text string - essentially i would have to use a different character, then replace it with a \n to replicate a space for the serial printout.
It is typical to have value separators such as the bar "|". This is useful if you want specific values to populate specific Labels in the App GUI. However, if you just want to List the values in a single Label or TextBox, then to keep it tidy, replace "|" with \n.
In theory, there is no difference but in practice a Serial.println() stand-alone ensures the Line Feed character ends the data stream. It is also more obvious that is the case when reading Sketch code.
i think i follow to a degree - so my spaces wont hinder me as they are now, but i may be misunderstanding on that regard.
I will probably try to catch this particular text by starting with a star "*", then changing that to a \n as only this info i want printed in the text box. currently i have this data updating twice a second as its necessary to do so - would that refresh speed cause any issues? originally i thought this was my problem, but i think you have showed me otherwise.
EXTREMELY useful info you are providing me here, and i do appreciate it.
Well, twice per second is marginal. If you display new data each time, you will not be able to read it! If you set the elapsed time for the Sketch @ 1 second, and set the App timer to 800 milliseconds, see how that goes first and then tweak for more speed if genuinely necessary - but you will no doubt hit a wall. Firstly, your microprocessor will slow down as it gets hotter and secondly, Android timers are mid-priority system events, so if you set the App timer to around 300 milliseconds, it may actually fire much slower than that. Certainly a good idea to ensure no other Apps are running.
solid advice - i will start slower and see where I hit the wall as i try to speed up the program.
excited to take a step closer to putting this issue to bed!!!
this is just a specific text box dedicated to sensor output data. i have an additional text box dedicated to all other incoming serial. this one piece of data that i screenshot i want to go to a specific text box only. otherwise it has worked very well - "very well".
the way i have the other text box set up is that when it gets to x amount of characters, it refreshes.
i want serial outputs from the arduino to be displayed in a list form to a degree.
if that makes any sense - the only issue i have is that depending on the length of each data piece, sometimes a few commands will print off screen before the text box refreshes. that's a minor issue i would like to correct at some point, but i don't want to burden you with the one at the moment!
that stuff i have had some fun with - before i figured out how to store data on the controller, i resent the data everytime the app was opened, and saved the data everytime it was changed while running.
LOL me trying to use the tinyDB function to store large amounts of data.
(errors are shown as I simply pulled this from the backpack)
Well, they do say you learn from your mistakes - I make a lot of mistakes and hence I know a few things
By the way, via the right mouse click menu in the Blocks work area, you can capture your blocks with "download blocks as image". This is a high quality zoomable image.
I don't see any place where you used the blue mutator to add extra local variable initializations. That would reduce the depth of your big brown onion.
