QUALIFICATIONS

KNOWLEDGE & SKILLS

S/W Architecture, RTOS, Wireless, Networking (TCP/UDP/IP, SNMP/ICMP/IGMP)
Data Communication, Data Acquisition, Structured Analysis, Device Drivers
Audio/Video Stream MPEG transport Layer I&III, Control Systems, Telephony
Access Control, Ultra-Sonics, Image processing, Optics, Automotive OBD-II
OOP+OOD+OOA, UML, VisualStudio.Net, VB6/VB.Net, ADA, C, C++, C#, Firmware
Sensor Application (Heat, Fluid, Pressure, Ultrasound), ActiveX, COM, GUI
CASE Tools, Configuration Management, Java, JavaScript, Perl, SQL, RDBMS
SEI Capability Maturity Model (CMM), Web, HTTP, DHTML, XML, VHDL, VERILOG
ISO-9000, Group Management, Mentoring, Systems Analyses, Analog / Digital
MathLab (Simulink & LabView), ALTERA / XILINX FPGA, GPS App, Fiber Optics

HARDWARE & SOFTWARE & STANDARDS & TOOLS

SUN Solaris, VxWorks, pSOS, Windows CE/XP, UNIX/LINUX, QNX, I2C, SPI, SCI
GPS, SCADA, CAN, MilStd-1553, J1708/J1587/J1939, VME, USB, Power Supplies

Signal Gen., Logic Analyzer/Oscilloscope, Protocol Analyzer, JTAG, ORCAD

CAREER ACCOMPLISHMENTS

Product: Wireless Energy Management Switch, offers two-way smart communications for utilities (electric, gas, water)
Meters in load control, demand/response, outage detection and means for timely billing. I successfully implemented integration
of Landis +Gyr UtilliNet Series III mesh radios from CellNet with CSE load Interruption/load control switch system. CellNet
Series III mesh radio operate in the range of 902.3 ~ 923.6 MHz which deploys Frequency Hopping Spread Spectrum (FHSS)
signal structuring technique for telecommunication and using GPS for their geographical location ID in a mesh group.

My integration efforts involved hardware design (level shifting 5.0v SCI bus on ST92F120 to CellNet Radio 3.3v micro SCI
bus, firmware in CellNet Device Control Word language and software development in Visual Studio .Net C# to validate the
radio and switch integration using CSE Autonomous Control Protocol (ACP) messaging system.

In general, CSE switches act as transponder to manage equipments such as HVAC or agriculture pump remotely via
ACP message contents. The ACP messages are embed with command and data to manage relays on board the switch as for
use in X10 or SCADA type applications. To implement, radio modules to work in Mesh protocol, I utilized Radio-Shop S/W
tool and MS SQL Express and C# in Visual Studio 2005.

I also provided support / expertise with updating Remote Site Controller (RSC), an existing system utilizing
AFSK (Audio Frequency Shift Keying) method to convey ACP messages via VHF (FM) transmissions to CSE
switches‘ built-in receivers operating in the range 154 to 173MHz. The CSE switch receivers were setup to
demodulate within operating range of 400Hz to 3000Hz. The AFSK encode / decode processes were interrupt
driven and utilized on board timer/capture functions for bit encode/decode processes.
This system had been designed with PC ISA bus architecture in mind. It had deployed a 4 MHz MC68HC705
controller to deliver AFSK tones via RS232 linkage (on given carrier frequencies) to transmitter modules.

The AFSK encoding process entailed: Key up, Encode, Key down with 51 bits per second. It also handled user
I/O requests via a high level application language, Visual Basic. The RSC PC-ISA firmware was developed
in MC68HC05 assembly language. In addition, I developed / integrated current sensing capability to provide
tamper proof functionality to the switch. This included using hardware components such as coil for current
sensing, amplifier and comparator for logic detection via software.

Since number of RSC transmitting towers has risen with time, SCE, Southern California Edison Electric had
demanded for signal strength monitoring equipment to track/identify transmitters. I created S/W test tools
to generate and embed transmitter IDs within transmitting ACP message payloads. This was required for
hardware and software development to be used in validation process provided by other team members.

I also developed new architecture for Remote Site Controller to be hosted by Linux operating system. This
included boot loading and diagnostics web pages usable by Apache web server to admin/maintain RSC units
in fields remotely. For the hardware I selected ARM M1-Cortex MPU both for address space and cost benefit
and to use switch mode regulator for power supply. For software, I redesigned project code so to be ported
to ARM7(C / Assembly) for larger code space. And I proposed to use Direct Digital Synthesis, Synthesized
wavetable technique) for FM–AFSK tone generation instead of hardware component crystal oscillator.

Product: Electric Utilities, Grid, Monitoring System, I maintained a multi-DSP/microcontroller digital fault recorder,
DFR, system by which power utilities grid could be closely monitored. A typical DFR chassis could consist of 1 through 16
DSP-USB input boards plus an I/O card for decoding GPS time codes from an external GPS receiver unit. Each DSP-USB
input board consisted of a DSP, Analog Devices ADSP 21065L 32-bit, an EZ-USB port (Cypress CY7C647 FX1 ,i8051 code
compatible) USB host controller/ hub for data transfer to a Windows-based PC via USB, a UART for GPS time code, an I2C
based data bus to fetch in card ID configuration (H/W jumper based setup). A DSP-USB board coupled with either analog or
digital input boards in groups of eight (8) per board to make up to 128 channels per chases.

An analog input board had eight (8) 16-bit analog to digital converter, ADC, by which line voltage, current, frequency and
phase to be monitored. A digital input board could be consisting of up to 160 event channels. The digital input event board
Channels were configured to monitor relay status (events) switches.

The GPS receiver ‘Schweitzer’ provided DFR with precision timing IRIG-B coding for data sampling and time stamping of
fault data to be recorded. To synchronize all DSP boards internal timing, 60 MHz, in DFR chases, an IRIG-B decoder card
was implemented to help with timing signals received from GPS satellites. The IRIG-B corrected timing frames, one pulse
per second, 1milisecond resolution, used to align sampling process and time stamping of data arriving on each input board.

Three Windows’ applications “Remote”, “Win -DFR” and “Master” provided means for data acquisition, data conversion-
communication (server) and graphical data analyses-communication (Client). TCP/IP networking was the primary means to
provide communication between clients and servers. Also dialup POP3 protocol served as secondary means for data
communication where wide area networking was not available.

The setup and configuration of all input channels are possible through a calibration record. The calibration record contained
parameters for analog channel trigger types for RMS voltage (AC-DC) / current / frequency / phase. The calibration record
contained parameters for digital inputs as well. This is to detect relay open-closure status events on grid system application.

Part of my work on DFR included updating USB drivers to speed up data transfer to the on-board computer. That was to
make use of Asynchronous I/O technique by which asynchronous polling of all DSP-USB modular boards to become possible
in the “Remote” application. This was necessary since high concentration of data traffic on the PC’s USB hub was causing
frequent timeout on read/write operation, especially when users requiring continuous recording to be turned on. Before this
upgrade, sequential polling of all sixteen (16) DSP-USB boards were implemented which were causing jamming of data .

I also updated wide area network interface part for client/server connection and activity process. I enhanced the analog
triggering processes by extending the number of analog triggers from eight (8) to sixteen (16) per board so that data from an
analog input channel could be monitored by multiple assigned trigger values such as voltage, current frequency, etc. Doing
this required to revamp USB data packet structure, DSP firmware and calibration record data structure. The calibration
record change brought change to the Windows GUI application layer as well.

Since power utility grids are vulnerable to thunder storms and lightening after the fact, I conducted some research on how to
provide automatic query on the location of a fault off the grid system which meant to log in to VAISALA, a service provider,
data base for regional lightening sensory information within the United States. I developed two XML web services so that
a fault location (longitude and latitude and radius) can be identified via the time field, key in fault records, in about 2 seconds.
This solution was integrated in Master application.
Before this upgrade, users had to manually login to the data base and upload and sort data for grid areas where may have been
affected by lightening. This was essentially causing incorrect estimation about fault locations. This was economically
expensive to maintaining energy in regions where seasonal lightening activity causes serious damage to power grid.
In general, fault data has some id for cables in a gird area where a fault originates; two or more DFR (s) are normally set up to
monitor a group of power lines at a distance. There was an algorithm to estimate occurring fault locations on grid system bus
using IRIG (GPS) time code embedded within a fault record.

As part of research and development, I made efforts to alleviate the imposed USB limit of 128 channels by creating clusters
of 4 DFR computers so it can be extended to 512 channels, using client /server technique but known as “Cross Triggering”
in power/ utilities industries. An Ethernet switching hub and TCP/IP protocol were deployed to emulate a fault data across
multiple digital fault recorders. This involved grabbing fault’s time stamp and emulating new ones on other DFR machines
in chain . This required modifying calibration record to provide support for 512 channels instead of the original 128.

I utilized IEEE1344 standard time codes which are also defined as IRIG-B, C37.111 (COMTRADE, Common Format for
Transient Data), Analog Devices Visual DSP++ for firmware development and Borland C++ Builder 6.0 for the applications
development. Oscilloscope and JTAG and other electronic hardware tools such as meters were used to help with diagnostic
processes. I was also supporting customers on a day to day basis on issues such as connectivity and hardware configuration.

Confidential, (2004 - 2005) Indirect Sr. Software/ Systems Engineer
Product: Development of Data-link Messages for OBD-II Power-train systems, I developed various system
requirements for both On-Board Diagnostic (OBD) and Parametric sensor information used for diesel engine and vehicle
subsystems. The OBD information relayed via Suspect Parameter Numbers (SPN) / Parameter Group Numbers (PGN)
and Diagnostic Trouble Codes (DTC), fault codes, on CAN message frame by SAE J1939-71/J1939-73 protocol to ECM.

The topics such as After-treatment, Fuel Control System, Engine/Lube and Electrical Power Distribution were covered. The
process included use of SAE database for existing parameters and new requests from various other SAE charter members.
I used SAE forum web site and administered conferences to maintain issues regarding data-link messaging. I participated
in design review discussions for data link related issues for scan-tools, diagnostic and forward looking product engineering .

Confidential, (2003 - 2004) Indirect Sr. Firmware Engineer
Product: Access Control System, I evaluated firmware requirements for a battery operated Security Lockset employing
a NEC4225, 16-bit 4.0 MHZ micro-controller. And based on requirements for new functionalities and cost effectiveness, I
recommended Philips LPC2124, a 32-bit 11.0 MHZ micro controller, a hybrid of ARM7 processor, for deployment on the
next generation of similar security lockset, marketed for businesses employing card access with their secure locksets.

The current product in the field had not envisioned for boot-load operation. The new design could take advantage of on-board
Flash memory and a boot-loader system, i.e. firmware may be downloaded to the lockset in the field or the manufacturing site.
I developed code in C/C++ and ARM 7 assembly using GNU tool set to benchmark operations of the on-board peripherals
which were to be considered in the new design. For example, the current draw for all modes as in Normal, Idle, Power-down
were examined, since battery life cycle is very important . I then conducted PLL (Phase Locked Loop) setting benchmarks
for supported clock speed with respect to current draw.

I also benchmarked on 20 microseconds pulse width detection required for Weigand access cards. Using LPC2124 on-board
peripheral Timer1- Capture1 input, I then measured the counts between consecutive rising and falling edges of a simulated
Weigand signal. The time-base was ¼ of MPU clock speed. In this set up I employed a function generator, an oscilloscope,
Slick Edit, Ashling PathFinder, and JTAG to build /debug firmware in flash memory. I later came up with algorithm how to
differentiate between a Mag strip (ABA) and a Weigand access card for the same reader using this measured time (ABA
travel time of 3 to 80 inches/seconds and either 75 or 210 bits per inch on track #2). I also reviewed Hardware Abstraction
Layer (HAL) of the current product in field. This was used as references in the new design strategy.

Confidential, (2002 - 2003) Indirect Sr. Software / Firmware Engineer
Product: Automotive Sonar Application, this was intended to forewarn/detect obstacles benefiting the trucking industry.
The system consists of a Driver Alert Module, DAM, and 40 KHz Sonar transducers linked by J1708 asynchronous serial
communication, using Bus topology for interconnection at 9600 baud rate with 12V-DC power supply. The DAM displayed
distance computed and relayed by a Sonar sensor unit via a 3digit LED readout The Sonar sensor unit contained two 40khz
transducers. One to send out 12microsec pulse width and the other to read in echoes bounced off of an object at the same rate.
It’s hardware design included a 4-channel serial A/D to monitor heat, sonar power, receive transducer and system power.
It used a serial 4096 bits (64x16bits word) E2PROM to retain setup map for parameters such as thresholds for initial distances,
Automatic Gain Control for Op Amps with respect to reported distances, Lock on target, Number of sample tests before a report,
Blanking Intervals, etc. A 20 MHz Microchip PIC16C57C with RTCC maintained timely controlled signals for the Sonar
acquisition such as driving a Push-Pull amplifier to send ultrasound through the send transducer. The distance from objects were
computed based on time differential of sent and received sonar signals.

Microchip PIC16C57C MPU in both DAM and sonar sensor units provided control for the J1708 serial communication protocol.
Microchip tools such as ICE 2000, MPLAB assembler/programmer utilized for software development. Hardware tools such as
digital scope, logic analyzer were used in hardware development process. Additionally, I developed Windows applications using
Visual Basic 6.0 for programming E2PROM to store non volatile calibration data , and others for in-house use to monitor serial
link, i.e. J1708 protocol data between DAM and sonar sensor units. This project was later suspended due to poor market
reception and economic recession during this period.

.
EDUCATIONS

• MS in APPLIED PHYSICS
• BS in COMPUTER SCIENCE
• BS in ELECTRONICS ENGINEERING TECH