Com3 problems

Started by church_art November 20, 2005
I am using a BX35 and inputing the output from Parallax's RFID
reader and I should receive 12 bytes Byte 1 to 12 >> CR &
Characters 1 to 10 & LF.
Actual String is CR 0F027D6013 LF

I process after the queue is >11 to get 12.I only get
F027D6013 LF and two empty characters.
So I only get byte 3 to 12 and nulls in 11 & 12

When I use a test VB program to test it I get the proper 12 digit
code so I know its not the RFID reader.

Releveant code ---------------------------------

dim ICom3(1 to 50) as byte
dim OCom3(1 to 50) as byte

defineCom3 xpin(6),xpin(0),bx0000_1000 'non inv, no parity, 8 bits

qs=getqueuecount(Icom3)
if qs>11 then
code=""
debug.print cstr(qs) ' getqueue Icom3,code,12
for n=1 to 12
debug.print mid(code,n,1)
Next
clearqueue Icom3
end if

(i display to an LCD & get the same result so its not a stck issue
with debug.print i dont think)

Help ??

Art


> Actual String is CR 0F027D6013 LF
> I only get F027D6013 LF and two empty characters.


If the RFID sends continuous data, my guess is that your processing
takes two character times (while the CR and first zero are received) and
then you erase them before they are read from the queue with the
ClearQueue. Unless you can reduce your process time to less than a
character time (you do waste much time with the debug.prints), I think
you should remove the ClearQueue.

And, just counting 12 incoming bytes to trigger processing does not
guarantee synchronization with the RFID data. I think I'd take data
byte-at-a-time and look for the LF to start the process.

You do not need a 50-byte input queue if you take the data in 12-byte
chunks and you can keep up with it. You need room for the 12 byte
record, plus apparently a few bytes of process time, in your case, or
something like 15 bytes. If you take the data byte-at-a-time and keep
up, you only need a few bytes of input queue. Tom


I've been meaning to play with this critter but I haven't had the
time yet. However, notice that the docs for the reader contain some
sample code and in the sample code, the reader program "enables" the
reader, gets it's 12 bytes and then "disables" the reader. If you use
this approach, that would eliminate any timing issues. Combine this
with Tom's suggestion to get the id data "a byte at a time" and you
shouldn't have any problems. The sample code that comes with the
reader is for the Stamp but it's very straight forward and you
shouldn't have any trouble porting it to the BX35.

Paul At 04:27 PM 11/20/2005, you wrote:

>I am using a BX35 and inputing the output from Parallax's RFID
>reader and I should receive 12 bytes Byte 1 to 12 >> CR &
>Characters 1 to 10 & LF.
>Actual String is CR 0F027D6013 LF
>
>I process after the queue is >11 to get 12.I only get
>F027D6013 LF and two empty characters.
>So I only get byte 3 to 12 and nulls in 11 & 12
>
>When I use a test VB program to test it I get the proper 12 digit
>code so I know its not the RFID reader.
>
>Releveant code ---------------------------------
>
>dim ICom3(1 to 50) as byte
>dim OCom3(1 to 50) as byte
>
>defineCom3 xpin(6),xpin(0),bx0000_1000 'non inv, no parity, 8 bits
>
>qs=getqueuecount(Icom3)
>if qs>11 then
> code=""
> debug.print cstr(qs) ' getqueue Icom3,code,12
> for n=1 to 12
> debug.print mid(code,n,1)
> Next
> clearqueue Icom3
>end if
>
>(i display to an LCD & get the same result so its not a stck issue
>with debug.print i dont think)
>
>Help ??
>
>Art >Yahoo! Groups Links >
>

"I've seen the future, and you're not going to like it."
-- Vincent van Gui



I do enable and disable the reader (didnt attach that part of code) but I am going to try the byte at a time LOOK FOR cr & lf and see if I can get this figured out.
Art

-----Original Message-----
From: basicx@basi... on behalf of Paul Dubinsky
Sent: Sun 11/20/2005 5:40 PM
To: basicx@basi...
Cc:
Subject: Re: [BasicX] Com3 problems I've been meaning to play with this critter but I haven't had the
time yet. However, notice that the docs for the reader contain some
sample code and in the sample code, the reader program "enables" the
reader, gets it's 12 bytes and then "disables" the reader. If you use
this approach, that would eliminate any timing issues. Combine this
with Tom's suggestion to get the id data "a byte at a time" and you
shouldn't have any problems. The sample code that comes with the
reader is for the Stamp but it's very straight forward and you
shouldn't have any trouble porting it to the BX35.

Paul


Thanks Tom. I tried the following

qs=getqueuecount(Icom3)

if qs>30 then

Call PutPin(XPin(7), bxOutputHigh) 'turn off

getqueue Icom3,code,30

debug.print code

delay 2.0

Call PutPin(XPin(7), bxOutputLow)

end if

If i clear the debug window i get

F027D6013

Then scan again i get

F027D6013
013
0F027D6013
0F027D6013
@ :

So the right code is in there as you suspected. Why it works like this is beyond me - perhaps the software enabled com3

On the pc I get it perfect the first time
cr 0F027D6013 lf

Thanks - I can get around this problem for now.

Art



OK I finally solved my problem .... i was getting a string of 1 from the queue instead of a byte ( I assumed you could do that .. guess not) !!
Thanks Tom

Art

New code

qs=getqueuecount(Icom3)

if qs>0 then

getqueue Icom3,code,1

if code then 'CR

txcard=""

for n=1 to 10

getqueue Icom3,code,1

txcard=txcard & chr(code)

next

getqueue Icom3,code,1

if code then 'double check LF

Call PutPin(XPin(7), bxOutputHigh) 'turn off

debug.print txcard

delay 2.0

Call PutPin(XPin(7), bxOutputLow)

end if

end if

end if


--- In basicx@basi..., "Art Church" <achurch@m...> wrote:
> ... I was getting a string of 1 from the queue instead of a byte
> ( I assumed you could do that .. guess not) !!

Dim iq(1 to 25) as Byte
Dim code as String
...
code=""
Call GetQueue(iq, code, 12)

This will definitely not work as you might have expected. The
GetQueue() routine simply places the bytes read in memory beginning
at the address of the variable that you've given. It knows nothing
about what the variable's type is.

Strings are special variables in that the first two bytes of storage
contain control information (length and type). The actual data area
of a String variable begins at the third byte. If you could tell
GetQueue() to place the data beginning at the third byte (you can't)
this strategy might work but you would still have to patch up the
string length (first byte) afterward.

The code that is written above will extract 12 bytes from the queue
but they'll be in the wrong part of the String variable.
Unfortunately, you can't use BlockMove() to copy them to the correct
place because it doesn't perform an overlapping copy correctly. (An
overlapping copy is where the destination is in the midst of the
data being copied.)

Don


Excellent !!! Now I understand why when I did do this I was missing the first two bytes (LF, 1st character)
Thank you. Its always better when you understand why something dosn't work instead of only what does work. Thanks Don.

Art

[]