Cinterion plugin (in)compatibilities

[Colin Helliwell]

> On 13 February 2017 at 13:56 Colin Helliwell <colin.helliwell at ln-systems.com> wrote:
> 
> > On 10 February 2017 at 17:52 Aleksander Morgado <aleksander at aleksander.es> wrote:
> > 
> > On Fri, Feb 10, 2017 at 3:40 PM, <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...!
> 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):
> 

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

I'm not confident of correctly interpreting the regex in smong_query_ready() (let alone fixing it properly!), but I wonder if the SMONG problem is that it's getting an additional CRLF. The response to the command is

<CR><LF>GPRS Monitor<CR><LF><CR><LF>BCCH  G  PBCCH  PAT MCC  MNC  NOM  TA      RAC                              # Cell #<CR><LF>