I have cross-compiled the GobiNet and GobiSerial drivers for an embedded linux platform, the device gets brought up, I do notice that I can send AT-command using /dev/ttyUSB2, but I also have the QMI SDK compiled in with some of the example programs.
Here’s my conundrum…
From what I have seen most cellular cards/modems have more than one UART, so one can be used for the cellular connection and the other can be used for AT-commands. This isn’t true for the MC7354, it only has one UART. With our platform we must use two. One to talk to the modem (we dial out using pppd) and another to send AT-commands and responses in an automated fashion.
Since this isn’t possible since two UARTs do not exist, I would like to use the QMI SDK to establish a connection (like using pppd with our dev/ttyUSB2 port) and then this should free up the /dev/ttyUSB2 port for AT-commands right? Does the QMI SDK work off of a different communications port / pins?
OR is it one and only one point of communication? (that /dev/ttyUSB2 UART - I know it could be other ttyUSBs but in this case its 2 for us)
I have some questions for you how did you compile the sdk? I’m having one hell of a time, trying to get the firmware_download tool onto a openwrt mipsel router. I get linking errors as if lib are missing.
The other question is why use ppp mode which limits to 25 mbps. is there a reason you can’t use the QMI tools to manage the connection but also have access to the ttyUSB2 port?
when I want access to a comport port inuse form a modem I use mutex which created a non-locked port I can use to get signal strength, etc
As for what we’re trying to do. We’re using pppd because that’s typically how we get a modem online to communicate. If for any reason we use future modems from different brands, we would like to have it available for use. We are trying to see if using the QMI SDK to connect to a tower could replace pppd, while still having /dev/ttyUSB2 available for AT-commands. Is this even possible? does the QMI SDK communicate using something other than /dev/ttyUSB2 UART? Does it have its own QMI pins to communicate with?
What I’m ultimately trying to do is have the QMI SDK connect to a tower, while still having a single UART available (in this case /dev/ttyUSB2) to send/receive AT-commands.
The mutex you mention would not work because as soon as we free up pppd (as pppd uses ttyUSB2 to communicate with), we lose connection to the cellular tower, and thus we disconnect and would have to reconnect back to a tower once done sending an AT-command. This device must be online 24 / 7.
we use a muxed comport so we don’t have to disconnect from any cell tower at all and it locks the comport port for ttyUSB2 use, we are still free to send signal strength etc to the sudo comport in this case to /dev/modem. no disconnects. we support hundreds of usb sticks this way on our router.
if you use the SDK the connection manager uses the /dev/qcqmi0 to connect and leaves the AT interfaces alone and free for other uses.
When I download the latest SDK 3.3.10 from sierra, it won’t compile at all if you check my other post under dtherrien you will see the error messages that I’m facing.