Post by thread:PIC17C44 & Modem

Does anyone know how to send 'at' commands to a modem? I've tried many things and nothing works. I connected my pic to a PC, and it sends the 'at' strings fine. Is there something else that I should be sending the modem before the 'at' commands? Thanks, Donald ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Email: spam_OUTddalessTakeThisOuTee.ryerson.ca ~~~~~~~~~~~~~~~~~~

Thanks for the info. I'll try it when I get back to my thesis lab. What is the best and simplest way to implement a 1 second delay? I'm running my PIC at 33Mhz. A nested loop is about the only method I can think of. Also, does the modem respond to the '+++' escape sequence with an OK or 0 (if numeric codes)? If so, then I can just wait for the response to be sent to the my PIC. thanks, Donald On Mon, 13 Mar 2000, Paul B. Webster VK2BZC wrote: {Quote hidden}> Donald D'Alessandro wrote: > > > Is there something else that I should be sending the modem before the > > 'at' commands? > > YES! > > A one second delay, three "plus" signs ("+++") in continuous > succession, and another one second delay. > -- > Cheers, > Paul B. >

OK, how about: connect pic to PC to see what you see? On Sun, 12 Mar 2000, Donald D'Alessandro wrote: {Quote hidden}> Date: Sun, 12 Mar 2000 15:50:17 -0500 > From: Donald D'Alessandro <.....ddalessKILLspam@spam@EE.RYERSON.CA> > Reply-To: pic microcontroller discussion list <PICLISTKILLspamMITVMA.MIT.EDU> > To: .....PICLISTKILLspam.....MITVMA.MIT.EDU > Subject: PIC17C44 & Modem > > Does anyone know how to send 'at' commands to a modem? I've tried many > things and nothing works. I connected my pic to a PC, and it sends the > 'at' strings fine. Is there something else that I should be sending the > modem before the 'at' commands? > > Thanks, > Donald > > ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ > ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ > ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Email: EraseMEddalessspam_OUTTakeThisOuTee.ryerson.ca ~~~~~~~~~~~~~~~~~~ >

I have connected my PIC to the pc and I see the 'at' commands sent to the PROCOMM application. And my PIC waits for a response before sending other 'at' commands. So I tested that too on the computer, and its works well. Donald On Sun, 12 Mar 2000, Rich Leggitt wrote: {Quote hidden}> OK, how about: connect pic to PC to see what you see? > > On Sun, 12 Mar 2000, Donald D'Alessandro wrote: > > > Date: Sun, 12 Mar 2000 15:50:17 -0500 > > From: Donald D'Alessandro <ddalessspam_OUTEE.RYERSON.CA> > > Reply-To: pic microcontroller discussion list <@spam@PICLISTKILLspamMITVMA.MIT.EDU> > > To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > > Subject: PIC17C44 & Modem > > > > Does anyone know how to send 'at' commands to a modem? I've tried many > > things and nothing works. I connected my pic to a PC, and it sends the > > 'at' strings fine. Is there something else that I should be sending the > > modem before the 'at' commands? > > > > Thanks, > > Donald > > > > ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ > > ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ~~~~~~~~ Email: RemoveMEddalessTakeThisOuTee.ryerson.ca ~~~~~~~~~~~~~~~~~~ > > >

Donald D'Alessandro wrote: > What is the best and simplest way to implement a 1 second delay? I'm > running my PIC at 33Mhz. *Really?* Sounds like over-clocking to me! > A nested loop is about the only method I can think of. Well, that's about right, but I think most applications of this sort should *already* have the timer/ prescaler generating overflows or interrupts at some period like 1, 2, 4 or 8 milliseconds, and the main loop should be checking for these and counting them to derive a count of seconds or such for whatever timing/ clock functions you might want. The one second is a minimum - anywhere from one to two seconds will do, accuracy is unimportant. > Also, does the modem respond to the '+++' escape sequence with an OK > or 0 (if numeric codes)? It may do, but won't if it is already in command mode. > If so, then I can just wait for the response to be sent to the my PIC. I wouldn't really advise it for the above reason. You only need to do it once. Once in command mode, it stays there and accepts further "AT" commands until told otherwise or a connection is made. -- Cheers, Paul B.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Also, does the modem respond to the '+++' escape sequence with an OK >> or 0 (if numeric codes)? Yes. (either, depending on how it's set up, or nothing at all, or the manufacturer's proprietary responses in some cases) Welcome to the wonderful wierd world of hayes non-standards. There are even hayes modems that don't implement the "hayes standards" properly. FWIW, there is no way to ALWAYS set a hayes modem to a known state. There are a bunch of things that usually work, but you can legitimately turn off the response to command codes, and in that state, your driving software can't determine what state the modem is in. Also, many allow you to disable the command codes entirely. There is a "restore to factory defaults" that's pretty useful, if you aren't locked out, but it's anyone's guess what "factory defaults" are. Various vendors do things that aren't really what the hayes docs say they should do in various modes as well. This is one of several reasons I dis-reccomend using a hayes mode controller on top of a data pump in embedded applications. If it's broke in a way that matters to you, you're hosed. If you roll your own, at least you can fix it. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOMw+loFlGDz1l6VWEQKQzwCdF6XmPiMjy7m1Hkh92Twqxi0cuT8AmwRi pW6ri3bGlVc9866vXplDTUSk =5xAq -----END PGP SIGNATURE-----

Did you send a CR? Miguel ----- Original Message ----- From: Donald D'Alessandro <spamBeGoneddalessspamBeGoneEE.RYERSON.CA> To: <TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> Sent: Sunday, March 12, 2000 5:50 PM Subject: PIC17C44 & Modem {Quote hidden}> Does anyone know how to send 'at' commands to a modem? I've tried many > things and nothing works. I connected my pic to a PC, and it sends the > 'at' strings fine. Is there something else that I should be sending the > modem before the 'at' commands? > > Thanks, > Donald > > ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ > ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ > ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Email: RemoveMEddalessTakeThisOuTee.ryerson.ca ~~~~~~~~~~~~~~~~~~

Thanks for the response. Actually, I did. Donald ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Email: ddalessEraseME.....ee.ryerson.ca ~~~~~~~~~~~~~~~~~~ On Mon, 13 Mar 2000, WF wrote: > Did you send a CR? > > Miguel > {Original Message removed}

Did you send an LF? Phillip Donald D'Alessandro wrote: {Quote hidden}> > Thanks for the response. > Actually, I did. > > Donald > > ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ > ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ > ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Email: EraseMEddalessee.ryerson.ca ~~~~~~~~~~~~~~~~~~ > > On Mon, 13 Mar 2000, WF wrote: > > > Did you send a CR? > > > > Miguel > > {Original Message removed}

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 01:33 PM 3/13/00 -0500, Phillip Vogel wrote: >Did you send an LF? You may need either or both, depending on how the controller is currently configured. Also, correct parity may be an issue (I don't know if you're talking to it in 8N1 or 7(x)1 mode) A DLM is almost essential when dealing with these things, so you can monitor the conversation realtime. Remember, you're talking to someone else's micro and code, and therefore, their bugset gets to interact with yours. :) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOM1i8YFlGDz1l6VWEQJmJwCfYxDpFfr8d3+t6rRqAZFJU+oBjFAAn3Lv R378vdYZvqj2QL5osj5nZrG9 =kcgk -----END PGP SIGNATURE-----

What is an LF? Do you mean line feed? I am sending a CR. What does LF do? Thanks, Donald ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Email: RemoveMEddalessEraseMEEraseMEee.ryerson.ca ~~~~~~~~~~~~~~~~~~ On Mon, 13 Mar 2000, Phillip Vogel wrote: {Quote hidden}> Did you send an LF? > > Phillip > > Donald D'Alessandro wrote: > > > > Thanks for the response. > > Actually, I did. > > > > Donald > > > > ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ > > ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ > > ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ~~~~~~~~ Email: RemoveMEddalessspam_OUTKILLspamee.ryerson.ca ~~~~~~~~~~~~~~~~~~ > > > > On Mon, 13 Mar 2000, WF wrote: > > > > > Did you send a CR? > > > > > > Miguel > > > {Original Message removed}

I have connected my PIC to a PC and it sends the 'at' command strings correctly. Do your routines work for an external modem? What do you mean by, "Do you want to?"? Thanks, Donald ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Email: RemoveMEddalessTakeThisOuTspamee.ryerson.ca ~~~~~~~~~~~~~~~~~~ On Mon, 13 Mar 2000, WF wrote: {Quote hidden}> Maybe your problem the SERIAL COMMUNICATION routines... > > Did you verified if they send a correct character for the terminal emulator? > (BAUDxXTAL) > > I have some ready routines (C) that i did for PIC17C42... works fine! (at > 10Mhz) > > Do you want to? > > Miguel > {Original Message removed}

Generaly terminal programs send out both a CR and an LF after every line. CR - Carriage return (ascii 13) LF - Line feed (ascii 10) This from the bad ol' days when the teletype was VERY dumb (but not deaf, just deafening). I would send both (CR then LF) after each AT command. -Adam Donald D'Alessandro wrote: {Quote hidden}> What is an LF? Do you mean line feed? I am sending a CR. What does LF > do? > > Thanks, > Donald > > Did you send an LF? > > > > Phillip > > > > > > > > Thanks for the response. > > > Actually, I did. > > > > > > Donald > > > > > > > Did you send a CR? > > > > > > > > Miguel

Donald D'Alessandro wrote: > > I have connected my PIC to a PC and it sends the 'at' command strings > correctly. Do your routines work for an external modem? > > What do you mean by, "Do you want to?"? > > Thanks, > Donald Opss...i wrote "incorrect"... Please, verify the SD and RD leds...all must FLASH when you send a command, for example, "ATA" + ENTER (CR) ASCII 13 Don't forget, before to do all tests, to send a INIT string... Well, if your AT commands goes very well, maybe your CABLE (TXD)=MODEM has problems... Miguel Wisintainer

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 04:10 PM 3/13/00 -0500, Donald D'Alessandro wrote: >What is an LF? Do you mean line feed? I am sending a CR. What does LF >do? CR = carriage return (10h??) LF = line feed (13?) No ascii chart handy.. Anyway, the controller may require either one or both, and may or may not permit extras as in sending CR,LF when CR is what it wants. You think that's wierd? Why do rockwell controllers, in Bell 212A mode require a CCITT V.22 BIS answer tone? Cause their controller code is buggy! However, they've shipped a few million of them, so it's a "standard" now. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOM2KFYFlGDz1l6VWEQK9zwCgrQhtKlKGx6fggvRPONRCz9iS+3sAn3iR wf2E8CKAFHtJMX1FViUos4af =suWe -----END PGP SIGNATURE-----

Thanks for all your help. But I still cannot get my modem to communicate with my PIC. I have tried using LF, '+++', pauses, uppercase 'AT', and even verified with the PIC connected with a PC that the commands are indeed correct, and they are. My modem still doesn't like my PIC. And I verified that the modem is working through a generic PC terminal program. Any more suggestions would be very much appreciated. Thanks, Donald ~~~~~~~~ Donald D'Alessandro ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Fourth Year Electrical Engineering ~~~~~~~~~~~~ ~~~~~~~~ Ryerson Polytechnic University ~~~~~~~~~~~~~~~~ ~~~~~~~~ Toronto, Ontario ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Email: EraseMEddalessspamspamBeGoneee.ryerson.ca ~~~~~~~~~~~~~~~~~~

Generaly terminal programs send out both a CR and an LF after every line. CR - Carriage return (ascii 13) LF - Line feed (ascii 10) NO! Terminal programs SEND only the CR. The data stream coming BACK has both CR and LF to adjust the screen/paper/whatever correctly. This from the bad ol' days when the teletype was VERY dumb (but not deaf, just deafening). I would send both (CR then LF) after each AT command. Don't. It probably won't hurt anything at the modem, but elsewhere this will be interpretted as TWO lines worth of commands. BillW

Well, yikes... most serial modems expect PC rates, i.e. 115200/X. Why don't you try something a little more sedate, like 300 baud, and work your way up from there. On Mon, 13 Mar 2000, Donald D'Alessandro wrote: {Quote hidden}> Date: Mon, 13 Mar 2000 17:49:39 -0500 > From: Donald D'Alessandro <RemoveMEddalessKILLspamEE.RYERSON.CA> > Reply-To: pic microcontroller discussion list <PICLISTSTOPspamspam_OUTMITVMA.MIT.EDU> > To: spamBeGonePICLISTSTOPspamEraseMEMITVMA.MIT.EDU > Subject: Re: PIC17C44 & Modem > > That's great, I don't feel alone anymore. > > Ok, I tried several bauds. They are 33.6kbaud, 115.2kbaud, and > 134.4kbaud. > > Donald > > On Tue, 14 Mar 2000, John Orhan wrote: > > > Hi there, > > I've just been through this horrible exercise and may be able to help. What > > baud are you sending? > > > > {Original Message removed}

> That's great, I don't feel alone anymore. > > Ok, I tried several bauds. They are 33.6kbaud, 115.2kbaud, and > 134.4kbaud. That might be your problem right there. Many modems don't like non standard baud rates (33.6k and 134.4k both being non standard. What speed modem are you using? I have encountered some 14.4s and most below that don't touch anything about 38400bps. Try 2400bps, almost every modem will except that one without hickup. TTYL

----- Original Message ----- From: Marc <KILLspammarcspamBeGoneAARGH.FRANKEN.DE> To: <EraseMEPICLISTEraseMEMITVMA.MIT.EDU> Sent: Monday, March 13, 2000 8:48 PM Subject: Re: PIC17C44 & Modem > This should solve your problems: > > a) insert a 10ms pause between each character I don't agree with this item only! > > b) use same case for A and T (ie not aT or At) > > c) terminate the line with CR only (not CR LF etc) > > d) never send a command longer than 60 chars > > e) don't expect the chars to echo back immediately, allow for a few ms delay

Ok, lets review all the possible issues here. 1) You said you send the ATxxx characters from the PIC to a PC, and you are able to SEE the ATxx text at the PC hyperterminal, or whatever are you are using at the PC side. It means your PIC is sending data at the right speed, character separation, required RS232 levels (RS232 logic level is reversed from the UART levels, it means bit 0 is high, bit 1 is low), etc. 2) If your modem is able to auto-detect comm speed, start by using 9600 bps. 3) Make sure your modem has all the interface lines satisfied, as DTR (modem DB25 pin 20) and RTS (modem DB25 pin 4) should be active, if not, modem could still dead as a door knob even if powered up. 4) Make sure you are connecting it correctly... Data TO modem is pin 2 at the modem DB25 connector, Data FROM modem is pin 3 at the modem DB25 connector. I already saw people using RS232 Cross Cable (Null modem cable) to communicate with a modem... wrong decision. Some people think that if the cross-cable works with the PC it should works too with a modem... cross-cable is exactly to eliminate the modems link in a DTE-DTE connection. 5) The AT command could be sent to the modem in a simple and direct string, ending by CR (dec char 13). As many modems default to echo back, your ATxxx command should be observed at the modem rx data pin 3 at the same time you send it to tx pin 2. 6) Remember that ground is at DB25 pin 7, and not pin 1 as I already saw people using around... Pin 1 is Frame ground, not signal ground. 7) Your modem RS232 could be expecting to deal with high RS232 voltage levels, as bigger than +8 and -8 Volts at the interface. I already saw few modems that needed ±10 V at the interface. Your PC RS232 can work in bare TTL levels... 0 and 5 Volts. Other than that, your modem is faulty, or your PIC is not respecting the RS232 correct bit timming, including the 1 or 1¸ stop bits. Wagner Lipnharski UST Research Inc. Orlando, Florida http://www.ustr.net <-- 8051 and Modem website.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> This should solve your problems: >> a) insert a 10ms pause between each character > >I don't agree with this item only! I've seen many cases of this, in fact I'm dealing with this on a barcode wand right now. They need an undocumented 1mS delay between chars. When the modem is flowing data, there would be no need for the delay (else an un-acceptable product) mainly because the modem controller dosen't have to make any decisions. It's just shoveling the data. In "command mode", it's got to be parsing the data looking for commands. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOM6bp4FlGDz1l6VWEQI13ACgrZFm9fpkr0treOvI+TGT5DUui90AoPFT J2Z6qjeqnTOXDGJmDU7CYqXF =NYCG -----END PGP SIGNATURE-----

David VanHorn wrote: > In "command mode", it's got to be parsing the data looking for commands. Not quite for professional products. Most modem chips as TI or Rockwell (Conexant now), buffer all the incomming command string, and only after receiving the CR char they start to parse, decode and execute it. Some other serial devices as bar code scanners and edge units, don't use really a "modem" chip, they use a bare microcontroller that receives byte by byte, some of them doesn't even buffer the incomming data, and this should be the reason why you need an extra inter-character delay. I already saw *several* programmers (doing software UART) just raising the STOP bit and without any delay jumping to another routine, or looping the next character. Stop bit requires at least one bit timming, when 1¸ bit time is recommended, people think the software routine to read the next char to transmit will take the necessary time, don't needing to worry about the stop bit anyway... wrong decision. You said about the undocumented 1ms between characters. In a 2400 bps communication, 1ms means aproximately ¸ bit timming, so a stop bit delay of 1¸ or 2 bit timmings solve the problem. Some mechanic devices require it, or the unbuffered edge units as described above. Wagner.

David VanHorn wrote: > When the modem is flowing data, there would be no need for the delay (else an > un-acceptable product) mainly because the modem controller dosen't have to > make any decisions. It's just shoveling the data. Most new modems can receive data much faster than they transmit, using internal buffers it is common to see the speed between modem and PC as high as 115k bps, even when communicating at only 28.8kbps at the transmission media. Most of this new modems do other processing while transmitting and receiving data, as signal integrity and compression / decompression. Some new modems use to recognize frequently used data packets (whole data strings) and store them into an internal memory, they tell the remote modem to do the same for those particular packets, so, when the same packets needs to be transmitted again, they just send the packet index code and the remote modem just grab it from its internal memory and deliver to its DTE, instead to transmit/receive it all again. I was discussing to produce a "pluggable" 32MB memory solution to such modems, and speed up 8 or more times the actual data links. All the transmitted data was to be saved (buffered) in such memory using a very efficient indexing algoritm. Whenever a new data should be transmitted, the indexing system would try to locate the same data already in the memory, and if yes, will send just the indexed read command to the remote modem. You can call it an "MPEG" compression modem style...

> and speed up 8 or more times the actual data links. All the transmitted > data was to be saved (buffered) in such memory using a very efficient > indexing algoritm. Whenever a new data should be transmitted, the > indexing system would try to locate the same data already in the memory, > and if yes, will send just the indexed read command to the remote > modem. You can call it an "MPEG" compression modem style... If I understand correctly, is that just a variation on the hash table concept? It sounds pretty neat, especially if you are transfering things with repetative patterns in them. TTYL

Wagner Lipnharski wrote: > Most of this new modems do other processing while transmitting and > receiving data, as signal integrity and compression / decompression. Unfortunately, there is, or has been at some times past, a temptation to claim the data transfer rate achieved by compression, as a *real* rate. This, along with WinModems, is one of the big "cons" in the game. On the Internet, compression assists the passing of HTML files somewhat, but is of no use whatsoever on images. And of course, images are the most common, time consuming part of the transaction. > You can call it an "MPEG" compression modem style... *You* can if you like, but insofar as MPEG refers to "lossy" compression, it has no relevance to modems. ;-) -- Cheers, Paul B.

["new" compression scheme for modems] Isn't this basically what v.42bis (and/or classic LZW compression) DOES already? It builds a table of "symbols" (multibyte sequences) and assigns bit patterns to them, with the size of bit pattern decreasing with the rep rate of the symbol. You manage to hit points of diminishing returns pretty quickly as you ramp up the amount of storage for symbols - CPU usage becomes excessive, length of bit patterns for unfrequently used patterns gets large, and overall compression rate flattens out. You can do the relevant experiments with the unix "compress" utility: Compressing with 9 bits /tmp/barwew: Compression: 29.80% -- replaced with /tmp/barwew.Z Compressing with 10 bits /tmp/barwew: Compression: 41.89% -- replaced with /tmp/barwew.Z Compressing with 11 bits /tmp/barwew: Compression: 48.80% -- replaced with /tmp/barwew.Z Compressing with 12 bits /tmp/barwew: Compression: 56.72% -- replaced with /tmp/barwew.Z Compressing with 13 bits /tmp/barwew: Compression: 60.99% -- replaced with /tmp/barwew.Z Compressing with 14 bits /tmp/barwew: Compression: 62.11% -- replaced with /tmp/barwew.Z Compressing with 15 bits /tmp/barwew: Compression: 63.58% -- replaced with /tmp/barwew.Z Compressing with 16 bits /tmp/barwew: Compression: 63.58% -- replaced with /tmp/barwew.Z a 4mb table would be equivilent to 22 bits... BillW

> This from the bad ol' days when the teletype was VERY dumb (but not deaf, > just deafening). I would send both (CR then LF) after each AT command. > > Don't. It probably won't hurt anything at the modem, but elsewhere this > will be interpretted as TWO lines worth of commands. Don't _because_ it hurts. Some commands cancel when you send an additional key (almost all modems will cancel ATD, some even a lot more commands).

> > a) insert a 10ms pause between each character > > I don't agree with this item only! It's the most probable solution to the problem!!! I'm talking to modems since 2400bps was considered "high speed", and there were a lot of different chipsets and proprietary firmware implementations among them. Unless you use char pacing (until the connection is established), some modems will refuse to work reliably.

> > In "command mode", it's got to be parsing the data looking for commands. > > Not quite for professional products. Most modem chips as TI or Rockwell > (Conexant now), buffer all the incomming command string, and only after > receiving the CR char they start to parse, decode and execute it. That might be true for late chipsets, but there are zillions of 2496 faxmodems out there for example, that are still perfectly up to the job of transmitting temperature readings or other low bandwidth info. Those don't necessarily have what you find on your v90 modem, although they are "modems" as well. (and cheap/free ones for the matter).