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/

Hi

I just got a new rockPro64 (v2.1) for a project I'm working on.

I have experience with Rockchip SBCs but not the rockpro in particular.

My preferred OS for them is Armbian so I downloaded both the CLi and XFCE versions 22.11.1 (Jammy current) from the armbian site.

I first burned the CLI img to a known-good 32GB micro sd card with Etcher.

This would boot u-boot when the SD card was enabled but would fail to go further.

If I had the emmc installed (uninitialized) it would complain about that and then start a PXE boot loop.

If I remove or bypass the emmc, it complains there is no partition found on MMC 1 (It is looking for MMC1:1)

Looking at the SD card there is one Linux partition and that's it.

I then burned a Debian image and was able to boot up the installer, but because Debian lacks support for the Wifi module, I couldn't get very far since I don't have Ethernet in my workshop yet.

I then tried the XFCE Armbian image and has the exact same issue as the CLI image.

Usually when working with SBCs I've noticed there are 2 partitions on the SDcard, DOS and Linux, is Armbian different?

Is there another recommended Linux image that supports the Wifi module?

Thanks!

(Edit: Just for grins I tried an edge community build of armbian and same exact thing even though the uboot was 2 months newer)

(Edit 2: breaking out of u-boot and running "mmc part" returns "Unknown partition table type 0")

(Edit 3: I checked and the Debian image is also MBR but with a single FAT32L partition showing probably because it's the installer only?
I also tried the latest auyufan which is a GPT instead of MBR and it booted just fine but lacked the firmware for the wireless device when it tried to load the module, so far this issue seems exclusive to Armbian images, I would be interested in hearing from anyone who had had success with them)

Attached Files

Thumbnail(s)
           

Where can I get spare ear cushions for PineBuds Pro? What are the ear cushions that come with PineBuds Pro (material, dimensions, etc.)? What kind of ear pads are suitable for PineBuds Pro?

Related to, but this thread is more specific: https://forum.pine64.org/showthread.php?tid=17806

Admins, please add own sub for PineBuds Pro to this forum.

It's common (especially with "true wireless earbuds") that one of the earbuds, the earcushions or the charging-case gets lost. Is it possible to order these spare parts from Pine Store by e-mail? Are they coming to the store more widely?

Pine Store has said that it's committed to repairability of its products and providing spare parts. And they do with many of their products, but not yet with PineBuds Pro. This must be done with PineBuds Pros as well. Just sell some whole PineBuds Pro in parts.

CC: @tllim

Yesterday, I did my normal Manjaro update, and was told there was a new version of u-boot and to run the two dd commands (Not the first time i've done this). I ran the two commands, but upon reboot, I saw a new u-boot screen (I've never seen this one before), then the screen would show a bunch of junk, then go blank.

It appeared that something was failing during the boot process. I was not able to switch to a terminal (ctrl-alt-f2), nor ssh/ping the machine.

Unfortunately, my keyboard did not seem to be active during the boot process, so I couldn't interrupt or inspect u-boot before it started booting manjaro.

I assumed my best option was to revert uboot, and followed the 'Flashing u-boot to SPI Flash' from the NOOB page.

It wasn't booting from the SDcard by default, so I flipped the switch to disable my emmc.

When I turned on the power, with the SDcard with the u-boot-flash-spi-pinebookpro.img.xz image written to it, the power light went amber, and the display stayed off. I let it sit there for about 5 minutes, but nothing happened. No blinking lights as expected.

I turned it off, removed the SDcard, and re-enabled the emmc switch.

Upon a reboot, the power light starts off amber, and then goes green. However, the display never turns on. I hooked up an external monitor through usb-c-> hdmi, and it never gets a signal either.

I seem to be in an un-bootable state, and get no feedback since the display never turns on.

With emmc enabled, the power light is amber, then goes to green and stays green. Display is off, external display doesn't work. No indication that it has booted. No network.

With emmc disabled and a bootable SDcard (Manjaro), the power light stays amber and the display stays off. No indication that anything booted.

What are my options for fixing this?

TIA