Latest firmware for PinePhone modem!
#51
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
  Reply
#52
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.
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
  Reply
#53
(08-09-2021, 02:19 PM)bcnaz Wrote: 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!
  Reply
#54
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
  Reply
#55
(08-09-2021, 09:54 PM)mouffa Wrote: 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.
  Reply
#56
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.
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
  Reply
#57
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
  Reply
#58
(08-11-2021, 06:58 AM)bcnaz Wrote: <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.

(08-11-2021, 07:14 AM)zetabeta Wrote: 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! Cry

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.
  Reply
#59
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?
  Reply
#60
(08-11-2021, 10:34 PM)calinb Wrote: ...
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
  • ROCKPro64 v2.1 2GB, 16Gb eMMC for rootfs, SX8200Pro 512GB NVMe for /home, HDMI video & sound, Bluetooth keyboard & mouse. Arch (6.2 kernel, Openbox desktop) for general purpose daily PC.
  • PinePhone Pro Explorer Edition, daily driver, rk2aw & U-boot on SPI, Arch/SXMO & Arch/phosh on eMMC
  • PinePhone BraveHeart now v1.2b 3/32Gb, Tow-boot with Arch/SXMO on eMMC
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Why does Pine64 sabotage office on the Pinephone? Peter Gamma 5 442 07-04-2024, 07:34 AM
Last Post: Kevin Kofler
  Which word processor to choose for the Pinephone? Peter Gamma 16 3,540 06-22-2024, 07:28 AM
Last Post: Peter Gamma
  Samba share on the Pinephone? Peter Gamma 0 446 06-16-2024, 10:26 PM
Last Post: Peter Gamma
  Struggle to install LibreOffice on the PinePhone Peter Gamma 49 29,675 06-13-2024, 05:50 PM
Last Post: Peter Gamma
  Possible Free Backup Carrier for PinePhone PineFone 0 144 06-13-2024, 03:45 PM
Last Post: PineFone
  Using Signal on PinePhone in mid-2023? dante404 47 17,775 05-03-2024, 02:19 AM
Last Post: dragonhospital
  Slarm64 on PinePhone [Unofficial Slackware ARM - 64 bit] acid andy 38 28,075 04-23-2024, 10:29 AM
Last Post: donchurch
  PinePhone app development WhiteHexagon 15 5,396 04-23-2024, 05:19 AM
Last Post: Jonnyc
Wink PINEPHONE not booting Touchwood 2 825 02-23-2024, 07:27 AM
Last Post: Touchwood
  Slack on PinePhone Adam Seline 5 5,903 12-20-2023, 07:20 AM
Last Post: nickolas

Forum Jump:


Users browsing this thread: 1 Guest(s)