Hi Stanislav,
On Fri, May 18, 2018 at 10:07:47PM +0200, Stanislav Sinyagin wrote:
> Simcom seems to be quite consistent in their support for this feature:
> it's available in 3 latest models, the 7100, 7500, and 7600 series,
> and they share the same AT command set for this.
Thanks a lot for poin
Hi Bob,
On Wed, May 16, 2018 at 04:10:55PM +0100, Bob Ham wrote:
> On 12/05/18 08:37, Harald Welte wrote:
>
> > As there are no modems that reliably can deliver the actual audio data via
> > USB
> > (aside some non-supported outdated experimental firmwares), we're only
> > testing
> > the signa
Hi Stanislav,
On Wed, May 16, 2018 at 05:15:07PM +0200, Stanislav Sinyagin wrote:
> also most mPCIE modems deliver PCI voice over dedicated wires on their
> mPCIE socket. These wires are standardized as "reserved" and most
> standard boards with mPCIE don't connect them anywhere.
This is the "PCM
On 12/05/18 08:37, Harald Welte wrote:
As there are no modems that reliably can deliver the actual audio data via USB
(aside some non-supported outdated experimental firmwares), we're only testing
the signaling plane so far.
Hi Harald,
I'm alarmed to see this statement. Can I ask what you me
Hi Alexander, Joey,
On 05/12/2018 09:19 AM, Alexander Couzens wrote:
Hi Joey,
nice to hear, somebody else is using it.
The voicecall driver needs to be refactored as Denis already pointed
out on the mailinglist before it can go upstream.
If it wasn't clear from my earlier mail, I would like
Hi!
> > Is this actually an AT command modem or one of those modems where AT
> > commands were only bolted on for carrier certification? Does it
> > support QMI
> > or something maybe?
> Ok, so ... this is complex. And maybe this is one of "those" modems.
> There's USB
On Fri 2018-05-11 05:39:26, Tony Lindgren wrote:
> * Pavel Machek [180511 12:36]:
> > Is there way to power cycle the modem without reboot? That should make
> > the debugging... less bad.
>
> Yeah you can currently do:
>
> # rmmod ohci-platform
> # rmmod phy-mapphone-mdm6600
> # modprobe phy-map
Hi!
> nice to hear, somebody else is using it.
>
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.
>
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look like
Hi Joey,
> nice to hear, somebody else is using it.
>
> The voicecall driver needs to be refactored as Denis already pointed
> out on the mailinglist before it can go upstream.
>
> The original idea of the voice_generated.c/h files was to create a
> prototype how qmi generated files should look
Hi Joey,
nice to hear, somebody else is using it.
The voicecall driver needs to be refactored as Denis already pointed
out on the mailinglist before it can go upstream.
The original idea of the voice_generated.c/h files was to create a
prototype how qmi generated files should look like and then
Hi!
> > It looks like the QMI voicecall driver is just a stub with no operations
> actually implemented.
>
> I hope I'm not stealing their thunder, but Alexander Couzens at sysmocom
> seems to be working on implementing it [0]. Last fall, I had
> incoming/outgoing calls in oFono working on my MSM
Hi Denis, Pavel, Marcel,
On Fri, May 11, 2018 at 08:02:01PM -0500, Denis Kenzior wrote:
> This reminds me... Weren't you the one who mentioned that you got voicecalls
> working on QMI devices? Does that include the circuit switched control
> operations (e.g. dial, etc) as well? Any chance that c
Hi Denis and Pavel,
> It looks like the QMI voicecall driver is just a stub with no
operations actually implemented.
I hope I'm not stealing their thunder, but Alexander Couzens at sysmocom
seems to be working on implementing it [0]. Last fall, I had
incoming/outgoing calls in oFono working
Hi Harald,
ofono supports voice calls over qmi, right? Is it possible that
mdm6600 does not support them?
This reminds me... Weren't you the one who mentioned that you got
voicecalls working on QMI devices? Does that include the circuit
switched control operations (e.g. dial, etc) as well?
Hi Pavel,
ofono supports voice calls over qmi, right? Is it possible that
mdm6600 does not support them?
It looks like the QMI voicecall driver is just a stub with no operations
actually implemented.
Regards,
-Denis
___
ofono mailing list
ofono@of
Hi!
> > More explanation needed it seems:
> >
> > I can already do USB with AT commands, no multiplexer needed. We'd
> > actually prefer to go over serial (with multiplexer), because USB
> > needs to be powered down in idle, and you still need communication
> > ovre serial to know that wakeup of
Hi!
> > > And that's probably the incoming SMS size. But I don't see
> > > anything for what actually reads the incoming SMS.
>
> Hmm it occured to me that maybe the incoming messages are read
> using QMI over USB.
>
> > That seems to be standard message
> > ftp://www.3gpp.org/tsg_t/TSG_T/TSGT_0
Hi Pavel,
If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that, either, but with +CMS ERROR: 500.
>>>
>>> CNMA=1 is required to work in PDU mode according to 27.005 btw. How
>>> about:
>>>
>>> window.open();
>>> window.t
Hi!
> >> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> >> not like that, either, but with +CMS ERROR: 500.
> >
> > CNMA=1 is required to work in PDU mode according to 27.005 btw. How
> > about:
> >
> > window.open();
> > window.throw(m
Hi Pavel,
>> If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
>> not like that, either, but with +CMS ERROR: 500.
>
> CNMA=1 is required to work in PDU mode according to 27.005 btw. How
> about:
>
> window.open();
> window.throw(modem);
>>>
Hi Pavel,
On 05/09/2018 01:57 PM, Pavel Machek wrote:
Hi!
If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that, either, but with +CMS ERROR: 500.
CNMA=1 is required to work in PDU mode according to 27.005 btw. How about:
window.open();
window.throw(modem);
Hi!
> >>>If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
> >>>not like that, either, but with +CMS ERROR: 500.
> >>
> >>CNMA=1 is required to work in PDU mode according to 27.005 btw. How about:
> >>
> >>window.open();
> >>window.throw(modem);
> >
> >Heh :-). Well, there ar
Hi Pavel,
If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that, either, but with +CMS ERROR: 500.
CNMA=1 is required to work in PDU mode according to 27.005 btw. How about:
window.open();
window.throw(modem);
Heh :-). Well, there are two phones with reasonab
Hi!
> >PDU Len 2, strlen 4
> >PDU last char 48
> >^ZCNMA=1,2
> > >^ZCNMA=1,2
> >< +CMS ERROR: 304
> >ofonod[3057]: CNMA acknowledgement failed: Further SMS reception is
> >not guaranteed
> >< +CIEV: 1,4
> >
> >Modem does not like our CNMA acknowledgement. AFAICT, we are sending
> >
> >AT+C
Hi!
> > > > > AT+CNMI=1,2,2,1,0
> > > > < OK
> >
> > > Well you can try to see what Android is doing for SMS with:
> > >
> > > # echo 0x7fff > /sys/module/ts27010mux/parameters/debug_level
> > > # dmesg | grep ts27010 | grep AT
> > >
> > > To send SMS, looks like Android RIL first does:
> >
Hi Pavel,
PDU Len 2, strlen 4
PDU last char 48
^ZCNMA=1,2
That looks correct. In fact that logic has been working for something
like 8-9 years, but it doesn't hurt to be paranoid and double check.
If I attempt to do AT+CNMA=1, AT+CNMA=0 or just plain At=CNMA, it does
not like that,
Hi!
> > > AT+CNMI=1,2,2,1,0
> > < OK
> Well you can try to see what Android is doing for SMS with:
>
> # echo 0x7fff > /sys/module/ts27010mux/parameters/debug_level
> # dmesg | grep ts27010 | grep AT
>
> To send SMS, looks like Android RIL first does:
>
> 2 AT+CMGS=327 where 327 seems to b
Hi!
> >> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> >>> AT+CNMI=?
> >> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> >> < OK
> >> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
> >> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> >>> AT+CNMI=1,2,2
On Tue 2018-05-08 17:08:25, Denis Kenzior wrote:
> Hi Pavel,
>
> On 05/08/2018 04:51 PM, Pavel Machek wrote:
> >Hi!
> >
> >I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> >
> >>AT+CNMI=?
> >< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> >< OK
> >ofonod[3070]: drivers/atmo
Hi Pavel,
>> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
>>> AT+CNMI=?
>> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
>> < OK
>> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
>> ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
>>> AT+CNMI=1,2,2,1,0
>>
Hi Pavel,
On 05/08/2018 04:51 PM, Pavel Machek wrote:
Hi!
I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_
Hi!
I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
ofonod[3070]: src/netw
32 matches
Mail list logo
