I’m also looking for a good overview graphic. Best thing so far are two tables from wikipedia here and here
This site also has graphical representaions but only by country. So cross country comparison is also tedious.
So what i read so far for europe is:
B1 2100MHz 3g (subject to be repurposed for LTE)
B3 1800MHz LTE (repurposed from GSM )
B7 2600MHz LTE
B8 900MHZ GSM / 3g
B20 800MHz LTE
B28 700MHz (old TV (dvbt) and wireless microphone frequencies) 5g which will probably be compatible with 4g i think
B22 B42 B48 3500/3600MHz lies in the 5g spectrum (3.4-3.8 5GHz) but could also be used for 4g
B32 1500MHz some limited use in few eu countries
b40 2300MHz also only few countries
So i see us only miss out on the B28. Which is a shame as it is an additional low frequency band, which are good for long distance and good building penetration and will grant for good coverage in the near future as it will be much cheaper to deploy than the many high frequency cells need for high-speed 5g.
And this graphic from here for 5g and as far as i know there is some kind of compatibility between these two. So The big thing here is again the B28 700Mhz Band
The BM818-E1 does support 1800 MHz (at least the most common variant, which is 3gpp band 3).
If the confidential datasheet that Purism has doesn’t mention this, it is likely a mistake in that datasheet and not in the website (which explicitly mentions it), since B3 support is basically a hard requirement for a EU/International variant that does dual-band GSM (which is 900 MHz B8 and 1800 MHz B3).
In Singapore, US surveillance isn’t the major issue, Singapore itself is one of the more surveillance-intensive states and the government itself is known to keep taps on communication in the country.
Of course there are still US interests, and also Chinese interests.
The BM818 combines both, since the Chipset and most of the software comes from Qualcomm in the US, and the other parts of the software (operating system services and some more) from Broadmobi.
The Qualcomm vulnerabilities are nothing unexpected, every modem manufacturer will have them, since they all run very complex software.
These vulnerabilities will themselves not directly apply to the Librem, because it doesn’t use the Qualcomm-integrated stack and so cannot be attacked by the same chained exploits.
However, the “Respects Your Freedom”-badge from the FSF, which Purism strives to achieve, prevents Purism to ship firmware updates for the modem, since that would require Purism to ship non-free firmware.
This could lead to future exploits at least for the modem portion (though the OS is unlikely to be attackable from that angle).
Oops. I messed up 3G and 4G table sections.
in FAQ BM818-E1 support B3 for LTE but not support B3 for HSPA+
I check again my operators. I dont need B3 for UMTS, only for LTE and 2G
So that’s all okay for me, BM818-E1 is fully compatible with my country.
And Purism FAQ is correct for BM818-E1.
But may be mistake in FAQ in PLS8-E for HSPA+ B3. How PLS8-E support B3 for 3G?? May be it possible and uses in some counties. I hear only about compatibility GSM+LTE signals for B3 (1800MHz) not for 3G
UMTS on B3 is highly uncommon, and therefore rarely supported.
Also, 3G support shouldn’t be of any concern anyway, because there are not that many 3G networks left, more will be phased out when the Librem hits the market, and in 3 years at the latest, almost none will exist.
Just for clarification: We are talking about the firmware of the modem, right? Isn’t it still a blob. Just one that is not loaded and executed on the main CPU but on the chip of the modem? If this is right I would not say that there are nor blobs included in the Librem 5. As the modem is separated from the main CPU etc. of the Librem 5 it may be safe anyway or at least safer compared to the conventional highly integrated architecture of common smartphones.
I don’t wan’t to spread any FUD. I would like to get a better understanding. So please explain.
In short: there’s zero proprietary code executed or even seen (copied) by the main CPU.
I think the definition of blob is a binary (e.g. a file) that is loaded into a device at runtime and executed there. Thus, I call it runtime-firmware (in contrast to fw that resides on the device)
And yes, both radios contain (resident) firmware, but have no access to the system. Remote code execution seems almost impossible. In any case that would be a bug in the (free) kernel driver - in contrast to all other modems that could read and write freely to RAM, without any way to prevent it.
Even resident firmware is of some concern. Whether the device has firmware loaded or firmware permanently resident, if that firmware is closed source then it is unable to be audited and hence it may be trusted but it is not verified. So the device itself retains a level of untrustworthiness. That’s just where the world is at right now - and it applies to every computer, not just the Librem 5.
As others have commented, being unable to update the firmware is a two-edged sword.
and that is good but it is as good as it gets right now.
For radios it may not matter so much because a) you are going to broadcast the traffic for anyone to receive, and - for the modem - b) it is going to be received by an untrusted party (the telco / the government). Ideally therefore you are running end-to-end encryption for the traffic over those radios.
ideally we would trust encryption to remain unencrypted by a third party only if the firmware residing on the lowest level was not compromised.
ah there was the “possibility” of brute-force-cracking a 2048 bit encryption but nowadays you really don’t use that unless you’re after the BIG fish. then there is quantum canon-blowing-encryption but that’s a mistery to me.
Running end-to-end encryption means that you don’t have to trust the card that is implementing the transmission and/or the encryption.
However since the mobile phone network doesn’t have end-to-end encryption, the firmware on the mobile card is a consideration, just not one that will be solved in a hurry.
the question is WHO is going to solve it because at the present moment the-spoon-is-in-the-corner. sure Purisms road-map looks good at first glance, for most people maybe even acceptable but experts know better right ?
Besides talking about bands and carrier compatibility, do we know anything about reception sensitivity and power usage of the modems?
In the light of this reddit post, this seems an issue that was not discussed here yet and I wonder if there is information available.
Its also very hard to find information on such a comparison. In general I think both cards are based on Qualcomm chips (see here). On the FCC website you can find out which chip the Broadmobi card uses but unfortunately not for the Gemalto card. But even with knowing the exact modem IC its hard to find information since Qualcomm is not really open with that.
The Gemalto card offers LTE cat 3. The Broadmobi offers Cat4 (a later revision). Hence I would assume the modem IC Broadmobi uses is a slightly newer modem and maybe has a better reception (due to more development time on the later IC version). But thats a big assumption…
Maybe you find some additional information on the FCC website. At least the uplink (from the phone to the base station) part can be compared using the output power listed on the FCC site of boths cards PLS8-USBM818. I did not see any information on the sensitivity for the downlink.
Just to confirm…
I am seeing the following options:
Option 1 is Gemalto’s PLS8. Two variants are considered, PLS8-E and PLS8-US.
Option 2 is BroadMobi BM818. Also two variants are considered, BM818-E1 and BM818-A1.
Does this mean people will have the option to choose from 4 variants; PLS8-E, PLS8-US, BM818-E1 and BM818-A1? What are the finalized options, if this is not correct?
I hear only about compatibility GSM+LTE signals for B3 (1800MHz) not for 3G