[Lonny Knudson]

Hi Charles,

Could you check your syslog configuration to see where daemon.debug messages are being written? The log file you are looking at doesn’t appear to have debug level messages included. The debug level messages should show at least some LCP and PAP packets exchanged.

[Lonny Knudson]

Hi Charles,

I don’t see a definite cause for the hang up given the information provided. You may want to open a support ticket at http://support.multitech.com

In order to capture more information, it would be helpful to use the chat script below and include the debug option on the command line when you invoke pppd.

pppd debug call gsm

Then get a copy of the log file and post it. Make sure that the log you post includes all events from the connection attempt (the log posted here was missing some of the chat events).

SAY “GSM chatn”

ECHO OFF

ABORT ‘NO DIAL TONE’

ABORT ‘NO DIALTONE’

ABORT ‘NO ANSWER’

ABORT ‘NO CARRIER’

ABORT ‘DELAYED’

ABORT ‘VOICE’

ABORT ‘BUSY’

” ‘AT’

OK ‘AT+CPIN?’

OK ‘AT+CREG?’

OK ‘AT+CSQ’

OK ‘AT+CGDCONT=1,”IP”,”telargo.t-mobile.com”‘

SAY “Dialing…n”

OK ‘ATD*99***1#’

SAY “Waiting for CONNECT…n”

TIMEOUT 120

CONNECT ”

SAY “Connectedn”

[Lonny Knudson]

A Couple of suggestions:

On the ‘IP Setup -> General Configuration’ page, in the ‘Auto Dialout Configuration’ section, try setting ‘Raw Dialout’ to enabled and ‘Handle EIA Signal’ to disabled.

You may also want to try setting ‘Autodialout login’ to disabled (unless your application is programmed to login).

[Lonny Knudson]

A common method used in cellular applications is to have a process that periodically tests the IP layer (example: by attempting to ping a known good address on the remote end of the cellular link) and resetting the cellular modem (and restarting pppd) in the event that the IP transport appears unresponsive. This approach has proven to be very robust way to make sure the cellular link is always up. The tradeoff is that the IP test generates billable traffic on the cellular account so you need to be mindful if your provider charges fees for going over the data usage limit.

[Lonny Knudson]

Hi JM,

Sorry, I don’t know of any.

[Lonny Knudson]

Hi JM,

I’m not a software developer so I don’t think I can provide the best insight on the advantages and disadvantages of different software packages. Since PHP was designed for web based applications, it’s almost always going to be a good choice for this type of application. I’m not sure why Mysql is required… maybe it fulfills a dependency for the PHP implementation, or maybe it just provides a fast way store and look up dynamic information when processing web forms or generating output to be sent back to the browser.

[Lonny Knudson]

Hi JM,

Yes, the UI would be a webpage. Common examples would be configuration utilities in devices like WiFi access points, Cable and DSL modems, various internet appliances, etc…

[Lonny Knudson]

Hi JM,

The CDP doesn’t have a graphics chip onboard so I don’t think there would be much advantage in running graphical interface on the CDP processor.

For devices like this I think the most common solution is a web based application where you use a web browser for the graphical display.

[Lonny Knudson]

Hi Mariano,

Is your DB9 cable a ‘straight’ cable or a crossover (sometimes called null modem) cable ?

The serial port on the CDP is configured as a DCE interface, so you will need a null modem cable to connect to another DCE device like a modem.

[Lonny Knudson]

Hi JM,

A simple method would be to disconnect your existing serial cable then short the TXD and RXD signals on the physical interface (of the CDP).

Next use a terminal program like minicom with flow control and local echo disabled. With local echo disabled you should still be able to see any transmitted characters echoed back to the terminal (if local echo is enabled you should see a double echo).

[Lonny Knudson]

Hi JM,

It is possible to build the cable that you need, however we can’t suggest a pinout without knowing how the connector on the PLC is wired. In your support portal case we posted a diagram showing how the DB9 on the CDP is wired. You will need to have the same information for the connector on the PLC to determine the correct pinout for the cable.

The serial interface on the CDP is a DCE device with standard pin assignments. If the PLC also has a standard DCE interface you can use what’s called a ‘null modem’ or ‘crossover’ cable. If the PLC is a standard DTE interface you can use a ‘straight’ cable (pin 1 wired to pin 1, pin 2 wired to pin 2, etc…). Both of these types of cables you should be able to buy pre-made. If the PLC uses non-standard pin assignments you are more likely to need to build your own cable.

[Lonny Knudson]

Hi Gustavo,

Here is a link to the request form for the embedded product documentation:

http://www.multitech.com/en_US/TOOLS/FORMS/order/embedded_developer_guide.asp

You can also email a request to this address oemsales@multitech.com

[Lonny Knudson]

The cellular radio in the EV-DO models uses a non standard command set for SMS, I don’t think it’s likely that sms-utils will work correctly with these radios.

[Lonny Knudson]

kill [pid of pppd] or killall pppd are generally considered graceful.

[Lonny Knudson]

A HTTP GET or POST would be performed the same way regardless of if it gets transported over the Ethernet link or the cellular link. How the request gets transported is up to the routing table, packet filters, etc…

The first step is to establish a network link using the cellular device. Network links over the cellular devices are brought up using pppd. The link below should help get you started:

http://www.multitech.net/developer/products/cellular-development-platform/applications/ppp-peers/

[Author]

Posts