M1 enclosure, LED's, power and connections

Tachyon
1

With the Tachyon, I also ordered the M1 enclosure kit. Recently, I tried it with the Tachyon. Just to have it in a box, no intentions to mount it on the wall.

Some surprises when assembling:

  • Wiring of the power button. There is a cable in the kit, but apparently one of the connectors has to be cut and the cable must be soldered to the Tachyon’s main circuit board.
  • The position of the Tachyon’s USB-C ports when it is mounted in the enclosure. They can’t be reached, and require an “upward right angle” cable-type adapter. The kit contains one of these.
  • Extra led lights that are visible on the outside of the closed enclosure. They are wired to the enclosure’s own board.

A
A799×1200 290 KB

Not sure if I am going to try soldering the power button wire on the short term. No real issue, because with the lid removed, I can just reach the Tachyon’s power button inside.

The connector for an external 5V power supply is convenient. I figured I can use that to power the device, so that I can use the single USB-C cable adapter on the Tachyon’s main USB-C port, for connectivity (camera, other peripherals). The specs mention the external power supply has to be capable of 5A at 5V DC. So far, I have powered the Tachyon (without enclosure) using the USB-C port and a USB-A to USB-C cable. USB-A is never going to deliver 5A, but still it works. Possibly by draining the battery at high loads. I could connect an open end USB-C cable to the enclosure, which would make the 5A possible.

Questions:

  • Did anyone try to power the Tachyon in the M1 enclosure using the power slot? Does it work when connected to a USB-A outlet? Also for a longer period?
  • The enclosure’s LED’s can be controlled using the same I²C bus as the Qwiic connector. How do I access this (programmatically or command line) from the Tachyon?

Thanks. Erwin

2

About the enclosure’s LED’s and the I²C bus.

On the Tachyon’s Linux, package i2c-tools must be installed. Then, i2cdetect -l gives the list of interfaces on the bus. “i2c-3“ represents interface #3. You will have to probe the interfaces with an “aggressive” command that could interfere with the bus’s normal operations.

As the LED’s are controlled via address 0x27, look for something odd on that address in the output of command i2cdetect -y -a -r 3. In this command, the 3 is for interface #3.

In my case, it is on interface #1. Command: i2cdetect -y -a -r 1

Output:

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Read the contents of address 0x27 with command: i2ctransfer -y 1 r1@0x27. Result: 0x0d. For interface #1, this commands reads 1 byte (r1) starting on address 0x27.

The i2ctransfer command can also write. But I have not managed to make this work yet. All attempts lead to Error: sending messages failed: Transport endpoint is not connected.

A useful source of information about talking I²C (or I2C or IIC) on Linux: Accessing I2C devices from userspace in Linux - EmLogic AS