Determine Serial Port Settings
I am writing an application which is basically acting as a keyboard wedge. The data is coming from a custom keyboard through RS232 to USB and into my PC. Im just wondering if there is a clever way to determine the correct settings for my MSComm control. As these keyboards are abit specialist and Im not sure who would know what baud rate etc the keyboard is outputting. I currently have the MSComm settings below but I find that some strings come through fine (F014 for instance), some are truncated (Cursor L becomes more like Curso) and some need multiple keypresses (Pressing the number 7 does nothing but if I do 7, 8, 9 then on the 9 being pressed all three numbers arrive at the other end.)
Incidentally I have been getting a preceding character (a small square) before the the expected string. Whats that all about? Ive been stripping this out of the string in my code but should I be using that better?
DRTEnable = True
EOFEnable = False
Handshaking 2- comRTS
InBufferSize = 1024
InputMode = 0 - comInputModeText
NullDiscard False
OutBufferSize = 512
ParityReplace = ?
RThreshold = 0
RTSEnable = True
Settings = 115200,n,8,1
SThreshold = 0
Incidentally I have been getting a preceding character (a small square) before the the expected string. Whats that all about? Ive been stripping this out of the string in my code but should I be using that better?
DRTEnable = True
EOFEnable = False
Handshaking 2- comRTS
InBufferSize = 1024
InputMode = 0 - comInputModeText
NullDiscard False
OutBufferSize = 512
ParityReplace = ?
RThreshold = 0
RTSEnable = True
Settings = 115200,n,8,1
SThreshold = 0
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
No, it looks perfect to me.
The KB is outputting more than a single character when each key is pressed.
The smiley face is a CHR(2) - STX or start of text. That makes sense. There may be others there we can't see.
In HyperTerm select Transfer->Capture Text, then press each key on the KB. That will save the output to a file. You can then look at the content of the file to work out exactly what's going on.
Post the file here if you like and I will take a look at it for you.
What settings are you using?
The KB is outputting more than a single character when each key is pressed.
The smiley face is a CHR(2) - STX or start of text. That makes sense. There may be others there we can't see.
In HyperTerm select Transfer->Capture Text, then press each key on the KB. That will save the output to a file. You can then look at the content of the file to work out exactly what's going on.
Post the file here if you like and I will take a look at it for you.
What settings are you using?
ASKER
Here is the file you suggested I capture with every button being pressed. It was using a virtual version of the physical keyboard because Im not anywhere near that. The virtual version was written in VB6 with an mscomm control but seems to act exactly the same as the real keyboard when looking at this problem.
I then tried setting my virtual keyboard to 115200 but leaving hyperterminal at 9600 and still got the same results (albeit I didnt do all the keys). Im not sure if this adds any more information to helping with this but I found it odd that the 2 still communicated OK when at completely different bauds.
Capture.TXT
Capture2.TXT
I then tried setting my virtual keyboard to 115200 but leaving hyperterminal at 9600 and still got the same results (albeit I didnt do all the keys). Im not sure if this adds any more information to helping with this but I found it odd that the 2 still communicated OK when at completely different bauds.
Capture.TXT
Capture2.TXT
OK. Every key pressed starts with STX character (ascii 2) then a string to represent which key was pressed.
I'd suggest that the speed of the virtual keyboard is fixed at 9600, even if you change the setting - no sure why.
9600 is pretty standard for this type of device.
It is unusual that there is no ETX character (ascii 3) after the string. I'm wondering if the emulator isn't perfect. Can you test this with the actual KB?
I'd suggest that the speed of the virtual keyboard is fixed at 9600, even if you change the setting - no sure why.
9600 is pretty standard for this type of device.
It is unusual that there is no ETX character (ascii 3) after the string. I'm wondering if the emulator isn't perfect. Can you test this with the actual KB?
ASKER
I can but just not for a few days until I go and visit the site again maybe next week. Thanks for your help so far.
You're welcome. I'll keep my eye out for your next post and try to be of assistance if I can. Please post another HyperTerm capture file of the actual KB and we should be able to sort it out.
ASKER
Hi
So I have discovered that the keyboard seems to be split into two sections, the majority of the buttons output this STX character however the numeric keys don't. In my VB code I was assuming the character was always there and was stripping it out which was causing the code to exit the sub. This seems easy enough to resolve. One thing I still find though is that the MSComm control does not trigger the oncomm even on the first numeric key press. This seems to be linked to the RThreshold value. If it is set to a low number then it will take 3 keypresses to trigger. increasing this then means more keypresses. The instant answer to this is to keep the number to 1 but then this truncates longer strings received.
So I have discovered that the keyboard seems to be split into two sections, the majority of the buttons output this STX character however the numeric keys don't. In my VB code I was assuming the character was always there and was stripping it out which was causing the code to exit the sub. This seems easy enough to resolve. One thing I still find though is that the MSComm control does not trigger the oncomm even on the first numeric key press. This seems to be linked to the RThreshold value. If it is set to a low number then it will take 3 keypresses to trigger. increasing this then means more keypresses. The instant answer to this is to keep the number to 1 but then this truncates longer strings received.
ASKER
Sorry I forgot to include the capture.
actual-desk-115200.TXT
actual-desk-115200.TXT
Hi Simon,
It appears that every key is a predefined character or set of characters. Some of them start with Chr(2) and some don't. You will need to write your program is such a way that it receives the entire string from the keyboard before processing it. You will need a table of all possibilities. I will leave the logic to you. You will need to start a new question if you need assistance with this.
It appears that every key is a predefined character or set of characters. Some of them start with Chr(2) and some don't. You will need to write your program is such a way that it receives the entire string from the keyboard before processing it. You will need a table of all possibilities. I will leave the logic to you. You will need to start a new question if you need assistance with this.
ASKER
Hi
Yeah I have got the fact that sometimes there is the Chr(2) and sometimes not (this was actually very easy as the code assumed the character was there and would exit if not. Not it just strips it out and carries on). My bigger issue is still though the fact that I sometimes either loose part of the string or have to do mutiple presses (depending on the RTheshold value.) If I set it to trigger oncomm with a single character then longer words are truncated and if II set it higher I dont see shorter strings. I think part of the problem is that there is no consistent last character to look for.
Yeah I have got the fact that sometimes there is the Chr(2) and sometimes not (this was actually very easy as the code assumed the character was there and would exit if not. Not it just strips it out and carries on). My bigger issue is still though the fact that I sometimes either loose part of the string or have to do mutiple presses (depending on the RTheshold value.) If I set it to trigger oncomm with a single character then longer words are truncated and if II set it higher I dont see shorter strings. I think part of the problem is that there is no consistent last character to look for.
Hi Simon,
I think I have answered your original question and then some. I think you should post the current issue as a separate question.
I think I have answered your original question and then some. I think you should post the current issue as a separate question.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
ASKER
I tried hyperterminal and found that the leading character on there was some sort of smiley face. So on here with my original settings I seem to get a result as expected whenever a keypress is made (well if you accept the random character). Here is a screenshot of what I saw when I hit 1,2,3,4,5,6,7,8,9,0 then the four cursor keys and then 3 function keys once in succession.
So It does indeed appear to be something is up with my mscomm control doesnt it?