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 , 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 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 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