> On 13 February 2017 at 14:14 Aleksander Morgado <[email protected]> > wrote: > > On Mon, Feb 13, 2017 at 2:56 PM, Colin Helliwell > > <[email protected]> wrote: > > > > > For simplicity, I’d begun my exploration of MM using the Generic > > > > plugin. My > > > > design has a choice of two Cinterion modems (BGS2 and EHS5), though they > > > > don’t have much of the functionality supported by the Cinterion plugin > > > > such > > > > as GPS. > > > > > > > > But because of one command incompatibility (CMER) with the Generic, I > > > > decided to try the Cinterion plugin. This addresses the CMER issue, but > > > > throws up more incompatibilities due to differing versions of Cinterion > > > > commands sets. > > > > > > > > If Generic turns out to be the closest fit then I could just patch it as > > > > needed. But I also wondered if there’s a key Maintainer of the Cinterion > > > > plugin who might like to discuss what I’ve found with a view to > > > > incorporating the variations somehow? Or I could patch the plugin. Or I > > > > could generate *another* Cinterion plugin…. > > > > > > Depending on the incompatibilities, the changes should go to the > > > Cinterion plugin (if Cinterion specific) or to the Generic plugin (if > > > generic things we didn't support yet). If it is a generic AT command, > > > to know if it is one or the other, you can lookup the relevant doc in > > > the 3GPP reference (ETSI 27.007). If the incompatibility is something > > > in that reference that we don't support yet, it should go to the > > > Generic plugin, > > > > It's probably a bit difficult/subjective to decide that - some items are > > 'generic' commands, but seemingly supported in a > > Cinterion-and-modem-specific way...! > > If the command is 'generic' but has a format or fields specific to > Cinterion, then it's Cinterion specific and should go in the plugin. > If the format or fields are specific to a single device... well, we > should either handle that specific case in the existing plugin or in > the worst case write a new plugin for that specific single device... > although I'd advise against that. > > > Here's some of what I've found so far - either from actual debug logs on > > their BGS2, or from reading the Command Set docs for their EHS5 (I'm > > currently awaiting hardware to test for real): > > > > BGS2 requires 'AT+CMER=3,0,0,2' instead of 'AT+CMER=3,0,0,1'. (As > > mentioned, the Cinterion plugin does cater for this param change). But the > > EHS5 appears to not support CMER at all. > > BGS2 errors on 'AT+CNMI=2,1,2,1,0' - the bfr=0 isn't supported, and ds=1 is > > only accepted when "phase2+" is enabled (by an 'AT+CSMS=1'). For the latter > > I see similar restrictions mention in the TODO, for Huawei K4505 and ZTE > > MF637. > > If there is no easy logic to make it work by 'detecting' which command > to use, then we should try several in a row until one works. > > > 'AT^SIND="simstatus",1' isn't supported by either - 'simstatus' is > > unrecognised. > > We could test for the command support (e.g. AT^SIND=?) before using it > in the plugin itself and cover both cases there. > > > 'AT^SCFG=?' - BGS2 doesn't supply "Band/Radio/.." in its response (even > > though it is a dual 900/1800 device) > > MM isn't able to parse the BGS2 response to 'AT^SMONG' - I haven't > > investigated this further. EHS5 doesn't seem to support the command at all. > > This is something to try to fix. Can you provide the result of > AT^SCFG=? in your case? > > > There's a few others, but I suspect they may be things that don't matter to > > subsequent functionality (e.g. 'AT^SQPORT?') > > You'd maybe be thinking "Well, the Cinterion plugin is kind of aimed at > > some particular devices of theirs, not just *any* of their devices"... and > > I admit I'd be hard-pushed to convincingly argue against such a stance....! > > (But I still don't really wanna be writing a whole new plugin from scratch > > :S) > > The Cinterion plugin was originally developed for RS232-only (i.e. not > even USB) devices, and was extended from there :) Not easy, but we > should be able to support newer models just by extending the support > we already have. Let's try to handle each thing one by one :) >
Sounds good to me - happy to feedback and test out. I am though currently using the 1.6.4 tag, so patching across from head/master is a bit painful. Though given that there's some tweaks I'm feeding back on, maybe I should switch to master for the moment anyway, and lock to a tag at a later date. _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
