Like I did when receiving the Cosmo Communicator, I want to share the first impressions while unboxing the brand new Astro Slide, I have received yesterday. About two and a half years ago I have backed Planet Computers Astro Slide Indiegogo campaign. Again Planet Computers has promised a device that is different from anything else, that is available for purchase. The Astro Slide is a slider class device with a fully integrated keyboard and touchscreen and full phone usability that is designed for Android, but will also be capable of running Linux or Sailfish OS. No need to go through the full specs here, everything interesting regarding these can be read on Planet Computers web page. Originally Planet Computers was planning the device in March 2021, then Covid-19 appeared… Yesterday, after a long time of waiting the parcel with the Astro Slide finally arrived. When receiving the parcel I had to pay an additional 33€ import fees.

Inside the parcel has been a single box.

Before opening the box has to be fold out.

After Opening the box one can see the well packed Astro in there.

The full content of the box can be seen below. One can see the Cosmo wrapped well in foil as well as an envelope containing a quick start manual and the Sim card tool. Still in the box are two smaller boxes containing the charger and the USB cable.

After some further unboxing we can see charger and user manual.

After removing the foil we can see the Astros full beauty.

From the back side we can see camera and rubber feet.

With the opened device we can see the display and the German QWERTZ keyboard. The keyboard again feels more solid as with the Cosmo.

When opened we can see the sliding mechanism from the back. The sliding mechanism is a bit clumpsy as others described before. It will take some time to get the feel for it.

After completing the initial setup process the Astro shows the Android desktop.

Below we can see the desktop in landscape while the keyboard is slided out and its backlit is turned on. Unfortunately the display corners are far rounder than with the Cosmo.

I am hoping you have enjoyed the photo series and some first impressions of the Cosmo. Further articles regarding testing some aspects of the device, and hopefully some solutions will follow. Stay tuned for updates.

Jürgen

(1 votes, average: 5.00 out of 5)

Loading...

Posted in android, fun, gadgets, hardware, linux | No Comments »

Bosch’s BME680 is a very interesting component. It is a four in one sensor, which can measure temperature, humidity, pressure and air quality. Unfortunately there is no official support for using the sensor with arm64 linux. This article shows a kernel based approach to use this sensor with NVIDIA’s arm64 based Jetson boards.

Connecting the sensor
First of all the sensor has to be connected to an i²c port of the Jetson board. There is no difference whether we use a TX2, Nano or Xavier board for this. The pin Layout of the Raspberry based GPIO connector (for example J12 on Xavier NX, J42 on Nano and J21 on TX2)¹²³ is the same with all these boards. After connecting the sensor to the pins 1-9-5-3, as shown above, we can check the connection using i2detect. If we can see a device with i²c address 0x77 or 0x76 everything is connected properly.

root@jetson:/usr/src# i2cdetect -ry 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using receive byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- 77                       

Building the kernel modules
During Google Sommer of Code 2018 Himanshu Jha has developed a kernel based driver for the bme680 sensor⁴. The kernel supplied by nvidia (4.9.140) does not support the BME680 sensor. Mainline kernel started supporting this sensor with version 4.19. Fortunately the required kernel module can also be built against the older NVIDIA supplied kernel. So we just have to get the kernel source of a kernel version supporting the sensor. This time we will use the most recent 4.19 kernel:

wget http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.116.tar.gz

We just need to extract the drivers/iio/chemical subtree of the kernel source for building the bme680 sensors kernel module.

tar --strip-components=3 -xzf linux-4.19.116.tar.gz linux-4.19.116/drivers/iio/chemical

After extracting, we have to configure the build. To do so, prepend the following lines to the Makefile in this subtree:

CONFIG_BME680=m
CONFIG_BME680_I2C=m

Afterwards build the kernel module⁵ and install the binaries to the modules folder:

make -C /lib/modules/`uname -r`/build M=$PWD
make -C /lib/modules/`uname -r`/build M=$PWD modules_install

Once the kernel modules have been installed as shown above, we can load the the kernel module with modprobe bme680_i2c. This can be automated on startup by adding the module to /etc/modules-load.d/modules.conf.

Using the sensor via sysfs
To use the sensor we have to register it with the kernels i²c subsystem⁶. This could be added to a startup script, for example /etc/rc.local.

echo bme680 0x77 > /sys/bus/i2c/devices/i2c-1/new_device

Depending on sensor configuration the i²c address can be 0x76 or 0x77. Once the sensor is registered, the sensors readings can be acquired using the sysfs interface:

grep ^ /dev/null /sys/bus/i2c/devices/i2c-1/1-0077/iio_device/*input*
/sys/bus/i2c/devices/i2c-1/1-0077/iio_device/in_humidityrelative_input:45.503000000
/sys/bus/i2c/devices/i2c-1/1-0077/iio_device/in_pressure_input:1005.830000000
/sys/bus/i2c/devices/i2c-1/1-0077/iio_device/in_resistance_input:60726
/sys/bus/i2c/devices/i2c-1/1-0077/iio_device/in_temp_input:25100

Unfortunately the kernel driver does not support the calibration of the sensor and just outputs the resistance value of the air quality sensor. So calculating CO2 equivalent or air quality from the sensors readings has to be done in userspace. Usually this calculation is being done using Bosch’s closed source BSEC library which cannot be used on arm64 architecture or within kernel context. A promising approach on self-calculating the air quality from the raw sensors readings has been shown in pimoronii forums⁷. According to this, the IAQ⁸ air quality index ranging from 0 to 500, can be calculated from the bme680 readings using the following formula:

iaq = log(gas_reading) + 0.04 * humidity_reading

For completeness, the bme680 device can be unregistered⁶ from the kernels i2c subsystem as follows:

echo 0x77 > /sys/bus/i2c/devices/i2c-1/delete_device

Jürgen

References:
1. jetsonhacks.com: jetson-tx2 pinout
2. jetsonhacks.com: jetson-nano pinout
3. jetsonhacks.com: jetson-xavier-nx pinout
4. himanshujha199640.wordpress.com: bme680 driver
5. kernel.org: external modules build
6. erlerobotics.gitbooks.io: i2c kernel devices
7. pimoronii forums: calculation air quality from bme680 readings
8. wikipedia.org: Air quality index

(No Ratings Yet)

Loading...

Posted in drivers, hardware, kernel, linux | No Comments »

Like I did when receiving the Gemini PDA, I want to share the first impressions while unboxing the brand new Cosmo Communicator, I have received today. About one year ago I have backed Planet Computers Cosmo Communicator Indiegogo campaign. Planet Computers has promised a device that is different from anything else, that is available for purchase. The Cosmo Communicator is a clamp-shell class device with a fully integrated keyboard and touchscreen and full phone usability that is designed for Android, but will also be capable of running Linux or Sailfish OS. Major improvements compared to the Gemini PDA, beside better specs, are the outside cover display and the backlit keyboard. No need to go through the full specs here, everything interesting regarding these can be read on Planet Computers web page. Yesterday, after a long time of waiting the parcel with the Cosmo finally arrived.

Inside the parcel has been a single box

Before opening the box has to be fold out.

After Opening the box one can see the well packed Cosmo in there.

The full content of the box can be seen below. One can see the Cosmo wrapped well in foil as well as an envelope containing a quick start manual and the Sim card tool. Still in the box are two smaller boxes containing the charger and the USB cable.

After removing the foil we can see the Cosmos full beauty.

With the opened device we can see the display and the German QWERTZ keyboard. Keyboard and hinge even feel more solid as with the Gemini PDA.

After booting the Cosmo shows the initial welcome screen. With a press to the start button one could start the initial setup process.

The outer cover touch display, which shows the caller id and allows to accept calls can be seen below.

For the Cosmo Communicator I also ordered a third party belt case which can be seen below with the Cosmo inside and a Adonit Dash2 stylus attached.

I am hoping you have enjoyed the photo series and some first impressions of the Cosmo. Further articles regarding testing some aspects of the device, and hopefully some solutions will follow. Stay tuned for updates.

Jürgen

(4 votes, average: 3.50 out of 5)

Loading...

Posted in android, fun, gadgets, hardware, linux | 5 Comments »

There has been a discussion about enabling the auto power on feature of the Jetson TX2 development kit on devtalk.nvidia.com. The solutions discussed there involved using a additional micro controller or soldering directly on the quite expensive board which is not desired by quite some users. This article will show a fairly simple and quite safe method to use the auto power on feature without additional circuitry or soldering directly on the board.

According to the Developer Kit Carrier Board Specification the auto power on feature can be enabled by shorting the CHARGR_PRSNT pin (pin 1) of the charge Charge Control Receptacle (J27) to ground (pin 5). This is fairly hard to achieve without having the appropriate connector or soldering the board itself. Since the pins 2-4 also are input pins it is safe to short all these pins (1-4)  to ground. This can easily be achieved by using a small piece of a copper plated circuit board matching the receptacles dimensions.

The piece of circuit board has to be cut and grinded to proper dimensions. A board of approximately 6mm x 8mm x1 mm size is fine. Afterwards the copper plating has to be grinded off in the area that can get contact with any other pin than the five mentioned pins. It is advisable to check this with a Multimeter while moving the board left and right in the receptable before attaching power. If you damage your board due to this procedure, you are the only one responsible. The resulting board is being shown below.

The completed circuit board.

This board turned out to be a bit to thin to ensure contact, thus a bit of soldering tin has been applied to the copper plating to ensure the contact between the pins. The tiny board can now be inserted into the Charge Control Receptacle

Jetson TX2 Development board with applied board for auto-power-on

With the crafted piece of circuit board inserted into the Charge Control Receptacle the Jetson TX2 now boots directly after applying power. This has been tested with two different development boardw. For the older board (Revision B04, SATA port facing up) it worked, but it did not work for the newer (Revision C02, SATA port facing to the side) one. So your mileage might vary.

Jürgen

References:
1 NVIDIA development forums
2 JetsonTX1 TX2 Developer Kit Carrier Board Specification p. 31
3 how-to-find-carrier-board-version

(No Ratings Yet)

Loading...

Posted in hardware | No Comments »

Recently, when writing the article Some first tests with the Gemini PDA, I have noticed the ridiculous slow micro SD card I/O performance with Android. Because of this, later on, I did some further testing with Debian installed on the Gemini. After booting the device, the micro SD card read speed looks good, but after having the device suspended (i.e. closing the lid) the speed drops to about 20 MB/sec, which is consistent with the result of the Android test. So most  probably this also has been after a suspend. To pinpoint the problem a bit more, a more extensive test setup has been carried out.

Test setup

For this performance test the common tool hdparm has been used. On Debian based systems it can be installed from a root shell:

root@gemini:/home/gemini# apt-get install hdparm

Its usage for the test is quite simple:

root@gemini:/home/gemini# hdparm -t /dev/mmcblk1 

/dev/mmcblk1:
 Timing buffered disk reads:  62 MB in  3.05 seconds =  20.34 MB/sec

To make sure that the problem is not limited to the SD card that has been tried out initially, the test has been carried out with four different cards:

•SanDisk Ultra 200GB microSDXC Speicherkarte, Class 10, U1, A1
•Samsung EVO Plus Micro SDXC 128GB, Class 10, U3
•Samsung EVO MicroSDHC 64GB, UHS-I, Grade 1, Class 10
•SanDisk Ultra microSDXC 64GB, UHS-I, Class 10

The four tested cards are being shown in the photo below.

Micro SD cards tested with the Gemini, from the left Sandisk Ultra 200GB, Samsung EVO Plus 128GB, Samsung EVO 64GB, Sandisk Ultra 64GB

For each card the read speed has been measured directly after startup and after closing the lid and reopening it. To ensure not to use fake or broken SD cards, all the cards also have been tested using a laptop with Gentoo Linux and a USB 3 card reader (Transcend TS-RDF8K). These speeds then can be compared to the results with the Gemini.

Results

The following table shows the results of the test as well as the “official” speed rating of the cards.

The measured speed of the two older 64GB cards is quite close to the rated speed, but the performance of the two 100MB/sec rated cards is far too low. Especially the results for the 128GB Samsung EVO are catastrophic. With the Gemini these cards operate at 57% respectively 69% of the speed  measured with the laptop. After suspending the Gemini the read speed of all cards drops below 20 MB/sec. The initial higher speed can only be achieved by rebooting the device. The results with the cards inserted into an external card reader attached to a laptop show that the cards generally are in a good working condition.

Conclusion

The test shows, that there is a performance issue with the Gemini PDA and micro SD cards. The higher rated cards operate far below their capabilities. For all the cards, the speed drops below 20 MB/sec after a suspend cycle. Thus, most probably there is a bug inside the Mediatek driver for the SD card reader, that prevents the cards from operating at high speed after a suspend cycle.  Also it might be possible to optimize the driver for newer cards. Hopefully these issues get resolved when the Gemini gets Android Oreo and a 4.X Linux kernel with it.

Jürgen

(1 votes, average: 5.00 out of 5)

Loading...

Posted in gadgets, hardware, linux | 2 Comments »

As I promised in New version of the vr920 headtracking driver coming soon here is the new version of my headtracking driver for the Vuzix VR920 iwear for Linux. It calculates yaw, pitch and roll from the accelerometer and magnetometer data (The device has got three of each). This makes a 3DOF tracking possible and allows you to look around in a 3D Scene.  In example you can use the driver with my stereoscopic image viewer SIV. The driver averages the sensor readings with an improved algorithm, which gives a far smoother experience than with the initial driver version. The driver package consists of a daemon which can be run in the background and for convenience a basic control application that enables one to easily tweak the various driver settings and to callibrate the device. For general Information on how to use the device with Linux see: Vuzix VR920 with Linux and active 3D stereo.

The driver provides the trackingdata in different formats to the application using it. It always writes the data to /dev/headtracking. A line read from /dev/vrtrack consists of six floats that correspond a sensor reading in this format:

yaw pitch roll x y z

Yaw, pitch and roll are angles from 0 to 360 degrees. X, y and z are always zero for the vr920, since it only supports three degrees of freedom. These values are reserved for future devices which may support six degrees of freedom, in the hope to propose a standard for tracking devices.

The driver can scale the readings and invert the axes independantly to get the needed value range for the used application and a pleasant experience.

For maximum compatibility with existing applications there are four other modes of operation available that can be enabled separately:

• Joystick emulation
  The driver emulates a joystick device /dev/input/jsX. The readings for yaw, pitch and roll are the X,Y and Z axis of the emulated joystick. This may be used to enable basic headtracking support in games that do not natively support headtracking.

• Mouse emulation
  The driver emulates a joystick device /dev/input/mouseX. The readings for yaw and pitch are being translated to X and Y of the mouse device, so when you look right the mouse pointer moves to the right and when you look up the pointer moves upwards and vice versa.  This may also be used to enable basic headtracking support in games that do not natively support headtracking. It can also be used to just control the mouse pointer of the window system. Controlling the viewport of the window system can also be a resonable purpose. With the new MPX extension in xorg this may be possible.

• UDP – network
  In UDP mode the driver sends the tracking data via network as UDP unicast. The approach to send the data out via network makes the language used for writing the application independant from the language used for developing the driver. The packet sent to the clients contains the three angles, yaw, pitch and roll and x,y and z as 32 bit fixed point in Q16.16 format. This mode may i.e. used to control flightgear.

• Multicast – network
  In multicast mode the driver sends the tracking data via network as UDP multicast, thus many clients may read the data, which makes parallelization more possible, i.e. one could use one machine for rendering and another machine for calculations. In addition to this, the approach to send the data out via network makes the language used for writing the application independant from the language used for developing the driver. The tracking data sent to the clients contains the three angles, yaw, pitch and roll and for easy usage a viewmatrix, one can directly use with scenegraph libraries. If you intend to develop an application using the headtracking of the VR920 see the file democlient.cpp included in the download for details on how to get the data into your application. This mode is used by the stereoscopic image viewer SIV.

Important note: During calibration make sure that the display of the device is displaying something. Since the displays not only showing a blue screen influences the sensor data (at least with my device) you’ll end with wrong calibration else. You may use i.e. nvidia-settings to ensure this. For detailed usage instructions see the readme included in the download.

Download:

I decided to publish the driver under the creative common noncommercial license. You may download the full source from here: vr920-driver(source) (13483 downloads ) , an x86_64 binary from here: vr920-driver(x86_64 binary) (12938 downloads ) , or an i686 binary from here: vr920-driver(i686 binary) (13312 downloads ) . An Archlinux PKGBUILD provided by Feilen is available here: aur.archlinux.org More binary/distribution specific formats may be available in the future. The x86_64 binary has been build on an up to date gentoo system, the i686 binary on ubuntu hardy. For the i686 binary you may install libconfig++ i.e. libconfig++8_1.3.2-2 from here: libconfig++ If none of the binaries works for you, you may have to build from source…

You need to have libusb, libconfig++, libfuse and libcurses installed on your system. For ubuntu users I included the small shell script ubuntu_install_deps.sh that installs the dependencies. Maybe it works also for for other Debian-based distributions. Gentoo users just have to make sure that  libusb, ncurses, fuse, and libconfig have been emerged. Your kernel version has to be at least 2.6.31 and you must have cuse enabled in your kernel.

Footnote:

If you like the driver, feel free to link to www.mygnu.de. If you developed an application using the tracking data provided by the driver please leave a comment, because then I can review the application and eventually write about it. To request commercial licenses contact us at info(at)mygnu.de. Well, if you just want to support our work on MyGNU.de use the donate button 😉

best regards

Jürgen

(1 votes, average: 5.00 out of 5)

Loading...

Posted in 3d, drivers, games, hardware, linux, programming | 21 Comments »

A while ago I noticed my gnome-sensors-applet displaying wrong units for some sensors. I.e. it displayed an “A” next to a fan sensor value.  Since I had the same problem once before I remembered quickly how to solve it. Because I did not find anything about this problem in the web, I decided to write this post.

The reason for the wrong units is wrong data stored in gconf. Each sensor has a type. If this type is stored wrong the applets configuration the applet displays the wrong unit for the sensor. Sensor types I know are:

• 0 – current (A)
• 1 – fan (RPM)
• 2 – temperature (C or F, depends on selection)
• 3 – voltage (V)

To change the applets configuration to the right sensor types start gconf-editor.

Search for the key name sensors_applet_version. At the same location you will find the properties of the sensors applet. Then open (doubleclick onto each)  the keys ids or labels and sensor_types edit key pages and move them next to each other to identify which sensor type entry belongs to which sensor.

Now change sensors with wrong type settings to the correct ones. Then from console issue a killall gnome-panel to force the configuration to get reloaded. Afterwards you should get the correct unit being displayed next to your sensor data.

Jürgen

(No Ratings Yet)

Loading...

Posted in hardware, linux | No Comments »