I have said the PicServo talks fine at 19200 baud with a PC program. This being said, last night I sent the PicServo a 'set baud command to 9600' and this is what happened. I began getting the status byte from my 'return version info' command. I could tell as the returned values were either hex 11 or hex 19. It was 11h when i had 'power_on' input attached to voltage. It was 19h when I took it off and bit 3 goes off while bit 4 gets set. This is normal as I understand things. However, it always gives me a 'chksum_error' bit. I read this as bad values were sent to it. My command stream consists of: two AAh , Fh , Fh resets then the first command to retrieve model and version info. It should return two bytes and a checksum. ---------- header, Def_addr, cmd, addcmd cksum I am sending AAh, 00h , 13h, 20h, 33h In case of wrap around, header = AAh addr = 00 cmd = 13h add cmd = 20h request type and version chksum = 33h address + cmd + add'tl cmds and this returns the status ( 11 or 19h). If I understanding the checksum correctly? I am summing the address, command and additional command bytes. I never get the data only the status byte. For this I will have to verify my SendCommand routine. Fine.. But. I know the BasicX24 can speak 19200 well as I use it on the LCD, only one way, transmit. More work to be done. Tonight a circuit to insure good data between BX24 and PicServo. A 7141 Schmidt trigger and a couple of invertors should do it. More to come. BTW, after reducing the baud to 9600 all the RcvStat versions I tried work. (Do While, For Next, If Then) I have illiminated all my Call Delay's with no change. I am a learning son-of-a-gun.... Thanks, Don Lewis --- In , "Frank Manning" <fmanning@n...> wrote: > From: Don Lewis <djlewis@a...> > > > [...] I expect i misinterpreted the > > GetQueue(InQueue, Variable, number) function. while > > I have been over and over the BasicX Docs I did not > > catch that the instring might misrepresent the > > datatype I am trying to capture. I was thinking it > > would store RAW data. > > And you would be right. It does store raw data. > > This is in fact a high performance way of writing to a string. > Byte 1 is the length, byte 2 is the type (fixed vs. variable), and > bytes 3 through N are the characters in the string. > > In other words, low-level data is written directly to the string. > > The problem is that most people probably expect bytes 1 to N to be > the string characters, not bytes 3 through N. > > The system library has a procedure called PutQueueStr but > unfortunately doesn't include its counterpart GetQueueStr. We > should probably add GetQueueStr or something similar in the future > to prevent misunderstandings. > > -- Frank Manning > -- NetMedia, Inc. |