Applied FreeBSD: Basic iSCSI

iSCSI is often touted as a low-cost replacement for fibre-channel (FC) Storage Area Networks (SANs). Instead of having to setup a separate fibre-channel network for the SAN, or invest in the infrastructure to run Fibre-Channel over Ethernet (FCoE), iSCSI runs on top of standard TCP/IP. This means that the same network equipment used for routing user data on a network could be utilized for the storage as well. In practice, to get high-levels of performance, it is advised that system designers consider iSCSI Host Bus Adaptors (HBAs) for each iSCSI participating team, and that the network at a minimum have a separate VLAN for iSCSI traffic–or more ideally, have separate physical network.

My disclaimer: this article does not cover any of the above performance enhancements! The systems in this article are setup and configured in a VMWare Workstation virtualized environment so that I don’t have to physically procure all of the hardware just to learn about iSCSI.

This article will cover a very basic setup where a FreeBSD server is configured as an iSCSI Target, and another FreeBSD server is configured as the iSCSI Initiator. The iSCSI Target will export a single disk drive, and the initiator will create a filesystem on this disk and mount it locally. Advanced topics, such as multipath, ZFS storage pools, failover controllers, etc. are not covered.  Please refer to the following documentation on iSCSI for more information:

Now to get started…

iSCSI Target Test Setup

The disk drive which should be shared on the network is /dev/ada0, a 5G SATA disk created in VMWare that I attached to the system before starting it up. With FeeBSD, iSCSI is controled by the ctld daemon, so this needs to be enabled on the system. While at it, why not go ahead and enable it at boot time too?

root@bsdtarget:~ # echo ‘ctld_enable=”YES”‘ >> /etc/rc.conf
root@bsdtarget:~ # service start ctld
Starting iscsid.

The real magic is the /etc/ctl.conf file, which contains all of the information necessary for ctld to share disk drives on the network. Check out the man page for /etc/ctl.conf for more details; below is the configuration file that I created for this test setup. Note that on a system that has never had iSCSI configured, there will be no existing configuration file, so go ahead and create it.

root@bsdtarget:/dev # less /etc/ctl.conf
auth-group test{
chap “iscsitest” “bsdforthewin”

portal-group pg0 {
discovery-auth-group no-authentication

target iqn.2017-02.lab.testing:basictarget {
auth-group no-authentication
portal-group pg0
lun 0 {
path /dev/ada0
size 5G
lun 1 {
path /dev/ada1
size 5G

For this setup, LUN 0 will be used by a FreeBSD iSCSI Initiator. I have LUN 1 configured for experimenting with Windows Server at a later time. Before starting ctld, it is a good idea to make sure that the /etc/ctl.conf file is not readable by all users (ctld will complain). At a later point it might be necessary to add iSCSI authentication for the sessions, and it would not be wise to have all users able to look at the authentication secret password.

root@bsdtarget:~ # chmod 640 /etc/ctl.conf
root@bsdtarget:~ # service start ctld

If there are any syntax errors or warnings, ctld will complain about it on the console. The ctladm tool can be used to query the system for more information, for example:

root@bsdtarget:/dev # ctladm lunlist
(7:0:0/0): <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
(7:0:1/1): <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
root@bsdtarget:/dev # ctladm devlist
LUN Backend Size (Blocks) BS Serial Number Device ID
0 block 10485760 512 MYSERIAL 0 MYDEVID 0
1 block 10485760 512 MYSERIAL 1 MYDEVID 1


That’s really it for the iSCSI Target configuration. The real effort is in setting up the /etc/ctl.conf file. And for a real production system, there would be more configuration with the exported disks, such as using ZFS shares, RAID-1 mirroring, et cetera.

iSCSI Initiator Test Setup

In order for a FreeBSD host to become an iSCSI Initiator, the iscsd daemon needs to be started. It doesn’t hurt to go ahead and add the instruction to /etc/rc.conf so that iscsid is started when the system comes up.

root@bsdinitiator:~ # echo ‘iscsid_enable=”YES”‘ >> /etc/rc.conf
root@bsdinitiator:~ # service start iscsid
Starting iscsid.

Next, the iSCSI Initiator can manually connect to the iSCSI target using the iscsictl tool. While setting up a new iSCSI session, this is probably the best option. Once you are sure the configuration is correct, add the configuration to the /etc/iscsi.conf file (see man page for this file). For iscsictl, pass the IP address of the target as well as the iSCSI IQN for the session:

root@bsdinitiator:~ # iscsictl -A -p -t iqn.2017-02.lab.testing:basictarget

The command returns silently, but a look at /var/message/logs shows that the remote disk was recognized and is now recognized by the Initiator as /dev/da1.

da1 at iscsi3 bus 0 scbus34 target 0 lun 0
da1: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number MYSERIAL 0
da1: 150.000MB/s transfers
da1: Command Queueing enabled
da1: 5120MB (10485760 512 byte sectors)

The iSCSI session connection status can also be verified with iscsictl:

root@bsdinitiator:~ # iscsictl -L
Target name                                                 Target portal          State
iqn.2017-02.lab.testing:basictarget       Connected: da1

Once the disk is recognized by the iSCSI Initiator system, it can be configured for use on the Initiator like a regular SCSI/SATA disk attached to the system physically. The commands below create a partition and UFS filesystem on /dev/da1.

root@bsdinitiator:~ # gpart create -s gpt /dev/da1
root@bsdinitiator:~ # gpart add -t freebsd-ufs -l 1m /dev/da1
root@bsdinitiator:~ # newfs -U /dev/da1p1
/dev/da1p1: 5120.0MB (10485688 sectors) block size 32768, fragment size 4096
using 9 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112
root@bsdinitiator:~ # mkdir /iscsi_share
root@bsdinitiator:~ # mount -t ufs -o rw /dev/da1p1 /iscsi_share

If there is already a filesystem resident on the device, it only needs to be mounted after the iSCSI session is connected. Back on the iSCSI Target machine, it is possible to see all of the iSCSI Initiators connected

root@bsdtarget:/dev # ctladm islist
ID   Portal                   Initiator name                                                 Target name
6      iqn.2017-02.lab.testing:basictarget

Finally, if for some reason it is necessary to disconnect the system, unmount the filesystem and use iscsictl to disconnect the iSCSI session.

root@bsdinitiator:~ # umount /iscsi_share
root@bsdinitiator:~ # iscsictl -R -t iqn.2017-02.lab.testing:basictarget

There is much more to explore with iSCSI, this is just the very beginning, but it serves a a model and a starting point for this work. More to come in the future!

Update: Windows iSCSI Initiator

I am not a very savvy Windows user, and I am very new to Windows Server. I have just started to learn some of the basics. As such, I thought I’d try setting up a Windows Server 2016 host as an iSCSI Initiator. I won’t go into much detail other than what is required for setting up the iSCSI parts. Go ahead and fire up Server Manager.


From the “Tools” menu, select iSCSI Initiator. It is also possible to start this application from the Windows search tool by searching for “iSCSI Initiator”. As shown below, when running it for the first time, Microsoft’s iSCSI service may not be running. If not, start it up!initiator2

There are many options for configuring the iSCSI Initiator, but for demonstration purposes we’ll cover the basic case. In the Target box, enter the IP address of the iSCSI Target machine and click on the Quick Connect button.


A screen should pop-up window finding the IQN for the iSCSI Target service, and it should also state somewhere that the Login was successful.


After closing out the pop-up window, the target should now be in the Discovered targets area of the Targets tab.


Next go to the Volumes and Devices tab. Unless you know the exact mount point for the iSCSI volume, the best bet is to click the Auto Configure button which will get the data from the iSCSI Target, as shown below.


I bet you wouldn’t have memorized that!  Both LUN 0 and LUN 1 are recognized by Windows. Press OK to exit out of the iSCSI Initiator application. Next, open up the Disk Management application on the Windows Server.


Notice that two new 5 GB disks are present. The tricky part here is that I am not sure which is LUN 0 and which is LUN 1. My best guess is that the disk that is recognized as a healthy primary partition is LUN 0 which contains a GPT label and is UFS formatted.  Thus the unrecognized disk must be LUN 1, which was not modified by the FreeBSD iSCSI Initiator. In reality I would deploy two iSCSI portal groups, one for the FreeBSD iSCSI Initiators and one for Windows iSCSI Initiators. I might have a third portal group for shared volumes.

For the unrecognized volume, create a MBR partition with the Disk Management tool, and then create a FAT32 partition on this disk as well. I decided to name the partition ISCSI_BSD. As shown below, on this Windows Server, the E: drive is now LUN 1, or /dev/ada2 back on my FreeBSD iSCSI Target machine.


The iSCSI drive shows up as a regular drive in Windows Explorer, as shown below.


Inside I created a special message for viewing from the FreeBSD side:


Finally, it is possible to verify the Windows access using the FreeBSD iSCSI Initiator. Reload the iSCSI Target session data, and now /dev/da2 is available on the FreeBSD Initiator. Even nicer, the FAT32 partitions are recognized by FreeBSD–less work to do! On Windows Server an MBR partition was created, which shows up as /dev/da2p1 in FreeBSD, and the actual FAT32 data partition is /dev/da2p2.

root@bsdinitiator:/iscsi_win_edrive # iscsictl -R -t iqn.2017-02.lab.testing:basictarget
root@bsdinitiator:/iscsi_win_edrive # iscsictl -A -p -t iqn.2017-02.lab.testing:basictarget

root@bsdinitiator:~ # ls -l /dev/da2*
crw-r—– 1 root operator 0x72 Mar 4 22:32 /dev/da2
crw-r—– 1 root operator 0x77 Mar 4 22:32 /dev/da2p1
crw-r—– 1 root operator 0x78 Mar 4 22:32 /dev/da2p2
root@bsdinitiator:~ # mount_msdosfs /dev/da2p2 /iscsi_win_edrive
root@bsdinitiator:~ # cd /iscsi_win_edrive/
root@bsdinitiator:/iscsi_win_edrive # ls
$RECYCLE.BIN hello.txt
System Volume Information
root@bsdinitiator:/iscsi_win_edrive # cat hello.txt
Hello FreeBSD! This is Windows Server!
I made your /dev/ada1 into a FAT32 partition.
I call it E: Drive. Thank you!

It works! I can see the message from Windows land.

Iomega ZIP drives!

I still have my old computer from back when I started at university in 1999! I keep thinking it is time to get rid off the machine, but then again it working just fine.  The only problems with it are that the CD-RW drive is broken and that the Pentium-III consumes a lot of power compared to modern machines. It is a great machine for FreeBSD, however, since all of the hardware is supported by FreeBSD now: wireless NIC, NVidia AGI card, etc.  It also has physical serial ports–two of them!  Last year I installed FreeBSD 10.2, and it has been powered down since. I just got too busy with school work. This morning I came across my stack of Iomega ZIP disks and thought I should see if I still have any data on them. Would my ZIP drive still function after all of this time?

The Iomega ZIP drive was a bid deal for me personally. All of the workstations in the university’s computer science and computer engineering labs had ZIP drives because often our work would not fit on a regular floppy disk. And at this time, there were no USB thumbdrives! I would frequently work in the lab, saving Visual C++ 6.0 projects  or Altera Max-Plus II FPGA projects to my zip disks. I used to carry two around just in case I filled up one disk. I would then continue working at home, taking advantage of the quieter environments to fix my C++ or VHDL code issues. The next day I would take the work I’d accomplished at home and move forward.

Looking back it was really a bit unnecessary though. The school should have prepared a better remote working environment.  The computer science department’s UNIX (Solaris 7 and 8!) network allowed for remote access, so for many of my computer science projects I just worked remotely via ssh on the Solaris machines. But the engineering department didn’t have any remote access capabilities, so I could not use FTP or SCP to transfer work between the engineering network and home. So thus it was the trusty Iomega ZIP disk technology that made my life just that much easier.

When you read about ZIP drives on the Internet, there are lots of complaints about the “click of death” and how unreliable the drives were. I must have been very lucky I suppose. I never had an issue with ZIP drives, and they were extremely reliable. I suppose that the issues was worse for external ZIP drives rather than internal drives. I used zip drives nearly day in and day out for 4 years. Amazingly, the Iomega ZIP drive in my old machine is still working today!

I went through all eight of my disks, and it was a worthwhile experience as I found some old documents and photos. Most of the disks were empty, but one had a bunch of academic papers I had been reading about computational electromagnetics, and another disk had many cover letters and resumes I had written back when I was trying to find a job. I also had some photos from my college days. I got rid of most of the data there, but decided to keep the photos.

In 2003 I purchased a 128 MB USB thumbdrive, and from that time forward I quite using the ZIP drives. The technology now is long dead, and rightly so, USB-based storage is clearly the way to go. But I will alwasy fondly recall the Iomega ZIP disk, much like those before me have memories of 5.25-inch floppy disks. I am going to hold on to these disks for awhile longer. I may keep it around to play around with, but that is about it. After all, I have no where else to transfer the disks to!

Notebook computer for a nerd

I am really struggling with the decision for a new laptop. I really need one, my ASUS X401A is quite challenged by my workload, such as opening more than 8 tabs in chrome, or the battery holding a charge longer than 30 minutes.

I was thinking of getting a MacBook Pro, but the October 2016 product line really left me disappointed. The basic MacBook Pro would have been fine except that there are no USB type-A ports! My Logitech M570 trackball does not come with a USB-C adaptor. Furthermore, my external DVD-RAM drive, USB thumb drives, and USB hard drives are all USB type-A. I suppose one day when the rest of the computer industry has taken the leap of faith and moved away from USB type-A, may then I will switch. But not today. Then I looked at the MacBook Air, and actually it would be ideal, but the screen resolution is very dated and I just feel like for the price that Apple is selling it for, it ought to have a much better display resolution in 2016.  So no Apple this time around…

I have a Dell XPS13 developer edition at work, and I was thinking I would get one for myself at home. I have an older version at work, and the only annoyance is that no matter what I try I cannot disable the trackpad while typing, so the mouse cursor jumps all over the place. Of course at work this is not much of an issue as I use an external mouse at my desk. More disturbing though is that current versions with Kaby Lake Intel processors have an annoying “whine” coming from the power supply. The Dell user forms are full of complains about this, and I am now  going to have to avoid this notebook computer until Dell can determine the fix. It is ashame, because this really would be the ideal machine for me, but I know the whining sound would take its toll.

So where does that leave me? I want a portable ultrabook that I can install Linux on and do some basic software development. I looked at some of the HP and ASUS product lines, but there seem to be issues with Linux and Kaby Lake support on some of these devices. The ASUS device I liked seems to no longer be sold too.  So now I’m looking at Lenovo, the Carbon X1 Thinkpad. I was considering the T460 Thinkpad, but I really want something portable and lightweight.  The X1 has everything I want, except that the it costs so much more to go from a 128GB SSD to a 256GB SSD. Oh and it comes with Windows, so I would have to blow that away.

I am thinking that I will go with the small hard drive in the end though. After all, my Mac Mini is now my primary desktop device, and I do have the NAS on the home network too. What do I need more than 128GB of storage for? Would I even use the additional 128GB, so is it worth an extra $250?

Synology and UPS

By and large I have been happy with the Synology purchase for the home NAS. While I would have had more fun with FreeNAS, my spouse is probably happy I went with the solution that did not require my tinkering or attention here and there frequently. It is also nice to have the Synology apps for iPhone/Android so that we do not have to deal with upload data to the magic cloud.

I did have my first scare with the NAS though, entirely my own fault! At the end of summer there was a power outage that took down everything in the house, including the NAS. I did not have it hooked up to any sort of UPS device at the time, so it went down hard. I could not access it over the network, so I went to look at it, and the Synology NAS just sat there flashing two blue status lights. After doing some google research I was concerned they might be the death indicator lights. I ended up having to pull out the disk drives, remove physical power from the NAS, and then reboot it. After some time the device recovered and I gracefully shut it down, replaced the disk drives, and then rebooted. It came back up, no data lost, and what a relief!

After that scare I decided that I really ought to get a basic UPS for the NAS. I did my homework and found that Synology supports UPS standards that communicate the status of the power supply from the UPS. On Synology’s website is a compatibility list with rather expensive devices and even some dated devices. However, more google research said that any standards-compliant device should work. Of course, being primarily a Linux / Mac user, one could excuse me for balking at that idea when it comes to consumer grade computer equipment!

I really did not need a fancy UPS with lots of features. I just wanted a simple UPS device that will inform the Synology NAS when it switches over to battery. Ideally the UPS would use USB, since EIA-232 Serial Ports are not on Synology devices. I am not looking for a device that will keep a computer running for some amount of time, I simply want to keep the NAS and perhaps a network switch up and running long enough to safely shutdown.

After reading the Wirecutter recommendation for the CyperPower CP685AVR UPS, I searched around some more with google. I did not find any definitive information about Synology NAS devices working with this UPS model, but I decided to take the plunge and see if it would work since my local Microcenter store carries the UPS in stock. I really like the size of the UPS, it is about the size of a small shoe-box or a Cisco Press textbook. It also doesn’t make any noise which is always nice!

Safe Shutdown Test

Before hooking up the NAS to the UPS for power, I decided to try an experiment to make sure the UPS would work with my NAS.

  1. Keep Synology NAS powered by A/C power, but connect the UPS USB cable to the back of the NAS, and power on the UPS
  2. Switch off the UPS outputs only and see how the NAS handles the event.
  3. Switch on the UPS outputs, and then after a minute remove A/C power supply to the UPS
  4. Wait for safe shutdown time, and then confirm the NAS safely powers down.



Configuration was probably the easiest thing I have ever seen. In the Synology NAS control panel, in the Hardware and Power section, one simply navigates to the UPS tab. Place a check mark in the Enable UPS support box, and then set the safe mode timer. For now I have set this timer to 5 minutes. There is also a button “Device Information” at the bottom of the tab, and as shown in the above screen capture, the NAS automatically detects the UPS.

Test Results

Starting at the bottom and working up with the messages in the screen shot, all of the power events are stored in the NAS log file.  After enabling the UPS support, the NAS logs that the service started and identifies a UPS on the USB port. The message “Local UPS was plugged out” refers to step 2 of my simple test, where I kept the UPS plugged into A/C power but simply disabled the UPS outputs. After 5+ minutes, the NAS was still online and did not shutdown. Next, I re-enabled the power outputs on the UPS, and after a minute or two, removed A/C power from the UPS. The NAS logs that the UPS has gone to “battery” and the safe shutdown timer begins.


After the safe shutdown timer expires, the NAS shuts down the Cloud Station service, and logs a message stating it will be going into Safe Shutdown. At this point, keep in mind the NAS is still plugged into A/C power. After the NAS shuts down, the Status LED on the NAS was cleared, and I was no longer able to navigate the NAS via its web interface. I reconnected the UPS to A/C power, and after a minute or two, the blue lights on the NAS began to flicker. A few minutes later, the NAS was back up online and I was able to access to the web interface. Success!


The CyberPower CP685AVR UPS and Synology NAS work just as I had hoped–I could not be happier. I have read that some UPS devices will initiate periodic self-checks than can cause some NAS devices to think power has been lost. I will have to keep an eye out for this, and worst case I may need to extend the safe shutdown timer from 5 minutes to something longer. However, this UPS claims up to 70 minutes on an iMac G4, and I am sure that this NAS with its low-power ARM CPU will not exceed the power draw of an iMac G4. As such, there appears to be plenty of margin to work with.

Home network upgrade: Storage Acquisition

For as long as I can remember I have been dealing with storing files in the following manner: floppy disks, zip drive disks, and now USB hard drives. When I had a Mac computer I actually was very good about regularly backing up my files via ChronoSync and then finally Time Machine. For the past three years I have been without a Mac and just have an old Laptop with Linux and an old desktop with Windows. For these machines, I have been backing up simply by copying files to a USB hard drive. My wife has been using the USB hard drive as well with her Windows laptop  However, over the years we have compiled and saved a lot of photos and videos. The USB hard drives are difficult to organize and manage well among the two of us, and a large volume USB drive is still quite pricey, so we entered the market for a networked storage system where we can save and share files from a central location.

I ruled out Dropbox, Google Drive, and other cloud based solutions as primary storage source. Why? Because I frankly haven’t bought into the cloud yet. For sharing files with people at large, sharing code for school projects, etc., I find such services great. I utilize my Google Drive extensively for school work. However, I’m not quite ready to put tax returns, photos and private data on the cloud yet. For off-site back-up, it is on my to-do list for research and evaluation, but I prefer to keep my primary back-up in my control for the time being. Perhaps when I get a better grip on encryption…

The initial thought was to go for a step-up from a USB hard drive like my Western Digital My Passport and use a Personal Cloud device. Seems simple enough, right? Network connectivity? Check. File sharing? Check. However, last summer at the lab at work a manager came to me with a problem: three HDDs failed in the RAID5 solution purchased from Dell almost a decade ago. I found myself reading more about network storage solutions, which also got me thinking about my home situation. While a personal cloud solves the immediate problem of having a network-based storage, what if it fails? I need RAID!

I then went crazy and dived into the deep end, looking at a FreeNAS build with RAID Z3, SSDs, SAS disks, Xeon CPUs, 64 GB of memory…it started to get expensive quickly, and then I started thinking about the noise of server fans…stop!  I looked at scalding down to RAID Z1, and even just RAID1, but I would still need to build a PC and deal with the configuration and performance tuning. I decided that since I am working full-time, going to graduate school at night, and raising two small kids, that I probably should settle for a canned solution such as a storage appliance rather than something I would need to tune and pay close attention to. When I done with school and have more free time, I still like the idea of building my own FreeNAS system–what a project!

I started looking at Western Digital, Buffalo, Seagate, Drobo, Synology, QNAS, and many others. I narrowed down the decision to the QNAP TS-251 or Synology DS216+ based on reading many reviews, web forum posts, etc. Both units are priced competitively, and in the end I selected the Synology DS216+. With roughly the same technica specifications, it came down to look to the unit and the OS on the device. I would have went with the QNAP if we were to use the NAS for streaming video (the HDMI output is nice), but in reality this storage solution will be used solely for file storage.

I consider this an entry-level purchase since it is a two-drive bay enclosure, and I will configure it for RAID1 with two 3TB Western Digital Red NAS disks. The hope is that it will last me approximately five years, with the plan to upgrade the capacity in three years when the cost of larger hard disks has come down. The DS216+ is powered by a dual-core Intel Celeron rather than a Marvell or ARM solution, so hopefully that will help it keep up with our storage demands. After five years I will take a look at our storage need and consider a higher capacity solution such as 4-drive bay enclosures.

Now that we have a storage solution, I need to figure out the home network connectivity once and for all. We currently access and connect to everything through the Verizon FIOS provided wireless router/AP combo…

Femtocell tear down

Back in 2009 my wife and I bought iPhones. We had just come from Japan where smart phones had not yet penetrated the market, and were curious about the devices. At the time, only AT&T had iPhones, so we had to sign up for the AT&T network. Where we lived, however, we could not get any cellular reception indoor.  In March 2011, with about six months left on our contract, AT&T sent us a femtocell so that we could use our phones in the home. It was free, and we only had to return it if we did not keep AT&T service for two years. It has been 4 years now, so I think it is about time I retire it–with a tear down!

Note: While this device certainly helped with cellular reception, and we could use our phones anywhere in our two-floor townhouse at the time, it was a bandwidth hog on our Internet connection!  We ended up unhooking the femtocell because Skype calls had terrible performance on our regular PCs. When the femtocell was removed, the Skype calls were flawless and picture-perfect. So in the end we did not end up using this device! (In hindsight I wish I would have debugged and troubleshooted the device a bit more, but I just did not have the time.)

The Femtocell

The specific femtocell is actually a product called Cisco’s AT&T Microcell Wireless Cell Signal Booster Tower. I personally was a fan of the design, I thought it was aesthetically pleasing.


Let’s get straight to the tear down. After ripping apart the casing, which was not easy to remove, the following circuit board is revealed.


The top-left is a digital part of the circuit board. Some sort of device, no doubt some form of a processor, is under the heat sink.  To its left are two Samsung memory chips.  I was not sure what the square IC to the southwest of the processor was.  In the center-top is a Spartan 3 FPGA, and to the right of that is the shielded RF circuitry.  Directly below the heat-sink IC is a bunch of power regulation circuit. At the very bottom is the power input and two Ethernet jacks.  The bottom right side has three ICs, and a shielded IC with a yellow labeling.  Directly below it is the external antenna input. Also in that area are a large circular capacitor and a ceramic device coming off of the circuit board.


Close up of the The ceramic device and the capacitor – turns out that the ceramic device is a GPS antenna.

I popped the yellow cover off of the shielded IC, and it revealed the above. This circuit is on its own PCB which is mounted to the main PCB, and it has it owns oscillator and other off-chip components.  Finally, following are some close-ups of the large shielded RF circuitry.


There are three shielded components.  The top part with three different ICs, the bottom right, with an oscillator, and the bottom left, which an IC that is so small I cannot make it out. It is interesting to note also the two PCB micorstrip antennas feeding into the larger of the shielded areas, which are home to the transmitter and receiver RFICs.


A closer look at the transmitter (left) and receiver (right). Note all of the exposed copper and vias! I love RF circuits!

Interesting Parts

  • MAXIM 2597 – UMTS transmitter RFIC: complete with DAC, filters, modulators, Power Ampflier, etc.
  • MAX2557 – UMTS receiver RFIC: ADC, filters, demodulation, etc.
  • HFIO20190630 – ???
  • Picochip PC202 Picoarray – multicore digital signal processing chip
  • Samsung K4T51163QG – 512 MB DDR2 SDRAM
  • Spansion GL512P –  512-Mbit Flash memory
  • Ralink RT2150F – Ethernet MAC and 802.11 radio (most likely only the Ethernet MAC is used)
  • MXT102144 – ???
  • Winbond W9812G6JH-6 – 128-Mbit SDRAM
  • SMSC 8700C – Ethernet PHY
  • Xilinx Spartan-3 – FPGA that most likely glues everything together

The most interesting device in this femtocell is the Picochip PC202. The company was as fabless start-up that was bought out a decade ago. A quick search did not turn up any data sheets or processor guides for the PC202. All in all though, a very cool circuit board with lots of capability!

Further Reading on hacking the board: fail0verflow.

My First ASIC

For the first time in the past few years, I’m really having a lot of fun, and I owe it to my ASIC design course.  For a previous homework assignment, I had to modify and customize a simple counter device.  I then had to simulate and find the optimal clock period with Synopsys.  In the next homework assignment, I had generate the back-annotated delays, and then re-simulate, re-synthesize, and finally analyze for power consumption.  Using the Cadence Encounter tool that is available on campus, the result of my efforts is shown below.

My First ASIC - a simple counter


Now I just have to learn how to read what Encounter is showing me (Fence, Guide, Obstruct, etc.) …