Cinterion plugin (in)compatibilities

[Colin Helliwell]

> On 13 February 2017 at 14:14 Aleksander Morgado <aleksander at aleksander.es> wrote:
> 
> On Mon, Feb 13, 2017 at 2:56 PM, Colin Helliwell
> 
> <colin.helliwell at ln-systems.com> 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.