Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by claude0001

  1. I had been suspecting this was the case for some time now. Thanks for clarifying. This means that off-mode-charging cannot actually protect us from the battery depletion bug. If the battery is flat, it's game over, irrespective of the off-mode-charge setting. Thanks, it is clear to me that LineageOS cannot fix those bits. Does anyone know whether F(x)tec actually have the sources? I.e. can they fix these things in house or do they rely on some external software company for maintaining the stock OS and its drivers?
  2. That variable has nothing to do with individual signal levels. It works in conjunction with the INTERMEDIATE_POS=1 setting, and causes also the very early iterations of position estimates to be reported to client apps as a "fix". The unit of ACCURACY_THRESH is meters. Setting it to 3000 means that early position estimates are reported, even if they are still uncertain by 3 km. However, to my knowledge, the variable does not actually influence how the iteration towards the final solution for the position progresses. To me, the fact that @Name_not_avail saw their phone getting the fix
  3. So ... I recharged my Pro1-X battery using a laboratory power supply after it had depleted completely, probably due to the "battery protection bug" mentioned by f(x)tec in their updates. It turned out that the most difficult part in this is getting to the battery. The Pro1-X is not nearly as "serviceable" as I expected. Separating the different parts of the body is not as easy as the instructional videos suggest. Also, the battery itself is glued into the phone, which makes its removal a scaring endeavour. Note that removing the battery from the phone is not strictly necessary for re-char
  4. So ... in case you want to relive the good old days with the Pro1 (SD835 only!), LineageOS 16.0 just got another update. At https://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1 fetch the ROM dated 202304024. It gives you backported ASB patches up to 5 April 2023. There are no other changes compared to last month's release. Refer to my tarball of localmods for the full list of code changes with respect to upstream LineageOS 16.0. Have a lot of fun.
  5. OK, fixed it. Prawn-X is back alive! 🥳 Turned out the battery was completely flat. After disassembling, I measured 0.00 V between the pins! I do not know how that happened, maybe I did accidentally leave the device on when putting it away. Still, I'm pretty sure the battery should never discharge to 0 V in any design scenario, as the device should automatically switch itself off before. I guess this is related to the "battery protection bug" f(x)tec keep mentioning in their updates ... Anyway, I was able to charge the battery to ~50% (3.9 V) using a laboratory power supply. After tha
  6. I fixed similar problems (in Germany) years ago by having the following changes in /system/vendor/etc/gps.conf: [...] XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin [...] XTRA_VERSION_CHECK=1 [...] NTP_SERVER=europe.pool.ntp.org [...] INTERMEDIATE_POS=1 [..] SUPL_HOST=supl.vodafone.com SUPL_PORT=7275 [...] since then, GPS has been working quite OK for me (I have no Gapps on my Pro1). Changing that file in LOS 20 probably involves Magisk scripting, which I unfortunately have no
  7. I confirm that installing Lineage on Pro1-X breaks offline-charging-mode. I had that enabled and working successfully on 2.1.5-GMSless, but never checked after installing LineageOS. I am not on one of the official builds, but on one of the betas from few weeks ago. After reading this, I tried to charge my Pro1-X (shelved for several months) and it seems to be bricked. Upon connecting the charger it briefly blinks red, but then nothing. Previously (with 2.1.5.-GMSless) it would charge (while displaying the "battery screen"). Well ... what to complain about with such a broken device ..
  8. No offence, but, in your report, you are doing precisely that: whitewash a faulty device. Your LTE-router workaround is technically interesting, but it doesn't mitigate the Pro1-X's failure as a mobile phone.
  9. I agree that the Pro1-X's keyboard is better than the Pro1's. But, yes, for me the whole point with the Pro1/Pro1-X is to carry around only the one device I need anyway - my phone. A single device that works as a normal Android slab most of the time but can transform into an UMPC if I urgently need to get some stuff done while away from a real workstation. If I were to settle for carrying two pocket-sized devices all the time, I'd probably choose something else than a Pro1/X as the "computer". I think there are far more capable miniature laptops. But, honestly, I think this discussio
  10. Forget it. People from all over the world have been reporting those network problems for 8 months now. At one point @Casey even acknowledged that this is one of the most reported issues. Still, they haven't come up with even a glimpse of a solution. I think the two most likely explanations are: 1) Something is systematically wrong with the qx1050's RF hardware, causing it to fail in many regions/networks. 2) There are a lot of defective devices around, as @Rob. S. suggests. Either way, f(x)tec will not have the (financial) means to fix all those devices. All they can do is keep affected c
  11. The unofficial builds of LOS have been available for some time. While it is great that they are now to become official, for me, they unfortunately never made any difference with regard to mobile connectivity. Note that does not necessarily mean its hardware issues. LOS has to use the closed-source driver blobs from stock firmware as-is. If the bugs are in there, they couldn't fix them even if they wanted.
  12. Sorry, but this does not make sense to me. For me, this entire discussion started with you trying to fix a broken build of AICP precisely without recompiling its source (as others would have done). Rather, you tried to substitute-in the boot partition from another build in binary form, hoping that would magically fix things. Do you personally know the AICP developers? For the Pro1? I do not think so. You simply trust that project because it's open-source and others trust it. That "toss-salt-over-your-shoulder-and-hope" approach is quite common. And we both use it. Strangely, that seems to
  13. Eske, I usually wouldn't care. But as you are a moderator on this forum, I would really like to know how I deserve this kind of hostile response to (what I intended to be) a helpful post. I linked to the github main pages of those two projects. They provide project descriptions, source-code (as you noticed), how-tos, instructional videos, and official (not "random") downloads of binaries from their release branches. I think that is a pretty transparent and widely accepted way to link to an external open-source project. None of the *.exe's need to be "installed" by the way - they run right
  14. So why then make fun of my proposal and wrongly suggest it requires you to install a GO interpreter? (Something I am not sure even exists, I believe GO is meant to be a compiled language.)
  15. Did you even follow the links I posted?! Both of them give you portable Windows *.exe's (along with builds for other OS) that just run on any random box. No one expects you to compile the code yourself. When I say "no dependencies whatsoever", I mean it. Was actually trying to help ... 🙄
  16. 😄 ... as I already hinted above, you could have avoided python and git -- and thus most of those tedious steps -- by using one of the standalone extractor tools I linked to above: I just tested payload-dumper-go. It works well and has no dependencies whatsoever.
  17. True. However, the reports of connectivity failure are so widespread, both in time and location, that I suspect something is just designed too much on-the-edge with the Pro1-X's RF system. Meanwhile, I must admit that I find the "cannot reproduce" attitude of F(x)tec on the topic increasingly hard to believe. As @jakfish suggested, they could just fly a dev with a handful devices (from different batches) to one of the reported areas and test away. As you write, one possible reason they do not do this is money. Then again: if they cannot afford a boarding pass to the US or continental Euro
  18. Dear @Hook and @jakfish, Thanks for sharing the outcome of your investigations. It is intriguing that you get better results with GSM telephony. With my German carrier (O2), I have never been able to place or receive a call on GSM. Only VoLTE will work in the few places where the underlying LTE connection can actually be established. Note that this is not a restriction of my provider: I use and prefer GSM for calls all the time with the Pro1. What is different in our two cases is that US T-Mobile uses the 1.9 GHz band for GSM, while my O2 Germany relies on 900 MHz for that. Also, I o
  19. Your aversion to python is obviously still going strong. 😄 Can't really understand why, but then, I'm into scientific computing where there has hardly been a way around that language for 15 years or so ... That being said, there are standalone payload extractors, like this one or that one. I haven't tested them though, as I have a lineage build environment anyway, which includes the official 'extract.py' tool.
  20. Found my report from a month ago: To repeat: I think I have seen the Pro1-X switch between LTE bands 3 and 1 without dropping dead. Band 20 seems to be the problem for me.
  21. Unfortunately doesn't help. As (I think) I wrote previously, band 20 does not work, even if I enable the modem (or boot the Pro1-X) in that "zone" of my apartment. It will then directly go to the "no service" state.
  22. According to my research, T-Mobile US uses several "long-range" LTE bands (5, 12 and 71), all below 1 GHz (though not identical to my band 20). We'll see what happens ... 👍
  23. This doesn't change anything for me (nor all the other "preferred modes" I have tried). I have a pretty constant behaviour in all the tests I have made: 1) At one end of my apartment, the Pro1-X works acceptably. It uses LTE band 3 (1840 MHz) in that spot. Mobile data is fine. Phone calls go in and out, though only via VoLTE (in principle, my carrier supports GSM calls and I use those exclusively with the Pro1). 2) When I move to the other side of the house (~ 10 m), the Pro1-X switches to LTE band 20 (800 MHz), and all connections stall, even though the signal strength is displ
  24. The latest build of LineageOS 16.0 (for SD835-Pro1 only) is available at https://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1. Go for the ROM dated 201230326. It includes backported ASB fixes up to 5 March 2023. As for the last months, there is no upstream code review any more. I can confirm that there are no problems on my own Pro1. Beyond the ASB, there are no changes since last month. My full list of increments with respect to the upstream LOS 16.0 tree can be downloaded for reference. Have fun.
  25. I agree. I am in the lucky position to own an original Pro1 that is unaffected by all these issues. It shows that F(x)tec can make functional phones, just to emphasize that here once more. One thing @Michael074 could do is join their beta testing programme and provide debug-info to them. I haven't done so yet because my Pro1-X is already on LineageOS. Also, I admittedly have too much other fish to fry right now and cannot routinely carry a second smartphone along just to study its field-behaviour. That being said, admittedly, even with all necessary debugging info provided, I no lon
  • Create New...

Important Information