BLE string values are being merged

[Scientistnobee]

Hi everyone,

Hi everyone,

I am trying to get the data from a BLE device running Arduino code. The device sends the data using the bleserialwrite function. However, the data coming from the app after recieving the values is merged.

My Arduino code is as follwoing:

bleSerial.print("V");

bleSerial.print(V);

delay(500); bleSerial.print("I"); bleSerial.print(I); delay(2000); This data is sent every 2500ms by the BLE device. However, when this is data is recieved by the app, it is writing to a file as following  (535V4844I65535V4848I) My question how can I recieved data just as (V4844I65535) without the extra values? Why app inventor is fetching extra values. This problem is not there I think in the Classic Bluetooth Devices. Please let me know, how to improve my situation. Thanks in advance. P.S: I read the previous threads in this forum but they address mostly the classic bluetooth devices which doesn't use the StringsRecieved function.

 

[Chris Ward]

Hi

Like this:

bleSerial.print("V"); //Value Label

bleSerial.print(V);   //Value

bleSerial.print("I"); //Value Label

bleSerial.print(I);   //Value

bleSerial.println();  //End Of Data Stream

delay(2000);

The If test in your Block should be deleted - it is not necessary!

[Scientistnobee]

Hi Chris, thanks, I will test this today and let you know.

[Scientistnobee]

Hi Chris,

I tried your suggestion. It seems not working. Now my sensor reading on the app comes as (V200I400 V30I400). So the only difference is that the bleSerial.println at the end added a space between two values. I don't think it's the problem on the Arduino part, as the normal serial port is outputting values as expected. It's only the bleSerial that's not working. So, I think it's the app Inventor part. Please let me know if there's a way to troubleshoot this issue.

[Chris Ward]

Hi again

Some confusion here! The result you are now receiving is correct. That is not two values, it's two sets of data, two values in each set (V and I). So those two sets are technically a stream of data, all be it the World's shortest ever.

As I understood it, you are trying to stream the data into a file are you not? Your App still has a little bit of work to do that or anything else with the data. 

I think we need a precise and concise description of:

1) What exactly do you want to do with the data;

2) How many sets of data are received in one session (one use of the App), over how long in time.

[Scientistnobee]

Hi Chris, 

Thanks for your reply. 

I don't think it is correctly sending the just two times, sometimes it is two and half times and so such as (3934 V11089 I13919V110) and (85I13928 V11088I13908). If you see carefully sometimes data is not even starting with V. So it is random at the moment.

I am gathering the data into a text file, for processing it for separation of V and I values with time stamp.

1) What exactly do you want to do with the data;

I need to save the data to a file to plot later times vs V and time vs I. This is time value is flexible. 

2) How many sets of data are received in one session (one use of the App), over how long in time.

The experiment goes on for 12 hours and I receive data usually for every 8 seconds through the app. 

[Chris Ward]

Hi again

Right then - progress :) 

We need to see your Arduino Sketch and your App Inventor Blocks. I can tell from your results that the values are most likely being received faster than the App is processing them - but either way, if a value is 'not received', the issue starts with the Sketch, so both certainly need addressing together. Given that you want to process the data as a plot later, it needs to be saved in a more read-friendly way to suit, which could mean values only, no identifier labels for example - we would need to know exactly how the data is to be presented (hand drawn sketch?)  in the plot in order to advise how best to store it for efficient retrieval.

Eight seconds per data set is good in terms of allowing the processing to work, but 12 hours = 43200 seconds = 5400 lines of data, which is largish for a smartphone to handle, depending on requirements. The data file size, text only, would be around 200KB, so that would not be a problem.

Big concern is the 12 hours in general. Need to know more about what the setup is doing - for example, are the devices/sensors stationary? Unless your phone is directly attached to the electricity grid or has it's own nuclear power station, it is possible the battery will run out well before the experiment is finished......

Another caveat - if the phone goes into sleep mode, all App Activity (including the BLE connection) is lost, so we would need to have a routine to keep the App 'alive' and that means the phone has to be 100% dedicated to the task, no other Apps can be run or calls answered etc.

Much as I would love to help, I'm not very available this month as I have a (non App Inventor) project of my own to complete, so bear that it mind when you post information - it has to be clear, concise and without any element of mystery or others will be loath to pick-up the mantel :)

[Ghica]

StringValues is a list, most probably of the V value and the I value. If you put that on a file, it will be serialized with a space in between.

If you make a log of what you are receiving ,you may have a more clear idea, like this:

Cheers, Ghica.

[Scientistnobee]

Hi Ghica,

I have always been seeing the values by logging them. See the attached cropped screenshot.

[Scientistnobee]

Hi Chris, I posted the relevant blocks of the code and app inventor. The rest of the code or the blocks are interfering with the results. Thanks for offering help and I understand that you are busy as well. 

The size of the file generated and the sleep mode of the phone are not problems.  

[ABG]

Where is your for each loop in your StringsReceived event?

You are receiving a list, and must process each list item individually.

ABG

[Scientistnobee]

Dear ABG,

Thanks for your suggestion. I implemented your solution.  Now I found that the brackets are disappeared and each set of data is being stored in the file as a separate line. However, as can be seen from the data, some of the digits in the values of V and I are missing. Except that there are no issues. 

My blocks look like the following.

[ABG]

You are processing the received data cleanly,

so the problem is upstream.

Show us the new arduino code.

Also check for a loose wire on the V sensor,

just in case.

Do you have  access to an  oscilloscope?

ABg

[Scientistnobee]

Hi ABG,

I am attaching the code here. The sensor is Si1143, which provides both the Vis and IR photodiode values, which I am calling as V and I. So no loose wire here.

No, I don't have access to Oscilloscope. Thanks a lot for your help so far. You already solved 90% of my problem.

[ABG]

I started to read the pdf doc on your Si1143 chip at https://www.silabs.com/documents/public/data-sheets/Si114x.pdf

and my eyes glazed over by page 50.

This is not a simple sensor, like the temperature and humidity sensors we usually see.

The Si1143 is programmable into different modes, and

uses interrupts to send its data back to the host Arduino,

which must not be ignored, or the two-byte values sent

to the host will get out of sync.

Do you have a sample working sketch for that chip?

Your sketch is a palimpsest.

ABG

[Chris Ward]

Hi

I'm not here, but if I was, I would suggest writing the Sketch from scratch and only including what is essential to the Project Goal. Assign the int variables outside of the Loop. bleSerial.begin(9600); If yield() is necessary (because the oled is necessary?), you cannot use delay(). it has to be inside the Loop's delay to be effective.

As you can see from your results file, the test "is a list" does nothing in this context because stringValues is already designated as a List and it contains a list of one Item. You do not need to assign the List item to the variable "reading", you can just use "item" as-is.

[ABG]

Here's what I found searching for Si1143 support board:

https://www.silabs.com/community/mcu/8-bit/forum.topic.html/si1143-6lSv

You should find people there far more knowledgeable about

Si1143 Arduino control.

@Chris - I assume the OP added that intermediate

global variable for the data in the for each item

to allow Do It to grab ephemeral values.

ABG

[ABG]

Here's another pdf that might be relevant to your data pattern,

with discontinuous high and low values:

https://www.silabs.com/documents/public/application-notes/AN498.pdf

The Designer's guide mentions how failure to block

short light paths between the emitter and sensor 

could cause near vs far confusion.

Also check for light ripple, if your environment 

has LED or fluorescent lighting.

ABG

[Scientistnobee]

Hi Chris,

Thanks for your suggestions. I am writing and testing the code from scratch. However, I am not understanding why the strings recieved have two copies of the data I mean two items in the list, when I expect only one item in the list.

I can leave the yield. OLED is necessary. I understood that I don't need the reading thing and can directly use the item.

[Scientistnobee]

Hi ABG, I am trying my best to understand the Si1143 documentation and I am not very good at electronics.

I posted as an in the issue about the sensor working mechanism in the corresponding github libraries.

[Chris Ward]

Hi again

If the OLED is necessary, then you will have to change how the time interval of the Loop is managed. However, I would be concentrating on getting the data flow to the App correct first. The bleSerial lib was developed to allow multiple Serial outputs (to multiple devices) at the same time. I'm not at all sure this is necessary in your case - Where are the Serial.print values going -to the Ardunio Serial Monitor on a PC? If so, I would assume that would not be the case for the finished project? 

You are going to have to explain what you mean by "However, I am not understanding why the strings received have two copies of the data I mean two items in the list, when I expect only one item in the list."  Your test output file seems to contradict what you say. I note also that you have dropped the time-stamping of each set. If that is just while testing streaming, then I would suggest that the time stamp should be prefixed by the Sketch rather than the App, for best process flow.

The attached Sketch, which I have simplified to concentrate on the sensor output to the App, shows how to handle the Loop time interval - this is a tried and trusted method that does not require delay(). Concerning sensor output - is it always positive? If so, set the variables as unsigned int.

[Scientistnobee]

Hi Chris,

Thanks for providing the code and your time. I uploaded it and I got the following data.

V4,R259

V510,R259

V9,R259

V9,R261

V256,R259

V256,R258

V262,R261

V257,R5

V273,R511

V10,R0

V266,R261

V13,R260

V259,R259

V509,R257

V507,R259

On the other hand, I also simplified my code with ble serial communication. I would be very grateful if you can have look into it. My code and the file generated is attached.

[ABG]

How reasonable do those numbers look to you?

If they are coming from a distance sensor, do they match

hand measured distances from your test runs?

ABG

[Chris Ward]

Hi

I think you would be better off modifying my Sketch to use the BLE library (If it has to be used), the changes are small. Your Sketch has includes, defines and variables that are not being used. If they are required later, add them later. I don't wish to sound mean, but how you layout your code is also important - if it is "scruffy", it's much harder to follow.

I have not seen the BLE lib before (there seems to be more than one). I suspected that it might be responsible for the data content glitches (missing labels/values). This is why I used the standard Serial lib, which is ubiquitous. If you have good reason to use the BLE Library, set the baud rate in setup()  - that might fix the glitches.

Never define variables within the Ardunio loop. You can perform digital writes to the OLED within the same loop, in the same part of the code that outputs to the App.

As ABG has observed, the values the App is recording seem to lurch a lot, but that might be down to the simplicity of early test conditions.

[Scientistnobee]

Thanks, ABG.

The numbers look reasonable to me and correlated to the distance measurements.

[Scientistnobee]

Hi Chris,

Thanks for reviewing my code. I will keep your suggestions in mind while writing the code based on the code you provided.