Ok, bit of stretch but im totally confused right now.
#include "FastLED.h" // included for EVERY_N_MILLIS non blocking delay function and my main code uses it elsewhere
#include <SoftwareSerial.h>
SoftwareSerial HM10(9, 8);///9 (RX) ///8 (TX)
char AAA[6] = {'W', 'W', 'A', 'T', 'T', '\0'};
//This is the only data format i've managed to use to receive anything legible on AI2 while using softwareserial.
void setup() {
Serial.begin(9600);
HM10.begin(9600);
}
void loop() {
EVERY_N_MILLIS(10000);{
HM10.write(AAA);
}
}
I can't seem to get the string to stay as a readable format. It keeps switching back to unreadable data.
"["� �_��"]" If i change encoding to utf16 true. The "["� �_��"]" turns into chinese characters.
Im so lost so any help in understanding whats going on would be great. If i rapidly tap Button1 the correct data shows for a split second before reverting back to garbage characters.
Hey juan, i've time and again found your posts when looking for solutions. Alot of helpfull information in there,
Unfortunatley the constant stream of ["� �_��"] into my apps serial buffer confuses me with no answer in sight. and searching "�" doesn't give any usefull results as search engines ignore the character.
You seem well versed in BLE AI2 to arduino.
So my "work around" is now failing as non unicode characters are entering in the middle of the sent data.
Can you explain why the AI2 BLE "serial.read" is continuosly reading nonunicode characters?
I can remove these non characters using loops but i'd like to know what i've done wrong where it is registering characters when nothing is being sent.
The fact you know FFFD is close to BOM is a big help. See this is where i don't have enough knowledge of UTF unicode to be able to make even the simplest assumption of how to resolve this. But that has helped me to find more brain food.
See i now know BOM is probably whats causing this funky failure
BOM use is optional. Its presence interferes with the use of UTF-8 by software that does not expect non-ASCII bytes at the start of a file but that could otherwise handle the text stream.
So now i can look for how to disable the arduino or HM-10 from creating a BOM BOM on my data.
In the mean time. This code block removes the junk from my data. And ignores empty input
On the subject of input cleanup, part of your mess is self-inflicted, where you don't account for the fact that stringValues is always going to be a list, subject to AI2 type conversion (["..."]) if you try to treat it like text.
You can avoid having to remove [" and "] if you extract item 1 of the incoming stringValues with a SELECT ITEM 1 of LIST block.
I have yet to hear of any one receiving an item 2 in stringValues.
Because i am sending it as an array/list of course that means im going to be receiving it in the same format! My god I feel like a jackass I just spent 20 mins rebuilding it as a list.. Time for a i think.
Alright thanks to your insight i've managed to condense the blocks down quite abit.
Now works at removing � from data stream and seperating values base on stated delimeters. Posting block layouts incase anyone else comes looking for an answer for my seemingly isolated problem.
ABG's solution which is clearly cleaner:
Converts incoming long list into seperate list indexs
My god I feel like a jackass I just spent 20 mins rebuilding it as a list.. Time for a 
i think.
