Bluetooth data aquisition

[Miky_Mike]

There is what we've done for now.

We just wanted to see if we could establish the connexion, send and receive data.
The connexion is well established and LabVIEW can send data (we chose to send the "~" caracter because its value is 01111110 so it was easier for us the see if LV was sending what we wanted) but it won't receive any...

We also tried opening a bluetooth connexion, and then read the data from the serial port but we didn't succeed...

Thanks a lot !

[ThiCop]

Hello Mike,

To make sure we're understanding eachother clearly:

- The sent data is being received at the side of the PIC?

Something that surprised me is that you're reading out 0 bytes.

"bytes to read" has a default value of 0 if you don't wire anything to it.

Can you change this to the expected amount and also put a string indicator directly at the output?

[Miky_Mike]

Hello,

Yes, the data sent by LV is being received by the PIC.

Yesterday, we were able to read some data. The "bytes to read" was set to 16 but it actually receive 2 bytes (we mixed bits and bytes in our head...) so that's why we had a timeout error. 

As I told you, the PIC sends 2 sets of 8 bits, one called ADRESL containing the 8 first data value bits and the second one called ADRESH containing the 2 last data value bits, 3 non-used bits and 3 adress bits. 

The second problem that we had is that LV sometimes read ADRESL first then ADRESH but sometimes read ADRESH first and then ADRESL, so the decimal value obtained was all mixed up and non usable.

We managed to correct that by puting 2 "read boxes", reading 1 byte each time. It appears that the first boxe now always read ADRESL and the second one always read ADRESH.
ADRESL contains a decimal value from 0 to 255 as expected
ADRESH contains a decimal value from 0-3 for sensor1 (max binary value is 11000000), from 32-35 for sensor2 (max binary value is 11000100), etc. for each sensor, as expected either.

So now, based on the idea that we had (labview flowchart is now obselete), we have to "analyze" ADRESH and make "if cases". ie: if  64 <= value <= 67, then display value for sensor3 (max binary value is 11000010). But we have to display on a XY graph the 10 data value bits and only those 10. How can we do that ?

I joined you the .vi so that you can visualize what I did.
 

[ThiCop]

Hello Mike,

I think the issue with the order of the bytes might be linked to the byte order of the data you're sending from the PIC.

One thing I would like to ask you is the following:

Why are you using the "Delete From Array" node?

Can you draw in paint how you would like your XY graph to look?

Then I can take a look at how it should look and try to reproduce it.

[Miky_Mike]

Hello,

The PIC always send one register first, then the other. That's why it seemed strange to us that LabVIEW would sometimes display the second before the first.

To answer your question "Why are you using the "Delete From Array" node?" : we figured out that Labview reads the signal as "string" so we had to convert it into an "array" using the "String to Byte array" node but we couldn't display it. The array seems to be stored in a table so the guy who helps us (I told you about him in one of my post before) made us use the "Delete from Array" node. We can now read the bits properly.

Is there another way to do it ?

The output voltage from our sensors is not linear whend different forces are applied. We will have to make a linear regression when we'll calibrate the sensors, and find a way to apply the equation found to the decimal value given by the 10 data bits in LabVIEW in order to display the "force value" and not the "voltage value". I don't know if i made myself clear... 

We made you a paint drawing of the program as we see it.
As you can see, we have color boxes on an image of a foot, and XY graph for each sensor, have the force value on the Y axis and time on the X axis.

Hope this helps !

[ThiCop]

Hello Mike,

For me it would seem more logical to use the Index Array function (especially if you want to reuse the incoming array later on).

There are several functions available to do regression calculation in LabVIEW, but your question seems two-folded:

- At one side you have the regression for the non-linear curves.

- At the other side you have the conversion of bits to a decimal value.

For both of them you can make one (or multiple) VI(s)

Do you have partially working code to illustrate this?

[icecoldies]

Hi, I've just come across this thread.

I have set up the RN-41 bluetooth module on a ST development board and I'm able to communicate with it using hyperterminal but when I try and use the Labview basic read/write example it doesnt establish a connection with the bluetooth module (the green led doesnt go solid) and I get a VIsa i/o error, if I establish the connection using my bluettoth software (Blue Soleil) before running the VI (Led goes solid) and then run the VI it seems to break the connection and the Led starts to flash again?

Any idea or advice on getting the basic connection from Labview to the RN-41 module appreciated.

I have set board rate, parity, stop bits etc all the same in Labview, RN module and Windows device manager for the serial COM port.

[ThiCop]

Hello icecoldies,

Can you create a seperate thread?

These issues do not seem to be directly related to eachother (with regards to the hardware).

Therefore it would be best to create a new thread for your issue.

[Miky_Mike]

Hello icecoldies, hello ThiCop,

@icecoldies: Make sure that you have close your connexion with hyperterminal before trying to establish the connexion with LV, otherwise, it won't work. Check the MAC address you set in LabVew, make sure that you have enter the MAC address from your bluetooth module correctly. It's as far as I can help, sorry !

@ThiCop: There's an update VI. We were able to display a XY graph but we have a small problem: the graph doesn't "refresh" as fast as we wanted. It add a plot every second and we were wondering if we couldn't make it refresh any faster. We set the baudrate at 115.2k, trying to make it send and receive faster but it's still to slow... Any idea on how to make it go faster ?

Also, we weren't very happy with all the calculus needed with finding wich sensor was sending etc... so we decided to try something different. You can see in the flowchart that we tried to match  the flow of our programs. Also we will configure our PIC to make him send our data in that way: 00000011 (first byte) 11111111 (second byte) so that labview could read it all in one shot and make the decimal conversion without any more calculus needed.

But we are afraid that the two programs won't go at the same speed and so, loop 3 (which will send data from sensor 3 from the PIC) won't match loop 3 on LabVIEW side (if you see what I mean).

What do you thing about that ? Does the second method seems more efficient to you ? And if so, will the 2 programs go at the same speed ?

Thank you !

[Miky_Mike]

Hello ThiCop,

I made a .vi illustrating what I meant in my last post (by the way, no "edit button" ?).

I hope it will help you understand what I meant by the loops.
By the flow of both programs, they should "loop" at the same rate since the PIC won't send data if it doesn't receive any and LabView have flat sequences so technically, they should go at same speed.

I couldn't connect the wire on the close connexion boxe beceause the type doesn't match, but I never had this problem... How is it so ?

The foot image is just an example, I wanted to place some color boxes on it but I didn't succeed...