Trying Vada Pav

An Indian fast food franchise shop recently opened up in the area. I was out running errands today and realized it was 14:00 already, and I was “starving”, so I decided to give the shop a try. The theme of the shop was Indian takes on “Western” style foods like burgers, sandwiches and pizza, such as masala veggie burgers or Tandoori paneer pizza. There were several other dishes on the menu that were totally foreign to me: vada pav, veggie masala pav, and some other chick-pea curry type dishes with various garnishments such as eggs or nann.

Without knowing anything about the vada pav other than a picture on the menu, I decided to begin my adventure with the Mumbai-style vada pav. The shop offered it with mild, medium, or hot levels of spiciness.  I went with medium. It was quite delicious for just US $2.00, I would much rather have it than a McDonald’s cheeseburger or a Taco Bell taco!

According to Wikipedia, the vada pav is a deep-fried potato patty with various spices. The outside of the patty was crispy, while the inside was a dry-moist grit, yellow in color from cumin perhaps, as well as with various other spices. Until I checked Wikipedia, I honestly thought it was made of corn meal. The patty itself was enclosed on both sides by a regular hamburger bun which was nothing to write home about. However, on both sides of the hamburger buns a layer of green paste, and then a layer or red paste was spread onto the buns. It as smokin’ hot!

There is a significant Indian community where I live due to the area being a technology corridor, and I am hoping that as the community grows and thrives more such restaurants and shops will open up! Having never been to India (would like to visit some day though!) it would be nice to be able to try and experience various foods from the Indian subcontinent.

All in all the vada pav was a very good and makes a great, quick snack all on its own. I would like to try some more things from the menu, particularly dahi puri or pani puri.

Wireless AP and OpenWRT

Getting the wireless access point (AP) up and running looks to be a painless task. By default for my WRT160Nv2, OpenWRT provided the following settings in /etc/config/wireless (dumped via the UCI tool).

root@OpenWrt:~# uci show wireless
wireless.radio0.ht_capab=GF SHORT-GI-20 SHORT-GI-40 TX-STBC RX-STBC12

I want to create a custom SSID, ‘Armadillo’, and also set a WPA2 key for accessing the router. Furthermore, I want to make sure that my wireless radio in the router is configured for proper use in the United States.

root@OpenWrt:~# uci set wireless.@wifi-iface[0].ssid='Armadillo'
root@OpenWrt:~# uci set wireless.@wifi-iface[0].encryption='psk2'
root@OpenWrt:~# uci set wireless.@wifi-iface[0].key='****************'
root@OpenWrt:~# uci set
root@OpenWrt:~# uci set
root@OpenWrt:~# uci set wireless.radio0.disabled=0
root@OpenWrt:~# uci commit

With the configuration written to /etc/config/wireless, issue the wifi command to start the wireless service:

root@OpenWrt:~# wifi
Configuration file: /var/run/hostapd-phy0.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan0 with hwaddr 00:0c:43:28:80:e8 and ssid "Armadillo"
wlan0: interface state COUNTRY_UPDATE->ENABLED

To verify the access point is up and running, look at the available wireless networks. In my case, ‘Armadillo’ is available and after entering the WPA2 key I have access to the device.


WAN Port DHCP and OpenWRT

Last weekend I installed OpenWRT (v12 Attitude Adjustment) on my WRT160Nv2 router device. Out of the “box”, the internal LAN is setup as, and I can ssh into the router for configuration. I plan to plug this router into another router device, so I would like to configure it for the following:

  • DHCP on the WAN port: If I take this to a hotel or hook it up to a another router device, I want it to automatically obtain an IP address on the WAN port
  • Private network on the LAN ports: 192.168.2.x addresses
  • [Optional] Enable wireless access so that I don’t have to plug my laptop computer into this router via Ethernet cable each time I access it.

WAN port configuration

To modify settings, one can either edit /etc/config/network directly, or use the unified configuration interface (UCI) to issue commands from the shell. I chose to do the latter. Of course you can also use the web interface if you have a normal router and not a WRT160Nv2.

The commands below modify the wan port to use DHCP to obtain an IP address and DNS settings, and then bring up the WAN interface.

uci set network.wan.proto=dhcp
uci commit network
ifup wan

To verify that the WAN port has an IP address, issue the ifconfig command and look for the IP address used from the DHCP server, in this the router device issued to me by my ISP.


As shown below, the WAN port is given the IP address

eth0.2    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:  Bcast:  Mask:
          RX packets:7135 errors:0 dropped:406 overruns:0 frame:0
          TX packets:4675 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4727515 (4.5 MiB)  TX bytes:745096 (727.6 KiB)

LAN IP address re-assignment

The DHCP server on my network is running on the private network 192.168.1.x, and that conflicts with the default configuration from the OpenWRT installation. The WRT160Nv2’s LAN ports need to be moved to another network. I decided to move them to 192.168.2.x.

uci set network.lan.ipaddr=
uci commit network

Rebooting closes the SSH session, so reconnect to the router, but remember the address is now for the router device!

Testing Internet access

After logging into the machine, I issued a ping command to




I recently saw in the news that Sprint has run into some legal issues trying to pull the plug on its WiMAX network. That brought back memories to 2008 when I was working with WiMAX technology. I was working on a project to build a modem for XGPHS, or Next-Generation Personal Handyfone System. XGPHS was based on the WiMAX specification, but with improvements in performance for mobile access. This was all before Mobile WiMAX started to sprout up. The last thing I remember about XGPHS is that when the world economy crashed in 2008/2009, Willcom, the company leading the push to the XGPHS technology, was running into financial problems. What ever happened to XGPHS?

I had forgotten as well, but in 2007, NTT pulled the plug on PHS service and Wilcom was the last player in the game. Apparently in 2010, Willcom filed for bankruptcy, and then Willcom was acquired by Softbank. In 2014 it was sold to e-Mobile and renamed Y!Mobile. e-Mobile, however, was a data-only 3G provider originally.  Y!Mobile was then acquired by Softbank in 2015. I saw some Japanese language information stating that PHS may have its plug pulled in November 2022. However, that still leaves six years for another firm to try to acquire the technology and keep the system going.  Or maybe not, perhaps it will remain a technology used internally. Many hospitals and large factories use PHS internally for communicating with staff–usually managers.

As for XGPHS?  It turns out that XGPHS is still alive…sort-of.  Extended Global Platform (XGP) Forum is the group now representing XGPHS.  After a cursory look, XGP Forum is focusing on TD-LTE, and has its roots in the XGPHS that I once knew. @nifty offers a wireless service that uses the AXGP and LTE.

I was curious about some other mobile technology that was once big news in Japan when I lived there.  i-Mode was an Internet service offered by NTT DoCoMo for the FOMA service (UMTS network) customers. It was a proprietary network based on WAP-like technology and was hugely popular while I was in Japan. At the end of February 2015, NTT DoCoMo pulled the plug on the network. Smartphones killed the juggernaut of Japan’s mobile industry.

And WiMAX? Unlike in the US, it looks like there are still options for WiMAX in Japan.  UQ WiMAX appears to still be available, and @nifty is offering a WiMAX service as well. I am glad to see there is still some wireless technology diversity in Japan. I cannot say that much about where I live in the USA.

Serial Ports and Linux Screen

I am familiar with the screen tool on Linux for setting up terminal sessions that survive disconnect. At a job once I had a Linux workstation with OpenSUSE that was terribly unstable. It was not actually the OpenSUSE that was the issue, but it was the graphic driver. It would cause the system to hang and I would lose any work I was doing on a remote machine. Thus I started to use screen so that if my workstation went down, at least the work on the remote machine would not be lost!

Turns out that one can also use screen for accessing devices on a serial port. For example, if there is a modem device on /dev/ttyACM0, it is easy to connect:

screen /dev/ttyACM0 19200

The serial port connection parameters can be specified after the serial port device name: in this cause I am using baud rate 19200.  To disconnect gracefully, simply input “Ctrl-a” and then “k”.

Other options are of course minicom or picocom, but for when you just need to connect to a simple device and issue some commands, screen seems like the tool for the job!

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.

Ubiquiti Unifi Review Link

Just wanted to share a link to a very interesting review of Ubiquiti Network’s Unifi wireless access points by ArsTechnica. The article is quite lengthy and full of good information on the pros and cons of the product. It was also interesting to see how strong the Apple Express WiFi technology was as well!

I live in a small town-house and do not really have an issues with my wireless home network.  However, if you are having coverage difficulties or are looking for some advanced features, definitely take a look at this review and Ubiquiti’s offerings.