RF Handler Reader: has anyone of you ever used this device?

  • Thread starter Thread starter Andrea
  • Start date Start date
Andrea,

What does the code you're using to read from the device look like?
 
Well if it's got a publicly exposed API, then it can be used. Of course if
the API is COM, or uses exported classes, or uses callbacks then the story
is a bit more challenging, but it's still doable with the aid of an
unmanaged shim.
 
Hi
What does the code you're using to read from the device look like?
Click to expand...

Private Sub InitializeCOM()
With SerialPort
.PortName = "COM8:" ''''
'.RThreshold = 1
.DTREnable = True '''''
.Settings.BaudRate = IO.Serial.BaudRates.CBR_9600 ''''
.Settings.ByteSize = 8 ''''
.Settings.Parity = IO.Serial.Parity.none '''''
.Settings.StopBits = IO.Serial.StopBits.one ''''
'.InputLen = 16
.RTSEnable = False '''''
End With

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
InitializeCOM()

Try
SerialPort.Open()
SerialPort.RTSEnable = False
Catch ex As Exception
MsgBox(ex.ToString)
End Try
End Sub

Dim OutputData(11) As Byte

OutputData(0) = CByte(Asc("d"))
OutputData(1) = CByte(Asc("0"))
OutputData(2) = CByte(Asc("g"))
OutputData(3) = CByte(Asc("0"))
OutputData(4) = CByte(Asc("d"))
OutputData(5) = CByte(Asc("0"))
OutputData(6) = CByte(Asc("g"))
OutputData(7) = CByte(Asc("0"))

SerialPort.Output = OutputData
End Sub
 
Andrea,

This is the code that writes and works ok, correct? Do you also have code
that reads from that port, or did I misunderstand your question?
 
Hi,
This is the code that writes and works ok, correct? Do you also have code
that reads from that port, or did I misunderstand your question?
Click to expand...

No, I've not the code that reads form serial port. If you look (in the
debug window) in the output buffer, the buffer is empty :(

I also try to hook the DataReceived event but it's never raised....
 
Andrea,

So is this device supposed to reply to the string you are sending? I haven't
worked with this particular RFID device, but I have worked with other serial
devices that operated in "demand" mode - they sent output only in response
to receiving specific input. It seems to me that they also required an ACK
in reply to the last data they sent before they would listen for more
requests for data.
 
Based on your description, your code from several messages ago is clearly
wrong. "One char followed by zero" must mean the character, followed by a
zero byte. The way you've written your code is "One character followed by
the number zero", not a zero byte.

OutputData(0) = CByte(Asc("d"))
OutputData(1) = 0
OutputData(2) = CByte(Asc("g"))
OutputData(3) = 0
OutputData(4) = CByte(Asc("d"))
OutputData(5) = 0
OutputData(6) = CByte(Asc("g"))
OutputData(7) = 0

Paul T.

Andrea said:
Hi,
So is this device supposed to reply to the string you are sending?
Click to expand...

yes! It should reply to my request. On the website you can find the
complete documentation of the reader, maybe you can understand how it
works.
I haven't worked with this particular RFID device, but I have worked with
other serial devices that operated in "demand" mode - they sent output
only in response to receiving specific input.
Click to expand...

yes, it could be possible. In particular... I see that every command is a
2byte command. One char followed by zero. For example:

char buf[2];
buf[0]='v';
buf[1]=Microsoft.VisualBasic.ChrW(0)

"v0"

this command requires the CF Reader firmware version.
Other commands: "dg" (or maybe "d0g0") turn the led on.

ecc...

Thanks again.
Click to expand...
 
Hi,
So is this device supposed to reply to the string you are sending?
Click to expand...

yes! It should reply to my request. On the website you can find the
complete documentation of the reader, maybe you can understand how it works.
I haven't
worked with this particular RFID device, but I have worked with other serial
devices that operated in "demand" mode - they sent output only in response
to receiving specific input.
Click to expand...

yes, it could be possible. In particular... I see that every command is
a 2byte command. One char followed by zero. For example:

char buf[2];
buf[0]='v';
buf[1]=Microsoft.VisualBasic.ChrW(0)

"v0"

this command requires the CF Reader firmware version.
Other commands: "dg" (or maybe "d0g0") turn the led on.

ecc...

Thanks again.
 
Andrea,

Sorry for not referring to the docs on the website, but my German isn't that
good. I'd suggest rechecking very carefully exactly what bytes the device
expects, perhaps even calling the vendor. Maybe the device also expects a
carriage return and/or line feed at the end of the string and this is
assumed.

--
Ginny Caughey
..Net Compact Framework MVP



Andrea said:
Hi,
So is this device supposed to reply to the string you are sending?
Click to expand...

yes! It should reply to my request. On the website you can find the
complete documentation of the reader, maybe you can understand how it
works.
I haven't worked with this particular RFID device, but I have worked with
other serial devices that operated in "demand" mode - they sent output
only in response to receiving specific input.
Click to expand...

yes, it could be possible. In particular... I see that every command is a
2byte command. One char followed by zero. For example:

char buf[2];
buf[0]='v';
buf[1]=Microsoft.VisualBasic.ChrW(0)

"v0"

this command requires the CF Reader firmware version.
Other commands: "dg" (or maybe "d0g0") turn the led on.

ecc...

Thanks again.
Click to expand...
 
Good catch, Paul.

--
Ginny Caughey
..Net Compact Framework MVP



Paul G. Tobey said:
Based on your description, your code from several messages ago is clearly
wrong. "One char followed by zero" must mean the character, followed by a
zero byte. The way you've written your code is "One character followed by
the number zero", not a zero byte.

OutputData(0) = CByte(Asc("d"))
OutputData(1) = 0
OutputData(2) = CByte(Asc("g"))
OutputData(3) = 0
OutputData(4) = CByte(Asc("d"))
OutputData(5) = 0
OutputData(6) = CByte(Asc("g"))
OutputData(7) = 0

Paul T.

Andrea said:
Hi,
So is this device supposed to reply to the string you are sending?
Click to expand...

yes! It should reply to my request. On the website you can find the
complete documentation of the reader, maybe you can understand how it
works.
I haven't worked with this particular RFID device, but I have worked
with other serial devices that operated in "demand" mode - they sent
output only in response to receiving specific input.
Click to expand...

yes, it could be possible. In particular... I see that every command is a
2byte command. One char followed by zero. For example:

char buf[2];
buf[0]='v';
buf[1]=Microsoft.VisualBasic.ChrW(0)

"v0"

this command requires the CF Reader firmware version.
Other commands: "dg" (or maybe "d0g0") turn the led on.

ecc...

Thanks again.
Click to expand...
Click to expand...
 
Hi,
Based on your description, your code from several messages ago is clearly
wrong. "One char followed by zero" must mean the character, followed by a
zero byte. The way you've written your code is "One character followed by
the number zero", not a zero byte.
Click to expand...

I tried this code too:

Dim OutputData(11) As Byte

OutputData(0) = CByte(Asc("d"))
OutputData(1) = CByte(Asc(Microsoft.VisualBasic.ChrW(0)))
OutputData(2) = CByte(Asc("g"))
OutputData(3) = CByte(Asc(Microsoft.VisualBasic.ChrW(0)))
OutputData(4) = CByte(Asc("d"))
OutputData(5) = CByte(Asc(Microsoft.VisualBasic.ChrW(0)))
OutputData(6) = CByte(Asc("g"))
OutputData(7) = CByte(Asc(Microsoft.VisualBasic.ChrW(0)))

SerialPort.Output = OutputData

but it doesnt work :(
 
And why would you do that, rather than just setting it to zero? I'm sure
that you're making this harder than it needs to be. Read carefully the
manual for the device. Are you *sure* that you're supposed to send a zero
byte after *every* other character (that seems really stupid to me)? Are
there not other commands that you can try which return known strings to the
port (get version, return LED status, whatever)? Alternatively, translate
the manual to English or point us to the English version and we can help
more.

If the device vendor has C code which communicates with the device, *post
it*!

Paul T.
 
Never mind, I've read the application note and you're doing it completely
wrong. Read the section on the 'led green' command. The ***command*** is
"led green"!!! The ***response*** is "DG". That's *not* what you send.

Furthermore, it says *nothing* about sending 0 bytes at the end of strings.
It says that the strings passed to *their* DLL calls have to be
null-terminated. Well, that's just the way all C strings are. The 0 is not
sent and, as far as I can see *no* terminating character is required at the
end of a command. If sending "led green" doesn't work alone, you might
terminate it with a carriage return (ASC( 13 )), but I'm not convinced that
this is necessary, either.

Paul T.
 
Hi,
port (get version, return LED status, whatever)? Alternatively, translate
the manual to English or point us to the English version and we can help
more.

If the device vendor has C code which communicates with the device, *post
it*!
Click to expand...

sent by mail to you.

Thanks!
 
Wow! Their site sucks out loud at pointing you to the right documentation,
then. The datasheet I got lists a *totally* different command set (are you
sure that's not the right one?) At any rate, I see *no* evidence from the
docs that you just sent that there should be a zero after every byte. Try
it without that (send 'dg' alone, two bytes, and see what happens). If that
still doesn't work, try "dg" + 0 and sending three bytes and see what
happens. If that still doesn't work, try "dg" + CR (ASCII 13) and see what
that does.

Paul T.
 
hi,
Never mind, I've read the application note and you're doing it completely
wrong. Read the section on the 'led green' command. The ***command*** is
"led green"!!! The ***response*** is "DG". That's *not* what you send.
Click to expand...

are you sure oh that?
Anyway:
OutputData(0) = CByte(Asc("l"))
OutputData(1) = CByte(Asc("e"))
OutputData(2) = CByte(Asc("d"))
OutputData(3) = CByte(Asc(" "))
OutputData(4) = CByte(Asc("g"))
OutputData(5) = CByte(Asc("r"))
OutputData(6) = CByte(Asc("e"))
OutputData(7) = CByte(Asc("e"))
OutputData(8) = CByte(Asc("n"))
OutputData(9) = CByte(Asc(13))


SerialPort.Output = OutputData

this code doesn't work.

any other suggestions?

Thanks again!
 
Hi,
Wow! Their site sucks out loud at pointing you to the right documentation,
then. The datasheet I got lists a *totally* different command set (are you
sure that's not the right one?)
Click to expand...

the docs I sent you is those available on their website.
At any rate, I see *no* evidence from the
docs that you just sent that there should be a zero after every byte. Try
it without that (send 'dg' alone, two bytes, and see what happens). If that
still doesn't work, try "dg" + 0 and sending three bytes and see what
happens. If that still doesn't work, try "dg" + CR (ASCII 13) and see what
that does.
Click to expand...

I tried that. Still no reply from device :\
I'm trying to uderstand why the c++ sample code works and my .net code
doesn't, but I'm not a c++ programmer, so I cannot understand very much.

Can you help me understanding the right format that device requires?

Thanks!
 
Back
Top