On Sat, 2017-04-15 at 11:27 +0000, Karoly Pados wrote: > Hi! > > Sorry for the late reply, we have a 4-day holiday here and I spend > less time at the computer. > > > > But it does appear to support the LOC service (location) which is > > > a > > > newer service that ModemManager (and libqmi) doesn't yet support. > > > So I > > > think that's the current problem. > > > > Ouch :/ Patches welcome!! :) > > I can look into it, given there is some description or specification > of the loc service protocol I can use. Do you have any pointers? > Unfortunately I don't think I can allow myself the time to do full > reverse engineering of the modem communication, so some doc about the > QMI messages for the loc service would be nice (I'm not even familiar > with QMI itself).
It's pretty well described in the GobiAPI headers in libqmi git. I started describing the boilerplate, but that took too long so I just went ahead and did it: https://cgit.freedesktop.org/libqmi/commit/?id=4da476f676678d83a5c73b94c4337c9a437fb6a1 Three parts are left for filling in the messages and TLVs; what I've done is incomplete: 1) Messages: look in GobiConnectionMgmtAPIEnums.h for the message numbers, eg: eQMI_LOC_START, // 034 Start GPS session which you can then translate into the first part of the JSON for a new message in qmi-service-loc.json: { "name" : "Start", "type" : "Message", "service" : "LOC", "id" : "0x0022", "version" : "1.0", "since" : "1.19", "version" is the QMI service version that this command first appeared in, and I'd guess Start appeared in v1.0 of QMI_SVC_LOC. "since" is the libqmi version that this message was first defined in, so we'll use "1.19" since libqmi is 1.18 and this would be in the next release (1.19). 2) TLVs: these are found in GobiConnectionMgmtAPIStructs.h with a bit of searching. Look for "LOCStart" and you'll find the applicable TLVs for eQMI_LOC_START. For example: // Structure to describe request TLV 0x01 for LOCStart() struct sLOCStartRequest_SessionID { UINT8 mSessionID; }; That means TLV ID 0x01 for the Start message of the LOC service, and it has a single member: a uint8 session id. That becomes this JSON: { "name" : "Session ID", "id" : "0x01", "mandatory" : "no", "type" : "TLV", "since" : "1.19", "format" : "guint8" }, Repeat for each of the TLVs you want to add; if it's unclear how to add the JSON for one (and it will be, like for sLOCStartRequest_ApplicationID) feel free to ask! 3) Enums: when you come across a TLV that includes an enum, like: // Structure to describe request TLV 0x12 for LOCStart() struct sLOCStartRequest_EnableIntermediateReports { eQMILOCIntermediateReportState mEnableIntermediateReports; }; we usually create a mirror libqmi enum. So you go look up eQMILOCIntermediateReportState GobiConnectionMgmtAPIEnums.h and find: // Enum to describe QMI LOC Intermediate Report State enum eQMILOCIntermediateReportState:UINT32 { eQMILOCIntermediateReportState_Enable = 1, eQMILOCIntermediateReportState_Disable = 2, }; note the UINT32 there; we'll remember that for later in the JSON. This enum becomes the libqmi-glib enum in src/libmm-glib/qmi-enums-loc.h: /** * QmiLocIntermediateReportState: * @QMI_LOC_INTERMEDIATE_REPORT_STATE_UNKNOWN: Unknown. * @QMI_LOC_INTERMEDIATE_REPORT_STATE_ENABLE: Enable intermediate state reporting. * @QMI_LOC_INTERMEDIATE_REPORT_STATE_DISABLE: Disable intermediate state reporting. * * Whether to enable or disable intermediate state reporting. * * Since: 1.19 */ typedef enum { QMI_LOC_INTERMEDIATE_REPORT_STATE_UNKNOWN = 0, QMI_LOC_INTERMEDIATE_REPORT_STATE_ENABLE = 1, QMI_LOC_INTERMEDIATE_REPORT_STATE_DISABLE = 2, } QmiLocIntermediateReportState; and then back in the JSON... the TLV above becomes: { "name" : "Intermediate Report State", "id" : "0x12", "mandatory" : "no", "type" : "TLV", "since" : "1.0", "format" : "guint32", "public-format" : "QmiLocIntermediateReportState" } ] }, "format" is the QMI API size of the variable that libqmi uses when converting the enum to the QMI protocol, while "public-format" is the fancy enum that we've defined that will be used in the libqmi API. Let us know if you have more questions... Thanks! Dan > LG, > Károly Pados > > tec4data > finding of facts! > thoerl 35; 8621 thoerl; austria > mob +43 680 5577 310 > uid atu44131505 > mail [email protected] > http://www.tec4data.at > > This email and any associated attachment are confidential. > Unless you belong to the specified recipients, immediately notify the > sender. > The content may not be copied and given to third parties. > ___________________________________________________________________ > > April 15, 2017 12:11 AM, "Aleksander Morgado" <aleksander@aleksander. > es> wrote: > > > On Thu, Apr 13, 2017 at 8:30 PM, Dan Williams <[email protected]> > > wrote: > > > > > > > also, if you have ModemManager debug logs, that would be > > > > > great to > > > > > see > > > > > too so we can make sure things are being set up correctly. > > > > > > > > Attached. Also output of mmcli -m 0 in separate file. > > > > > > Thanks. This shows your device is in fact in QMI mode, and that > > > the > > > firmware doesn't implement the "PDS" (Position Determination > > > Service) > > > that is normally used for this. > > > > > > But it does appear to support the LOC service (location) which is > > > a > > > newer service that ModemManager (and libqmi) doesn't yet support. > > > So I > > > think that's the current problem. > > > > Ouch :/ Patches welcome!! :) > > > > -- > > Aleksander > > https://aleksander.es > > _______________________________________________ > > ModemManager-devel mailing list > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > > _______________________________________________ > ModemManager-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
