Subject:
|
rcx command/ echo/ reply - timestamped traces
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 3 Feb 2003 20:24:51 GMT
|
Viewed:
|
2957 times
|
| |
|
|
As I reinvent the wheel of framing commands & replies, I've posted my latest
source:
http://members.aol.com/plforth/console/rcx/RcxLineTerminal.java
My example tty log includes ms timestamps:
http://members.aol.com/plforth/console/rcx/rlt.tty.txt
Here, at least this morning, my IR tower works MUCH better on the little
triangle setting than on the big triangle setting. Which setting works best
appears to be random, as I've seen suggested on the web. Whatever is going
on is NOT as simple like little triangle works best at 15 cm and big
triangle otherwise.
I'd say this code is capable ... but as yet too arbitrary, too inadequately
transparent. To make what's going on plain to the eye, I may need a GUI, to
let me echo more detail without appearing intrusive. Meanwhile, by default,
this code:
1) Discards but complains of any old queued input.
2) Converts the command you entered as hex to a command packet and sends it.
You may punctuate your hex as you please, except that ';' divides one
command from another and '//' says ignore the rest of the line.
3) Listens for a well-formed reply of the expected length.
This code tries to guess when you'd like to see "all the incoming detail" i.e.:
1) A record of the times in ms when how many bytes appeared to arrive.
2) The values in sequence of the bytes that did arrive, including the
otherwise discarded echo and malformed replies.
Listen succeeds immediately if ever a well-formed reply of the expected
length appears at the end of the incoming bytes, else fails after a timeout
of something like 500ms repeats twice. After a success, the decoded reply
appears on screen. After ops x D2 F7, we expect no reply, so then the code
waits to receive an echo of the same length as the command packet, before
succeeding unconditionally.
If & when the listen for a well-formed reply fails, you get all the incoming
detail traced. Except, as yet, you see SerialPortEvent's traced only for
commands entered via "send" or "write". If more than one spe occurs, as yet
this code might be delaying reads.
If you reenter the same op after a success, what goes out will have mask x08
toggled. If you toggle mask x08 yourself after a success, you end up
resending the same command i.e. asking the RCX to resend the reply but not
repeat the command.
If you prefix your command with "send ", then you still get the outgoing
conversion to a command packet, but you read up to the timeout and you get
all the incoming detail traced. Also you lose the auto toggling of x08 in
the op.
If you prefix your command with "write ", then that's like "send" but with
no conversion at all: what you typed goes out unchanged.
The 500ms of the IR tower green light expiring is what I set via
enableReceiveTimeout ... I don't yet understand how that influences the
timeout I see in the last interval of the traced timeline.
Enjoy, Pat LaVarre
P.S. I commonly see javax.comm.SerialPortEvent.getOldValue equal to
.getNewValue, rather than being correct.
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
