From time to time, there are people contacting me asking about how they can read the export files from AndSafe.
So here it is. A quick hack put together with PyQt5: https://github.com/kitsook/PyAndSafe.
Sunday, October 7, 2018
Monday, June 4, 2018
Measuring film camera shutter speed with Beaglebone Black
Here is a simple circuit utilizing the ADC input on Beaglebone Black to measure camera shutter speed.
A photoresistor is used to detect the light when shutter open, and hence changing the values read by ADC pin P9_40. The push button is used to trigger the Python script to start reading the ADC input.
Testing on breadboard and the final build on through-hole board:
Note that this is by no mean an accurate measure of absolute shutter speed. The response time (rise/fall) of photoresistor will affect the result (see the graph below). Nevertheless, it is useful to compare different shutter speeds.
Source code is available on Github.
Quick start:
Plot the output using gnuplot:
Here is an example output of measuring 1/15 and 1/8 shutter speeds of my Pentax MX.
A photoresistor is used to detect the light when shutter open, and hence changing the values read by ADC pin P9_40. The push button is used to trigger the Python script to start reading the ADC input.
Testing on breadboard and the final build on through-hole board:
Note that this is by no mean an accurate measure of absolute shutter speed. The response time (rise/fall) of photoresistor will affect the result (see the graph below). Nevertheless, it is useful to compare different shutter speeds.
Source code is available on Github.
Quick start:
git clone https://github.com/kitsook/bbb-adc-measure cd bbb-adc-measure python3 -m venv venv . venv/bin/activate pip install -r requirements.txt python adc-measure.py -t 10 > result.csv
Plot the output using gnuplot:
gnuplot set mxtics 10 set grid plot 'result.csv' with lines
Here is an example output of measuring 1/15 and 1/8 shutter speeds of my Pentax MX.
Saturday, May 12, 2018
openSUSE Tumbleweed boot problem
After recent update (20180502) of openSUSE Tumbleweed, my machine failed to boot. A quick check in the dracut emergency shell seems to indicate that somehow the root volume is mounted as /kdump/mnt0 and so cannot be mounted as root again.
Here is a quick fix.
Boot the system with LiveCD or any emergency tool. Mount the Tumbleweed system (here I mounted it under /mnt/temp). Go to the boot directory and find the initrd file. We are going to extract and modify the fstab inside.
Now, repackage the initrd file
The original boot/initrd should be a symbolic link to the current kernel version. Remove it and point it to the modified initrd
Sync, umount, and reboot. There will be error messages saying /kdump/mnt0 can't be mounted but at least the system can boot up.
Here is a quick fix.
Boot the system with LiveCD or any emergency tool. Mount the Tumbleweed system (here I mounted it under /mnt/temp). Go to the boot directory and find the initrd file. We are going to extract and modify the fstab inside.
cd /mnt/temp/boot mkdir initrd-mod cd initrd-mod /usr/lib/dracut/skipcpio ../initrd > initrd.xz xz -d initrd.xz cpio -idv < initrd cd etc # edit the fstab file, comment out the mount of /kdump/mnt0 vi fstab
Now, repackage the initrd file
cd /mnt/temp/boot/initrd-mod find . 2>/dev/null | cpio --quiet -c -o | xz -9 --format=lzma >"../initrd-mod.img" chmod go-r ../initrd-mod.img
The original boot/initrd should be a symbolic link to the current kernel version. Remove it and point it to the modified initrd
cd /mnt/temp/boot rm initrd ln -s initrd-mod.img initrd # Depends on your setup, you probably also need to # backup and link specific kernel version of initrd. e.g. # mv initrd-4.16.6-1-default initrd-4.16.6-1-default.bak # ln -s initrd-mod.img initrd-4.16.6-1-default
Sync, umount, and reboot. There will be error messages saying /kdump/mnt0 can't be mounted but at least the system can boot up.
Tuesday, April 24, 2018
SSL connections with RTL8710
If you tried to compile any SSL example (e.g. WiFiSSLClient) that comes with Ameba Arduino, you will probably get an error saying "RTL8710 do not support SSL".
Some people say it is because RTL8710 is not powerful enough (!?) to handle SSL. But in fact, you edit the gcc linker blacklist file to get around it. On Linux, the file is probably at
~/.arduino15/packages/realtek/hardware/ameba/2.0.4/variants/rtl8710/linker_scripts/gcc/symbol_black_list.txt
The original file contains:
You can see that the RAM table referenced by SSL ROM is being blacklisted. Make a backup of the file and delete the first line.
Tried to compile WiFiSSLClient and it works properly on my RTL8710.
Some people say it is because RTL8710 is not powerful enough (!?) to handle SSL. But in fact, you edit the gcc linker blacklist file to get around it. On Linux, the file is probably at
~/.arduino15/packages/realtek/hardware/ameba/2.0.4/variants/rtl8710/linker_scripts/gcc/symbol_black_list.txt
The original file contains:
rom_ssl_ram_map RTL8710 do not support SSL analogReadResolution RTL8710 do not support ADC analogRead RTL8710 do not support ADC
You can see that the RAM table referenced by SSL ROM is being blacklisted. Make a backup of the file and delete the first line.
Tried to compile WiFiSSLClient and it works properly on my RTL8710.
Sunday, April 22, 2018
Sony SRS-XB30 and WH-H800 supported codecs
For reference, here is the negotiation traffic captured when connecting to a Sony SRS-XB30 bluetooth speaker.
By comparison, here is info when connecting a Sony WH-H800 Wireless Headphones:
localhost:~> sudo hcidump avdtp HCI sniffer - Bluetooth packet analyzer ver 5.49 device: hci0 snap_len: 1500 filter: 0x400 < AVDTP(s): Discover cmd: transaction 14 nsp 0x00 > AVDTP(s): Discover rsp: transaction 14 nsp 0x00 ACP SEID 1 - Audio Sink ACP SEID 2 - Audio Sink ACP SEID 3 - Audio Sink < AVDTP(s): All Capabilities cmd: transaction 15 nsp 0x00 ACP SEID 1 > AVDTP(s): All Capabilities rsp: transaction 15 nsp 0x00 Media Transport Media Codec - SBC 16kHz 32kHz 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-53 Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 0 nsp 0x00 ACP SEID 2 > AVDTP(s): All Capabilities rsp: transaction 0 nsp 0x00 Media Transport Media Codec - MPEG-2,4 AAC MPEG-2 AAC LC 44.1kHz 48kHz 1 2 Channels 0bps VBR Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 1 nsp 0x00 ACP SEID 3 > AVDTP(s): All Capabilities rsp: transaction 1 nsp 0x00 Media Transport Media Codec - non-A2DP (LDAC) 3C 07 Content Protection 02 00 Delay Reporting < AVDTP(s): Set config cmd: transaction 2 nsp 0x00 ACP SEID 1 - INT SEID 1 Media Transport Media Codec - SBC 44.1kHz JointStereo 16 Blocks 8 Subbands Loudness Bitpool Range 2-53 > AVDTP(s): Set config rsp: transaction 2 nsp 0x00 > AVDTP(s): Delay Report cmd: transaction 0 nsp 0x00 ACP SEID 1 delay 240.0ms < AVDTP(s): Open cmd: transaction 3 nsp 0x00 ACP SEID 1 < AVDTP(s): Delay Report rsp: transaction 0 nsp 0x00 > AVDTP(s): Open rsp: transaction 3 nsp 0x00
By comparison, here is info when connecting a Sony WH-H800 Wireless Headphones:
localhost:~> sudo hcidump avdtp HCI sniffer - Bluetooth packet analyzer ver 5.49 device: hci0 snap_len: 1500 filter: 0x400 < AVDTP(s): Discover cmd: transaction 8 nsp 0x00 > AVDTP(s): Discover rsp: transaction 8 nsp 0x00 ACP SEID 1 - Audio Sink ACP SEID 5 - Audio Sink ACP SEID 6 - Audio Sink ACP SEID 3 - Audio Sink ACP SEID 2 - Audio Sink < AVDTP(s): All Capabilities cmd: transaction 9 nsp 0x00 ACP SEID 1 > AVDTP(s): All Capabilities rsp: transaction 9 nsp 0x00 Media Transport Media Codec - SBC 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-53 Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 10 nsp 0x00 ACP SEID 5 > AVDTP(s): All Capabilities rsp: transaction 10 nsp 0x00 Media Transport Media Codec - non-A2DP (LDAC) 3C 07 Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 11 nsp 0x00 ACP SEID 6 > AVDTP(s): All Capabilities rsp: transaction 11 nsp 0x00 Media Transport Media Codec - non-A2DP (Unknown) 32 00 00 00 00 Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 12 nsp 0x00 ACP SEID 3 > AVDTP(s): All Capabilities rsp: transaction 12 nsp 0x00 Media Transport Media Codec - non-A2DP (aptX) 44.1kHz 48kHz Stereo Content Protection 02 00 Delay Reporting < AVDTP(s): All Capabilities cmd: transaction 13 nsp 0x00 ACP SEID 2 > AVDTP(s): All Capabilities rsp: transaction 13 nsp 0x00 Media Transport Media Codec - MPEG-2,4 AAC MPEG-2 AAC LC MPEG-4 AAC LC 44.1kHz 48kHz 1 2 Channels 320000bps VBR Content Protection 02 00 Delay Reporting < AVDTP(s): Set config cmd: transaction 14 nsp 0x00 ACP SEID 1 - INT SEID 1 Media Transport Media Codec - SBC 44.1kHz JointStereo 16 Blocks 8 Subbands Loudness Bitpool Range 2-53 > AVDTP(s): Set config rsp: transaction 14 nsp 0x00 < AVDTP(s): Open cmd: transaction 15 nsp 0x00 ACP SEID 1 > AVDTP(s): Open rsp: transaction 15 nsp 0x00
Monday, April 16, 2018
glibc broken on openSUSE Tumbleweed aarch64 201803
The glibc on Tumbleweed was broken since the March 2018 release. Any call to resolve IPv4 will cause core dump. Seems to be hitting an ARM erratum. Details discussion can be found here.
The glibc RPMs released on 2018-04-10 seems resolved the issue. Since DNS won't work on the affected machine, will need to manually specify IP addresses in the hosts file or copy the files to the machine and run zypper to install updates.
Here are the steps for the second approach:
- Download the RPMs from repository to another machine
- Copy the files to the affected machine via scp. Then remote to the affected machine and execute the followings.
- Temporarily disable remote repositories to avoid auto refresh that will cause core dump when running zypper install.
- Install the RPMs
The glibc RPMs released on 2018-04-10 seems resolved the issue. Since DNS won't work on the affected machine, will need to manually specify IP addresses in the hosts file or copy the files to the machine and run zypper to install updates.
Here are the steps for the second approach:
- Download the RPMs from repository to another machine
glibc-2.27-4.2.aarch64.rpm
glibc-devel-2.27-4.2.aarch64.rpm
glibc-extra-2.27-4.2.aarch64.rpm
glibc-locale-2.27-4.2.aarch64.rpm
- Copy the files to the affected machine via scp. Then remote to the affected machine and execute the followings.
- Temporarily disable remote repositories to avoid auto refresh that will cause core dump when running zypper install.
sudo zypper lr # list repositories
sudo zypper mr -d 1 # disable the first repository
sudo zypper mr -d 2 # disable the rest
......
- Install the RPMs
sudo zypper in glibc-2.27-4.2.aarch64.rpm glibc-devel-2.27-4.2.aarch64.rpm glibc-extra-2.27-4.2.aarch64.rpm glibc-locale-2.27-4.2.aarch64.rpm- Re-enable remote repositories
sudo zypper mr -e 1 # re-enable the first repository
sudo zypper mr -e 2 # re-enable the rest
......- Reboot and check. Run "sudo zypper dup" to update other packages
Wednesday, March 28, 2018
Generate noise
Found this interesting post on generating noise using Linux command line. Great way to burn-in headphone?
play -n synth brownnoise synth pinknoise mix synth sine amod 0.3 10
Monday, February 12, 2018
Running Monero miner with Mesa clover
Try to run Monero miner with OpenCL on my old Linux rig. The xmr-stak supports the official AMD APP SDK. But since I only have access to the relatively old hardware (AMD Kabini) running Mesa clover, a quick patch is needed to make it works.
Code changes available on github. Basically the changes are:
(1) add detection for Mesa platform vendor
(2) modify the OpenCL kernel. Mesa clover supports OpenCL 1.1 only. Also, although cl_amd_media_ops and cl_amd_media_ops2 are defined, some functions are missing and need definitions.
Just for reference, on my AMD Kabini 5350, the hash rate on GPU is around 18H/s when running GPU only. Once added CPU mining, the GPU hash rate drops to about 12H/s. And the CPU hash rate is round 28H/s.
This rig definitely not suitable if mining for profit. But OK to support the Monero network.
Config for GPU:
Also note that the radeon module may complain about lockup when executing long running OpenCL kernels. Add "radeon.lockup_timeout=0" Linux kernel parameter to disable the watchdog.
Code changes available on github. Basically the changes are:
(1) add detection for Mesa platform vendor
(2) modify the OpenCL kernel. Mesa clover supports OpenCL 1.1 only. Also, although cl_amd_media_ops and cl_amd_media_ops2 are defined, some functions are missing and need definitions.
Just for reference, on my AMD Kabini 5350, the hash rate on GPU is around 18H/s when running GPU only. Once added CPU mining, the GPU hash rate drops to about 12H/s. And the CPU hash rate is round 28H/s.
This rig definitely not suitable if mining for profit. But OK to support the Monero network.
Config for GPU:
gpu_threads_conf" : [ // gpu: AMD KABINI (DRM 2.50.0 / 4.14.15-2-default, LLVM 5.0.1) memory:1302 // compute units: 2 { "index" : 0, "intensity" : 128, "worksize" : 8, "affine_to_cpu" : true, "strided_index" : true }, ],
Also note that the radeon module may complain about lockup when executing long running OpenCL kernels. Add "radeon.lockup_timeout=0" Linux kernel parameter to disable the watchdog.
Monday, January 29, 2018
User LEDs on Beaglebone Black running FreeBSD
According to the DTS, the GPIO pins for the four user LEDS are pin 21-24 under gpioc1.
So, to turn them on:
Or, access them via the led driver under /dev/led
So, to turn them on:
sudo gpioctl -f /dev/gpioc1 21 1 sudo gpioctl -f /dev/gpioc1 22 1 sudo gpioctl -f /dev/gpioc1 23 1 sudo gpioctl -f /dev/gpioc1 24 1
Or, access them via the led driver under /dev/led
% ls -lA /dev/led total 0 crw------- 1 root wheel 0x33 Feb 3 15:58 beaglebone:green:heartbeat crw------- 1 root wheel 0x34 Feb 3 15:58 beaglebone:green:mmc0 crw------- 1 root wheel 0x35 Feb 3 23:44 beaglebone:green:usr2 crw------- 1 root wheel 0x36 Feb 3 15:58 beaglebone:green:usr3
Thursday, January 18, 2018
Running openSUSE Tumbleweed on Odroid C2
Testing out arm64 with openSUSE Tumbleweed on Odroid C2. The installation is pretty simple. Follow the steps to prepare the micro-sd card. The latest image can be found here.
The device tree of openSUSE seems a bit different from other distributions. e.g.:
- temperature: /sys/devices/platform/scpi/scpi:sensors/hwmon/hwmon0
- blue LED: /sys/devices/platform/leds/leds/c2:blue:alive
The device tree of openSUSE seems a bit different from other distributions. e.g.:
- temperature: /sys/devices/platform/scpi/scpi:sensors/hwmon/hwmon0
- blue LED: /sys/devices/platform/leds/leds/c2:blue:alive
Subscribe to:
Posts (Atom)