I've been mostly-happily using the PinePhone with Mobian for a long while (years), with MMS working pretty smoothly for a long time. Recently (last 5 days or so), MMS sending has completely stopped working.

  - It didn't happen after making any big software change (apt upgrade, settings change, things like that).
  - Group message sending and 1-on-1 media sending no longer works
  - Group and media receiving still works totally fine
  - Back when MMS sending was working, I noticed that after hitting "send" on an MMS message, the screen brightness would always change for a moment (something to do with power draw to the antenna?). Now when I try to send MMS that doesn't happen.

Any idea what the problem could be?

I have two PinePower 120W desktop power supplies, both have lost the USB-C ports.  No matter what is plugged in, the display reads 0 volts.  I have check the end devices and the cables with other chargers, the cables and end devices work fine.  I had previously charged the same devices with these PonePower supplies.

Judging from other messages, I am starting to get the impression something is defective with the USB-C port, does anyone have a fix?

Thanks

Mike

I am using noscript extension and it blocks the mobian website, is it really necessary? As it's a foss OS I think in my personal opinion that would be nice to have no javascript or use free js.
https://www.fsf.org/campaigns/freejs

Hi all, any idea how I can buy pinephone pro in Hong Kong? I lived here but I cannot fine "Hong Kong" in the list of shipping area! 
It's odd, I know Mainland China was not in the list, but Macau is! 

I know the products are produced here, but there's no local store that sells pine products too! 
I have emailed the pine team, got an email asked me to direct my question to the sales team, and I did. It's been a week, no reply yet. I'm very interested in this product and now frustrated that I cannot buy it anywhere.

Today my phone went to a black screen after booting, it was just a filesystem issue easy to fix by running fsck maually.



I "blogged" about it in case it can help someone someday:




https://mdk.fr/blog/black-screen-at-boot...phone.html



But I though, why asking a user to fsck manually on a phone? Is there an option Mobian could enable to just do the fsck if needed? It's not that simple as it'll still ask the user to fix or not to fix, like:

Trackers like Tiles and Airtags are cheap and simple to make, very useful, and likely have a large audience of people who avoid them for privacy reasons.

The tracking infrastructure is hard to do, because it requires wide adoption, but not technically difficult or expensive because it can be done with a community run trustless servers, and more importantly, even without the large community network it still has value.

Plus, if it ever got popular, the network could have other uses like 2-way messaging, and could maybe even integrate with meshtastic.


My dream tracker would come in 2 versions.

The small keychain version would look like all the other assorted CR2023 based tags, but would have 2-5 buttons, an accelerometer, and perhaps light or hall effect sensing.

The larger version would have a glowstick-like form factor and would add a rechargeable battery, light sensor, and passive IR motion sensor at the bottom.  This would let you attach it to your backpack and have it act as a visibility light at night,  or hang it up to keep an eye on a trailer at a job site, etc.   It could act as a motion triggered light, or glow dimly all the time to find things in the darkness.

Depending on cost/volume/etc, it could probably even have a tiny solar cell since BLE is so efficient.

Open firmware would allow a lot of stuff that's currently impossible:

* Link tags directly, give them to multiple people, press one to alert your group
* Use one as a home automation remote
* Get alerted on your phone if someone is messing with your bag
* Cool rainbow color patterns(Maybe even multiple LEDs) on visibility lights
* Maybe they could even be walkie talkies, if there's a mic cheap enough
* Act as a fixed public beacon anyone can find locally for geocaching type games
* Temperature sensing usually comes free on most chips
* They'd be decent dev boards
* Selfie remote

* Maybe they could even have an expansion port to control things(USB-C should be able to do I2C as an alternate mode)


 


The companion app that makes it work could use community hosted infrastructure managed like the NTP pool.  Anyone can apply to be on the official server list, anyone can choose to use a different list instead.

Since it's all open, clients can be built into anything and everything.  Dedicated hardware receivers could be made with ESP32s.





Sketch of how the protocol could work(Random notes, not edited) without completely cloning any other system:

Same as other tags, but using pure symmetric encryption for simplicity.

Every device generates an internal preshared key when it factory resets.  It also maintains time sync this way.

Hashing the time(Change every hour) with this produces the temporary key.

Hashing the temporary key produces the broadcast key.


The BLE advertisements contain 24 bytes of the broadcast key, plus an 8 byte lookup key made by hashing just the first 16 bytes of the temporary key with the time.

As we only have 27 bytes of data in an advertisement(After accounting for the type code and manufacturer code usually used),  we use 5 bytes of the MAC.

Listeners use the broadcast key to encrypt the GPS data, plus any other data the tag sent(Can just use standard Bluetooth data broadcasts for that in separate packets).

They then find a server in the official server list which has the ID that is closest to the broadcast key, and send it there(It's a distributed hash table, but not dynamic because that has efficiency issues).

Servers index data by the lookup key.


When the client wants to find the tag, they use the same process to look up the server. However they subscribe for updates by using the first 16 bytes of that temporary key as a password.


The server  hashes it to get the corresponding lookup key and do a lookup, but it is missing the rest of it so it cannot guess the broadcast key and decrypt anything itself.

64 bits is far too much to brute force anything, because the server is rate limited and keys change hourly.

A local eavesdropper knows the encryption key, but cannot get the data because it doesn't have the lookup password.

The server has the data, but it does not know the encryption key, and anyone who could set up a collusion between a corrupt server and a corrupt listener probably has much better ways to spy on you.



To keep it even simpler,  there's no concept of accounts or any persistent data.    Instead,  you can pair a tag with multiple devices, or import/export keys.

We’re porting Apache NuttX RTOS (Real-Time Operating System) to PinePhone. Now we can render LVGL Graphical User Interfaces… But it won’t work yet with Touch Input!

Let’s talk about the Capacitive Touch Panel inside PinePhone…

1. How it’s connected to PinePhone

2. How we read Touch Points

3. How we created the Touch Panel Driver for NuttX

4. And how we call the driver from LVGL Apps

NuttX RTOS for PinePhone: Touch Panel

The board between the barrel plug and usb-c shorted and blew flames out the usb-c port also looks like the chip under the lcd burnt as well I'm not sure how to post pics yet but I'll take some if needed.

Stickers and maybe T-shirts/hoodies with Pine logo would be a great. Would this be possible?

https://www.redbubble.com/shop/pine64+stickers





CC: @tllim

Change the forum's software from the current one to Discourse. I think it would be much more efficient to use.

Discourse's website:
https://www.discourse.org/

Also check:
https://news.itsfoss.com/discourse-3-0-release/