I am also an Electrical Engineer who works with pre-release integrated circuits on a daily basis. When I ordered this phone from Purism, I pretty much expected the phone to be released in its current state (although expecting better communications from Purism). The task that Purism has taken-on is almost unbelievable in scope. I didn’t expect complete success, just a worthy step in the right direction. With that being said, the article does accurately point out the areas that I predicted (and that any EE would predict) when it comes to the technical challenges of releasing an open sourced smart phone which is (despite a successful fundraising campaign) still relatively unfunded.
As the business model for the Librem 5 is unique, so will the development process of it need to be unique. If you set out to build a low-volume (relatively home made) car, the first model would most likely not resemble something made by Ford or Nissan. There might even be some valid reason to put something that looks like a Prius engine in to a flatbed truck. But we’ve got to start somewhere and Purism has made very reasonable engineering choices, given the available hardware and the stated goals of the project.
From an engineering perspective, if the reception/transmission range of the phone is limited to some degree, that is more of something to expect Purism to fix in a future release, especially if the limitations are the result of limitations of the modem which Purism only purchases and can’t actually fix it themselves. The same goes for any heat-related issues that are outside of Purism’s control for the same reasons. But the need for heat pipes does worry me. When low power is a primary goal, the idea should be to avoid generating heat, not simply to properly vent it. But maybe there is no choice for now with this, given the current state of this model.
Purism needs to make inroads on all fronts. Maybe the Librem 5 will be the cause of some IC manufacturers to take Purism more seriously when it comes to Purism’s next phone model. They need to believe that millions of their chips will sell in to these open sourced smart phones, while weighing how to deal with Purism’s expectations of ‘no firmware blobs’. Maybe an IC manufacturer will develop something that is ideally suited to match Purism’s market. But they need to see a market first. Someone has to start selling open sourced phones first, before chip manufacturers decide to build products that are optimized to sell in to that market. It’s the question of: what comes first, the chicken or the egg? So Purism puts a stake in the ground and says something like ‘we start right here and now’. They’ve got a lot of catching up to do to equal Samsung. But you’ve got to start somewhere.
It is my opinion that anyone who expects the Librem 5 to equal a Samsumg phone plus respecting your privacy and control over your own phone, will be greatly disappointed. I would love to be proven wrong about this. I think that we can expect some kind of a smart phone that fully respects our privacy, with room for technical improvements. That is worth more than seven hundred dollars to me as a first effort.
Yes you are right. I didn’t want to imply that. Just bad wording from me. I meant that purism is working with the interface of the blob contained on the m.2 module. Which is what the fsf counts as equal to a hardware API when it is not updateable (as far as i understood).
So i think the meaning is purism is working with the interface of the m.2 module, which was described by the editor as work on the firmware and lead to confusion.
Otherwise my impressions is the same as @tommes. Firmeware work with WiFI modules i heard of but not for modem modules. That seamed to me more like that they found a chip, the gemalto ones, they liked, but it was only available as bga or mPCIe so they needed to get it on a m.2 module. Which is a custom job but probably done without or very small need for firmware changes. But i might be totaly wrong here.
This brings even more hope for IoT m.2 modem optimisations for mobile use, since it’s been already installed in these tablets. I know that these tablets gonna have a limited space use (at one location - not searching for towers often) compared to cell phones, but at least there isalready some work done at least for power consumption if not both
Though, it’s not shipping with L5 and probably won’t be an option.
At least we can ask - @nicole.faerber@todd-weaver@joao.azevedo@mladen,
Is Quectel EM06 m.2 modem in consideration at all, by the time evergreen batch is rolling out?
Within Quectel_EM06_Hardware_Design_V1.0. is noted: “EM06 series module (EM06-E/EM06-J/EM06-A*/EM06-LA*) contains Telematics version and Data-only version. Telematics version supports voice and data functions, while Data-only version only supports data function. “*” means under development.”
Otherwise, a laptop on a WiFi connection with VoIP (and a VPN) will be objectively more useful.
+1
Or a Purism Librem 5 without SIM card. It is still smaller than most laptop computers. That’s my use case, btw. In my country, anonymous SIM cards are practically outlawed, therefore I have no interest in having one. I will just not use the Librem 5 modem.
Thank you @tommes for pointing out that Purism is using Qualcomm tech and isn’t doing firmware development. I used some of your points in posting a rebuttal on r/linux, but it seems to have been ignored.
In case anyone needs further proof that the BroadMobi BM818 is based on a Qualcomm cellular baseband, see this post by Angus Ainslie: https://lkml.org/lkml/2019/8/5/993
In that case you might see whether Purism will supply without a modem (unlikely for an agreed price for backer or preorder, but maybe in the future) and/or you should remove the modem once the phone arrives.
So you can take the modem out but you can’t realistically use that M.2 slot for anything else. (That’s not the SIM slot though, which is different but related.)
You can take out the M.2 card that holds the cellular modem, and put in something else, but that M.2 slot is probably only wired for USB (not PCIe), and it also might involve changing some code in the kernel to allow it. This is a question for the Purism engineers to answer.
No, that’s a different idea to what was in my head… I vaguely feel like it was maybe something Todd said in one of TLG’s videos… I’m skimming them now to try and find it shrug if I was wrong, thank you kieren and amosbatto for clearing up the complexities for me
edit: just re-watched the video and he didn’t mention it where I thought he did, so I now have no idea where the idea got into my head
Just need to wait some news from Purism about these issues. I think it’s really too complex for us.
If there are some issues some people can probably help them. This planet is big and some smart people help other for create an open source world and increase privacy
I am not Verizon customer, but according to this good news and to this bad news how it is possible that the very same firmware from Verizon once supports voice and in second scenario not, even though it is about the same firmware for the very same parent module? Basically I just wanted to link to those for your awareness as it looks like that (might be) EG06-A exists (on the particular market) as Telematics version and EM06-A as non-Telematics (Data-only) version. Just hypothetical question here, as I don’t understand, is it about EG06/EM06 modules for Verizon having some voice supportive chip (hardware) difference or just about disabling voice on M.2 card using software (and perhaps some preferable doctrinal rules)?
Secondly (and maybe somehow bothering), I like to point to Sierra Wireless AR7592 as this brings us to other modules that are just like AR7592: EMEA - AR7594, China - AR7596, Japan, Korea, Australia - AR7598. Which kind of glue do I need to put those on M.2 card? Epoxy for developers, even though I don’t posses mandatory certificate? And all of this leads me to finding (for myself) that there might exist some similarities when selecting modem module for L5 or Linux-based TCU (telematics control unit), similar development challenges, not sure and just guessing, @Tatatirci don’t get me serious on this one. But still some hopes I might keep alive, if nobody objects with some arguments why Sierra Wireless AR modules cannot be an option if eventually put by experts on M.2 card.
This is more of a general question regarding electrical or electronic engineering from the point of how an electric engineer uses physics theory. How much of the physics, as in Standard Quantum Mechanics, is used in designing a hardware component? Is that used at all, or just referred to, or is it something that is only at the back of the mind just in case something cannot be handled using plain old trial and error steps as in classical physics as opposed to the physics that concerns wave-particle duality, uncertainty principle, entanglement, tunnelling, and then SQM theory is looked at?
I am asking this because whenever I bring up the topic of using physics theory to design parts for, say the Purism devices, I get flack that the topic is inappropriate for the thread I am on. So, is there a more appropriate thread that I can discuss such things?
Even though this is not an relevant answer, but I guess that bringing your subject matter opinion/knowledge under Round Table (your own thread) should be fine.
I have never heard of quantum physics being a consideration in board-level electrical designs. The quantum stuff all takes place on the integrated circuits. The smaller the IC manufacturing process, the more quantum physics are involved. As things get smaller, quantum physics breaks some otherwise good electrical designs and makes new things happen that can be used to improve the design that would not be possible on a physically larger circuit. When you buy the chip to put it in to your board-level design, all of that has been established. All you need to do is to read the accompanying data sheet and count on the chip doing what the data sheet says it will do. Quantum physics plays a big part in how the chip functions (and thus, how the board-level application should function). But the board-level designers never have to consider the quantum mechanics issues. Quite simply, the chip always just does what the IC manufacturer says it will do when it is placed in to a board-level application. Board level designers never have to think of quantum mechanics.
This issue of quantum mechanics is also a different issue from the issues of radio wave propagation and antennas. At the frequencies we’re working with, the wavelength is very small. But the same rules of physics apply whether the wavelength is miles in size or in the nano-meter range. The only thing that changes are the physical constraints of what is practical to do to accomplish what is needed for the antenna to work well. For example, in an AM brodcast receiver, the antenna would be a few hundred meters in length. But that is not practical for the average person to have. So they coil a long-enough wire up to create an inductive loaded antenna to get an impedance match between transmitter tower and receiving radio and call it good enough. Even if most of the signal is lost, enough gets through to make things work. In a cell phone you have the opposite situation. The antenna has to be to big to catch enough of the signal to work, and capacitive loading is probably needed to provide an impedance match between transmitted signal and received signal. A lot of the signal is probably lost in the process. In any radio system, the antenna makes or breaks the system. Typically, the antenna gain is more important than how much power is transmitted.
That is more like the kind of info I need, to continue confirming my conclusions for or against, about what SQM is capable of being used for. What I really want, if you can get on my thread “Kazmroz Science” on Round Table, is to see what exactly Standard Quantum Mechanics has been used for as in using SQM as a guide in direct engineering design application and not just what it was used to try and explain after something was already designed by the use of regular trial and error engineering methods done without recourse to SQM.
