Cinterion plugin (in)compatibilities

[Aleksander Morgado]

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 :)

-- 
Aleksander
https://aleksander.es