2:21 p.m.
Hello,
I have got a custom board with a SIMCOM INCORPORATED SIM5216E modem, a
device not so common. I was able to successfully use it with Ofono, but
I want to get some advise to polish the work, as I have observed a
couple of strange things.
The modem is connected by the USB and report: vendor=0x05c6
product=0x9000. This seem to indicate that it use a Qualcomm chip. It
expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
the AT commands. Since the "atgen" driver is no more, I tested it with
the "g1" driver. It was only a guess and I would like to know if an
other driver is a better choice.
The first problem I faced is that I use Buildroot and the uClibc without
udev (only devtmpfs) on the target system. Dependencies problemes into
Buildroot make it hard to provides the libudev at the needed version
form Ofono 1.2. So I passed --disable-udev to the configure the get ride
of it. While compiling for a uClibc system I have to remove the
backtrace code from src/log.c since it is not available on the uClibc.
As others might like to use Ofono on the uClibc, I suggest to test the
presence of <execinfo.h>, but this is only a small glitch. Now the
difficult part is to find a way to call ofono_modem_register() without
the udev plugin, since the modem.conf support have been removed. I did
not find an other solution than writing a very small plugin that just do
this in his init function:
modem = ofono_modem_create("simcom", "g1");
ofono_modem_set_string(modem, "Device", "/dev/ttyUSB3");
ofono_modem_register(modem);
It work perfectly well, but look a bit overkill to force to write a
plugin for a such simple action. I have the feeling to have missed
something but I can't figure how I should have done this in a proper
way. At one point I hesitate to add a AddModem method into the
org.ofono.Manager interface, but the plugin solution was a quicker hack.
The resulting executable work on the target. I can power up, power down
the modem, enter the SIM pin code, dial and receive call, as well as
sending a SMS. But the operations are not reliable. This is where I
needs some hint if this is the normal consequence of the modification I
have made, or if I need to go into a deep debug session.
While getting a call indication, sometimes I got this:
ofonod[1346]: < \r\n+CDIP: "",128\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n
ofonod[1346]: CDIP for unknown call
ofonod[1346]: CLIP for unknown call
ofonod[1346]: < \r\n+CRING: VOICE\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n\r\n+CDIP:
"",128\r\n
ofonod[1346]: drivers/atmodem/voicecall.c:cring_notify()
ofonod[1346]: drivers/atmodem/voicecall.c:clip_notify() 0786577442 129 0
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Did not find a
call with id: 1
ofonod[1346]: drivers/atmodem/voicecall.c:cdip_notify() 128
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CME ERROR: unknown\r\n
ofonod[1346]: We are polling CLCC and received an error
ofonod[1346]: All bets are off for call management
ofonod[1346]: < \r\nMISSED_CALL: 09:34AM 0786577442\r\n
After that Ofono seem to be lost and only able to be terminated.
While receiving a SMS I sometimes got this:
ofonod[7191]: > AT+CIND?\r
ofonod[7191]: < \r\n+CIND: 4,3,1,0,0,0,1,0\r\n\r\nOK\r\n
ofonod[7191]: > AT+COPS=3,0\r
ofonod[7191]: < \r\nOK\r\n
ofonod[7191]: > AT+COPS?\r
ofonod[7191]: < \r\n+COPS: 0,0,"orange CH",0\r\n\r\nOK\r\n
ofonod[7191]: drivers/atmodem/network-registration.c:cops_cb() cops_cb:
orange CH, 228 03 0
ofonod[7191]: src/network.c:current_operator_callback() 0xf4eb8, 0xf69d8
solution ofonod[7191]: < \r\n+CMT:
,24\r\n07911487777770F0040B911487567744F200002110013094744
ofonod[7191]: < 005C3F79B1D02\r\n
ofonod[7191]: drivers/atmodem/sms.c:at_cmt_notify() Got new SMS Deliver
PDU via CMT:
07911487777770F0040B911487567744F200002110013094744005C3F79B1D02, 24
ofonod[7191]: src/sms.c:ofono_sms_deliver_notify() len 32 tpdu len 24
ofonod[7191]: src/sms.c:handle_deliver()
ofonod[7191]: src/sms.c:sms_dispatch()
ofonod[7191]: src/sms.c:sms_dispatch() dst -1 src -1
ofonod[7191]: drivers/atmodem/sms.c:at_ack_delivery()
ofonod[7191]: > AT+CNMA=1,2\r
ofonod[7191]: < \r\n>
ofonod[7191]: > 0000<CtrlZ>
ofonod[7191]: < \r\n\r\n+CMS ERROR: Invalid PDU mode parameter\r\n
ofonod[7191]: CNMA acknowledgement failed: Further SMS reception is not
guaranteed
And finally, when I send a SMS it could end badly this way:
ofonod[6085]: > AT+CSCA?\r
ofonod[6085]: < \r\n+CSCA: "+41787777070",145\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_csca_query_cb() csca_query_cb:
41787777070, 145
ofonod[6085]: src/sms.c:tx_queue_entry_new() pdu_len: 26, tpdu_len: 25
ofonod[6085]: src/sms.c:tx_next() tx_next: 0xf57c8
ofonod[6085]: > AT+CMGS=25\r
ofonod[6085]: < \r\n>
ofonod[6085]: > 0011000B911487567744F20000A70CC8329BFD063DCD6FF73B04<CtrlZ>
ofonod[6085]: < \r\n
ofonod[6085]: < \r\n+CREG: 1, 1778, 4333\r\n\r\n+CMGS: 23\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_cmgs_cb() Got MR: 23
ofonod[6085]: src/sms.c:tx_finished() tx_finished 0xf57c8
ofonod[6085]: src/sms.c:sms_tx_queue_remove_entry() 0xf57c8
ofonod[6085]: > AT+COPS=3,2\r
ofonod[6085]: < \r\nOK\r\n
ofonod[6085]: Aborting (signal 11) [ofonod]
Since uClibc did not have the backtrace call, I have no more information.
For the 3 issues, the problem is not systematic. It could work perfectly
well, or it could bug. Maybe a timing related problem, as I run Ofono on
a slow ARM926 device.
As I am a newbie about Ofono, I like to get some critics on what I can
do to quickly get a reliable operation.
Jean-Christian de Rivaz
5:03 p.m.
Hi Jean-Christian,
I have got a custom board with a SIMCOM INCORPORATED SIM5216E modem,
a
device not so common. I was able to successfully use it with Ofono, but
I want to get some advise to polish the work, as I have observed a
couple of strange things.
The modem is connected by the USB and report: vendor=0x05c6
product=0x9000. This seem to indicate that it use a Qualcomm chip. It
expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
the AT commands. Since the "atgen" driver is no more, I tested it with
the "g1" driver. It was only a guess and I would like to know if an
other driver is a better choice.
you really want to have a custom modem plugin for this chip. It is
pretty easy to develop this. Modem plugins are dirt simple to write and
that is intentional of course :)
I think there was some kind of SIMCOM patch (or similar enough) posted
on the mailing list some weeks ago.
The first problem I faced is that I use Buildroot and the uClibc
without
udev (only devtmpfs) on the target system. Dependencies problemes into
Buildroot make it hard to provides the libudev at the needed version
form Ofono 1.2. So I passed --disable-udev to the configure the get ride
of it. While compiling for a uClibc system I have to remove the
backtrace code from src/log.c since it is not available on the uClibc.
As others might like to use Ofono on the uClibc, I suggest to test the
presence of <execinfo.h>, but this is only a small glitch. Now the
difficult part is to find a way to call ofono_modem_register() without
the udev plugin, since the modem.conf support have been removed. I did
not find an other solution than writing a very small plugin that just do
this in his init function:
modem = ofono_modem_create("simcom", "g1");
ofono_modem_set_string(modem, "Device", "/dev/ttyUSB3");
ofono_modem_register(modem);
It work perfectly well, but look a bit overkill to force to write a
plugin for a such simple action. I have the feeling to have missed
something but I can't figure how I should have done this in a proper
way. At one point I hesitate to add a AddModem method into the
org.ofono.Manager interface, but the plugin solution was a quicker hack.
Actually the udev solution is a lot simpler. We even use that for
supporting Infineon/IMC modems and Calypso/Openmoko modems that are
hardwired to SPI or UART interfaces.
With USB as transport you really wanna do modem detection via udev. So
you might wanna get this solved with uclibc.
For the backtrace() support, I am pretty disappointed that uclibc does
not support this. It is a fundamental piece that you especially want in
embedded system. So this is strange to me.
Instead of us working around it, it might be better to get uclibc fixed
to support this. On the other hand I am open to look at patches to make
this optional.
The resulting executable work on the target. I can power up, power
down
the modem, enter the SIM pin code, dial and receive call, as well as
sending a SMS. But the operations are not reliable. This is where I
needs some hint if this is the normal consequence of the modification I
have made, or if I need to go into a deep debug session.
While getting a call indication, sometimes I got this:
ofonod[1346]: < \r\n+CDIP: "",128\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n
ofonod[1346]: CDIP for unknown call
ofonod[1346]: CLIP for unknown call
ofonod[1346]: < \r\n+CRING: VOICE\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n\r\n+CDIP:
"",128\r\n
ofonod[1346]: drivers/atmodem/voicecall.c:cring_notify()
ofonod[1346]: drivers/atmodem/voicecall.c:clip_notify() 0786577442 129 0
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Did not find a
call with id: 1
ofonod[1346]: drivers/atmodem/voicecall.c:cdip_notify() 128
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CME ERROR: unknown\r\n
ofonod[1346]: We are polling CLCC and received an error
ofonod[1346]: All bets are off for call management
ofonod[1346]: < \r\nMISSED_CALL: 09:34AM 0786577442\r\n
After that Ofono seem to be lost and only able to be terminated.
This looks like the voice call handling via AT+CLCC is really broken on
this modem. So you have a real problem here.
Do have the AT command specification for this modem? Maybe Simcom has a
vendor specific command for voice call state handling. And you are
suppose to use that instead.
While receiving a SMS I sometimes got this:
ofonod[7191]: > AT+CIND?\r
ofonod[7191]: < \r\n+CIND: 4,3,1,0,0,0,1,0\r\n\r\nOK\r\n
ofonod[7191]: > AT+COPS=3,0\r
ofonod[7191]: < \r\nOK\r\n
ofonod[7191]: > AT+COPS?\r
ofonod[7191]: < \r\n+COPS: 0,0,"orange CH",0\r\n\r\nOK\r\n
ofonod[7191]: drivers/atmodem/network-registration.c:cops_cb() cops_cb:
orange CH, 228 03 0
ofonod[7191]: src/network.c:current_operator_callback() 0xf4eb8, 0xf69d8
solution ofonod[7191]: < \r\n+CMT:
,24\r\n07911487777770F0040B911487567744F200002110013094744
ofonod[7191]: < 005C3F79B1D02\r\n
ofonod[7191]: drivers/atmodem/sms.c:at_cmt_notify() Got new SMS Deliver
PDU via CMT:
07911487777770F0040B911487567744F200002110013094744005C3F79B1D02, 24
ofonod[7191]: src/sms.c:ofono_sms_deliver_notify() len 32 tpdu len 24
ofonod[7191]: src/sms.c:handle_deliver()
ofonod[7191]: src/sms.c:sms_dispatch()
ofonod[7191]: src/sms.c:sms_dispatch() dst -1 src -1
ofonod[7191]: drivers/atmodem/sms.c:at_ack_delivery()
ofonod[7191]: > AT+CNMA=1,2\r
ofonod[7191]: < \r\n>
ofonod[7191]: > 0000<CtrlZ>
ofonod[7191]: < \r\n\r\n+CMS ERROR: Invalid PDU mode parameter\r\n
ofonod[7191]: CNMA acknowledgement failed: Further SMS reception is not
guaranteed
Meaning that acknowledgment with a PDU is not supported. This is sort of
normal.
Check for /* support for ack pdu is not working */ in
drivers/atmodem/sms.c. It does not list OFONO_VENDOR_QUALCOMM_MSM.
However your main problem is that the g1.c modem plugin is the wrong
base for your testing. You need to write your own modem plugin for this.
And finally, when I send a SMS it could end badly this way:
ofonod[6085]: > AT+CSCA?\r
ofonod[6085]: < \r\n+CSCA: "+41787777070",145\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_csca_query_cb() csca_query_cb:
41787777070, 145
ofonod[6085]: src/sms.c:tx_queue_entry_new() pdu_len: 26, tpdu_len: 25
ofonod[6085]: src/sms.c:tx_next() tx_next: 0xf57c8
ofonod[6085]: > AT+CMGS=25\r
ofonod[6085]: < \r\n>
ofonod[6085]: > 0011000B911487567744F20000A70CC8329BFD063DCD6FF73B04<CtrlZ>
ofonod[6085]: < \r\n
ofonod[6085]: < \r\n+CREG: 1, 1778, 4333\r\n\r\n+CMGS: 23\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_cmgs_cb() Got MR: 23
ofonod[6085]: src/sms.c:tx_finished() tx_finished 0xf57c8
ofonod[6085]: src/sms.c:sms_tx_queue_remove_entry() 0xf57c8
ofonod[6085]: > AT+COPS=3,2\r
ofonod[6085]: < \r\nOK\r\n
ofonod[6085]: Aborting (signal 11) [ofonod]
Since uClibc did not have the backtrace call, I have no more information.
For the 3 issues, the problem is not systematic. It could work perfectly
well, or it could bug. Maybe a timing related problem, as I run Ofono on
a slow ARM926 device.
I think you caught a real bug here. I would be great to get a gdb
backtrace to figure out what caused it.
Regards
Marcel
3:08 p.m.
Hi Marcel,
Thanks for your valuable response. Here is an update of the situation.
> The modem is connected by the USB and report: vendor=0x05c6
> product=0x9000. This seem to indicate that it use a Qualcomm chip. It
> expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
> the AT commands. Since the "atgen" driver is no more, I tested it with
> the "g1" driver. It was only a guess and I would like to know if an
> other driver is a better choice.
you really want to have a custom modem plugin for this chip. It is
pretty easy to develop this. Modem plugins are dirt simple to write and
that is intentional of course :)
I think there was some kind of SIMCOM patch (or similar enough) posted
on the mailing list some weeks ago.
It's a mystery for me if Simcom do there own software or only use the
Qualcamm one. The chipset of this modem is the QSC6270 and I expected
that ofono already have something appropriate. I suspect the "g1" driver
to be a close match and if fact it work already quite well. Are you
willing to accept a new modem plugin that is basically a copy of the "g1" ?
The "sim900" patch is still not accepted and, I as far as I understand,
it don't handle as many feature as the "g1" in the post_sim(). I don't
known yet if the two products are close enough to be handled by the same
driver. I have asked Simcom about this question an I hope that there
will give some indication.
With USB as transport you really wanna do modem detection via udev.
So
you might wanna get this solved with uclibc.
After some additional work I was getting udev working on the target. But
understanding how the udev ofono rules should be written for a composite
device is really hard. I did not found an example on how this should be
done to set both OFONO_DRIVER _and_ OFONO_LABEL. I was also confused by
the fact that there is two plugins that handles the udev events: udev
and udevng.
I finally gave up and used the patch below, without any udev rule. ( I
use the "g1" driver for now, but I understand that I need to change that
later. )
diff -ruN ofono/a/plugins/udevng.c ofono/b/plugins/udevng.c
--- ofono/a/plugins/udevng.c 2012-01-07 05:21:37.000000000 +0100
+++ ofono/b/plugins/udevng.c 2012-01-12 01:10:39.000000000 +0100
@@ -595,6 +595,36 @@
return TRUE;
}
+static gboolean setup_g1(struct modem_info *modem)
+{
+ const char *device = NULL;
+ GSList *list;
+
+ DBG("%s", modem->syspath);
+
+ for (list = modem->devices; list; list = list->next) {
+ struct device_info *info = list->data;
+
+ DBG("%s %s %s %s", info->devnode, info->interface,
+ info->number, info->label);
+
+ if (g_strcmp0(info->interface, "255/255/255") == 0 &&
+ g_strcmp0(info->number, "03") == 0) {
+ device = info->devnode;
+ break;
+ }
+ }
+
+ if (device == NULL)
+ return FALSE;
+
+ DBG("device=%s", device);
+
+ ofono_modem_set_string(modem->modem, "Device", device);
+
+ return TRUE;
+}
+
static struct {
const char *name;
gboolean (*setup)(struct modem_info *modem);
@@ -616,6 +646,7 @@
{ "telit", setup_telit },
{ "zte", setup_zte },
{ "samsung", setup_samsung },
+ { "g1", setup_g1 },
{ }
};
@@ -808,6 +839,7 @@
{ "nokia", "option", "0421", "0623" },
{ "samsung", "option", "04e8", "6889" },
{ "samsung", "kalmia" },
+ { "g1", "option", "05c6", "9000" },
{ }
};
Should I insist with the udev rules, or something like this (but the
"g1") is ok ?
For the backtrace() support, I am pretty disappointed that uclibc
does
not support this. It is a fundamental piece that you especially want in
embedded system. So this is strange to me.
Instead of us working around it, it might be better to get uclibc fixed
to support this. On the other hand I am open to look at patches to make
this optional.
I discovered that the last version of uClibc have now the libubactrace.
So I updated to it. I can propose this really simple patch to assert the
presence of the backtrace call:
From 662640e0afb2eb38d896c2673b3afe4c5a280737 Mon Sep 17 00:00:00 2001
From: Jean-Christian de Rivaz <jc(a)eclis.ch>
Date: Wed, 11 Jan 2012 11:39:22 +0100
Subject: [PATCH] Add autoconfigure rule to search for backtrace().
Add autoconfigure rule to search for backtrace().
On system with the uClibc, it can be into the libubacktrace.
---
configure.ac | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4115e34..b07544e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,10 @@ AC_CHECK_FUNC(signalfd, dummy=yes,
AC_CHECK_LIB(dl, dlopen, dummy=yes,
AC_MSG_ERROR(dynamic linking loader is required))
+AC_SEARCH_LIBS([backtrace], [execinfo ubacktrace], [], [
+ AC_MSG_ERROR(backtrace support is required)
+])
+
PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.22, dummy=yes,
AC_MSG_ERROR(GLib >= 2.22 is required))
AC_SUBST(GLIB_CFLAGS)
--
1.7.6.3
> ofonod[1346]:> AT+CLCC\r
> ofonod[1346]:< \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]:> AT+CLCC\r
> ofonod[1346]:< \r\n+CME ERROR: unknown\r\n
> ofonod[1346]: We are polling CLCC and received an error
> ofonod[1346]: All bets are off for call management
> ofonod[1346]:< \r\nMISSED_CALL: 09:34AM 0786577442\r\n
> After that Ofono seem to be lost and only able to be terminated.
This looks like the voice call handling via AT+CLCC is really broken on
this modem. So you have a real problem here.
Do have the AT command specification for this modem? Maybe Simcom has a
vendor specific command for voice call state handling. And you are
suppose to use that instead.
Simcom have now provided to me a complete documentation of all the AT
commands supported by this modem. The AT+CLCC command seem to be ok:
+CLCC:<id1>,<dir>,<stat>,<mode>,<mpty>[,<number>,<type>[,<alpha>]]
I can give more details if needed. The +CME ERROR: <err> is listed as a
possible response of the command. I noticed that the error raise when
the a call change his state (typically a hangup) at the same time that
the AT+CLCC is processing. The AT+CLCC command after the call state
change returns a valid result. Here is an example:
ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[28737]: > AT+CHUP\r
ofonod[28737]: < \r\nOK\r\n
ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\n+CME ERROR: unknown\r\n
ofonod[28737]: We are polling CLCC and received an error
ofonod[28737]: All bets are off for call management
ofonod[28737]: < \r\nMISSED_CALL: 04:11AM 0786577442\r\n
ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\nOK\r\n
Look like a -EINTR on UNIX that require to make a new invocation. Maybe
we should ignore this error for this modem in this particular case. I
have contacted the Simcom support to ask why this modem can return a
"+CME ERROR: unknown" to the AT+CLCC and how we should handle this.
Regards,
Jean-Christian
4:12 p.m.
Hi Jean-Christian,
Thanks for your valuable response. Here is an update of the
situation.
>> The modem is connected by the USB and report: vendor=0x05c6
>> product=0x9000. This seem to indicate that it use a Qualcomm chip. It
>> expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
>> the AT commands. Since the "atgen" driver is no more, I tested it
with
>> the "g1" driver. It was only a guess and I would like to know if an
>> other driver is a better choice.
>
> you really want to have a custom modem plugin for this chip. It is
> pretty easy to develop this. Modem plugins are dirt simple to write and
> that is intentional of course :)
>
> I think there was some kind of SIMCOM patch (or similar enough) posted
> on the mailing list some weeks ago.
It's a mystery for me if Simcom do there own software or only use the
Qualcamm one. The chipset of this modem is the QSC6270 and I expected
that ofono already have something appropriate. I suspect the "g1" driver
to be a close match and if fact it work already quite well. Are you
willing to accept a new modem plugin that is basically a copy of the "g1" ?
I expect a new modem plugin for the sim900. So that approach is fine.
However using the g1 driver as a base is a bad example. That driver is
bit-rotting a lot.
The "sim900" patch is still not accepted and, I as far as I
understand,
it don't handle as many feature as the "g1" in the post_sim(). I don't
known yet if the two products are close enough to be handled by the same
driver. I have asked Simcom about this question an I hope that there
will give some indication.
Let me ask this differently. What are the GSM/UMTS features that you
actually need for your product?
> With USB as transport you really wanna do modem detection via
udev. So
> you might wanna get this solved with uclibc.
After some additional work I was getting udev working on the target. But
understanding how the udev ofono rules should be written for a composite
device is really hard. I did not found an example on how this should be
done to set both OFONO_DRIVER _and_ OFONO_LABEL. I was also confused by
the fact that there is two plugins that handles the udev events: udev
and udevng.
Send the section for your device from /sys/kernel/debug/usb/devices. I
can have a look then.
Should I insist with the udev rules, or something like this (but the
"g1") is ok ?
We need something proper. I help you with that. Just need the devices
endpoint descriptors.
> For the backtrace() support, I am pretty disappointed that
uclibc does
> not support this. It is a fundamental piece that you especially want in
> embedded system. So this is strange to me.
>
> Instead of us working around it, it might be better to get uclibc fixed
> to support this. On the other hand I am open to look at patches to make
> this optional.
I discovered that the last version of uClibc have now the libubactrace.
So I updated to it. I can propose this really simple patch to assert the
presence of the backtrace call:
From 662640e0afb2eb38d896c2673b3afe4c5a280737 Mon Sep 17 00:00:00 2001
From: Jean-Christian de Rivaz <jc(a)eclis.ch>
Date: Wed, 11 Jan 2012 11:39:22 +0100
Subject: [PATCH] Add autoconfigure rule to search for backtrace().
Add autoconfigure rule to search for backtrace().
On system with the uClibc, it can be into the libubacktrace.
This is kinda stupid, but okay.
---
configure.ac | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4115e34..b07544e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,10 @@ AC_CHECK_FUNC(signalfd, dummy=yes,
AC_CHECK_LIB(dl, dlopen, dummy=yes,
AC_MSG_ERROR(dynamic linking loader is required))
+AC_SEARCH_LIBS([backtrace], [execinfo ubacktrace], [], [
+ AC_MSG_ERROR(backtrace support is required)
+])
+
Looks fine to me actually. Send a patch for it.
Regards
Marcel
2:13 p.m.
Hi Marcel,
> It's a mystery for me if Simcom do there own software or only
use the
> Qualcamm one. The chipset of this modem is the QSC6270 and I expected
> that ofono already have something appropriate. I suspect the "g1" driver
> to be a close match and if fact it work already quite well. Are you
> willing to accept a new modem plugin that is basically a copy of the "g1"
?
I expect a new modem plugin for the sim900. So that approach is fine.
However using the g1 driver as a base is a bad example. That driver is
bit-rotting a lot.
Ok, I didn't known that. Maybe the SIMCOM5216 need the same
"bit-rotting" as the g1. We will see.
Let me ask this differently. What are the GSM/UMTS features that you
actually need for your product?
Power control, SIM pin code, manual or automatic operator selection,
signal strength indication, Voice call dial/receive/hangup, SMS
send/receive, and GPRS TCP/IP link.
>> With USB as transport you really wanna do modem detection via
udev. So
>> you might wanna get this solved with uclibc.
>
> After some additional work I was getting udev working on the target. But
> understanding how the udev ofono rules should be written for a composite
> device is really hard. I did not found an example on how this should be
> done to set both OFONO_DRIVER _and_ OFONO_LABEL. I was also confused by
> the fact that there is two plugins that handles the udev events: udev
> and udevng.
Send the section for your device from /sys/kernel/debug/usb/devices. I
can have a look then.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=9000 Rev= 0.00
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech SIM5216
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
The SIMCOM documentation say:
USB interface is mapped to five virtual ports: “SIMTECH USB Modem”,
“SIMTECH NMEA Device”, “SIMTECH ATCOM Device”, “SIMTECH Diagnostics
interface” and “SIMTECH Wireless Ethernet Adapter”. UART, “SIMTECH USB
Modem” and “SIMTECH ATCOM Device” could respond to AT command, and URC
report to these three ports at the same time, but user could set
dedicated port to receive URC (Unsolicited Result Code).
But experiment show that only the If#=2 and If#=3 are able to handle the
AT commands, so I suspect that the doc don't list them in the good
order. I was unable to see anything on the other interfaces. The If#=1
even hang microcom if I try to send any char on it. The If#=3 was the
only one that the Linux USB cdc_acm driver was ok to recognize as a
serial port:
usb 1-1: new full speed USB device number 5 using ohci
ohci ohci.0: GetPortStatus(1)
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 6 descriptors after interface
usb 1-1: default language 0x0409
usb 1-1: udev 5, busnum 1, minor = 4
usb 1-1: New USB device found, idVendor=05c6, idProduct=9000
usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-1: Product: SimTech SIM5216
usb 1-1: Manufacturer: SimTech, Incorporated
usb 1-1: usb_probe_device
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
cdc_acm 1-1:1.0: usb_probe_interface
cdc_acm 1-1:1.0: usb_probe_interface - got id
cdc_acm 1-1:1.0: Control and data interfaces are not separated!
cdc_acm 1-1:1.0: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.0 failed with error -22
usb 1-1: adding 1-1:1.1 (config #1, interface 1)
cdc_acm 1-1:1.1: usb_probe_interface
cdc_acm 1-1:1.1: usb_probe_interface - got id
cdc_acm 1-1:1.1: Control and data interfaces are not separated!
cdc_acm 1-1:1.1: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.1 failed with error -22
usb 1-1: adding 1-1:1.2 (config #1, interface 2)
cdc_acm 1-1:1.2: usb_probe_interface
cdc_acm 1-1:1.2: usb_probe_interface - got id
cdc_acm 1-1:1.2: Control and data interfaces are not separated!
cdc_acm 1-1:1.2: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.2 failed with error -22
usb 1-1: adding 1-1:1.3 (config #1, interface 3)
cdc_acm 1-1:1.3: usb_probe_interface
cdc_acm 1-1:1.3: usb_probe_interface - got id
cdc_acm 1-1:1.3: Control and data interfaces are not separated!
cdc_acm 1-1:1.3: ttyACM0: USB ACM device
usb 1-1: adding 1-1:1.4 (config #1, interface 4)
cdc_acm 1-1:1.4: usb_probe_interface
cdc_acm 1-1:1.4: usb_probe_interface - got id
cdc_acm 1-1:1.4: Zero length descriptor references
cdc_acm: probe of 1-1:1.4 failed with error -22
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
ohci ohci.0: GetPortStatus(1)
I disabled the cdc_acm driver because I finally found that this commit
add the device from the Linux USB option driver:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commi...
It simply provides 5 serial ports 'ttyUSB#'. I was using the ttyUSB3 for
my experiments.
> I discovered that the last version of uClibc have now the
libubactrace.
> So I updated to it. I can propose this really simple patch to assert the
> presence of the backtrace call:
>
Looks fine to me actually. Send a patch for it.
Done.
Jean-Christian
2:19 p.m.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=9000 Rev= 0.00
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech SIM5216
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I didn't noticed that SIMCOM responded to my request while I edited my
last mail. Here is the interface usage according to them:
the USB interface index is:
0- DIAG
1- NMEA
2- AT
3- MODEM
4- Ethernet
So, the port index 2 and port index 3 exposes a working AT command
interface.
Jean-Christian
2:57 p.m.
Hi Jean-Christian,
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=05c6 ProdID=9000 Rev= 0.00
> S: Manufacturer=SimTech, Incorporated
> S: Product=SimTech SIM5216
> C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
> E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
> E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I didn't noticed that SIMCOM responded to my request while I edited my
last mail. Here is the interface usage according to them:
the USB interface index is:
0- DIAG
1- NMEA
2- AT
3- MODEM
4- Ethernet
So, the port index 2 and port index 3 exposes a working AT command
interface.
okay then, run ofonod -n -d '*udev*' and see if you get proper debug
output for your modem. Just pushed a udev patch that does the detection.
Regards
Marcel
3:39 p.m.
Hi Marcel,
> the USB interface index is:
> > 0- DIAG
> > 1- NMEA
> > 2- AT
> > 3- MODEM
> > 4- Ethernet
> > So, the port index 2 and port index 3 exposes a working AT command
> > interface.
okay then, run ofonod -n -d '*udev*' and see if you get
proper debug
output for your modem. Just pushed a udev patch that does the detection.
Thanks for it. Seem to be ok:
ofonod[484]: oFono version 1.2
ofonod[484]: plugins/udevng.c:udev_start()
ofonod[484]: plugins/udevng.c:enumerate_devices()
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device()
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB0 (simcom)
255/255/255 [00] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device()
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.1/ttyUSB1/tty/ttyUSB1
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB1 (simcom)
255/255/255 [01] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device()
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.2/ttyUSB2/tty/ttyUSB2
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB2 (simcom)
255/255/255 [02] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device()
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.3/ttyUSB3/tty/ttyUSB3
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB3 (simcom)
255/255/255 [03] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device()
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.4/ttyUSB4/tty/ttyUSB4
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB4 (simcom)
255/255/255 [04] ==> (null) (null)
ofonod[484]: plugins/udevng.c:create_modem()
/sys/devices/platform/ohci.0/usb1/1-1
ofonod[484]: plugins/udevng.c:create_modem() driver=simcom
ofonod[484]: plugins/udevng.c:setup_simcom()
/sys/devices/platform/ohci.0/usb1/1-1
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB0 255/255/255 00
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB1 255/255/255 01
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB2 255/255/255 02
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB3 255/255/255 03
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB4 255/255/255 04
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() modem=/dev/ttyUSB3
aux=/dev/ttyUSB2 gps=/dev/ttyUSB1 diag=/dev/ttyUSB0
But of course, since the "simcom" driver don't exists yet, there is
nothing after this:
ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property Modem
ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property Data
ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property GPS
ofonod[1019]: src/modem.c:ofono_modem_register() 0xfbcf8
What is the best driver to fork as a base for the simcom driver ?
Regards,
Jean-Christian
2:51 p.m.
Hi Jean-Christian,
>> It's a mystery for me if Simcom do there own software or
only use the
>> Qualcamm one. The chipset of this modem is the QSC6270 and I expected
>> that ofono already have something appropriate. I suspect the "g1"
driver
>> to be a close match and if fact it work already quite well. Are you
>> willing to accept a new modem plugin that is basically a copy of the
"g1" ?
>
> I expect a new modem plugin for the sim900. So that approach is fine.
>
> However using the g1 driver as a base is a bad example. That driver is
> bit-rotting a lot.
Ok, I didn't known that. Maybe the SIMCOM5216 need the same
"bit-rotting" as the g1. We will see.
> Let me ask this differently. What are the GSM/UMTS features that you
> actually need for your product?
Power control, SIM pin code, manual or automatic operator selection,
signal strength indication, Voice call dial/receive/hangup, SMS
send/receive, and GPRS TCP/IP link.
so essentially you need everything. I hope that the voice call
implementation of SIM COM modem is proper. Otherwise you end up with
higher power consumption. We can talk about that later.
>>> With USB as transport you really wanna do modem
detection via udev. So
>>> you might wanna get this solved with uclibc.
>>
>> After some additional work I was getting udev working on the target. But
>> understanding how the udev ofono rules should be written for a composite
>> device is really hard. I did not found an example on how this should be
>> done to set both OFONO_DRIVER _and_ OFONO_LABEL. I was also confused by
>> the fact that there is two plugins that handles the udev events: udev
>> and udevng.
>
> Send the section for your device from /sys/kernel/debug/usb/devices. I
> can have a look then.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05c6 ProdID=9000 Rev= 0.00
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech SIM5216
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=5ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
The SIMCOM documentation say:
USB interface is mapped to five virtual ports: “SIMTECH USB Modem”,
“SIMTECH NMEA Device”, “SIMTECH ATCOM Device”, “SIMTECH Diagnostics
interface” and “SIMTECH Wireless Ethernet Adapter”. UART, “SIMTECH USB
Modem” and “SIMTECH ATCOM Device” could respond to AT command, and URC
report to these three ports at the same time, but user could set
dedicated port to receive URC (Unsolicited Result Code).
So lets figure out which one is the NMEA port and which one is the
QCDM/DIAG port. Use gatchat/test-qcdm --device <tty> and see which one
responds. That one is the QCDM port and the other is the NMEA port.
I bet that interface #4 is actually some form of CDC Ethernet for
highspeed data transfers. So that you do not have to use PPP. Might
wanna ask SIM COM about it.
Once we know the interface mapping, it is pretty easy to add support for
plugins/udevng.c for this hardware.
Regards
Marcel
3:54 p.m.
Hi Marcel,
So lets figure out which one is the NMEA port and which one is the
QCDM/DIAG port. Use gatchat/test-qcdm --device<tty> and see which one
responds. That one is the QCDM port and the other is the NMEA port.
As expected, now that we known the mapping:
$ test-qcdm --device /dev/ttyUSB0
Device: /dev/ttyUSB0
==> Version information
Compiled Date: Nov 25 2010
Compiled Time: 10:41:31
Release Date: Jun 21 2010
Release Time: 01:00:00
Model: KPUBL
MSM version: 1
==> Features response
==> Invalid command response
Others interfaces don't response, as expected.
By the way, I just discover this test-qcdm utility. SIMCOM is currently
evaluating the possibility to provide to me some additional hardware to
investigate the AT+CLCC issue as there can't reproduce it on there side.
As far as understand, this would consist precisely in a software
connected to the diagnostic port. Did you think that test-qcdm is good
enough for the task ?
I bet that interface #4 is actually some form of CDC Ethernet for
highspeed data transfers. So that you do not have to use PPP. Might
wanna ask SIM COM about it.
Yes, would be great. I will ask them on that.
Regards,
Jean-Christian
5:23 p.m.
Hi Marcel,
I bet that interface #4 is actually some form of CDC Ethernet for
highspeed data transfers. So that you do not have to use PPP. Might
wanna ask SIM COM about it.
I got this response from them:
The interface #4 "SimTech Wireless HS-USB Ethernet Adapter 9000" needs a
special tool from Qualcomm for dialing, it's not open for us. We don't
suggest you use it.
At least this confirm that the chip is from Qualcomm.
Jean-Christian
3901
days inactive
3904
days old
10 comments
2 participants
participants (2)
-
Jean-Christian de Rivaz -
Marcel Holtmann