Latest firmware for PinePhone modem!

[calinb]

In reading the release notes on Github (Rev. EG25-G-GB_Firmware_Release_Notes_V0708_01.003.01.003), it seems like it has enough "Solved the problem..." entries (bug fixes) to make flashing it a worthwhile wager. I'm not so much worried about the actual flashing of the device as I am worried about maintaining all the modem settings or resetting them all correctly afterwards.

I did some mmcli tests and it looks like I can use mmcli to sent AT commands to archive current setting values and restore them afterwards, if necessary.

I do have some questions though.

1. Why all the howto elsewhere about shorting the test points or using ADB? From this thread, it seems that many Pinephone users have successfully updated modem firmware without using the test points or ADB.

2. Why is 01.002.01.002 the "default" branch on Github when 01.003.01.003 is available?

3. I'm running Mobian stable. Does it have Megi's kernel / driver code?

Any suggestions, warnings or final advice would be most appreciated!

-Cal

[bcnaz]

All the modems in my 5 separate Pine phones work great for Talk, sms text, cellular data.
I only occasionally need to delete the mms that plug up the modem cache

I will consider flashing them when/or if that includes getting the mms text to work.

[calinb]

All the modems in my 5 separate Pine phones work great for Talk, sms text, cellular data.
  I only occasionally need to delete the mms that plug up the modem cache

I will consider flashing them when/or if that includes getting the mms text to work.

I don't care much about MMS but I do care about excessive modem power consumption and heat and unreliable performance waking from sleep--particularly what appears to be deep sleep. As others have reported, the modem occasionally crashes and becomes undetectable and inaccessible via mmcli or "sudo systemctl enable ModemManager.service" for unknown reasons, requiring a Pinephone reset.

Finally, my phone reports off--network or otherwise strong but unusable 4G signals, which give the false impression that the phone is usable when it is not. I don't know if my old and original .001 modem firmware might be responsible for the false signal annunciations and values but some release note entries indicate that work has been done on power management and sleep mode compatibility.

So yeah, I'm motivated to try new firmware ASAP and, hopefully, get a daily driver out of it!

[mouffa]

you can set the modem to lower power modes with the at+cfun command

there is great instability in the communication between the modem and the GUI, a totally new approach is needed there and much code must be revised

the modem always works in the background, only the mobile data are stable if you don't totally lose the communication with the modem which happens when the USB bus restarts because the modem can draw much power momentarily and the voltage drop triggers a power surge in the bus

[calinb]

you can set the modem to lower power modes with the at+cfun command

there is great instability in the communication between the modem and the GUI, a totally new approach is needed there and much code must be revised

the modem always works in the background, only the mobile data are stable if you don't totally lose the communication with the modem which happens when the USB bus restarts because the modem can draw much power momentarily and the voltage drop triggers a power surge in the bus

That explains a lot. Thanks, mouffa. Like mobile data, VoLTE has been more reliable for me than 2G and 3G services.

[bcnaz]

NOTE :  August 11, 2021  >

After reading these recent posts, 

> I picked up my PMOS Convergence edition phone  (running a recent Mobian nightly from sd card)  Sitting next to me,  It has been "idle" for the

last 5+ hours,  and not connected to the charger.

  I gave it a call from another phone, I hear 2 ringtones on my calling phone  >  then the Pine phone starts ringing, 

   ... after the Pine phone rang once,  the screen to answer the call without a locked screen pops up and I am able answer the call

         and to talk and be heard on both phones Clearly.

  I am using only "Out of the Box" operating systems,  and Absolutely NO hardware/firmware modifications or "flashing".

* While we DO NEED people to go into the software and Bravely try to improve the Pine phone, 

   > Please remember to mention any "previous changes"  you have made to your software or firmware BEFORE it quits working.
     and which release, of what operating system are you running.

As I have said previously,   I am only a basic GUI user.

 ***  IF   I am using the same operating system as you are, > and my phone works,  and your phone does not ?

    WHY   ?

For me the simplest answer is usually the best answer.

[zetabeta]

i basically relay comments from matrix channel from some developers.

01.002.01.002 is the most recommended firmware. https://github.com/Biktorgj/quectel_eg25_recovery

01.003.01.003 is the most recent but buggy. https://github.com/Biktorgj/quectel_eg25...003.01.003

even with the 002 firmware, it's more or less buggy. so, none of the firmwares are totally stable.

edit:
i forgot this one, only for informative purposes. it may not apply to the pinephone directly!
https://git.teknik.io/gn0m3dio/EG25-G_GB...nch/master

[calinb]

<snip>

 ***  IF   I am using the same operating system as you are, > and my phone works,  and your phone does not ?

    WHY   ?

For me the simplest answer is usually the best answer.

Well...even my own phone's behavior is inconsistent with itself! That's the definition of "instability" in a system. The system include factors such as geographic position, the network/SIM card in use and the communications modulation and network in use (tower frequencies/spread spectrums 2G, 3G, 4G, etc.).

Even while using the same operating system, our software, including the configuration settings and history files that determine its behavior, is assuredly not exactly the same. Software installations and other histories often play a role in behavioral outcomes (including bugs). I assure you that, no matter how good the hardware design, there are hardware timing violations or signal integrity issues present too. Sometimes they result result in software behavioral differences.

---

i basically relay comments from matrix channel from some developers.

01.002.01.002 is the most recommended firmware. https://github.com/Biktorgj/quectel_eg25_recovery

01.003.01.003 is the most recent but buggy. https://github.com/Biktorgj/quectel_eg25...003.01.003

even with the 002 firmware, it's more or less buggy. so, none of the firmwares are totally stable.

edit:
i forgot this one, only for informative purposes. it may not apply to the pinephone directly!
https://git.teknik.io/gn0m3dio/EG25-G_GB...nch/master

Thanks, zetabeta!

I suspected that Biktorgj/quectel_eg25_recovery 01.003.01.003 might be considered to be a "testing" repository, but I guess there's no "stable" branch when it come to EG25G firmware!

It sounds like they will all flash and flashing should all be reversible so I guess I'll try both 01.003.01.003 and 01.002.01.002 and see if either works better for me than 01.001.01.001.

[calinb]

I flashed 01.003.01.003. After completion and the programmed modem reset I restarted the phone and made one outgoing test call and one inbound test call successfully. Then I let the phone go to sleep and tried another inbound call. The phone never rang or came out of sleep. When I pushed the power button to wake up the phone, the modem had crashed (no mobile annunciation on the top status strip and no modem in the Setting ap, etc.

As usually a phone reset brought the modem back to life and I restored the following settings that had changed after flashing the new firmware to match their values before I had flashed 01.003.01.003.

< lines are original settings
> lines are post flash settings, which I wrote over to match original settings.

Code:

< response: '+QCFG: "wakeupin/level",0'
---
> response: '+QCFG: "wakeupin/level",0,0'
11c11
< response: '+QCFG: "ModemRstLevel",0'
---
> response: '+QCFG: "ModemRstLevel",1'
13c13
< response: '+QCFG: "airplanecontrol",1,0'
---
> response: '+QCFG: "airplanecontrol",0,0'

Next I tried another inbound call to my sleeping pinephone. It rang on the third outbound phone ring tone and the call was completed successfully.

However, I've now had a second crash of the modem while testing to see if the GPS would function (it usually doesn't function), resulting in a loss of the modem from the system again and another phone reset was required to restore modem functionality. This is a problem that has always plagued my phone, but these two failures were within only about 20 minutes of use, which is an exceptionally poor failure rate. It usually only happens every few days or even only after a week or two.

I'll use 01.003.01.003. for a while and then I'll try 01.002.01.002.

Finally, though certainly convenient, the lack of enforcement of the requirement to use the test points or ADB is strange. Perhaps it's some kind of security feature bug?

[dukla2000]

...
I'll use 01.003.01.003. for a while and then I'll try 01.002.01.002.
...

I have had 01.003.01.003 in my modem for many months (since about when there was a link here to @biktorgj repository). It broadly worked fine with Mobian, in the last months arch was unusable as the modem would vanish within an hour or 2. (Note I have a dual-boot setup so the 2 OS are using precisely the same modem.)

A few days ago I added my experience to the issue on the Pine64-arch git and was "nudged" that the modem-vanishing "trick" was more of a problem with 01.003.01.003. So I flashed 01.002.01.002 about 36 hours ago and since then have been running arch without a hiccup.

I just had a quick check through my journal and it seems the eg25manager code to regularly try recover the modem works as intended with 01.002.01.002 and (my suspicion) does not work with arch & 01.003.01.003?

YMMV