PCMCIA modem fails when sending AT commands without delays
DComTalk.com Forum Index DComTalk.com
Discussion of VoIP, VPN, Video Conferencen, DSL and other data commucations.
 
 FAQFAQ   MemberlistMemberlist     RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Google
 
Web dcomtalk.com
PCMCIA modem fails when sending AT commands without delays

 
Post new topic   Reply to topic    DComTalk.com Forum Index -> Modems
Author Message
samraj
Guest





Posted: Thu Nov 11, 2004 4:59 pm    Post subject: PCMCIA modem fails when sending AT commands without delays Reply with quote

We have tried to debug the Sierra wireless modem AirCard 750(PCMCIA)
interfaced to our PowerPC 8270 based target through TI PCI1520 (PCI to
PCMCIA controller).
We used the "Linux Configuration for AirCardŽ 55x and 7xx" Application
note 2170005 dated June 3 2002

(http://mycusthelp.com/sierrawireless/supportkbitem.asp?sSessionID=&Inc=192&sFilA=FAQ%20Category&sFilB=Products&sFilC=&KEY=linux)

for testing. We have configured the PCI1520 controller to access the
registers on the Seirra wireless pc card. The Sierra wireless card
emulates a 16550 UART serial port interface.

The wireless modem is configured with the following parameters

1.Baud rate : 9600
2. Parity : NO PARITY
3. Data transfer: 8bits
4. FIFO enabled
5. We used a simple program without any OS.

We succeeded in dialing an external phone by sending ATD command and
also we were able to send SMS message using extended AT commands with
the following limitations.

1. The above operations were successful when the AT commands were sent
with a delay (approximately 1 sec) between each character written to
the virtual serial port transmit register.
The modem responds with "OK" or relevant success message.

2. These operations fail when the delays are removed. The modem
responds with error messages like "NO CARRIER" and "+CMS ERROR: 513".

We thought that the errors could be due to baud rate mismatch. Hence
we have tried with baudrates : 19200 and 38400 but the test did not
succeed.

Why don't the AT commands pass without inserting delays after each
character sent?.

Thanks in advance,
Sam
Back to top
Moe Trin
Guest





Posted: Fri Nov 12, 2004 7:50 am    Post subject: Re: PCMCIA modem fails when sending AT commands without dela Reply with quote

In article <6966c3f8.0411110359.5d235a78@posting.google.com>, samraj wrote:

Quote:
We have tried to debug the Sierra wireless modem AirCard 750(PCMCIA)
interfaced to our PowerPC 8270 based target through TI PCI1520 (PCI to
PCMCIA controller).
We used the "Linux Configuration for AirCardŽ 55x and 7xx" Application
note 2170005 dated June 3 2002

You might want to try over in comp.os.linux.portable and
comp.os.linux.powerpc.

Quote:
The Sierra wireless card emulates a 16550 UART serial port interface.

16550 or 16550_A_ ??? There is a difference. The 16550 without the
A effectively has a one byte buffer, while the 16550A (and later) had
a working 16 character buffer. 9600 BPS (Bits, not Bytes) was about the
limit in the earlier chips, while the A model could handle 115200 BPS.

Quote:
1. The above operations were successful when the AT commands were sent
with a delay (approximately 1 sec) between each character written to
the virtual serial port transmit register.
The modem responds with "OK" or relevant success message.

2. These operations fail when the delays are removed. The modem
responds with error messages like "NO CARRIER" and "+CMS ERROR: 513".

I'm not a PPC person, and I don't use PCMCIA. Normally, these kinds
of errors indicate a flow control or interrupt problem.

Quote:
We thought that the errors could be due to baud rate mismatch. Hence
we have tried with baudrates : 19200 and 38400 but the test did not
succeed.

No, and if it were, I'd be going in the opposite direction (slower).

Quote:
Why don't the AT commands pass without inserting delays after each
character sent?.

How long are the commands? Could you be overflowing the FIFO buffer?
What connect speed are the modems negotiating with each other? That's
why I more suspect flow control problems. You'd also want to mention
how you are sending the commands to the modem - minicom, seyon, cu, or
something?

Old guy
Back to top
 
Post new topic   Reply to topic    DComTalk.com Forum Index -> Modems All times are GMT
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




VoIP Solutions: Telephone Systems Electronics Satellite TV Tech & Gadgets
Powered by phpBB