|
Bluetooth serial port timeout
Géza Szayer from Hungary [2 posts] |
10 year
|
Hello,
I am having problem with connecting to a virtual serial port. My debug experiences are the followings:
- It works with an ordinary terminal program (Terminal.exe, Terminal v1.9b). I can control a robot along COM6 - Bluetooth, and it receives responses from the robot. Settings are: 115200/8bit/no parity/1 stop/no handshake. (On the robot, we are using BlueGiga WT12 Bluetooth module.)
- The first strange operation is that the serial module option panel cannot remember to the selected serial port as default weather I am checking the "Remember as default" checkbox or not. (It remembers the other parameters, like baudrate etc.)
- There is a difference between the connecting times. When I am using the Terminal.exe, it takes around 2 seconds to get the "Connected" message after starting the connection. (It is normal, and many serial terminals do this.) But RR writes me immediately the "Connected!" message. It is strange for me too.
- If I am trying to send any data with the send now button, and then the most of the control objects become disabled (grayed out) in the terminal window after the timeout (5000ms) elapsed. Why? In this case the serial port may doesn't work. But in normal conditions, if the robot does not send any data, the serial module will terminate? Is it possible to set the timeout to infinite? (I think I Am misunderstanding something about the processing sequence. Image processing is stopped until the serial port doing something?)
For first simple test, I would like to send these 3 decimal bytes: 001, 001, 002.
I wrote this to the send now edit box: \001\001\002 (I also tried \1\1\2 - same result)
Then I pressed the "Send now" button, and after 5000ms, the form grayed out.
- I have tried that, what happens if I "forget" to disconnect with the other terminal, hence it is not possible for RR to connect. In this case, RR writes me the "Connected!" message too. Optimist. :) But it is not possible if the port is not free.
- I have investigated that case, if the terminal program is faulty and lives the port open, and RR may not able to connect, weather I am disconnecting before or not: I used another terminal program (Termite 2.9) to test this, that was able to connect, and if I left the Terminal.exe connected, the Termite replied with error message. (And vice-versa, the Terminal.exe replied with timeout if I left Termite connected.) So the COM6 port is totally free for RR.
I think I forgot a stupid option to set, or doing something wrong. Can you advise?
Thank you for your kind investigation and help. If you need any further technical information that I forgot to describe, please ask for more information.
Best Regards, Géza Szayer
PS: I have attached a picture of the robot
|
|
|
|
Géza Szayer from Hungary [2 posts] |
10 year
|
Hello,
Today, I continued the debugging of the above issue, and now I am updating the results:
- I have tried out RR serial module with other types of serial ports. Ex. USB-serial (FTDI). It worked but I still don't understand when it connects and disconnects: I connected to the USB-serial (COM10), and I have received some data. Then, I pressed "Stop" and selected another COM port. Result: RR wrote a "Connected!" message, and then it received the same data from COM10.
What are the conditions of the "Connected!" message?
What kind of exception handlings are implemented for the serial port handling?
I think that RR can connect to the most of the serial ports, but cannot if one of the procedures takes more time than the ordinary. (In this case, it takes around 2-3 seconds for another terminal program to connect successfully.) During the port initialization procedure, RR may wait (more) for the driver's response.
I can't do more debug action as the problem is related to RR's serial module implementation.
If you can send us the source of that port handling we can review it.
Best Regards, Géza Szayer
|
|
|
|
Steven Gentner from United States [1446 posts] |
10 year
|
Geza,
We had re-reviewed the serial module when we introduced the ser2net capabilities and found a couple issues that you also identified. The graying out of the module was incorrect and caused by the serial modules ability to detect a second serial module within the pipeline that is using the same COM port. For some reason, folks seemed to like having more than on serial module but using the same COM port. Because of this, only one serial module can really determine the parameters of the port which is why if you have 2 modules one will gray out its controls. This was incorrectly being triggered and caused the grayout that you saw. This has been fixed.
The connected versus disconnected can be a bit out of sync. Connected is declared when the serial port is opened and the parameters are set correctly. In theory, if the port is in use, this will not happen. Because the serial module is asynchronous, i.e. it will receive and send data while other modules are executing you may see a delayed reaction from what you normally see with a terminal program that is dedicated to the port. Since we need to continue processing the pipeline and not wait on all input/output this happens. Towards your specific issue, the data appeared after the fact on a different port since the previous data was buffered and just not shown in the message log. We've also tightened the "what you see versus what you are getting" to avoid these confusions.
Keep in mind that the connected versus disconnected state only changes when data is sent or received. Since there is no connection polling like what is possible in TCP the port state only changes if you timeout on a read (see new timeout parameters that are available) or a write causes a failure. The serial tries to do as little as possible on the serial port to avoid confusing the device. You may also check that your terminal program and the serial module are using the same hardware control flow.
I'd recommend downloading the latest version with those fixes and see if that helps your situation.
That's quite a robot! You even put bumpers on it! Very cool.
STeven.
|
|
This Thread