Post by thread:Where's the Zero (found!)

I found the missing zero, I wrote a routine to dump just 0x0 out and I can see it on the scope. Found out procomm on getting a 0x0 just throws it away, guess it figures I don't need it (c: There is a character table in procomm, I assigned the 0 to a 65 and I get a stream of A's so I'm pretty sure I found the culprit. -Ralph spam_OUTrlandryTakeThisOuThaywood.main.nc.us "If they call it Tourist Season why can't we shoot 'em?"

At 07:17 PM 30/08/98 -0700, you wrote: >I found the missing zero, I wrote a routine to dump just 0x0 out >and I can see it on the scope. Found out procomm on getting >a 0x0 just throws it away, guess it figures I don't need it (c: >There is a character table in procomm, I assigned the 0 to a 65 >and I get a stream of A's so I'm pretty sure I found the culprit. >-Ralph >.....rlandryKILLspam@spam@haywood.main.nc.us >"If they call it Tourist Season why can't we shoot 'em?" > > If you have your termianl programme configured for ASCII mode, then this is correct, the 0 or NULLS are ignored as if they are "carrier" from a modem. To see if this is correct, put your terminal programme into BINARY or HEX mode Dennis

Dennis, I could see that happening if I were just sending to a dumb terminal ie ignoring the nulls, but I was using a capture buffer so I could look at the data file. Now to me if it's going to a file then it should get all the bytes period. But I Ass U me'd wrong. -Ralph rlandryKILLspamhaywood.main.nc.us "If they call it Tourist Season why can't we shoot 'em?"

At 08:33 PM 30/08/98 -0700, you wrote: >Dennis, >I could see that happening if I were just sending to a dumb terminal >ie ignoring the nulls, but I was using a capture buffer so I could >look at the data file. Now to me if it's going to a file then it should >get all the bytes period. But I Ass U me'd wrong. > >-Ralph >.....rlandryKILLspam.....haywood.main.nc.us >"If they call it Tourist Season why can't we shoot 'em?" > > Correct; with the assumption, it doesn't if you have the transfer mode in ASCII: as NULL is not a printable character (Look at as ASCII list). If you had set the transfer mode to BINARY, then you would have gotten the NULLS, and you would have to view the file in BINARY or HEX mode to see them. Also take note of the 7 ASCII and 8 bit extended character sets (But these you probably already know about). As for the capture buffer bit, this may be true, but what happens if you transfer data over a modem link without using RTS,CTS or XON XOFF to send data? When is there no more data to come? How do you know when the link is lost? If NULL where stored in the file, then the file size could get quite large as it will fill with the pack bytes that are inserted by the transmitting end while it waits for more data to process/send (NULL bytes). Dennis

>> ie ignoring the nulls, but I was using a capture buffer so I >> could look at the data file. Now to me if it's going to a >> file then it should get all the bytes period. > As for the capture buffer bit, this may be true, but what happens if you > transfer data over a modem link without using RTS,CTS or XON XOFF to send > data? When is there no more data to come? How do you know when the link is > lost? If NULL where stored in the file, then the file size could get quite > large as it will fill with the pack bytes that are inserted by the > transmitting end while it waits for more data to process/send (NULL bytes). I believe this discussion is about asynchronous links. When the transmitter has no character to send, it does _not_ send nulls. The line stays in a marking state but without start and stop bits. So no framing, ergo no octets being sent. Even if it were a synchronous link, the filler character (aka sync "byte") is usually not a null. Frequently, it is a bit pattern which is defined as illegal. Examples are IBM's SDLC and telephone T1 links. When this reserved bit pattern appears in valid data, the transmitter bit stuffs while the receiver bit unstuffs to keep the protected pattern out of the sync link. But I digress, an asynchronous serial link does not fill with nulls. Lee Jones ------------------------------------------------------------------- Jones Computer Communications EraseMEleespam_OUTTakeThisOuTfrumble.claremont.edu 509 Black Hills Dr, Claremont, CA 91711 voice: 909-621-9008 -------------------------------------------------------------------