[PATCH v3] quectel: Power on/off with a gpio pulse

2020-10-06 Thread poeschel
From: Lars Poeschel Current implementation uses a gpio level of 1 for powering on quectel modems using a gpio and a level of 0 for powering off. Normally quectel modems are powered on or off by a gpio pulse on their PWR_KEY pin. They turn on by the first pulse and turn then off by the next pulse

Re: [PATCH v2] quectel: Power on/off with a gpio pulse

2020-10-05 Thread Lars Poeschel
On Fri, Oct 02, 2020 at 09:50:22AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 10/1/20 6:42 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > Current implementation uses a gpio level of 1 for powering on quectel > > modems using a gpio

[PATCH] quectel: Possibility to switch power by gpio level

2020-10-02 Thread poeschel
From: Lars Poeschel This does apply on top of my previous patch: [PATCH v2] quectel: Power on/off with a gpio pulse -- >8 -- Subject: [PATCH] quectel: Possibility to switch power by gpio level Normally quectel modems are powered on or off by a gpio pulse on their PWR_KEY pin. If you have s

[PATCH v2] quectel: Power on/off with a gpio pulse

2020-10-01 Thread poeschel
From: Lars Poeschel Current implementation uses a gpio level of 1 for powering on quectel modems using a gpio and a level of 0 for powering off. This is wrong. Quectel modems use pulses for either power on and power off. They turn on by the first pulse and turn then off by the next pulse

Re: [PATCH 2/2] quectel: Power on/off with a gpio pulse

2020-09-30 Thread Lars Poeschel
Hi Denis, On Tue, Sep 29, 2020 at 09:22:26AM -0500, Denis Kenzior wrote: > > @@ -237,7 +248,7 @@ static void close_ngsm(struct ofono_modem *modem) > > static void close_serial(struct ofono_modem *modem) > > { > > struct quectel_data *data = ofono_modem_get_data(modem); > > - uint32_t

Re: [PATCH 2/2] quectel: Power on/off with a gpio pulse

2020-09-25 Thread Lars Poeschel
On Fri, Sep 25, 2020 at 08:43:15AM +0200, Martin Hundebøll wrote: > Hi Lars and Janez, > > On 24/09/2020 13.02, Martin Hundebøll wrote: > > Hi Lars, > > > > On 24/09/2020 12.38, poesc...@lemonage.de wrote: > > > From: Lars Poeschel > > > > &

[PATCH 1/2] quectel: Extend power-on timeout

2020-09-24 Thread poeschel
From: Lars Poeschel More complicated modems emerge and they need longer start-up times. An EC21 takes about 13 seconds to boot up. This is slightly longer than the 20 * 500 ms we have at the moment. This extends the retries to 30, so we have 30 * 500 ms and this does successfully power up

[PATCH 2/2] quectel: Power on/off with a gpio pulse

2020-09-24 Thread poeschel
From: Lars Poeschel Current implementation uses a gpio level of 1 for powering on quectel modems using a gpio and a level of 0 for powering off. This is wrong. Quectel modems use pulses for either power on and power off. They turn on by the first pulse and turn then off by the next pulse

[RFC PATCH] xmm7xxx: Fix non compiling file

2020-09-03 Thread poeschel
From: Lars Poeschel I get a compilation error on plugins/xmm7xx.c: CC plugins/xmm7xxx.o ../plugins/xmm7xxx.c:63:10: fatal error: dbus.h: No such file or directory 63 | #include "dbus.h" | ^~~~ compilation terminated. The commit that introduced t

Re: Unable to establish ppp connection with Huawei dongle

2020-09-02 Thread Lars Poeschel
On Wed, Sep 02, 2020 at 10:46:27AM -, rakesp...@gmail.com wrote: > Hi Lars , > > I have updated ofono to 1.31 > > After that also same error message I am getting . I captured pppdump for > this . I observe that I am not getting any response from the dongle. I think from the log you gave

[PATCH v3] atmodem: Detect usage of AT+CGEREP

2020-09-01 Thread poeschel
From: Lars Poeschel Currently AT+CGEREP=2,1 is sent in case we don't know what the modem needs. (default case) Not all modems understand this. So, we first query what the modem supports with AT+CGEREP=? and then use this information to be nice to the modem. This way modems, like the Quectel M95

Re: Unable to establish ppp connection with Huawei dongle

2020-08-31 Thread Lars Poeschel
Hi, I do notice two things looking at your logs: On Thu, Aug 27, 2020 at 04:26:40AM -, rakesp...@gmail.com wrote: > Hi , > > I am trying to enable lte connection with huawei dongle , but I am getting > below error log for activat/context. > > Aug 26 11:36:28 raspberrypi3 daemon.info

[PATCH v2] atmodem: Detect usage of AT+CGEREP

2020-08-31 Thread poeschel
From: Lars Poeschel Currently AT+CGEREP=2,1 is sent in case we don't know what the modem needs. (default case) Not all modems understand this. So, we first query what the modem supports with AT+CGEREP=? and then use this information to be nice to the modem. This way modems, like the Quectel M95

Re: [PATCH 1/2] atmodem: Detect usage of AT+CGEREP

2020-08-31 Thread Lars Poeschel
On Tue, Aug 25, 2020 at 11:49:02AM -0500, Denis Kenzior wrote: > Hi Lars, > > > > So in theory this could be written like: > > > int max = -1; > > > iter_open_list(); > > > > > > while (iter_next_range(, , )) { > > > if (max2 > max) > > > max = max2; > > > } > > > > > >

[PATCH v2] atmodem: Signal quality on quectel serial modems

2020-08-21 Thread poeschel
From: Lars Poeschel As the default way of getting the signal quality with +CIND is also unstable on quectel serial modems (the same as on quectel EC21). In fact the signal quality is only updated on cell changes. Those trigger a manual AT+CSQ in ofono and get an update this way, but the URCs do

Re: [PATCH 1/2] atmodem: Detect usage of AT+CGEREP

2020-08-21 Thread Lars Poeschel
Hi Denis, On Thu, Aug 20, 2020 at 09:41:28AM -0500, Denis Kenzior wrote: > > > So why not just run iter_next_range in a loop? it actually understands > > > both > > > lists and ranges. See cind_support_cb() for an example. > > > > Ok, I can do this i a loop if you want. > > > > > > +

Re: [RFC PATCH] atmodem: Signal quality on quectel serial modems

2020-08-20 Thread Lars Poeschel
On Wed, Aug 19, 2020 at 10:19:13AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 8/19/20 7:43 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > As the default way of getting the signal quality with +CIND is also > > unstable on quectel serial mo

Re: [PATCH 1/2] atmodem: Detect usage of AT+CGEREP

2020-08-20 Thread Lars Poeschel
On Wed, Aug 19, 2020 at 10:07:58AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 8/19/20 7:13 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > Currently AT+CGEREP=2,1 is sent in case we don't know what the modem > > needs. (default case) Not a

[RFC PATCH] atmodem: Signal quality on quectel serial modems

2020-08-19 Thread poeschel
From: Lars Poeschel As the default way of getting the signal quality with +CIND is also unstable on quectel serial modems (the same as on quectel EC21). In fact the signal quality is only updated on cell changes. Those trigger a manual AT+CSQ in ofono and get an update this way, but the URCs do

[PATCH 2/2] atmodem: Deactivate AT+CPSB for quectel serial modems

2020-08-19 Thread poeschel
From: Lars Poeschel There are at the moment two quectel modems in ofono vendored as OFONO_VENDOR_QUECTEL_SERIAL: The M95 and the MC60. Both modems are GSM only modems, and their official documentation does not mention the AT+CPSB command. I have a M95 here that gives an error on issuing

[PATCH 1/2] atmodem: Detect usage of AT+CGEREP

2020-08-19 Thread poeschel
From: Lars Poeschel Currently AT+CGEREP=2,1 is sent in case we don't know what the modem needs. (default case) Not all modems understand this. So, we first query what the modem supports with AT+CGEREP=? and then use this information to be nice to the modem. This way modems, like the Quectel M95

[PATCH v4] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-17 Thread poeschel
From: Lars Poeschel The Quectel EC21 modem does not understand the AT+CPSB command, and we did not find a suitable replacement in the Quectel_EC25_AT_Commands_Manual_V1.3.pdf AT+CPSB gives an error on this modem, so we just skip it. --- drivers/atmodem/gprs.c | 2 ++ 1 file changed, 2

Re: [PATCH v3] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-17 Thread Lars Poeschel
On Thu, Aug 13, 2020 at 10:03:12AM -0500, Denis Kenzior wrote: > > @@ -624,6 +667,12 @@ static void gprs_initialized(gboolean ok, GAtResult > > *result, gpointer user_data) > > g_at_chat_send(gd->chat, "AT#PSNT=1", none_prefix, > > NULL,

[PATCH v3] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-13 Thread poeschel
From: Lars Poeschel The Quectel EC21 modem does not understand the AT+CPSB command, so aquire the current packet switched bearer from quectel proprietary QIND:"act" URC. --- drivers/atmodem/gprs.c | 49 ++ 1 file changed, 49 insertions(+)

Re: [PATCH v2 3/3] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-12 Thread Lars Poeschel
On Tue, Aug 11, 2020 at 10:55:35AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 8/11/20 6:42 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > The Quectel EC21 modem does not understand the AT+CPSB command, so > > aquire the current pack

[PATCH v2 1/3] Add a vendor OFONO_VENDOR_QUECTEL_EC2X

2020-08-11 Thread poeschel
From: Lars Poeschel The distinction between OFONO_VENDOR_QUECTEL and OFONO_VENDOR_QUECTEL_SERIAL does not suffice for EC21/EC25 in some places, so introduce and use a new vendor: OFONO_VENDOR_QUECTEL_EC2X --- drivers/atmodem/sim.c | 1 + drivers/atmodem/sms.c | 2 ++ drivers/atmodem

[PATCH v2 2/3] atmodem: Get strength and tech the quectel way on EC21

2020-08-11 Thread poeschel
From: Lars Poeschel I had some trouble getting network strengh and access technology the standard way on Quectel EC21. It does work - but only kind of. I did not get URCs when I am sure I should. This way through CIEV, CIND and CMER is also not documented in Quectel documentation, so I suspect

[PATCH v2 3/3] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-11 Thread poeschel
From: Lars Poeschel The Quectel EC21 modem does not understand the AT+CPSB command, so aquire the current packet switched bearer from CGREG URC. --- drivers/atmodem/gprs.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/atmodem

Re: [PATCH 1/5] Add a vendor OFONO_VENDOR_QUECTEL_EC2X

2020-08-11 Thread Lars Poeschel
On Fri, Aug 07, 2020 at 11:09:19AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 8/4/20 7:38 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > The distinction between OFONO_VENDOR_QUECTEL and > > OFONO_VENDOR_QUECTEL_SERIAL does not suffice for

[PATCH 3/5] atmodem: Get strength and tech the quectel way on EC21

2020-08-04 Thread poeschel
From: Lars Poeschel I had some trouble getting network strengh and access technology the standard way on Quectel EC21. It does work - but only kind of. I did not get URCs when I am sure I should. This way through CIEV, CIND and CMER is also not documented in Quectel documentation, so I suspect

[PATCH 4/5] quectel: Try to update voltage only, when received "vbatt"

2020-08-04 Thread poeschel
From: Lars Poeschel As there are some more sources of +QIND: activated, do now only update voltage when we get the +QIND: "vbatt",-1 but not on things like +QIND: "act","LTE" or +QIND: "csq",20,99 --- plugins/quectel.c | 8 +--- 1 file changed, 5 i

[PATCH 1/5] Add a vendor OFONO_VENDOR_QUECTEL_EC2X

2020-08-04 Thread poeschel
From: Lars Poeschel The distinction between OFONO_VENDOR_QUECTEL and OFONO_VENDOR_QUECTEL_SERIAL does not suffice for EC21/EC25 in some places, so introduce and use a new vendor: OFONO_VENDOR_QUECTEL_EC2X --- drivers/atmodem/lte.c | 2 +- drivers/atmodem/sim.c | 1 + drivers/atmodem

[PATCH 5/5] gprs: Quectel EC21 does not understand AT+CPSB

2020-08-04 Thread poeschel
From: Lars Poeschel The Quectel EC21 modem does not understand the AT+CPSB command, so aquire the current packet switched bearer from CGREG URC. --- drivers/atmodem/gprs.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/atmodem

[PATCH 2/5] quectel: Set URC port to uart1 on EC21

2020-08-04 Thread poeschel
From: Lars Poeschel Set the URC port of the Quectel EC21 to uart1 when it is used through it's serial port. This setting is saved to non-volatile storage by the modem automatically. --- plugins/quectel.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/plugins/quectel.c

[PATCH] Revert "quectel: EC21 needs aux channel to be the first mux channel"

2020-08-04 Thread poeschel
From: Lars Poeschel This reverts commit 1868dbf2b3e5929a7081b03a8ff76d214fd38624. Development for this was done on EC21 firmware version EC21EFAR06A01M4G_BETA0318. It now turns out, that actual release firmware versions for this modem again need the original mux order with aux channel

Re: [PATCH v3] quectel: EC21 needs aux channel to be the first mux channel

2020-07-24 Thread Lars Poeschel
On Tue, May 26, 2020 at 10:22:46PM -0500, Denis Kenzior wrote: > Hi Lars, > > On 5/29/20 7:43 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > The Quectel EC21 does only work correctly, if the mux channel used for > > aux is the first mux c

[PATCH v3] quectel: EC21 needs aux channel to be the first mux channel

2020-05-29 Thread poeschel
From: Lars Poeschel The Quectel EC21 does only work correctly, if the mux channel used for aux is the first mux channel. It does only put it's URC messages in the first mux channel, so this has to be the aux channel in our case. To be flexible on the mux order we introduce two arrays here

Re: [PATCH] Adds optional phone number parameter to ofono-phonesim

2020-05-28 Thread Lars Poeschel
Hi Bettina-Jennifer, whatever way you chose to send your patches, this is totally messed up. It would be very hard to extract usable information from this email. It looks like you wanted to send two patches, but it is just one email. Your email does include text and html parts, which is also not

Re: Quectel BG95 Support

2020-05-28 Thread Lars Poeschel
Hello! On Thu, May 14, 2020 at 02:27:22PM -, arash.javanm...@inro-et.de wrote: > Hello, > unfortunately there is no support for Quectel BG95 in ofono. But > nevertheless i tried to adapt the existing Quectel implementation for BG95. > So i added: > > udevng.c > --- 8< - >

[PATCH v2] quectel: EC21 needs aux channel to be the first mux channel

2020-05-28 Thread poeschel
From: Lars Poeschel The Quectel EC21 does only work correctly, if the mux channel used for aux is the first mux channel. It does only put it's URC messages in the first mux channel, so this has to be the aux channel in our case. To be flexible on the mux order we introduce an array here

Re: [PATCH 4/7] quectel: EC21 needs aux channel to be the first mux channel

2020-05-27 Thread Lars Poeschel
On Thu, May 21, 2020 at 08:32:07AM -0500, Denis Kenzior wrote: > Hi Lars, > > On 5/26/20 5:16 AM, poesc...@lemonage.de wrote: > > From: Lars Poeschel > > > > The Quectel EC21 does only work correctly, if the mux channel used for > > aux is the first mux c

[PATCH 5/7] quectel: EC21 does not understand AT+QIURC

2020-05-26 Thread poeschel
From: Lars Poeschel Because the Quectel EC21 does not understand the AT+QIURC command, we leave that out during initialisation. --- plugins/quectel.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/plugins/quectel.c b/plugins/quectel.c index 9ff75516..574de44e

[PATCH 6/7] voicecall: Quectel modem do not understand AT+CNAP

2020-05-26 Thread poeschel
From: Lars Poeschel --- drivers/atmodem/voicecall.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c index 7ab6567f..e7f24b60 100644 --- a/drivers/atmodem/voicecall.c +++ b/drivers/atmodem/voicecall.c @@ -1113,7

[PATCH 7/7] quectel: EC21 add ussd with atmodem driver

2020-05-26 Thread poeschel
From: Lars Poeschel --- plugins/quectel.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/plugins/quectel.c b/plugins/quectel.c index 574de44e..a8fbc75a 100644 --- a/plugins/quectel.c +++ b/plugins/quectel.c @@ -1295,8 +1295,10 @@ static void quectel_post_sim(struct

[PATCH 4/7] quectel: EC21 needs aux channel to be the first mux channel

2020-05-26 Thread poeschel
From: Lars Poeschel The Quectel EC21 does only work correctly, if the mux channel used for aux is the first mux channel. It does only put it's URC messages in the first mux channel, so this has to be the aux channel in our case. --- plugins/quectel.c | 51

[PATCH 0/7] Add quectel EC21 in serial mode

2020-05-26 Thread poeschel
From: Lars Poeschel This patchset adds support for the quectel EC21 LTE modem connected through its serial port. Lars Poeschel (7): quectel: Add Quectel EC21 to known serial modems quectel: use lte atom on EC21 quectel: Query the model before setting up the mux quectel: EC21 needs aux

[PATCH 3/7] quectel: Query the model before setting up the mux

2020-05-26 Thread poeschel
From: Lars Poeschel This is a change for the EC21. It will require specific handling before and right after setting up the mux. So this change prepares this. It queries the modem model before the mux (CMUX) is activated. --- plugins/quectel.c | 86

[PATCH 2/7] quectel: use lte atom on EC21

2020-05-26 Thread poeschel
From: Lars Poeschel --- plugins/quectel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/plugins/quectel.c b/plugins/quectel.c index 1a49a5b3..0f6896b1 100644 --- a/plugins/quectel.c +++ b/plugins/quectel.c @@ -1263,6 +1263,9 @@ static void quectel_post_sim(struct ofono_modem *modem

[PATCH 1/7] quectel: Add Quectel EC21 to known serial modems

2020-05-26 Thread poeschel
From: Lars Poeschel This adds the Quectel EC21 to the known modems of the quectel driver and therefore allows to use it with its serial interface. --- plugins/quectel.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/plugins/quectel.c b/plugins/quectel.c index

Re: [PATCH 09/10] quectel: add basic support for serial connected modems

2019-07-08 Thread Lars Poeschel
On Fri, Jul 05, 2019 at 05:57:05PM -0500, Denis Kenzior wrote: > Hi Martin, > > On 07/03/2019 01:09 PM, Martin Hundebøll wrote: > > Setup GSM 07.10 multiplexing using the kernel n_gsm line discpline > > driver, and use the virtual tty devices as Aux and Modem channels. > > > > The driver

Re: [BUG] plugins: sim900 support broken for tty port users

2018-06-22 Thread poeschel
On 06/19/2018 03:19 AM, poesc...@lemonage.de wrote: Hi! I think I found a bug. Commit 1d63b1d35 essentially breaks the sim900 driver for serial port users. Right. This looks like some wires being crossed. sim900 driver is only meant for serial port usage. So listing it for 'option' isn't

[BUG] plugins: sim900 support broken for tty port users

2018-06-19 Thread poeschel
Hi! I think I found a bug. Commit 1d63b1d35 essentially breaks the sim900 driver for serial port users. It adds a new entry in plugins/udevng.c driver_list with name "sim900". There are two entries with the same name then: The new one which calls the new setup_sim900 function and the old one