Attempt to get item number 4 of a list of length 3

[Boris Novosad]

Hi guys, I have a problem with printing the data in the App. 

I want to transfer string via BLE to my app. I am splitting the string and showing the values continuously. 

On my program side is this:

sprintf(myConcatenation, "%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f", ax, myStr, ay, myStr, az, myStr,gx, myStr, gy, myStr, gz, myStr, mx, myStr, my, myStr, mz, myStr, yaw, myStr, pitch, myStr, roll); //connecting many variables that I want to display in one string

pCharacteristic->setValue(myConcatenation); //sending to the App

On my App side I have this:

As soon as I connect and start transferring data, I got this message. Do you know what might be wrong? 

Attempt to get item number 4 of a list of length 3: (989.00 707.00 16276.)

At the same time I am dealing problem with overloading the app with data. after receiving for about 20 secs. (sending data every 100ms) App gets frozen and crashes. Do you know how to optimize the speed so data is still useful and app is working fluently? Data is accelerometer reading so its necessary to be up to date and refreshed quickly.

Thank you for any helpful advice.

Boris

[Chris Ward]

Hello Boris

At the end of the data string, I think there needs to be a Line Feed (\n) to tell the App EOL (End of Line, End of Data). The myStr value delimiter is definitely a comma, right? 

Now, you don't show all your blocks so I can't see how you collect the data, and that's very important when streaming. You need to ensure that the whole packet of data is received.

Concerning the freezing of the App - in part, that will be because a whole packet is not received, so the App then tries to access a value in the list that does not exist. Also, to ensure good process flow, the App Inventor process (collection of the data) should be within a Clock Timer, and the timer duration must be less than the duration of the sending device. The App Timer duration must at the same time be adequate for the processing of the data received.

In your code, you initialise 12 local values, but none of them are required - just set the list Items directly to the relevant Text Labels. Simply append the file with the data string before it is split.

That's as much as I can tell you now, hopefully it's enough to get the running better.

[ABG]

I am wary of the stringValues contents that you received

at the top of the BLE.StringsReceived event.

I will bet that it is a list, not a text value,

because you found it necessary to strip ( ) off the ends.

Those usually happen when you do a text operation

(like SPLIT at Comma)  on a list.

Here is a belt and suspenders bulletproof approach to

dealing with your stringValues contents..

(See attached)

Also, I have a question regarding BLE Strings ...

Is there a length limit?  

(I haven't used it, not having hardware.)

ABG

[ABG]

You can also bulletproof your select item from list blocks

by replacing them with calls to the attached item() function,

which will return a harmless 0 value if out of index bounds.

ABG

[Chris Ward]

...some BLE hardware has a 32 byte per data limit, 72 bytes being used here, but it's easy enough to check the received strings in the output file. 

[Boris Novosad]

Guys thanks for your replies!

I will now send the entire canvas (firstly I didn't want so I don't confuse you or so.)

First I want to ensure you that on my first attempt I was sending only 3 values in an array like this and everything worked fine (Except for the freezing after 20 secs) -- but it was probably because of the size of myConcatenation[80] as Chris Ward mentioned :

 the App then tries to access a value in the list that does not exist

(still, don´t know how to get rid of it :( ). 

Code part:

char myConcatenation[80];

char myStr[] = ",";

sprintf(myConcatenation, "%3.2f%s%3.2f%s%3.2f", yaw, myStr, pitch, myStr, roll); //connect yaw, pitch, roll into string

App side:

This was the value of MyConcatenation in Serial Monitor:

953.00,512.00,16491.00

• Since I didn't have to put \n in the version with 3 variables I think it is not necessary to have it (I tried it and it didn't change anything).
• Regarding the appending the file and creating new variables from "already split list", if I understand it right, I will eventually have to make new variables since I want to display them in the app, right?

• I found that Maximum BLE size is 20 Bytes. (https://stackoverflow.com/questions/38913743/maximum-packet-length-for-bluetooth-le). If it is right should I rather send data in packages of 20 maximum? 

Reply to ABG - I was trying to follow your advice and implement the lists.aia but I didn't get where should I call it and how it might help me, I am sorry  I am a newbie in programming. I'll try to work on it and I will let keep you up to date with my progress.

------

Actual Code used now:

char myConcatenation[3];

char myStr[] = ",";

sprintf(myConcatenation, "%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f%s%3.2f\n", ax, myStr, ay, myStr, az, myStr,gx, myStr, gy, myStr, gz, myStr, mx, myStr, my, myStr, mz, myStr, yaw, myStr, pitch, myStr, roll); //connect yaw, pitch, roll into string

Actual App canvas now:

Serial Monitor MyConcatenation Output: 

871.00,618.00,16491.00,-7.00,5.00,4.00,-144.00,2.00,162.00,109.42,4.22,4.62

So after splitting in AppInventor, I suppose that there should be 12 values.

[ABG]

See the How to Work With Lists article in the Lists section of FAQ

https://groups.google.com/forum/#!msg/mitappinventortest/wqJin0qO8M0/8xUafdROAgAJ

Also see 

http://www.appinventor.org/bookChapters/chapter19.pdf

ABG

[ABG]

See attached for 2 places where you steamroll a list,

making it road kill text.

ABG

[ABG]

In programming as in cooking,

you have to remove data from its container

before cooking it ...

https://www.youtube.com/watch?v=NflemlptxDQ

Watch for where Curly adds a can of peas to the turkey.

ABG

[Chris Ward]

Hi Boris

If you post your Project file I can modify it to show you what I meant about the local vars.

The reason for suggesting \n was to be sure to keep data packets separate - if there is a blip in the timing, you could then effectively have more than 12 values in the string that arrives - App Inventor is reading to the end of the string. However, based on your tests, sounds OK either with or without \n. 

Another test would be - no stream, send 12 values only and see if the App Receives all of them. If it doesn't, that probably means we have gone beyond the limit of your hardware - actually, the manufacture's notes should tell you this limit, the maximum transmission unit (MTU).

If the limit is 32bytes, your device will have to stream the data in 3 packets, 4 values each.

[Chris Ward]

.... don't forget to remove the Notifier when your QA testing is complete :)

Ah, ABG has shown you how to append the file as I described. We just want to make the population of the Labels more efficient too. We can do that with a simple For Block.

If the data has to arrive in 3 packets, we will need to count them. We can possibly send an App Inventor format string List directly - if that were to work, no need for the Split function.

[ABG]

Ah, ABG has shown you how to append the file as I described.

No, I was showing the OP how to stuff a turkey.

The Append to File block asks for text,

but the OP was cramming a list into it.

I circled the offending sequence without

correcting it in my most recent post,

for focus.

ABG

 

[Chris Ward]

Hi ABG

I think it may not matter that the raw list is appended to the file, but the code will need significant change anyway if the data has to be split into multiple packets.

I can foresee problems when the turkey has been stuffed for a period of time. Might need to stop the data stream after x minutes, or use a bigger phone.

[Chris Ward]

Hi again Boris

The max packet size depends on your hardware's BLE version. As I mentioned before, it should be documented by the manufacturer.

[ABG]

I think it may not matter that the raw list is appended to the file,

Somewhere back in this thread, the OP had complained about '(' ')' removal.

Appending a raw list to a file will add ( ) to the file.

ABG

 

[Chris Ward]

Boris - are those deleted messages you? Attempting to upload your .aia file? Unfortunately Google Groups does not allow .aia files that contain an extension. However, that only seems to pertain to new posts - if you edit an existing post, you should be able to attach your file.

[Boris Novosad]

Oh, didn't know about the restriction. I try to add the aia file here then.

[Boris Novosad]

Okay, so the magic is to put the pea out of a can :D Thank you ABG, now I see.

Chris, I will definitely try the test with only the 12 values tomorrow, now it's 0:30 so ill take a rest. I will attach the .aia file so you can demonstrate what you meant by the EOL. 

[Chris Ward]

... App Inventor is adding the brackets, so the data should handle as an App Inventor List without needing to split it - but the value separator probably needs to change to be a space . It may depend on what is to be done with the file later, but given that the streaming needs to be fast, just saving the raw data would be efficient.

[Boris Novosad]

I am using the ESP32 that has BLE embedded. In its datasheet, I found only this but nothing regarding the maximal packet size. Am I looking at the right place? (https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf) Page 45. - Receiver/Transmitter characteristics.

Boris

[ABG]

I have a quick fix for ( ) on code.appinventor.mit.edu

Your Code to Re-enter is: NAT-SUP-MAE-SORE

(Going to supper)

ABG

[Chris Ward]

Boris

Quick Question: What happens to the file data? Are you going to load it into the App later? If it is going into the App, we probably do not want the column headers.... 

[Boris Novosad]

The data are saved to the file so they might be processed afterwards. The headers are not strictly necessary here. I put them there only for the clarity.

[Boris Novosad]

Thank you ABG, it doesn't show any error regarding entering the list that doesn't exist. But the body of the for each loop is not being processed I think. When I take a look in .xls or check the labels of the app... they are not being refreshed. 

Buon appetite.

Boris 

[Chris Ward]

OK - ESP-32 is using BLE 4.2, should be good for at least 32bytes but I have seen App Inventor code somewhere using more bytes from ESP-32 - so test your 12 value string (not streaming) and if it fails, test a 4-value string. Instead of using a comma delimiter, use a space, and put a \n at the end of the string.

[Chris Ward]

Hi Boris

Attached Project "app_cjw.aia" cleans-up bits and bobs. For incoming data, it is relying on the string being in App Inventor List Format (spaces instead of commas). We will have to modify the .StringsReceived Block if we are forced to use multiple packets.

You did not have the latest BLE extension installed. It should be edu.mit.appinventor.ble-20181124.aix, which I have added. 

[Chris Ward]

OK, I'm in the UK so signing off now, it's late. Happy experimenting :)

[ABG]

This would be a good time to mention the Blocks Editor Do It

feature, that lets you see block contents at run time.

See the Debugging section of FAQ

https://groups.google.com/forum/#!msg/mitappinventortest/wqJin0qO8M0/8xUafdROAgAJ

ABG

[Boris Novosad]

Hello Chris, I tried out your code and now I understand what you did there. These changes are much clearer than what I had in my blocks before. But the thing is that even when I was changing the string value sent from my ESP (using spaces instead of commas, sending only 3 values). I still cannot recieve them. I was trying to change the notify time to 500ms so it goes with the time you set in app timer. But still no data is being shown on my labels nor in the .csv file. Only thing that works nicely is that headings (that we didn't  eventually need are in the .csv file).

[Chris Ward]

Hi Boris

Now that's interesting :)  

What happens if you use comma delimiters again, instead of spaces? Note that, if your sample string is only 3 values, you need to modify the For Next loop accordingly so it goes from 1 to 3 instead of 1 to 12.

Timing. The time intervals can be tweaked later to improve process speed, but for now they need to be generous so that the testing is not "contaminated" by a time issue. With the App running at 500 milliseconds, the Device must send data slower than that - 800 milliseconds would be about right.

If the File does get appended, fingers and toes crossed, please attach it to your Post so that I can examine it (forensically).

You might notice your hair is getting grey from working on this Project...... be prepared for hair loss later :)

[Boris Novosad]

Hello Chris, Thank you for your responses :) Yes my hair is getting a little bit grayish, uff ... :D but I will solve it eventually!  The file is getting appended, but I am getting it only in one column. And the weird thing that I am little bit scared of is that even if I am trying to change the size of for loop, I am getting only 3 values (ax, ay, az) Check the code part. and even if I use NRFconnect (ble app from Nordic Semiconductor) I can't see it there.

SETUP:

My notify input from Arduino IDE (weird is that it won't notify more than 3 values even I put there 9) .

sprintf(myConcatenation, "%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f,%3.2f", ax, ay, az, gx, gy, gz, mx, my, mz);

This is what I get into a .csv file (all data is in column A)

Label print doest work either :/ 

nrfConnect output: 

I will attach my .aia file so you can check it out. 

I would be very glad if you would try to help me solve this or give some info on my troubleshooting process.

Thank you,

Boris

[Chris Ward]

Hi Boris

It's not really weird - just that the device cannot send all the values in one packet. I didn't know you are using the Arduino IDE - does that mean you are using an Arduino? 

In addition to the .aia, I would need the microprocessor script (Sketch (.ino)) too. 

I can spend a bit of time on it but not until Tuesday (UK time).

[ABG]

It looks like you're trying to stuff a watermelon through a keyhole.

Consider sending just 1 reading per message, labeled for identification:

ax:989.0

ay:707.00

az:162.76

gx:???

gy:???

gz:???

mx:???

my:???

mz:???

...

and at the receiving end, for each incoming string,

split it at : 

check what item 1 is ('ax', 'ay', ...) then take item 2 and put it into the appropriate global variable or label.text.

Using this technique, if some of the variables change slowly, they don't

need to be sent as frequently as the others.

ABG

[Boris Novosad]

Hello there,

before I try to change my code (since I am a newbie in coding) I tried to "make my keyhole larger" with changing MTU (maximal transmission unit) of communication. I found that trough nrfConnect it's possible to change the value of it. Is there a possibility to implement this in AppInventor? 

nrfConnect Output:

If there's no such a function to change MTU in AppInventor I will probably have to code, right? (let's slice the melon then).

Chris, I am using the Arduino IDE with ESP32. And I wish I could implement that code. I tried codes from GitHub and StackOverflow but I just don't have the programming skill to transform them into my desires.

If you would be so kind and helped me with the implementation of the code I really would be grateful. Entire .ino file I am using (fusion of BLE and MPU example from GitHub) is circa 1000 row file and from the beginning might be confusing so I will try to navigate you a bit. 

On row no. 555  is the connection of string I want to send. 

On rows, 585 - 591 is the notify function that sends it via BLE. 

The purpose of the code is to communicate with an accelerometer so other functions and calls are mainly for its calibration or register definitions.

PS: Not to confuse you, now is the code in the state when I want to call raw values from accelerometer so every offset function or calibration are commented. (That's the reason why in Serial.Monitor are Biases and Scales = 0).

Thank you for your patience with me.

Boris

[Chris Ward]

Hi Boris

I didn't know you were using an Arduino. I will fix your code and get back to you later this morning.

[Chris Ward]

Woa - couple of things :)

Firstly, you can't change the MTU unless your device has that capability - and why would anyone want to run their device at "half mast"? Secondly, your Arduino doesn't have an MTU issue, it's just the way you are sending the data as one giant packet - hopefully a simple to fix :)

[Chris Ward]

Hi Boris

Here we go. Please Test "SMARTHELMET_cjw.aia"  together with "MPU9250_BUTTERFLY_RAW_V2.ino"

In the Arduino sketch I have modified the value of PI to that commonly used in C. Using more decimal places does not make any positive difference because your Arduino does not compute doubles. In any event, there is too much emphasis on the accuracy of PI by many developers -  20 decimal places is already OTT :)

I have set-up the values to be sent as one value per package which works really well with Arduino. Currently the time intervals are generous.

[Boris Novosad]

Hello Chris, thank you for your files. I think that we didn't understand each other, I am using Arduino IDE to program my ESP32, not Arduino. So in the code, you prepared data to be sent via Serial, right?

[Boris Novosad]

My goal is to split the string into 3 parts and send them separately.   

sprintf(myConcatenation, "%3.2f,%3.2f,%3.2f|%3.2f,%3.2f,%3.2f|%3.2f,%3.2f,%3.2f|%3.2f,%3.2f,%3.2f|", ax,  ay, az, gx, gy, gz, mx, my, mz, yaw, pitch, roll);

ax, ay, az  - 1st. 20Byte packet

gx, gy, gz - 2st. 20Byte packet

mx, my, mz - 3st. 20Byte packet

[Chris Ward]

Hi Boris

What is the technical reason to split the sets of data that way, when you didn't before? It will take longer to process......

[Chris Ward]

Hi Boris

Yes indeed, Serial Output in the Loop.

[Boris Novosad]

Hi Chris, I want to split it so it can fit the notify function of BLE characteristics. I don't send the variables ax, ay, az directly because they are float and the  

BLE function: 

pCharacteristic->setValue();

accepts strings.

That's why I thought its better to connect the floats via sprintf  and the split to the packets.

[Chris Ward]

Hi Boris

Try my files and see how that goes :)

[Boris Novosad]

I tried your code Chris, and it is not functioning :/  the app writes connected but neither appends to file nor refreshes the labels. I understand why is that but I can't really realize my idea. (here it is well described https://esp32.com/viewtopic.php?t=5736 - at the end). And it is the same as you told me, to chunk the message on smaller parts and then use a delimiter to let the app know its right size.  (or here - https://github.com/NordicSemiconductor/Android-BLE-Library/issues/3 - 3rd point - implemented in Java i think). 

[Chris Ward]

Hi Boris

That is of course what my code does, keeps the packet size below the limit -this method has worked for many projects. I think this sort of issue might explain why people use the ESP-32 with a microcontroller rather than standalone :) By default, the ESP-32 alone doesn't have the memory buffer size necessary and I said before that I didn't think that could be changed. The article you linked to proves I was wrong - but you would have to resize the MTU via the Sketch, there is no facility to do it from the App side in App Inventor (I just put an enhancement request in).

Also in the article is a work-around that does not buffer the data but sends each packet immediately as though each one were unrelated. We could do that with a loop at the App end that counts the number of packets received. So, 1 value per packet without delimiters and without a buffer size increase.

Not exactly elegant:

//Data Packets to App

char strOut[16];

sprintf(strOut,"%3.2f\n",ax);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",ay);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",az);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",gx);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",gy);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",gz);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",mx);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",my);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",mz);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",yaw);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

sprintf(strOut,"%3.2f\n",pitch);

pCharacteristic->setValue(strOut);

pCharacteristic->notify();

delay(50);

[Boris Novosad]

Hello Chris! 

Thank you for the code, this looks promising :)! Even tho from the beginning, it might be a bit slow but I think it can be tweaked. 

These are the outputs of SavedData.csv and app itself:

Data were saving into the file only in one column so I changed "\n" for "," and it works well now. But I found a few problems (see pics below):

1) If I connect to the ESP32 at a different time, my labels get changed (ax doesn't display in axLabel and so on...) This occurs only with labels ((see pics below), appending to file is  OK. Maybe it has something to do with timings, I am not sure. (I tried to lower the delay from 800 to 200).

2) Is there any chance to make it faster?

3) And these brackets... I am thinking I will use the bracketErase Procedure I used before

EDIT:

[Chris Ward]

Hi Boris

A step in the right direction.

0) In the Sketch, you can try replacing \n with \0 (zero) - it might not work, depends on what the BLE extension actually supports for EndOfData.

1 & 2) I think you can delete the Loop delay (and tweak the individual value delays if possible - the App still has a lot to do). The values get out of synch when connect to the ESP32 at a different time? - might be timing yes (not good news) lets see what the tweaking does. On the App side, change the Screen1 Initialize to:

We are no longer using a timer :)  (remove from Designer too)

It is likely that the Packet Count is out of synch if you disconnect then reconnect, so:

3) The Text Blocks can indeed be used to remove the brackets - do that in the Populate Labels Procedure?

Concerning the MTU, Evan Patton is currently updating the BLE extension and needs victims -erm, people to test it. - would you like to volunteer?

[Boris Novosad]

Hello Chris! 

little progress I made, 

regarding the timings, I was able to shorten the time by deleting the delays entirely... I was afraid that it will corrupt the data but it didn't actually. I was checking it together with the serial monitor in Arduino IDE and it seemed all data were sent  (except while sending all packets with 50 ms loop delay, I found out that 8 rows of data in SavedData.csv is missing, It is probably because we are sending it in format single packet = one data. But for my intentions, it is not a real problem. By the way, is there a way how to add a timestamp to the .csv?

Now for the struggles :/

1) The desynchronization is still there... And for now, I don't know how to deal with that, maybe put some start symbol that would let the app know that ax is the first data, or something like that, what do you think?

2) I tried to implement the BracketEraser into the PopulateLabels procedure but I was not successful. Here are the blocks: (I add the .aia file to the attachment)

Chris, I would be very pleased to help Mr. Patton with testing! But I am afraid that I will be not able to catch up as you can see, my knowledge about MITAppInventor and coding is not very broad. But at the same time, I see this as a good opportunity to learn new things. So if you like, I'd happily become a "victim" if it is for a good purpose! :) 

[Chris Ward]

Hi Boris

1) Ah - The desynchronization is still there. That is probably because you have deleted the delays entirely! It's not possible to have zero delay because the App cannot process the data in zero milliseconds and that data is not buffered - so what is happening is that it receives a packet, processes that packet and during that time, misses the next one, or two, or three. So tweak the delays yes - but they are necessary.

2) The code is calling the Label components list instead of the values to go into the labels - also it is not necessary to change the list data, it is only temporary, getting replaced by the next data set, so just get the value from the list, trim off the brackets, apply to the Label. I'll code that for you.

It would be great to have your help testing the MTU feature, you know a lot more than you think you know, you know :)

[Chris Ward]

Hi Boris

"SMART_HELMET_cjw4.aia" Attached.

I have changed the bracket trimming as I previously described. I have also used the same Procedure to append SaveData.csv and to store the first value of the next set of 12. This is because I think my previous code could cause a race condition whereby the Strings Received block would start receiving the next value set before the processing of the current set had completed. The last Delay in the Sketch Loop probably needs to be a bit longer than the others.

If you timestamp the file name, you will need to store the name in TinyDB so you can later delete the file.

[Boris Novosad]

Hello Chris, 

Thank you for the code.  I made some changes there:

1) I deleted "," after each string in the code as it is already added in the app.

2) I deleted EoL symbol as well as it was making a mess with the labels, Now the data looks overall good but the problem is with its position, as you can see even while appending to files the position of each data changes.

3) I changed the variable CsvFileName to global so the data append to file with the date.

Code:

char strOut[16];


sprintf(strOut,"%3.2f",ax);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",ay);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",az);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",gx);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",gy);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",gz);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",mx);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",my);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",mz);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",yaw);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",pitch);
pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(10);


sprintf(strOut,"%3.2f",roll);

pCharacteristic->setValue(strOut);
pCharacteristic->notify();
delay(50);

16336 is on Ax now

You can see a change there (16334 is on Gy now)

[Chris Ward]

Hi Boris

Right - the sketch code is (now) reliant on the #NULL that sprintf() adds silently to the end of the string for EOD - sounds like the App Inventor's BLE function works with that. 

You cannot get away with 10 millisecond delays - as you can see, packets are dropped. The way to tweak these values is to start with very generous delays. Make each one 500, check that the results in the App are as expected, reduce the delays by 50%, check again and so on. The very last delay needs to be at least 2x the size of the others.

In the App, tiny thing, your initialisation of the filename global is a number, should be text.

Now, I don't understand why you would want to send data to the App to display so fast - no human can focus on 12 values changing every second - in fact most people would need 5-10 seconds and even then would not be able to keep that level of concentration for very long. This is one of the reasons why only a few are capable of driving formula 1 racing cars :)