RS232 - Timeout / RTS-CTS

Is it possible to define a Timeout when using the "ComRdByte" Function,
so that CVI will not break down, when no byte was send.
I´ve also problems with the RTS/CTS-Signal. If i use them , it is not
possible to read from the port ! There is nothing happening on these
lines.... can you help me ?

You can either set a timeout for read/write operations with the SetComTime function or set up a callback function to be called whenever there is a certain number of bytes at the port with the InstallComCallback function. I am a fan of using the InstallComCallback method and if you want to know exactly how to use it look at the example in the C:\MeasurementStudio\cvi\samples\rs232 directory.
Only use the handshaking modes that are supported by the device you are connecting to. Meaning either use hardware only, software only, hardware and software, or none. All are very common. In your case it doesn't appear that hardware is working for you, so to turn it off use the SetCTSMode function to turn hardware handshaking off.
Jason Foster
Applications Engineer
National Instrume
nts
www.ni.com/ask

Similar Messages

On RTS-CTS & DTR-DSR pairs, which and why?

Hello All
Is there somewhere in the Net a good article about when and why to use the flow control RTS-CTS and/or DTR-DSR.
I am dealing with duplex communication between two devices via RS232 and I would like to know when and why to control those lines.
I also found three types of Null-Modem cables and all it is connected with the control of those lines.
Where I can read about it?
Thanks in advance
Pawel

Most RS-232 communication is full duplex, meaning you can transmit and receive at the same time. RS-232 UARTs have separate transmit and receive machines and FIFOs. The processing speed and large available memory of today's electronics (PCs as well as other devices) drastically reduce the need for hardware handshaking. I've been writing RS-232 applications for almost 20 years. I haven't used hardware handshaking for over 15 years, and that application only required it because one piece of equipment was already 30 years old.
Hardware handshaking adds complexity to the software as well as the hardware. If you're only going a short distance, off the shelf cables include all RS-232 lines. But for longer runs, it will be easier and cheaper to run 3 or 4 conductor cabl
e without hardware handshaking.
If you need handshaking, consider software handshaking if your devices support XON/XOFF handshaking.
If you do a Google search for RS-232 handshaking, you'll find plenty of links. Some of these will give you an introduction.
http://www.airborn.com.au/rs232.html
http://www.bb-europe.com/tech_articles/faq_rs232_connections_work.asp
http://www.qkon.com/uploads/27_Practical%20RS232%20Design%20Considerations.pdf

Same Channel on Different WLANs and RTS/CTS

Hi
I have 2 questions about physical layer of wireless lan.
1-) Many WLANs(SSID) use same channel for communication, that means they use same frequency, what prevents the collisions between different wlans but same channel?( I am asking about RF signal collision)
2-) Do rts and cts valid for just one wlan that computer which is generated, belongs to or do rts/cts synchronize all different wlans that use same frequency.
Thanks.

1.) Congestion Avoidance. Before the client transmits, it listens to for energy on the frequency it is transmitting on. If it hears energy, it backs off for a time. Then listens again.
http://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_collision_avoidance take a look at the diagram on the left
2.) RTS/CTS client sends the RTS, then the AP will send the CTS.
http://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS
HTH,
Steve

802.11 RTS/CTS and hidden node problem

Guys,
A little confused here.
The hidden node problem is if two nodes within a cell can hear the AP but not each other. OK.
But, when we talk about 802.11b and 802.11g backwards compatibility causing reduced throughtput in terms of bandwidth, it seems that this is always blamed on 802.11g stations having to use RTS/CTS.
But,
Even in an 802.11g only cell, dont stations still have to use RTS/CTS mechanisms for the hidden node problem?
I'm confused.com!
Thx
Ken

When 802.11b clients are associated to an 802.11g access point, the access point will turn on a protection mechanism called Request to Send/Clear to Send (RTS/CTS). Originally a mechanism for addressing the "hidden node problem" , RTS/CTS adds a degree of determinism to the otherwise multiple access network. When RTS/CTS is invoked, clients must first request access to the medium from the access point with an RTS message. Until the access point replies to the client with a CTS message, the client will refrain from accessing the medium and transmitting its data packets. When received by clients other than the one that sent the original RTS, the CTS command is interpreted as a "do not send" command, causing them to refrain from accessing the medium. One can see that this mechanism will preclude 802.11b clients from transmitting simultaneously with an 802.11g client, thereby avoiding collisions that decrease throughput due to retries. One can see that this additional RTS/CTS process adds a significant amount of protocol overhead that also results in a decrease in network throughput.
In addition to RTS/CTS, the 802.11g standard adds one other significant requirement to allow for 802.11b compatibility. In the event that a collision occurs due to simultaneous transmissions (the likelihood of which is greatly reduced due to RTS/CTS), client devices "back off" the network for a random period of time before attempting to access the medium again. The client arrives at this random period of time by selecting from a number of slots, each of which has a fixed duration. For 802.11b, there are 31 slots, each of which are 20 microseconds long. For 802.11a, there are 15 slots, each of which are nine microseconds long. 802.11a generally provides shorter backoff times than does 802.11b, which provides for better performance than 802.11a, particularly as the number of clients in a cell increases. When operating in mixed mode (operating with 802.11b clients associated) the 802.11g network will adopt 802.11b backoff times. When operating without 802.11b clients associated, the 802.11g network will adopt the higher-performance 802.11a backoff times.

RTS/CTS Problem ?

Hi..
I have to communicate between RS485 (NI card) to RS485 of the application board "with handshaking RTS/CTS"
I use serial VISA of labview and set Flow Control = RTS/CTS. and I monitor the status of RTS and CTS by property node to LED.
I espect that when I run my program first RTS should be green but it always red (no signal when I measure from Oscilloscope).
When I connect with the board, CTS is green and I can receive some wrong data from the board !!
I don't understand firstly, why the status of RTS is always red ? Is this behavior is correct ?
Thanks for any kind help.

If you are using RTS/CTS flow control, you should not be looking at the RTS state. It will always return -1. Depending on how you handle the -1 case, I could believe your LED would be either green or red (I know you said it is red) but it will never change color.
The driver itself will properly set the state of RTS, but it's just not something we allow you to monitor, because you are not directly in control of it. If you measured the RTS signal from the pin with an oscilloscope, you should see it change when you write data with VISA Write.
CTS, on the other hand, should always be returning a valid value. If CTS is set, your device is telling you that you have data to read. And if you get garbage, perhaps your instrument is not properly set up in RT
S/CTS mode?
Dan Mondrik
National Instruments

Turning off wireless RTS/CTS feature

Is it feasible to turn on/off wireless card RTS/CTS feature for temporary from program code?
Which API to be used ?

nope. not from java. unless you use JNI and write code to interface with the network card software.

Protecting against Virtual Jamming (RTS/CTS) attacks ?

I am new to Wireless, and was wondering how Cisco products guard againts "Virtual Jamming" attacks where a station keeps sending RTS/CTS packets, and causes the NAV of all other stations to be reset.
I believe that the "Rouge AP" detection / prevention mechanism infact uses this very same method to block out rouge access points.
So what prevents a rouge station from doing the same ?
I am also not sure if this problem is eliminated in 802.11n due to its full-duplex like behaviour ??
Thanks

802.11 uses CSMA/CA.
There are 2 ways a radio will sense the medium.
Physical Carrier Sense - is a mech that allows the radio to sense if there is transmissions on the channel
Virtual Carrier Sense - is the use of rts-cts and cts-to-self to reserve the network with NAV timers.
yes, you can do DoS attacks with the correct software to 'jam' the MAC later and not allowing ANY radios to talk at ALL.
Rogue detector with the WLC does not operate in this way. It simply spoofs the rogues access point BSSID and sends deauth frames telling surrounding clients not to attach.

Monitoring DTR RTS CTS

Hello,
I'using Labview 5.1.1
I just want to monitor DTR RTS CTS states of my COM port.
I think it's basic, I know Google is my friend but i've spend too much
time trying tips that do not work.
What is the easiest way to perform the task according to you ?
thank you.
Rudy

Are you using VISA or the older serial functions? With VISA, you can do it with a VISA property node (Modem Line Settings). In your old version of LabVIEW the property node may have been called something (attribute nodes?). The other serial driver has a function called serial line ctrl.vi and it's in vi.lib>platform>_sersup.llb.

RTS/CTS -unicast or broadcast + Random backoff time

Hi everybody,
Iam reading through the frame handshake in WiFi. Also went through some of the good articles in this forum.
I understand that to avoid collision, RST/CTS handshake is used in the wireless Air medium.
I have attached the RTS-CTS handshake and I would like to know if these frames are unicast or broadcast.
Since they are sent from a specific source say Wifi Client to a specifc destination say Wifi AP, i assume the RTS and CTS signals to be unicast but i dont understand then how the other wifi stations/clients will listen/get the duration (NAV)
Also regarding the backoff time interval, I would like to know how this time is decided by the waiting clients? Say client A and Client B are waiting for the medium to be free. Both get the NAV duration as client C is using the medium. Now after the NAV time is complete, the clients A and B will wait for a backoff time.
>how much is this random time?
>Can both set the same backoff time say 1? >Will the clients with min backoff time will get to check the medium first.
>What is the max time each client will get to use the medium? What if Cient C using the medium has lots of data to send. Will clients A and B have to wait till Client C finishes? OR is there a max time duration.
Pl advise.

Whenever a wireless client wants to send a data packet to the access point, it actually transmits a four-packet sequence called the RTS-CTS-DATA-ACK packet sequence. Each of the four 802.11 frames carries a NAV field that indicates the number of microseconds that the channel is reserved for by a wireless client. During the RTS/CTS handshake between the wireless client and access point, the wireless client sends a small RTS frame that includes a NAV interval large enough to complete the entire sequence. This includes the CTS frame, the data frame, and the subsequent acknowledgment frame from the access point.
When the wireless client transmits its RTS packet with the NAV set, the transmitted value is used to set the NAV timers on all other wireless clients associated to the access point. The access point replies to the RTS packet from the client with a CTS packet that contains a new NAV value updated to account for the time already elapsed during the packet sequence. After the CTS packet is sent, every wireless client that can receive from the access point has updated their NAV timer and defers all transmissions until their NAV timer reaches 0. This keeps the channel free for the wireless client to complete the process of transmitting a packet to the access point.

RTS/CTS Mechanism

Guys,
Could you please explain briefly about RTS/CTS mechanism.
when an environment use RTS/CTS mechanism?
when CTS to self frames occurs?
How CSMA/CA mechanism involved in RTS /CTS mechanism?
Thanks,
Suresh

What happen when the rts packet destroy or collide with another packet.
When the RTS doesn't reach the radio the client will not get a CTS and will retry the RTS frame again.
What is difference b/w DCF & EDCA.
DCF doesn't support QoS and is considered equal access tocall. QoS is supported in HCF. EDCA work with HCF and QoS. It is the mechanism that supports cW sizes.
What is the time duration for “cts-to-self”.
Depends on really on how long the client needs the medium for. If it send large frames @ 1500 bytes at 1 PHY, it will need more time of course.
What is the max frame size of the rts & cts & cts-to-self.
Not sure, but they are small. These are control frames and have no payload.
In which 802.11 standard does rts and cts are implemented.
RTS/CTS is used when the protection mechanism is used for example b clients on a g/n network. Its also used in the new 11ac as well.
Does 802.11b supports rts and cts. If not then which CSMA/CA is used
I can't recall if b does I want to say yes. CSMA/CA is more about the overall mechanics not RTS/CTS.

RTS/CTS and Fragmentation Thresholds

Why does the CB21AG card not support these settings like the 350 and CB20A cards do? These settings are VERY important in my environment.

I just got my first response from TAC on this. I asked how do I set the fragmentation and RTS threshold on the cb21ag card. The response was that I set these on the AP and I should not adjust these because they are set to optimum. I asked for the case to be escalated to someone who actually knows what and why I need to set these.
I feel like I am dealing in the "Black Arts" when asking questions about building large scale 802.11 wireless networks and dealing with these issues.

Cts/rts handshake

Hi,
For a PI motion controller I need according to the manual the rs232 cts/rts handshake. As I have seen this can be selected from the 'open serial port.vi'. However, the instrument driver provided by the manufacturer doesn't switch the handshaking on in the open serial port.vi .
If i switch the handshaking off i can see a signal at pin3 of my serial port. I also see something when I switch on either RTS or CTS. When I switch on both I don't see anything (that's what I might expect). But -and here is my question- I never see anything on the RTS pin of my serial port, nomather which handshake settings in the 'serial port open.vi' .Could anybody give me suggestions about the RTS/CTS handshaking for LAbview ? I'm not using the VISA package since the
instrument driver from the manufacturer didn't use it. I'm working with Labview 6.1 and SUSE linux OS.
Thank you very much

The native serial vi for opening a serial port in LabVIEW is Serial Port Init.vi. Open serial port.vi is not a native function. You may want to check on the origins of this vi. You also mentioned switching on RTS and CTS. The CTS line is an input, what do you mean by setting it? To set RTS, are you using serial line ctrl.vi? When you just open the port with RTS/CTS handshaking you should be reading a positive voltage on the RTS line, pin 7.

Serial port CTS monitoring

I would like to know how to read the status of the Clear To Send (CTS) line.
I need this in order to implement a write with timeout vi, required when
using the RTS/CTS handshaking protocol.
Thanks
Gilles

Hallo, Gilles,
Du meintest am 21.09.99 zum Thema serial port CTS monitoring:
> I would like to know how to read the status of the Clear To Send
> (CTS) line.
advanced/memory/in port
If you run LabView under Windows NT, you need "hwaccess" from the NI ftp-
server for direct port access.
CTS is line 4 (2^4) at (port base + 6), the MSR (modem status register).
Ralf Browns interrupt list (especially the "ports.lst") shows many
details.
Viele Gruesse!
Helmut

Missing data rs232

I repeat this quatsion because I have the same problem and can not find a solution.
I have a serial connection to the modem using VISA in Labview 6i.
I have a good connection with the other modem and then recieve a file. This file is good untill I go over 1000 - 1100 lines. From this point complete lines are missing.
Q : Where is the data?
Q : Example of modem-connection?"
Thanks

Serial comm:
1) Use large buffers (64K if possible).
2) Use RTS/CTS (HW) handshaking if possible.
3) Implement a while loop that just determines the # of bytes
available, reads those bytes, and stuffs them into a named queue so
that a different loop can then process them (to disk or wherever). If
you do this you shouldn't lose any data unless there is a hardware
problem (bad cable, long cable, etc.)
You can signal your processing loop from your serial reading loop
using a set occurrence / wait on occurrence.
Douglas De Clue
LabVIEW developer
[email protected]
Dan Mondrik wrote in message news:<[email protected]>...
> It sounds like you should be doing 1 of 2 things (or possibly both)
> th
at you are not doing:
> 1) Call VISA Set I/O Buffer Size with mask 16 and a size greater than
> what you expect to receive. This generally should be less than 32KB
> for it to work cross platform.
> 2) Use flow control so the other side will stop sending data if your
> OS buffer ever fills up.
>
> Good luck,
> Dan Mondrik
> Senior Software Engineer, NI-VISA
> National Instruments

Simultaneous RS232 - DAQ operation messes serial communication

I have 2 GUIs running on my desktop, one of them communicates with an embedded board via the serial port. The other one communicates with the DAQ board via NIDAQ 6062E.
The issue is that the serial comm VI works fine as long as it is running by itself. However, as soon as the DAQ VI fires up, serial commn VI starts acting crazy and returns this error intermittently.
1073807252 VISA:
(Hex 0xBFFF006C) An overrun error occurred during transfer. A
character was not read from the hardware before the next character
arrived.
I have tried resolving issues with this error, but that has not helped.
The Serial comm is the more important VI and it needs to run and acquire data uninterrupted. How can I set it up to do this?
TIA
Vijit

Hi Vijit,
The recommendations from the last post are good, and I would add to
that that you should confirm that your DAQ card is configured to work
using DMA data transfers and not IRQ.
I think that the more serious problem you are seeing is that your flow
control is not working properly. Flow control is intended
specifically to stop the flow of data if you are going to experience a
buffer overflow. You mentioned in your other post that you are
using Xon/Xoff flow control, are you sure that this is supported in
your embedded device? If it is supported, I would recommend
RTS/CTS (hardware) flow control.
Please let us know what forms of flow control are supported by your
embedded controller, and whether or not hardware flow control is an
option.
Jason S.
Applications Engineer
National Instruments

RS232 - Timeout / RTS-CTS

Similar Messages

Maybe you are looking for