Some experiments with the SIMCOM SIM5216E modem on a ARM926 board

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

Hi Jean-Christian,

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.

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.

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.

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.

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

Hi Marcel,

Thanks for your valuable response. Here is an update of the situation.

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.

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
@@ -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 ?

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 <[email protected]>
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(-)

index 4115e34..b07544e 100644
@@ -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

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

Hi Jean-Christian,

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.

Let me ask this differently. What are the GSM/UMTS features that you actually need for your product?

Send the section for your device from /sys/kernel/debug/usb/devices. I can have a look then.

We need something proper. I help you with that. Just need the devices endpoint descriptors.

This is kinda stupid, but okay.

Hi Marcel,

Ok, I didn't known that. Maybe the SIMCOM5216 need the same "bit-rotting" as the g1. We will see.

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.

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=commitdiff;h=ec0cd94d881ca89cc9fb61d00d0f4b2b52e605b3;hp=46b1848360c8e634e0b063932a1261062fa0f7d6

It simply provides 5 serial ports 'ttyUSB#'. I was using the ttyUSB3 for my experiments.

Done.

Jean-Christian

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

Hi Jean-Christian,

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

Hi Marcel,

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

Hi Jean-Christian,

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.

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

Hi Marcel,

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 ?

Yes, would be great. I will ask them on that.

Regards,

Jean-Christian

Hi Marcel,

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