That sounds like either a missing end of message delimiter ( \0 or \n) at the transmitting end.
How does the transmitting BLE package know when to transmit?
OK, that would point to physical damage of some kind. As I mentioned, you are not the only App Inventor developer to hit this issue. The board should be under warranty for a free replacement. Unless you damaged it yourself, allowing it to overheat, dropped it or whatever.
Here is a more robust parser, not vulnerable to broken pairs:
(In retrospect, it might choke on ',' alone.)
Need to look upstream.
May I answer it sir? Sorry if my answer is wrong
To find out when the BLE package is to transmit, can't we already know if we press the register button, then BLE will initialize RegisterforString. From there, haven't we also ordered BLE to transmit data?
1 Like
Yes.
So, I think just giving the Label Nilai_1 a fixed height should stop it expanding into infinity (and beyond). I have made what is a terribly long-winded catch for wonky values but it should work:
LED_Control_6E.aia (617.4 KB)
Here is the upstream code, which I am weak on:
char sSensorVals[16];
unsigned int nilai_sensor;
unsigned int nilai_sensor2;
...
{
lgUpdateTime = millis();
nilai_sensor = analogRead(A0);
nilai_sensor2 = analogRead(A1);
sprintf(sSensorVals, "%u,%u\0", nilai_sensor, nilai_sensor2);
switchCharacteristic.writeValue(sSensorVals); //Send value pair to App
}
Here are some stabs in the dark for this code:
- Is 16 bytes enough for the sprintf buffer?
- Does sSensorVals need to be cleared between sprintf calls?
- how does the %u print format work? (Can it be broken with bad input?)
- Does that trailing \0 really work, on both ends of the transmission, to delimit messages?
Some good points!
16 bytes: anologRead() outputs unsigned integers between 0 and 1023
1023,1023\0\0 = 13 UTF-8 string bytes. Note, Sprintf() should add it's own null (\0) but for some unknown reason that can go missing, so imposing another is a belt-and-braces measure. We should test without the extra \0, see below.
sSensorVals: Should not need to be cleared, but there is no harm in doing so.
%u: is a place holder for an unsigned int. That should be bullet proof but it is possible for the sensor to glitch, depending on sensor quality and the environment.
\0: Yes, that seems to be working, Muhammad has a working graph. It is technically not a delimiter but an end-of-string flag. Each value pair is streamed to the App per 1 second (Arduino timing is more accurate than Android timing).
Some more stabs in the dark:
This error text does not appear in the app, so I am going to point the finger at the Kio graph block, because it does not match any AI2 list block complaint I have ever seen before.
I assume the Kio blocks maintain their own internal lists, because their graphs extend across the Canvas and that graph block accepts two points at a time.
I notice there is an initialization call in
but it is not initialized in Screen init, so I suggest adding it:
That hardly makes sense, though, since the graph starts out okay.
Is it possible that the graph extension reaches an internal limit?
Based on the error message alone, I would switch to the AI2 list based graph component, with two input list Chartdata components.
Example:
(needs an extra chartData component, does not need normalization.)
Regarding ABG's comments about the Sketch:
Apart from the latest App Inventor Blocks fix, here is a modified Sketch that clears the sSensorVals string before the next value is applied. Also, '\0' is removed from sprinf(). Hopefully this will be even more robust.
ACTUATOR_COBAK6e.ino (8.3 KB)
The error message is triggered by the wonky value passed to the extension.
I think it would be good not to use an extension as there will be no point Juan maintaining it in future, now that App Inventor has it's own charts component.
Does the App Inventor chart allow run-time updates the way Juan's does? It will still require the code to omit wonky values.
... one way to make everything more robust would be to increase the time interval from one second to two seconds.
Hi Juan - that's actually very similar to earlier code. I think our latest code will ensure that wonky values will not get through to the graph.
I I've tried it, sir, but I can only catch it once, however the signal changes, it's still the same
Maybe I can try it first sir 
Hi Muhammad
Not sure if that's the Sketch or the App - I don't understand what you mean 
Can you describe the latest situation again (E.aia and E.ino) with the aid of an image?
Like our first code, it would let for example "444," and ",444" through.
I think the difference is that the .aia files are not showing in the labels
I don't know if I use labels, is there a number that is wonky again or not