X4SD Operation Automation
The X4SD USB 2.0 SD Card Reader allows simultaneous access to four SD Card style media including miniSD and microSD in adapters and MultiMediaCard and its derivatives. The unit can be deployed as a card duplicator, since it presents all inserted cards simultaneously. This document is intended to provide users with ideas for deployment, but leaves the precise details of implementation up to the reader.
While it would be common for users to initiate file copies to the X4SD's individual slots manually in XFCE's Thunar, Mac OS X's Finder, or Windows' Explorer, we believe automating the process is the optimal method. To this end, we've explored a few ways to do this. First, we wrote a sample shell script that does the same thing without the benefit of visual feedback. Next, we created an example multi-threaded AppleScript that allows visual feedback of the file copies. Modifications would be required for it to be an actual production script. Last, we reproduce an article which discusses using the X4SD for creating byte-for-byte (binary images) copies of SD Cards via the Unix dd command line tool.
X4SD File Copy Shell Script
The following example shell script forks a separate process for copying to each of the X4SD's individual slots. The downsides to this script are that there is no visual feedback as to the progress of the forked processes or as to their status. We ran the top command in a separate terminal in order to watch the progress of each cp process. Removing the reader or inserted SD media before copies complete can cause a variety of problems, including corrupting the media. Forking from a shell script also has the disadvantage of not letting us see the exit results of the processes. Better parallelism and execution feedback are left as an exercise to the reader, GNU parallel and PRLL are suggested starting places. The script's ending comment provides information for converting it to sequential execution, which increases runtime significantly. The destination (target) path in this example uses Mac OS X naming conventions, see Determining Media Paths for how these mounts appear in OpenBSD and Xubuntu.
#!/bin/sh
TESTFILE="/Users/rds/Desktop/testfile680mb.m4v";
cp $TESTFILE /Volumes/NO\ NAME &
cp $TESTFILE /Volumes/NO\ NAME 1 &
cp $TESTFILE /Volumes/NO\ NAME 2 &
cp $TESTFILE /Volumes/NO\ NAME 3 &
# replace ampersands and preceding spaces with a
# semicolons for sequential execution
X4SD File Copy Multi-threaded AppleScript
Mac OS X users uncomfortable with using the built-in unix terminal do have the option of using AppleScript with the X4SD. This example takes advantage of the Mac OS X Finder's multi-thread capabilities and provides the added benefit of visual feedback of the copies and error dialogs in the case of problems. The illustration shows the simultaneous copies occurring in the foreground with a version of the script in the Script Editor in the background.
tell application "Finder"
ignoring application responses
duplicate "G5:testfile680mb.m4v" to "G5:Volumes:NO NAME" replacing yes
duplicate "G5:testfile680mb.m4v" to "G5:Volumes:NO NAME 1" replacing yes
duplicate "G5:testfile680mb.m4v" to "G5:Volumes:NO NAME 2" replacing yes
duplicate "G5:testfile680mb.m4v" to "G5:Volumes:NO NAME 3" replacing yes
end ignoring
end tell
X4SD SD Card Duplication Example
The following has been reproduced with permission from Using Synchrotech's X4SD USB 2.0 SD Card Reader Four (4) Slot for SD Card duplication.
There's various ways to do do device duplication or byte-for-byte copies of media. Whether we're duplicating CD-ROMs, hard drive disks, SRAM PC Cards, or other removable media, the Unix dd is frequently preferred for these types of operations. While we can execute card to card duplications from one X4SD slot to another, the most common use for the reader is to write an existing SD Card image to all four slots simultaneously. To that end we'll create a binary image of a master SD Card and then use that master to write to blank cards.
Creating an image of the SD Card
dd works with block devices, so we need to unmount the SD Card. To make this simple, we'll be using just one of the X4SD slots at this stage. We'll be using Mac OS X for our example and detail the difference for OpenBSD and Xubuntu. First, we need to identify the mount point of the inserted card. Calling mount in the terminal shows us the information we need (we're leaving out the rest of the output here).
/dev/disk1s1 on /Volumes/NO NAME (local, nodev, nosuid)
We use that information to unmount the mounted device.
[kyoto:~/Desktop] rds% sudo diskutil unmount /Volumes/NO\ NAME
Volume /Volumes/NO NAME unmounted
OpenBSD and Xubuntu would use umount /[devicepath]. Using the block device reference to the X4SD slot, we can copy the card to a binary file using dd.
[kyoto:~/Desktop] rds% sudo dd if=/dev/disk1s1 of=sdcard.bin
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)
Writing the image to SD Cards
Inserting a new card into the X4SD, then unmounting it, we can create a duplicate of the original. We then test it using cmp to see if it is identical to the binary file.
[kyoto:~/Desktop] rds% sudo dd if=sdcard.bin of=/dev/disk1s1
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)
[kyoto:~/Desktop] rds% cmp /dev/disk1s1 ~/Desktop/sdcard.bin
[kyoto:~/Desktop] rds%
Here we write to all four slots simultaneously on a Xubuntu machine. It's feasible that using hubs and multiple X4SD, we could write to more than four cards at once on a machine with enough CPUs/CPU cores. However, there's a practical limit to the amount of I/O operations one would want to run at the same time. Perhaps writing to each bank of cards sequentially would be the best practice? Since I was only provided a single test unit, that remains an academic question.
rds@okinawa-lin2:~$ sudo dd if=sdcard.bin of=/dev/sdc1 & \
&& dd if=sdcard.bin of=/dev/sdd1 & \
&& dd if=sdcard.bin of=/dev/sde1 & \
&& dd if=sdcard.bin of=/dev/sdf1 &
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 270.799 s, 3.7 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 423.987 s, 2.4 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 775.1 s, 1.3 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 860.479 s, 1.2 MB/s
Appendices
Determining Media Paths
Here's the abridged results of running mount on our various test systems with the X4SD plugged in and all four of its slot occupied. This output will look different based on what's connected to an individual system.
OpenBSD
sd0i on /mnt/s1 type msdos (local)
sd1i on /mnt/s2 type msdos (local)
sd2i on /mnt/s3 type msdos (local)
sd3i on /mnt/s4 type msdos (local)
Xubuntu Linux
/dev/sdd1 on /media/BF2C-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdf1 on /media/02A3-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sde1 on /media/3A3A-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdc1 on /media/5AED-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
Mac OS X
/dev/disk2s1 on /Volumes/NO NAME 3 (local, nodev, nosuid)
/dev/disk4s1 on /Volumes/NO NAME 2 (local, nodev, nosuid)
/dev/disk3s1 on /Volumes/NO NAME (local, nodev, nosuid)
/dev/disk1s1 on /Volumes/NO NAME 1 (local, nodev, nosuid)
Our Test Systems
Here's the results of running uname -a on our various test systems.
OpenBSD okinawa-bsd2.my.domain 5.1 GENERIC.MP#207 amd64
Linux okinawa-lin2 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
Darwin kyoto 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
Code example disclaimer
Synchrotech grants you a nonexclusive copyright license to use all programming code examples from which you can generate similar function tailored to your own specific needs.
All sample code is provided by Synchrotech for illustrative purposes only. These examples have not been thoroughly tested under all conditions. Synchrotech, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
All programs contained herein are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.
The FireNEX-COAX-S800 uses flexible coaxial cabling to provide reliable FireWire 800 transmission up to 60 meters (196 feet). There are several advantages in using a standard 75 Ohm coax cable, like wide availability, excellent EMC performance, low cost connections, enabling of terminations by end users, and the possibility of using existing cabling infrastructure. Since each FireNEX-COAX-S800 repeater has two IEEE 1394b FireWire 800 ports it can also be used as a hub for daisy chain connections.
The FMJ USB 10-Pin Module
The ACR122U NFC Reader
The DisplayPort to 2-Port DisplayPort (DPD200) or HDMI (DPH200) Graphics Splitter Adapters
Orico's latest portable SuperSpeed USB 3.0 Hub series
You do need to change some Settings in order to get the 
