Discussion of Car Thing annoyances and possible future project goals

[jakemauer]

In another issue @chewitt posed the question, what are the goals of this work?

I figured that the best place to start is with the things that annoy us so I'd love to hear from folks what they wish the Car Thing did differently. Here's my initial list:

1. Interaction with the Car Thing often returns audio playback to the phone. I'm currently using the car thing on my desk and with the current behavior I can't really do much more than use the previous/next buttons. Pressing "play" will cause audio to revert to being played out from my phone rather than my desktop Spotify player.
2. Reliance on a phone at all. Right now I have an old iPhone 6 acting as the base station for the car thing, but it feels silly. It would be great to be able to pair this with my computer and not have to rely on a dummy phone at all.
3. Volume control over Spotify connect works...sometimes. Sometimes it will change the desktop player's volume, sometimes it just doesn't.
4. Turning the display off after N minutes of no playback. Right now the car thing stays on forever as long as it has power. Fortunately I can plug it into a power strip I use that has a master/slave setup with my main desktop. When the desktop goes to sleep or is off, the rest of my audio gear shuts off too. However it would be nice if the car thing could "go to sleep" if there's no activity for a while.

[bishopdynamics]

For me, the Car Thing is a neat piece of hardware that I want to repurpose.

For home automation stuff, it is common to wall-mount an old phone or tablet to use as a touchscreen interface to control things (like for HomeAssistant). One of the major downsides of wall-mounting a battery-powered device is that you end up charging it 24/7, which will eventually degrade the battery, and in some cases it can swell up and catch fire; these devices were never meant to be constantly charging. So for me, the fact that the Car Thing does not have a battery is actually a huge win!

Its about the same size as a light switch, but unlike other similar-sized hardware, it has physical buttons and a knob!

The device is already running what appears to be OpenLinux, and the GUI appears to use CEF, which means the hardware is capable enough to run a chromium browser fullscreen. It also has bluetooth and wifi.

I want to put a HomeAssistant Lovelace dashboard on the display, and setup some background service to handle input from the buttons, probably by sending mqtt messages back to HA, and then wrap the thing in a 3d printed housing that can be used to replace a light switch.

So to me, the big goal is to build and flash a custom firmware.

[everettperiman]

Not to deviate but I believe that the app is written in QT. There is a myriad of QT properties that are listed in #12. @bishopdynamics

I reflect a lot of the same feelings as listed above. It would be really interesting to build and a flash a custom ROM, but also to provide a future for such an interesting device. They have already supposedly stopped production so that means the commercial viability is limited. It would be a great opportunity to show the positive outcomes that having more open HW & SW designs can enable new uses and extend the life of products.

[risograph]

i was just gonna run doom

[jakemauer]

I agree with all of these things. I know modifying the existing "rom" or program running on the car thing might actually be more difficult than booting something new/different altogether. I optimistically bought a second car thing because I'm hoping people much smarter than me will be able to crack it and make it an awesome multi-purpose device. Having it in hand...the hardware is so nice, I really hope it can become more than a pseudo-useful spotify connect controller.

[big-harry]

Not to deviate but I believe that the app is written in QT. There is a myriad of QT properties that are listed in #12. @bishopdynamics

~To me it looks like only the web browser is QT from #12 reporting QtWebEngineProcess.~ Looking at the third party notices, it looks like the app was written using TypeScript ~or~ and QML. You can install QtWebEngineProcess on Ubuntu from the package libqt5webenginecore5.

[timothy-nishimura]

While attempting to listen to a podcast at 2x speed via the web browser (Brave), I see that the Car Thing allows for the change in playback speed, but this does not reflect on the browser. Phone playback is supported. Correctly.

[nateonline]

If there's any decent amount of onboard RAM and storage, I would love to get android running on it so I can develop simple android apps for it. If all of that was working, I would be looking for ways to capture the knob input for use in said apps.

[0oERASERo0]

For me, the Car Thing is a neat piece of hardware that I want to repurpose.

For home automation stuff, it is common to wall-mount an old phone or tablet to use as a touchscreen interface to control things (like for HomeAssistant). One of the major downsides of wall-mounting a battery-powered device is that you end up charging it 24/7, which will eventually degrade the battery, and in some cases it can swell up and catch fire; these devices were never meant to be constantly charging. So for me, the fact that the Car Thing does not have a battery is actually a huge win!

Its about the same size as a light switch, but unlike other similar-sized hardware, it has physical buttons and a knob!

The device is already running what appears to be OpenLinux, and the GUI appears to use CEF, which means the hardware is capable enough to run a chromium browser fullscreen. It also has bluetooth and wifi.

I want to put a HomeAssistant Lovelace dashboard on the display, and setup some background service to handle input from the buttons, probably by sending mqtt messages back to HA, and then wrap the thing in a 3d printed housing that can be used to replace a light switch.

So to me, the big goal is to build and flash a custom firmware.

Car thing have Wi-Fi? I thought it only has Bluetooth on it.

[emkay5771]

Now that the system has been rooted/ unlocked, it seems like it may be possible to run it as an Android Auto HeadUnit... See these projects as potential start points: OpenAuto: https://github.com/f1xpl/openauto CrankShaft: https://github.com/opencardev/crankshaft

[bishopdynamics]

Aw man, you're totally right about the QT thing, i saw some references to CEF in the licenses page and jumped to conclusions.

I also incorrectly thought the bluetooth chip was a bluetooth/wifi combo; I was hoping it could be enabled just by adding the right section to device tree. I'm interested in experimenting with adding a wifi module, probably via SPI or SDIO; I bet one or both are available via testpads.

Thanks to the work done by frederic, i was able to setup debian in a chroot and easily got X11 and chromium going using the framebuffer driver. No network, so I pointed it at some index.html i found locally.

I haven't addressed buttons, touch, or audio yet; once I do I will upload something to share.

If anyone manages to identify pins for SDIO, SPI, or any other interesting bus (another uart?), please let me know!

[quentinhayot]

I knew I was right ordering two devices a week ago! Congrats guys!

[justMaku]

Buttons and touchpad are exposed as /dev/input devices (event0 is buttons, event1 is rotary switch, event2 is touchpad)

[bishopdynamics]

I cleaned up and uploaded what I have so far: https://github.com/bishopdynamics/spotify-car-thing_debian_chroot

[williamtcastro]

Any update regarding the WI-FI capabilities of the car thing ?

[bishopdynamics]

In the kernel source, arch/arm64/boot/dts/amlogic/superbird_ep0.dts#L290 indicates that the SoC likely has wifi.

I'm not sure that is actually the dts used for superbird, it seems more likely they used arch/arm64/boot/dts/amlogic/superbird_evt_512.dts which lacks the wifi section, but still mentions efuse for wifi mac address.

I had previously thought that the broadcom bluetooth chip also did wifi with a shared antenna, which is pretty common. In the dts wifi section, it lists compatible = "amlogic, aml_wifi"; which makes me think it is a separate wifi chiplet on the same SoC.

So, we might be able to modify dts and build dtbs and kernel that expose the wifi hardware, BUT it probably doesn't have an antenna, so performance will likely be awful.

I think our best bet is to add our own wifi module.

Another option is to attach a Raspberry Pi Zero W 2 to the back, and forward network ports over adb

[williamtcastro]

Are we able to use a usb-c hub and connect a wifi dongle or Ethernet cable to it ?

[ivybowman]

I want to see the equivalent of a custom rom that just allows whatever web app and has adb by default at least. Even just in the context of now playing, having it be universal and running of your computer sounds way better.

[aarondj122]

I think that the most obvious thing would be to remove the "premium" check that the car thing has in place. It already allows for other media (when there is a spotify connection) through the phone.

[ivybowman]

With the 8.1.6 firmware it's just raw chromium, it's version 69, so not everything is going to be supported but it's extremely easy to swap the web app or connect to a web server via adb forward.

The buttons are all just keyboard keys 1234m esc and enter so it's annoying but somewhat easy to capture those inputs in js.

[patrickjquinn]

Did we ever figure out if wifi was A) able to be brought up and B) had enough signal strength to connect to a network sans an antenna? I have a plan to port one of my applications (https://getradiant.app/) to the CarThing as the first "Official" purpose-built homebrew app and I'm wondering how I'll handle connectivity and networking.

[fonix232]

I think frederic had the right idea by using buildroot: https://github.com/frederic/superbird-buildroot

It's much more flexible than tinkering around with chroots, plus it allows defining reproducible builds.

Hardware-wise, the Car Thing is about on par with ~2012 era smartphones, except for the SoC (which is way more powerful). The default firmware barely uses the resources available - even when "stressed" by e.g. quick song switching, memory usage never went above 200MB, and load average stays well below 1.00. And this is with continuous BT communication + a browser webapp running.

I think the best approach for more universally usable devices would be to look at what the PinePhone supports right now - the original PinePhone is really close in hardware (except for vastly more RAM being available), and has a number of open source Linux distros in various stages of development. Things like LuneOS, postmarketOS, or even Arch with Plasma Mobile or Phosh could easily work, and with some tinkering/trimming, I think even Ubuntu Touch could be brought up.

The two main issues will be the amount of RAM and flash storage - 500MB and 4GB respectively. I think most of the dual-boot partitions, as well as e.g. settings could be reclaimed with a new partition layout, though I'm not sure if the U-boot shell would be enough to achieve this goal.

As for WiFi, I have to agree, while the chip itself might be capable of some lower speed 802.11b/g/n (possibly not even full N spec), the lack of antennas will be an issue. As an alternative solution (also to make it portable), I think we could design a small "backpack" addon board that hosts a small battery (3000mAh should be more than enough to drive this bad boy for 8-10 hours, the SoC's max power draw is around 5W), its charging circuitry (with USB pass-through), as well as a small USB hub IC with an off-the-shelf USB WiFi module in tow.

My use-case would be a bit different from what has been listed above. I still aim to use it for smarthome control, but instead of trying to hack Home Assistant Lovelace into the device, a much better approach would be to write a custom UI system, similar to e.g. how Nextion's displays work (unfortunately their framework is not open source, but their HMI file format, as well as the serial API, is open enough so that it could be replicated). Combine that with the above idea of a "backpack", though a different one for such purposes (one that would not include a battery, but instead could combine Ethernet+PoE, and a handful of free USB ports for external dongles like WiFi, ZigBee, Z-Wave/Thread, among other things), and maybe sprinkle some HA remote config goodness on top (this actually bugs me a lot, that HA does not have a standardised "adoption" API yet, that would allow device developers to create user-friendly flows for adding/pairing new devices with HA, similar to how Ubiquiti networking devices can be added with one click and remotely configured), and you've got a really handy plug and play smarthome control center/panel.

But, to get back on topic, these are the steps needed for long term maintainable support:

1. Bring up mainline U-Boot support. Latest and greatest.
2. Custom built U-Boot images will also allow repartitioning the device, to do away with some stupid Spotify decisions like the 8MB env partition, or the settings partition, etc.
3. Luckily Amlogic's Burn Mode is not part of the writable bootloader, so completely bricking the device shouldn't be possible (as long as nobody fastboots...)
4. With a custom partition layout, brand spanking new operating systems in an optimal environment become possible
5. Bring up mainline kernel support - this shouldn't be an issue, the S905D should be well supported (thanks to the many Android HDMI dongles using this SoC)
6. Port the extra drivers needed for e.g. the touch screen
7. ???
8. Profit

[bishopdynamics]

@fonix232

I totally missed that fredric posted the suberbird-buildroot, I will need to try that out!

I've been experimenting with debian arm64 on the device. My setup right now is roughly as follows

• enable adb and rndis (usb networking)
• disable superbird app
• modify fstab and inittab so that data and settings partitions not mounted
• do the same for both system_a and system_b
• modify env so that if i hold button 1, it boots system_a, otherwise boots with data partition as root (boot_b kernel)
• in system_a, added debootstrap

So now, I have a situation where I'm using system_a as my "recovery" system, which always has working adb and rndis, and has debootstrap. So I can experiment with something else installed in data partition, and if anything goes wrong I can just boot back into "recovery" and fix it.

So I used debootstrap to setup a really basic debian root filesystem in data partition, and I've been experimenting with that. I'm just using the stock kernel in boot_b, so the result is not truly debian, but it does seem to work!

The usb gadget with rndis works well, but adding the adb function does not, and I suspect my version of adbd is not compatible. I had to grab an arm64 binary from a random ubuntu repo, and never really expected it to work.

I have been running into trouble getting framebuffer to work correctly with xorg fbdev driver, which is strange because I got it working pretty quickly using a chroot. I now suspect that the Spotify app does a bunch of configuration to the framebuffer, and maybe when I tried in a chroot it was after Spotify app had already run and then been closed.

Once I get xorg figured out, I'll put together a "rom" as-is, to make it easier for others to experiment. I will also upload all the scripts I used to build it.

[fonix232]

@bishopdynamics

Why not make the boot options pick between system_a and system_b instead? That way you don't need to repurpose data as your root partition.

I'm for the time being will be focusing a bit more on the hardware. Any idea if USB Host mode can be easily enabled, or not? I know that not having WiFi, etc. makes things harder - I was thinking about using the Bluetooth stack to create a PAN and have a computer share internet (as well as e.g. shell/SSH access) to it until we get WiFi working in one manner or another.

In the meantime here's a little sneak peek of what I'm working on:

It's the Pip Thing! Or SuperBoy. Or PipBird. Take your pick. Next step is to add a powerbank, and a USB-C hub that can power the whole stack. Then we can easily add USB devices for e.g. WiFi purposes.

As for ADBD, I'd recommend you check the Amlogic OpenLinux buildroot - adbd sources should be right there and you should be able to see how it's different from the build you got.

[bishopdynamics]

@fonix232 I'm just using the data partition as second root because it's 2GB instead of the system partitions which are 516MB; I wanted more room to experiment with installing packages.

It totally didn't occur to me to check the OpenLinux buildroot for adb, good tip!

[350d]

Hello! WEBUSB supported on this device via micro usb or not? I want to try to stream video from other device over usb. Is this possible?