@fsflover, Thanks for the suggestions to update the table.
I made most of your suggested changes, but I kept the part about PINE64 being “transparent” as one of the “Reasons to buy” the PinePhone. In some ways PINE64 is less transparent (for example we don’t know the names of its employees and we only hear from 2 people in the company), but PINE64’s projected shipping dates are generally reliable and the company uses very little PR in its communications with the public. I understand that financing long and expensive development projects through crowdfunding requires PR and positive messaging to prevent the cancellation of pre-orders, but it does annoy some people and they do see it as a reason to buy the PinePhone over the Librem 5 (for examples, see the posts by @admsjas and @eugenr).
I don’t consider that to be a transparency issue. In fact, I think it’s positive that employees are afforded a level of privacy. Some organisations manage to balance an open process with the desire for privacy of the people working on their products.
Also, cultural and personal factors play a role in whether people are comfortable performing in public, in roles with elements of customer support and public relations tasks, while being unable to really influence the policies that have the most impact on how well they can perform those tasks.
Anyway, this is not really related to the specifications of the phones, but perhaps transparency is too subjective to include in a comparison of product features.
I agree with @david.boddie that the issue should not be called “transparency”. You could perhaps call it something like “keeping every single promise” or “reliable shipping dates”.
@amosbatto you may want to consider adding this (the F(x)tec Pro1 X) to the comparison on your blog. The Pro1 has already finished production and the Pro1 X is on track to start shipping in October. That estimate should of course be taken with a grain of salt, since the shipping estimate has been pushed back twice now.
Huh, that’s in conflict with their Indiegogo page: https://www.indiegogo.com/projects/pro1-x-smartphone-functionality-choice-control#/updates/all (they said “between October and November” in their July update). I haven’t seen anyone ask in the comments or in the forum about the discrepancy. I would guess that October is a very optimistic estimate and November is more realistic, so that’s what they put on the order page.
I wondered about that, but when I asked about the external connector, I was told that it just consisted of a UART and I2C bus, underneath the WiFi/Bluetooth card, but now I see that those two buses go to the 24-pin connector. OK, that clears up a lot of the confusion. I will fix the FAQ.
@dos, I have documented the pins in the external connector as best as I can by looking at the schematics, but there are three pins that confuse me:
Why is pin 13 (SPI_SS1) labeled as Serial Peripheral Interface, when it is connected to the UART4_RXD (UART bus4 receive serial data) pin in the i.MX 8M Quad? What is its purpose?
From their names, I would guess that pin 6 (NFC_EN) and pin 14 (NFC_IRQ) are for adding Near Field Communication mods, but pin 6 is connected to SAI3_RXFS (Serial Audio Interface bus3 receiver frame sync) pin in the i.MX 8M Quad, and pin 14 is connected to the SAI1_TXC (Serial Audio Interface bus1 transmitter clock) pin. Are these pins for adding audio mods?
Just take a look at the SAI and eNET blocks (page 5). Since we don’t use Ethernet and some of the audio interfaces, these pins got reused as GPIOs. I guess similar thing happens with UART4, as the real UART4 (Bluetooth) is connected to ECSPI2 (it’s a four pin UART with flow control, and dedicated UART interfaces only have two pins). We have only one SPI flash, so it all makes sense to me.
@dos,
I looked into SPI, and it needs a Slave Select wire, so I described SPI_SSI as “SPI Flash Chip/Slave Select (to indicate when data is sent from master or slave), connected to the UART4_RXD (UART bus4 receive serial data) pin in the i.MX 8M Quad”.
Is the purpose of the four SPI Flash pins to be able to reflash the code stored in the W25Q16JVUXIM TR SPI NOR Flash?
I described NFC_EN as: “NFC data, connected to the SAI3_RXFS (Serial Audio Interface bus3 receiver frame sync) pin in the i.MX 8M Quad” and NFC_IRQ as “NFC interrupt request, connected to the SAI1_TXC (Serial Audio Interface bus1 transmitter clock) pin in the i.MX 8M Quad”. However, since there is no documentation on how to use these pins, it seems more likely to me that someone wishing to implement an NFC mod will use the I2C port.
Do we have a part number for a 24-pin male connector that fits in the OCN / OKI OK-06F024-04 socket or a link where people can buy a 24-pin connector if they want to try to make their own mods?
The only description that I can find for it is: “24pin 0.4mm pitch TBT board-to-board connector”.
I’d rather imagine that its main use case would be to use something that’s stored in the flash by the user. There’s no need to fiddle with hardware to reflash it.
If you wanted to implement an NFC mod, you would want to use these two pins and I2C anyway
I don’t have it at hand right now, but FWIW the same connector is used for selfie cam.
