Bluetooth options with PDA & realtime controllers

[plrybarc]

Hello all,

I am doing some early proof-of-concept work with LabVIEW and its abilities with bluetooth, PDA, and real-time machine control.  I'd like to do a simple application where sensor data acquired from the realtime controller (PXI 8145) would be continuously transferred to the PDA (obviously determinism is not important for this part of the application).   Here's the trick:  We have a "Socket" brand Bluetooth "CSA" adapter which hooks up to a serial port and can enable a PC for bluetooth communication.  So my first question is, does anybody know if you can use these serial adapters to bluetooth-enable a realtime controller?  Then, if so, I'd need advice on how to architect the software.  Would the "server" program on the RT controller use the serial VISA VIs?  Would the "client" program on the PDA use bluetooth VIs?  Our PDA is a Palm Zire 72 with Palm OS v.5.2.  We're using LV 8.0 and PDA/Realtime modules v8.0.

The serial adapter we're using is here:  http://www.socketcom.com/product/CS0400-479.asp

I think it has a goofy command set you usually have to adhere to but was wondering, if you used LabVIEW, could you get around this?

Thanks!

-Phil (long time user, first time poster!)

[JLS]

Hello,

The following document is going to be a good starting point for the PDA side:

Does LabVIEW for PDA Support Bluetooth?

http://digital.ni.com/public.nsf/websearch/15987C8CB752EAD786256DC20070B433?OpenDocument

On your RT side, it sounds like you'll be using a serial to bluetooth converter - this should abstract way the bluetooth from your RT side, since you should just be able to write to your serial port, and the converter will take care of the rest.  This should just amount to NI-VISA programming on your RT side as noted in the following document:

How Do I Program the Serial Ports on My PXI RT System?

http://digital.ni.com/public.nsf/websearch/965C93F1A0FB904386256A3E005A64A1?OpenDocument

The related links in each of the above documents may also be of interest, so be sure to check those out as well.

So, there doesn't seem to be any major hurdles theoretically, and effectively your next request was "Then, if so, I'd need advice on how to architect the software."

It sounds like you'll want to have a non-time-critical loop whose job it is to write to a serial port, where you pass the data you're acquiring (presumably) in your time-critical loop via an RT FIFO.

I hope this helps!

Best Regards,

JLS

PS - I recall having played with an example which peformed PC to PDA communication via bluetooth, using serial-bluetooth converters.  I have pinged a few colleagues in an attempt to track it down - if I get ahold of it I'll post it here for reference.

[JLS]

Just a note:

No luck finding the example, but since the bluetooth communication was abstracted away by the serial converters, almost any serial example would do just as well 🙂

Best Regards,

JLS

[plrybarc]

Hi JLS,

Thanks for replying!  I think one of the quirks with this is the use of this "virtual serial port."  How do I know if I need to use this?  Also, how does one create a virtual serial port?  It looks like maybe you need some kind of Windows software to do it.   Then, there's apparently a Palm OS SDK 5 toolkit to download but I'm not sure if I need it or not for this.  The KB is linked below.  I was just wondering if it really was that complicated or not.   I have had serious issues trying to download that SDK kit...the website is malfunctioning and tech support is pretty much nonexistent.

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/15987c8cb752ead786256dc20070b433?O...

-Phil

[JLS]

Hello,

I think you're referring to this part of the document you linked:

"The LabVIEW PDA module can also utilize Bluetooth support by taking advantage of the virtual serial driver most Bluetooth drivers provide. In general the driver supports only one active serial channel at a time, which can be either an outbound (client) port or an inbound (server) port. There are different methods to initialize the port between the PocketPC and Palm modules, however once the connection is made the current Serial PDA VIs are used."

The idea of a virtual serial port refers only to your PDA side, and that's if you have built-in bluetooth support on your PDA.  Basically, some bluetooth devices will expose a "virtual serial port" as an interface to programming them.  They usually have an alias like other serial ports, such as COM2, where you can then program that bluetooth "resource" as a serial port by writing your favorite string data. 

On the Windows side, your serial-bluetooth converter should completely abstract away the details of the bluetooth interface.  In that case, all you will see on your Windows machine is the usual serial port with its usual alias, say COM1.  When you write data to that resource (just as you would any serial port, which for you will likely be using the NI-VISA API functions), it will be received by your converter (since it is physically connected to that physical port) and susequently broadcasted via bluetooth.  Thus, there should be no concept of a virtual serial port when you use a serial-bluetooth converter, and thus you shouldn't have to worry about this on your Windows side. 

Further, if you have a standard serial port on your PDA, and you are also using a serial-bluetooth converter there, you will again be abstracting away all details of bluetooth, and you'll simply be programming a serial port on your PDA side as well.  Now, the available API for serial programming with LabVIEW PDA depends on your version of LabVIEW PDA.  Starting with version 8.2, NI-VISA is supported with LabVIEW PDA, so it'll be just like programming your Windows side serial ports.  For versions previous to 8.2, you'll have to use the "Serial Compatibility VIs" - Don't be confused by the fact that those actually have VISA functions underneath.  LabVIEW PDA actually replaces those functions entirely with appropriate functions for the PDA before your program is downloaded to your PDA target - this is a common point of confusion for those who dig deeper and find VISA under the serial compatibility API.

Does that clear up your confusion?  I hope so, and tried to include some other information to prevent any confusion about other related details.

Best Regards,

JLS

[plrybarc]

JLS,

Success!!!  Yes your explanation above was really good.  I was able to use that KB with the example VIs, LLB, and .c file to make a virtual serial port on the PDA and exchange data to/from my PC.  Cool!

Here's the next quirk.  I wrote a similar app that basically just continuously sends data (every 500 msec) from the PC to the PDA.  The PDA graphs it (every 500 msec).  Sometimes it's obvious they're not in sync...the PDA will plot a very big or very small number when it shouldn't.  I know all the serial settings match EXCEPT for flow control.  I noticed on that "BT Serial Port Init" subVI there is no input argument for flow control type.  So what kind is it?  I know that my serial-to-bluetooth adapter on my PC can only be set for RTS/CTS, there are no other choices.  Might this be the cause of the errant data transfer?  Or could it be something else?

Thanks, Phil

[JLS]

Hello,

RTS/CTS is commonly referred to as hardware flow control, because the RTS and CTS lines of the standard RS-232 DB9 interface are basically used to let the other side know "hey, my buffer is filling up, hold on a minute" and then later to say "ok, my buffer is empty enough for you to send data again."  Well, since there isn't a hard connection between your PDA and your PC.  Since there are no wires in your PDA-PC connection, I suspect the following is happening, and is the reason for your adapter requiring RTS/CTS control:

Suppose your PDA's bluetooth buffer gets, say, 75% full, and that there is a flow control message mechanism built into bluetooth to tell the other side to wait (I am speculating here - I don't know this specifically exists for bluetooth).  Then we would expect your PDA to send that message, which would be received by your bluetooth adapter on your PC.  This message could be translated and then used to set the RTS/CTS lines so that your PC (underneath really the serial port) would "wait" (stop sending data) until it received a message from the PDA saying it was ok to begin sending again.  At this point the adapter would again set the RTS/CTS lines to tell the serial port that it was ok to start sending data again (which of course your adapter receives and broadcasts via bluetooth).

Thus, this may be the cause for the errant data, but I think I would have a better idea of whether or not this is the case if I could see the data - can you attach a screenshot of a). "good" data and b). "bad" data, so that I can compare them.  And keep in mind that, if you're using a bluetooth interface which is built into your PDA, the concept of RTS/CTS control for that resource doesn't really make sense - that is an RS-232 specific concept, not bluetooth, and the "virtual serial port" isn't actually a serial port... there's no RS-232 interface... no wires 🙂

Ok, I hope this gets us a step closer...

Best Regards,

JLS

Message Edited by JLS on 08-30-2006 03:05 PM

[plrybarc]

JLS,

I think it's faster just to describe in writing "good" and "bad" data.  I'm not sure how to take screenshots of a PDA.   I write a number (random I32 from 0-100) from my laptop (with serial adapter) to PDA every 500 msec.  At the PDA end I am then reading that number also every 500 msec.  Let's say I was constantly writing the number 50.  You could see on the PDA sometimes it will read 50 but sometimes it will read 505 or 5050 or 5 or 0.  It's pretty easy to see it's some kind of flow control or handshaking issue.  Depending on the timing, there may be cases where the PDA reads the value from the PC, then tries to read again but there's nothing there, so it reads 0.  Or there may be a case where two serial 'write' commands get sent before a read ever occurs, so you get data like '5050'.  My question is without the proper flow control how do you adjust for this?  Also should the serial flow control setting on my laptop LV program and the bluetooth adapter be set to RTS/CTS or should the LV program be set to none? (Remember the adapter can ONLY be set to RTS CTS).

Thanks,

Phil

[plrybarc]

JLS,

I had another thought.  You mentioned above that with Labview 8.20, VISA is supported in the PDA module.  So would you suspect that this issue could resolve itself if I had this added level of control?  In that case maybe I'll just wait for my 8.20 to ship. 

-PR

[JLS]

Hello,

Let me take your questions in order:

1." My question is without the proper flow control how do you adjust for this?"

What I meant to convey in the last post was that the flow control should be taken care of - there are really 2 considerations:

a). the RTS/CTS flow control - this is only relevant when there is an actual, physical serial port, which in your case I believe is only on the PC side.  Since your converter specifies precisely that it needs to use this "hardware" flow control, after which the communication is entirely bluetooth, I don't think you need to worry about it.  To that effect, I tried to provide a theoretical justification for why that converter might use the RTS/CTS flow control for it's RS-232 interface.

b). bluetooth flow control - it appears that, like rs-232 serial ports, bluetooth also has some form of flow control.  This seemed implicitly true given that the converter was somehow using the serial port's RTS/CTS flow control, so I did a quick google search and seem to have confirmed this:

Bluetooth Flow Control

http://www.kjhole.com/Standards/BT/BT-PDF/Bluetooth5alt.pdf#search=%22bluetooth%20flow%20control%22

However, this should be completely abstracted away and handled by the bluetooth interfaces on both ends.

2. "Also should the serial flow control setting on my laptop LV program and the bluetooth adapter be set to RTS/CTS or should the LV program be set to none?" 

Given that the adapter "can ONLY be set to RTS/CTS", then you should absolutely configure your PC serial port (to which the adapter is connected) to use RTS/CTS flow control (ie. hardware flow control).  This way, the serial port will mimic the flow control that bluetooth has built in - this will be necessary for maintaining synchronization and data integrity, and this could be the cause of the problem!  You can set this using the VISA Configure Serial Port VI, which is on the VISA serial palette - if you look inside, you'll see it's just a VISA property node, but I would recommend explicitly setting all the inputs to that VI to match the requirements of your bluetooth adapter.

3. In reference to VISA support in the 8.20 PDA module, you asked: "So would you suspect that this issue could resolve itself if I had this added level of control?"

No, it doesn't sound like using the VISA API on your PDA side is going to solve this problem - when your PDA code is compiled and sent to the PDA, it's going to be the same calls on the PDA whether you use the VISA API or the current compatibility API.  On that side, we have a direct bluetooth interface... remember the idea of a "virtual serial port" is only to allow us to use a serial programming API in order to access the bluetooth resource, there isn't actually a serial port involved.

It sounds like we're a step closer... hopefully we'll take another with this post!

Best Regards,

JLS