Go to your images. Check out the metadata;
exiv2 image.jpg
exiftool image.jpg

Remove the exif data;
exiftool -all= image.jpg
exiftool -all= *

You'll be left with an _original copy. If you don't need them;
rm *_original
◾ Tags:
I had an idea to set up my cubox as an Android station to sync/operate all my bluetooth wearables. But neither the Android image (4.4?!) nor the Ignition installer would boot. Just sat there, glowing a red LED at me. I found their official builds server, and the only image up there for cubox is Debian. Which also doesn't work.

Okay so. *rolls up sleeves in dramatic fashion*

Cuboxes come with serial on by default, over the micro-USB cable.
Find the device name;
sudo dmesg
Connect to serial;
sudo screen /dev/ttyUSB0 1115200
(If you are in Windows it's the same procedure as for Raspberry Pi.)

U-Boot 2009.08-dirty (Jan 21 2013 - 10:57:40) Marvell version: 5.4.4 NQ SR1

BootROM:
       Version on chip: 2.33
       Status: OK
       Retries #: 0
Board: CuBox
SoC:   88AP510 (A1)
CPU:   Marvell Sheeva (Rev 5)
       CPU @ 800Mhz, L2 @ 400Mhz
       DDR3 @ 400Mhz, TClock @ 166Mhz
PEX 0: interface detected no Link.
PEX 1: interface detected no Link.
DRAM:   2 GB
       CS 0: base 0x00000000 size  1 GB
       CS 1: base 0x40000000 size  1 GB
       Addresses 60M - 0M are saved for the U-Boot usage.
SF: Detected W25Q32 with page size  4 kB, total  4 MB

Streaming disabled 
L2 Cache Prefetch disabled
L2 Cache ECC disabled
Modifying CPU/CORE/DDR power rails to 1.0(-2.5%) / 1.0(-5%) / 1.5(-5%)
USB 0: Host Mode
USB 1: Host Mode
Setting VPU power OFF.
Setting GPU power ON.
MMC:   MV_SDHCI: 0, MV_SDHCI: 1
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0 
===> Executing ext4load usb 0:1 0x02000000 /boot.scr
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 1 USB Device(s) found
...
** Unable to use ide 0:2 for fatload **
===> Executing ext4load ide 0:2 0x02000000 /boot/boot.scr
** Bad partition 2 **
===> Executing fatload ide 0:2 0x02000000 /boot/boot.scr
Error No HD connection 
** Can't read from device 0 **

** Unable to use ide 0:2 for fatload **

egiga0 no link
Using egiga0 device
TFTP from server 192.168.15.100; our IP address is 192.168.15.223
Filename 'boot.scr'.
Load address: 0x2000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again


Oh no. The very first line delivers the bad news. This machine is old. Older than I'd thought. Turns out there are two kinds of cubox; Marvell/Armada 510 CPU, and Freescale imx6 cubox-i. The former is the one I have, the latter is the only one currently supported.

As my hardware has been abandoned by the manufacturer I'm left with Kali, Arch, or Geexbox/Kodi.

Kali;
Download cubox version, e.g. kali-2017.3-cubox-i.img.xz
Extract; unxz kali-2017.3-cubox.img.xz
Write; sudo dd if=kali-2017.3-cubox.img of=/dev/sdcard bs=512k
Finally use gparted to expand partition to whole sdcard
And as if by magic, the cubox boots up into Kali! (I find this especially humourous as I recently tried to create a Kali LiveUSB stick for my laptop, and couldn't get it to boot, it appears due to a lack of hardware support.)

It doesn't help me build my Android station, but, thank you Community, for helping keep this hardware from obsolescence.
◾ Tags:
Gizmo can speak (albeit with a new accent), and Gizmo can move, now we have to tie the two together so they only move when they speak. And it's all software.

Again, we're following an adapted version of Furlexa project.

First we need a python script, a more structured version of the motor/motor.py from Part 3. Separate the parts into setup(), start_furby(), and stop_furby(), and add a main(). We'll also need the sound device status file path from Part 2, /proc/asound/card0/pcm0p/sub0/status.

furby.py )

This script only sets the motors in motion (or stops them) based on the current state of the status file when invoked, and exits. It doesn't keep running while the motors do.

In order to keep track of the changes of the status file a monitor script is needed. (And because we made the changes to PulseAudio in Part 2 the status will actually change.)
output-monitor.sh )

Make the script executable with chmod +x output-monitor.sh, and run with ./output-monitor.sh. Then make some sounds in another ssh session. There you go, singing, dancing, Gizmo!


But hey, wouldn't it be nice to make this Gizmo's default behaviour without having to invoke it every time? Let's get it to run at startup. We're going to set it up with systemd as described here.

systemd )

Reboot to pickup changes. And finally, Furby/Gizmo is all singing, all dancing.

(Small caveat; Furby/Gizmo will do a little shimmy with every pop/click out of the speaker.)

You can install Alexa if you want, I won't be. I do have other plans to extend the project a bit but this is the bulk of the project, and plenty to freak your friends out. Bonus, you don't even have to close up and re-skin Furby/Gizmo. Don't believe me? Have a look for yourself.


Part 1 | Part 2 | Part 3 | Part 4
After disassembling Gizmo I found I needed to remove, and discard, some stuff.

Details and pictures )

Now, some assembly; the brain transplant.

Brain wiring )

Brain programming )


Part 1 | Part 2 | Part 3 | Part 4
I spent way too long trying to build a solution out of parts I had readily available before I discovered that Adafruit had exactly the thing I needed: the piOLED, tiny screen to attach to my Raspberry Pi Zero W. One of the examples even included what I was after; a way to display the ip address, in stats.py.

The script doesn't exit as cleanly as I'd like, so the first thing is to put the while True: loop into a try: and put the cleanup in the catch:
except KeyboardInterrupt:
    disp.clear()
    disp.display()


The tutorial also has instructions on how to run the script on startup; by putting it in rc.local
sudo vim /etc/rc.local
And add the call to the script, before exit 0, pushing it into the background;
sudo python /home/pi/Adafruit_Python_SSD1306/examples/stats.py &
Save and exit.

Cool, now we have a way to display the ip address of the pi so we can ssh in. But, there is nothing to turn it off again.

First thing needed is a python script to blank the screen. You can take a copy of stats.py and strip out everything except the setup code and the cleanup code. Cool, this works, kinda. It clears for a moment and then starts displaying again. This is because we haven't killed the processes doing that yet.

So, we write a script to do that. (Here I ran into some dash versus bash problems. Damn you dash, damn you.)
Something like;
#/bin/sh

pids=$(ps -ef | grep 'python .*examples/stats.py' | awk '{print $2}')

echo $pids | while read -r line;
do
    sudo kill -9 $line
done

sudo python /home/pi/Adafruit_Python_SSD1306/examples/blank.py


Great, this works wonderfully, when we manually invoke it. We're going to want it to run at shutdown too though. (Because, while power is still supplied to the pi, even though it's off, and the screen isn't updating, the old data is still displaying.)

This is not as easy as it should be. I basically wanted a rc-local for shutting down. I'm not the only person who has had this idea, so have a look here for a way to add shutdown functionality to rc-local.

Summary;
* Copy /etc/rc.local to /etc/rc.local.stop
* Edit /etc/init.d/rc.local, adding in extra info to # Required-Stop:, # Default-Stop:, edit the case statement to call do_stop in event of stop), and add the do_stop function (which is a copy of the do_start function changed to point at rc.local.stop).
* Delete the old rc-local daemon; sudo update-rc.d -f rc.local remove
* Pick up the new; sudo update-rc.d rc.local defaults

But, this alone isn't enough for Debian/Raspbian to pick up the changes. Enter systemd.
sudo vim /lib/systemd/system/rc-local.service
And add this line just after ExecStart;
ExecStop=/etc/rc.local.stop stop
Save and exit.

Now, stop the daemon, reload it, and then start it.
sudo systemctl stop rc-local
sudo systemctl daemon-reload
sudo systemctl start rc-local


One final thing, edit rc.local.stop to use the stop script instead of the start one. And don't push it to the background. Something like;
sudo /home/pi/Adafruit_Python_SSD1306/examples/kill_SSD1306.sh

Finally, when you reboot, startup, and all the other fun things the screen should behave nicely. Enjoy.
Okay. Hi. Yes, I'm still here. It's been an eventful err, many months. But more about that another time. Maybe.

Well, either that, or, I only post once in a Blue Moon! (Sorry, couldn't resist.)

Last year at EMF I picked up a BeagleBone Black (rev C). This week I actually unpacked it and powered it up. I was pleasantly surprised to find that the rev C ships with Debian installed, but that means most of the documentation online (and on the BBB) is slightly out of date. No worries; things are actually simpler now!

Even though it shipped with Debian when I tried to apt-get update/upgrade/install I got errors. So there was only one thing for it; flash the onboard memory. When I went about this I found that the source of online documentation was (is?) offline. And the wayback machine was only serving up some too-old files. Luckily I found a chap with a link to the most recent eMMC flasher image! I've said it before, and I'll say it again, yay for bloggers!

One thing that tripped me up; when writing the image to the SD card, on Windows you need to run the program As Administrator for sufficient privileges. Learn from my mistakes friends. Also, only hold down the SD button until the 4-LEDs start to flash, then let go. The rest is smooth sailing.

When you boot up, you ssh in (over the USB cable); as root, with no password. Set one immediately! Then you do all the usual configuration things;
set a nice hostname - vim /etc/hostnames, vim /etc/hosts
add a non-root user - adduser, visudo
setup wireless - vim /etc/network/interfaces (unfortunately it involves hardcoding your password)

(I got a raspberry pi wireless dongle to use with my cubox, and now my BBB. Poor thing has never meet a raspberry pi. ... Speaking of the cubox; arch linux turned out to be just too much effort. Will probably throw Debian on there as well.)

Then reboot, and if ifconfig doesn't show an ip-address try ifup wlan0. Once online apt-get update, apt-get upgrade. And just like that you have a fully functioning Debian server (with broken out physical pins) to bend to your will. I have to say, it is one of the easiest setups I have encountered with microcontrollers/embedded systems. And a good first impression means a lot. I look forward to playing with it more.

*edit 2015-09-16*
Setting up my second BBB was far more troublesome! I finally got it working; using dd in linux, onto an 8gb micro sdcard (my 4gb must have a .1 or .2 too small), and even though the file (from here) is named 2015-03-01 the installation reports 2015-07-17. Curiouser and curiouser.
I've always wanted my own server. Although I haven't exactly had much need for one. Then I heard about these little beauties; the CuBox (or rather one with the older chipset). For some scale here it is next to a 250ml teapot and a one-Euro coin.

CuBox next to a 250ml glass teapot and one-Euro coin

Just too cute
Photo by chebe



It arrived with Ubuntu (10.04!) installed, which would just not do. So I copied all the cool kids and installed Arch linux on it. For that extra-low-level feel. I actually used the CuBox installer, which was very simple to use. But Arch is very stripped down, so I then had the fun of installing all the things I normally take for granted. Like vim, and sudo. Though to be fair, once I figured out that the package manager was called pacman, and an update is just pacman -Syu, things got much easier.

I've configured it up as a DNS server, and installed this dotey USB wifi dongle. So now it can sit happily next to the power socket (all the other cables unplugged), and I can ssh in to it. I'm still not sure what, if anything, I need it for, but at the very least I'm going to play around with mongodb and django for a bit.
◾ Tags:
"Why do you still care about dual booting? Why don't you just run everything in a VM?"

I gave it a go, I really did. Created a Ubuntu 1110 vm in VirtualBox. Fixed storage size, everything was going well enough. (Ubuntu has a problem with my wireless card, but that's almost traditional at this point.) I was using it for college work so I needed stability and didn't upgrade for a while. Too long it seems. When I went to upgrade the repos had vanished, and for added benefit, the vm lost the ability to use any network connection.

I noticed VirtualBox had an update, and thought, maybe they'll have better drivers. But instead the vm wouldn't even start. I attempted to mount the .vdi filesystem. Discovered the way I knew only worked with Windows vms, but found another method using guestmount. So I mount with guestmount, but seemingly my /home no longer exists!

Frustrated I try running the vm again, and for some unknown reason it actually starts, but the graphics crash and die leaving me with a text-only terminal. Grand, as soon as I remembered my password. I log in, and right there is my /home! I quickly copy everything to a previously set-up shared folder in the host, and exit.

VirtualBox says there's another update available. So I update, and now the vm won't run again, giving me error messages about something disabled in the BIOS. I should have known better.

And this is just another reason why I dislike virtual machines. (And before you start, it's not just VirtualBox, I've had even more problems with VMWare.)
◾ Tags:
I bought a touchatag ages ago, but couldn't get it installed properly under linux (and when I got it working under Windows the supplied software required that I create an account, which I really dislike). It's no longer available to purchase (except perhaps through resellers with old stock), but it is a RFID-tag reader (that came with a few RFID-tags) and was part of the 'Internet-of-Things' effort. Although anyone I know who has one didn't get it for that reason. It lay gathering dust in the back of my mind until I suddenly had a project idea. But first, I had to get the darned thing to work!

Here's how I went about it under Fedora 18.

Pre-requisites (you probably don't need all these, but I have ambitions);
yum install pcsc-*
yum install libusb libusb-devel
yum install libnfc*


Install the driver;
wget http://www.acs.com.hk/drivers/eng/ACR122_Driver_Lnx_Mac10.5_10.6_10.7_104_P.zip
unzip ACR122_Driver_Lnx_Mac10.5_10.6_10.7_104_P.zip
cd ACR122_Driver_Lnx_Mac10.5_10.6_10.7_104_P/
tar -jxvf acsccid-1.0.4.tar.bz2
cd acsccid-1.0.4/
./configure
make


Check it's working;
lsusb
Lists it as Advanced Card Systems, Ltd.

nfc-list
It should list your reader, if not, try pcsc_scan, if still no luck run pcscd -f.
If at this point it's complaining that your firmware is bogus you need to edit the config file to skip the version checking, for me the file path is;
vim /usr/lib64/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist

Locate "ifdDriverOptions" and turn the "0x0000" value into 0x0005 (0x0004 might work too). Save and exit, then restart the daemon. I had trouble getting it back up again, so I rebooted.

Run the checks again to see that it is now picking up the device properly.

Use it;
This varies greatly depending on what you want to do. One of the alternatives recommended on the touchatag site is iotope. I downloaded it (to run in standalone node mode), unzipped, and ran the bash script provided (it's Java based). Then you open a browser and go to http://localhost:4242/ui/. Then simply put a RFID-tag in the reader and (if compatible) see the details show up.


I pieced together this information from two sources;
1. An archlinux wiki page which suggests another application, and
2. A backtrack linux page that suggests an entirely different application and use.

This is probably old-hat to those of you it interests, but I've finally gotten it to work, so I'm putting it here against my forgetting in future.
◾ Tags:
I got a Huawei E173 internet dongle today, and was surprised to find that only Windows and MacOS were supported (I'm not sure why, maybe I just haven't bought any new tech in a long time). But I persevered.

Fedora 15 & 16;
Plug in device, and NetworkManager will (after a while) automatically pick it up. Turn on 'Mobile Broadband', click on the clickable option below it and you'll be brought through the wizard (insert PIN, select provider, plan type (i.e. contract or prepay), etc). Done.

Fedora 14;
Not so easy. Plug in device and it's only getting picked up as removable storage.
You need two packages from the official repos; libusb-devel and usb_modeswitch
Once installed the device gets picked up properly by NetworkManager. Select it from the 'Mobile Broadband' section and go through the wizard. Done.

All in all, not too bad. And actually faster than installing the .exe under Windows 7. (Note, the Ubuntu package names seem to be libusb-dev and usb-modeswitch.)
◾ Tags: