That's good to know! I thought I was doing the App a service by shifting some of the load off to the Arduino.
What are you referring to when you suggest having the Serial.println() stand-alone?
And I've since fixed the interruptions between the Serial.prints and other concerns you brought up. Thank you for the suggestion.
Something I'm concerned about is that the buffer overflowing issue has been present since the simplified test of only sending out Distance, before I added any of the extra complications the end result needs to have. I'm starting to believe it could be the phone I'm testing it on since it's an old phone (Samsung S6) and I haven't been able to find any reproduceable issues others have had.
Of Bluetooth packet? It's about 23 bytes, of which 20 bytes is your data, so that's more than adequate for four integers. However, the overflow might be caused by what is happening with the Distance value? Very strange that it is correct on the Terminal but not the App.
The S6 is a well specified phone, certainly suitable for your Project. Does it have a huge number of Apps, files etc on it?
The way to minimise the potential for buffer overflow caused by process time is to increase the time interval of the Sketch. Usually I would say start off with a large interval, say five seconds in this case, then tweak the value down until the App can't cope (App set @ 20% shorter interval for every test).
Edit: Does the phone have an anti-virus App, in addition to the AV that was pre-installed on the phone by Samsung? If so, it's possible that your tests are being treated as suspicious and the App being examined at runtime. This can be a killer, so it's necessary for the App to be on the AV 'white list'.
No, I wouldn't say so. My assumption was based on the feeling of running out of options on the source of the problem.
Could you elaborate on this please? I'm not sure I understand what you mean.
The overflowing issue happens approximately every third update, regardless of how frequent updates occur.
Here are a few examples I've got screenshotted as updates occur with their respective Serial Monitor on the Arduino side. It's as if the new input is being added onto the old value every now and then instead of the expected result of replacing it.
There is an Arduino Lib that delivers Ambient Temperature and Relative Humidity without any reference to an event: "dht.h" -used this for a Water Monitor project. Value output very simple:
Serial.print(DHT.temperature, 2); //Ambient Temperature
Serial.print('|');
Serial.print(DHT.humidity, 2); //Relative Humidity
Serial.println();
...but we don't know Aj's exact hardware setup nor the goal of the Project.
Having the distance as a float has been a change I made from when I was still going to be doing the unit conversion from the Arduino. Now that we're keeping that part of things in the App, i'll switch it back to int. That's correct.
Since changing things back to int and how they were originally, the problem still persists.
So what is the exact Arduino you are using AJ? Adafruit libs tend to be specifically for Adafruit boards and they are generally a bit different to verbatim Arduino.
I'm using an Arduino Nano. Do you believe the problem has more to do with the Arduino than the App considering the problem also happens when I'm only sending Distance?
An overachiever problem I put some time into solving before scrapping it as I ended up putting more time than I'd like and can afford into solving the buffer problem
I might just wait till I have access to another phone to test from and report from there.
Regarding the Adafruit Lib, good catch! I've adjusted it as suggested.
It does not look as though the Adafruit Lib is needed, not that it should in any way affect the Distance value problem.