January 10, 2006 (1 hour):
This was the first day of class. We solidified our team, as well as a
clever team name, the J Team. We had a team meeting to brainstorm possible ideas for the design project. Some
of the ideas that we considered were an IPASS unit that had additional built-in capabilities, a digital host
for use in a restaurant, a laser tag game, and a laser target practice unit. The team decided to do additional
research on Josh's digital host idea. He had a personal interest in the project since he works as a host at
Chili's. Our initial concern was that the project might be too software-intensive, and the solution we would
develop for this course wouldn't be nearly as practical as developing a software suite to do the same thing.
January 11, 2006 (1 hour):
Today we had a team meeting to expand on the research we had done for the
digital host project idea. Josh brought a list of applications & interfaces for the "DigiHost", and we
discussed different peripherals with which we could interface.
At this time, Jared shared with the team an
idea that he had thought of for an RFID checkout system in a supermarket. He envisioned a shopper filling up a
shopping cart with numerous items tagged with passive RFID tags. Shoppers would apply for an RFID Key Fob
to attach to their keychain that contained an identifying unique user number. When finished, the shoppers would
pass through the exit door, on which would be mounted an RFID receiver. The receiver would read all of the tags
simultaneously, as well as the shopper's keycard or FOB that would act like a SpeedPass. An email receipt
would be sent to the shopper, obtained from a database accessed via the shopper's user number.
The team
members really took well to this project suggestion, as we thought of many different possibilities for
interfacing and considered this topic to be a valid step forward in potential future technology. We decided to
do more independent research on RFID applications, since none of us had any previous experience. Jared and I
both helped to develop concept appliance ideas with Whirlpool Corporation in the Summer of 2005 during our
internship there, which was the source of the idea.
January 12, 2006 (1.5 hours):
I spent a bit of time this afternoon surfing the internet for
information on RFID technology to gain a better understanding. Huge learning curve for me today!
Helpful sites that I used for reference:
http://www.rfidjournal.com/faq
http://www.ti.com/tiris/docs/customerService/faq.shtml
January 12, 2006 (2.5 hours):
Today's team meeting centered mainly around drafting our initial
project proposal, which was due tomorrow. We did an ample amount of online research as a team to learn the
fundamentals behind RFID applications. We searched for possible development kits or chips, but we're unsure as of
right now whether we are expected to just buy a kit or build the receiver/transmitter/antenna ourselves.
That seems a bit hardware-intensive, and quite frankly, with a group of 4 software-oriented CompEs, scares us!
During one of our many Google searches, we happened upon a 477 Senior Design Team's website from about a year
ago who attempted a similar project. We were able to snoop around and gain some insight as to how they chose
to approach their project. We were a little worried by the fact that their project seemed to be
unsuccessful at the end of the semester though!
We learned that for our project, we would most
likely need to use high frequency tags and readers (13.56 MHz) in order to obtain the maximum range (up to
3 feet, according to the websites above). Unfortunately, antennas for that range are quite
expensive! We wonder just how generous sample parts givers can be. Finally, we completed our initial project idea,
which can be found here. We also divided up the responsibility for the Design
Component Homeworks and Professional Component Homeworks.
WEEK 01 SUMMARY
Accomplishments: Formed design team, decided upon a seemingly appropriate project idea, researched
fundamental concepts of RFID technology and systems, drafted an initial project
idea proposal for course staff to review, determined areas of project responsibility.
Weekly Work Total: 6 hours
Project Work Total: 6 hours
January 18, 2006 (2 hours):
Today we received our initial project idea back in class, and Dr.
Meyer provided some useful feedback about his perceived difficulties with the RFID tag detection and
differentiation. The course staff said our projet was not "tractable". First we spent some time investigating
the concept of tag collision, which is when multiple tags, or tansponders, emit a frequency at the same time,
confusing the reader. This problem was anticipated in our project since many items in the cart will all be
transmitting simultaneously. We learned that while several companies have developed algorithms for
anti-collision that singularize the tags so they appear to send data one at a time, this technology is new and likely
underdeveloped. Rather than experiment in such a gray area for our senior design project, we brainstormed
methods to modify our project idea so that tags were being read one by one. We came up with two modifications:
the first was an RFID garage door that detected tags on the license plate and opened for correct cars only, the
second was a Walmart-like self-checkout system using RFID technology as opposed to the current UPC. The team
seemed unanimously pleased with the later idea, as it was closely related to our initial project idea and
completely resolved the issue of tractability.
We also ran across several websites that discussed practical implementations of our new idea:
Self-Checkout Gets RFID Upgrade
Self-Checkout Popularity Increasing
January 19, 2006 (15 mins.):
After class today, our team spoke with Dr. Meyer about our proposed
change to our initial project idea, and he approved it. We are happy to finally have an official project!
WEEK 02 SUMMARY
Accomplishments: Researched RFID technology and appliations, brainstormed related project ideas, settled
on self-checkout RFID system, had new project idea approved by Dr. Meyer.
Weekly Work Total: 2.25 hours
Project Work Total: 8.25 hours
January 24, 2006 (1 hour):
Jared, Josh, and I met today to discuss our 5 Project Specific Success
Criteria (PSSC). Tomorrow in class, we will give a 1-slide PowerPoint presentation of our 5 PSSC to the class. We
decided upon the following initial PSSC, to be evaluated and modified by classmates and course staff tomorrow:
1. Ability to provide audio feedback ("beep") in response to RFID detection
2. Ability to display useful information on LCD
3. Ability to email customer a receipt of purchase
4. Ability to identify an item by reading its RFID tag
5. Ability to interface with a keypad to input customer PIN
We then designed our custom powerpoint background and organized our brief presentation for tomorrow. Our
PSSC presentation can be found here, as well as on the "Documents" page.
January 25, 2006 (2.5 hours):
The team met today after class to make the suggested revisions to our PSSC, as
seen below (reordered & reworded):
1. Ability to identify an item by reading its RFID tag
2. Ability to enter customer PIN on a keypad for added security
3. Ability to modify the product database via an embedded web server
4. Ability to display useful information on a graphical LCD (e.g., customer ID, scanned item description, etc.)
5. Ability to email customer a receipt of purchase
We also worked to develop a general block diagram so we could
better visualize the components of the project, which Jared helped out with a lot. Afterwards, I spent a while
working on revising our initial project idea from homework 1 for the Project Proposal, or homework 2. Jared and
I explored our new plan to purchase a multi-frequency RFID module that contained a reader and an antenna, rather than
trying to buy the reader IC and build an antenna, as we had previously considered. This solution seems much more
practical!
January 26, 2006 (3 hours):
Jared and I searched the internet for more specific products that met the
design constraints for our project. Our initial aim was to gain a better price estimation for the prototype;
however, we ended up learning a lot more about the options available to us and simplifying our existing block
diagram (for example, we were able to remove a keypad controller and LCD controller). I created the block
diagram, finished writing the Project Proposal for homework 2, had it read and
approved by the team.
Here are some of the components that Jared & I found this evening:
neCore12 MC9S12NE64 Microcontroller w/
10/100 Ethernet, $67.00
TI S4100 Multi-Function RFID Reader
Module, $90.00
Crystalfontz 320x240 negative
blue backlit graphic LCD, $145.00
Storm 16 key
keypad, $45.00
70dB 2.048kHz
magnetic external drive buzzer, $1.00
TI Tag-it HF-ISO Mini Inlay
RFID tags, $1.55/ea
TI Tag-it 13.56MHz ISO Vicinity
Key Ring Transponders, $6.00/ea
WEEK 03 SUMMARY
Accomplishments: Developed acceptable PSSC and presented to classmates and course staff, completed Project
Proposal, corresponded with Symbol reps about requests for demo parts, selected several
candidate components.
Weekly Work Total: 6.5 hours
Project Work Total: 14.75 hours
February 1, 2006 (2 hours):
We had a team meeting over lunch today to discuss the estimated cost of the product
and come up with a plan to start requesting sample parts. Jared and I explained our choice of the microcontroller to the team,
and they agreed with our decision. At least for now, we can't forsee the need to spend more money just to obtain more pins
and built-in peripherals that our application won't make use of.
As for the requesting of sample parts, we staggered our phone calls and emails so that the companies
wouldn't be bombarded by multiple requests for the same part from one team. I was assigned to email TechnologicalArts
about our microcontroller module and special development board. The Micro retails for $79 and the dev. board for $48.
We found out in their response email that they don't give sample parts, but offer a 15% educational discount, which would
bring those prices down to $67.15 and $40.8, respectively.
I also gathered information about Homework 3 and Homework 4, which are due next Friday. The papers are assigned to Josh and
Jonathan, but we're hoping to work on them as a group. On a bad note, Josh found out during his conversation with a TI rep that
the reader module that we had selected actually doesn't include an antenna. I guess the documentation is a bit misleading, because several
of us read it and thought that it did include an antenna adjustable to short and long range frequencies. This
means that we're going to have to work extra hard at finding an affordable one, or rather, a very generous supplier.
February 4, 2006 (3 hours):
Today I did lots of online research attempting to locate similar products that we can compare our project
to as part of the Homework 3 and Homework 4 requirements. Not only was it difficult to find such products, but it was even harder to find a MSRP
for them. I guess this is understandable since the self-checkout system is a commercial product, so generally all that interested people need is a
contact with the manufacturer. I've sent emails to the manufacturer of both of the products below, hoping to hear back on a standard price.
The most similar product that I found was the NCR FastLane, which has
actually been installed in Metro Group's RFID Innovation Center in Neuss-Norf, Germany, a sort of "grocery store of the future". This product is
actually the entire checkout station, but it uses UPC labels to identify the products and deactivates RFID tags on the products to enable them to
pass through security without beeping.
It took a long time for me to locate a second product that was similar to our project. I really wanted to locate the manufacturer of the
self-checkout lanes at WalMart, since those most closely match our design, even though they use UPC labels instead of RFID tags on the purchased items.
However, I learned that the company that originally made those, Optimal Robotics, sold its self-checkout business to Fujitsu Transaction Solutions
in 2004. Their product, called U-Scan, also consists of the
entire checkout station.
Finally, I found a third product that actually utilizes RFID technology, but in a different way. This product, called
XpressCheck, is a self-service kiosk designed for use in a library. It
deactivates RFID labels on multiple books "simultaneously" to enable them to pass through security.
February 5, 2006 (1 hour):
I started helping Josh and Jonathan today on Homework 3 and Homework 4. I did some additional research on
the NCR and U-Scan units, and wrote the Cost Constraints section of Homework 3 & sent it to the group for approval. I hear back from the NCR rep
today... she said that due to company policy and security reasons, they cannot release pricing information for the FastLane. I still haven't
heard at all from Fujitsu, so I'm beginning to assume they're in the same boat. I also learned that only the FastLane installed in Germany is
fitted with the RFID upgrade kit - it doesn't come standard yet. This is important to note in Homework 4 when we're doing the product comparison -
RFID Expr3ss will be the only product of its kind on the market!
WEEK 04 SUMMARY
Accomplishments: Acquired multiple sample parts, including microcontrollers, development boards, and keypad, found several simlar
products available for comparison, began work on Homework 3 and Homework 4.
Weekly Work Total: 6 hours
Project Work Total: 20.75 hours
February 7, 2006 (3 hours):
This was our first team meeting to help Jonathan and Josh get started on Homeworks 3 and 4, respectively.
Everyone came with bulleted points of information that they thought should be discussed in each section of the paper. Jared and I agreed to take
responsibility for the PowerPoint presentation due tomorrow for the TCSP on Design and Packaging
Constraints, as well as the PCB Footprint Layout (since we are working on the schematic and PCB for Homeworks 5
and 6). We also made final decisions on component selection, including changing
our reader to the Intersoft reader/antenna and tags and Fobs (Josh is in contact with
a rep. there to find out more information, as their online documentation is a bit lacking) and selecting a
Storm 16-key keypad as opposed to the Grayhill one that Jonathan procured for us for free. The Grayhill pad just
had a cheap look and feel to it, with hard-to-press, small buttons... not ideal for a consumer application where the PIN is entered from a
distance.
February 7, 2006 (2 hours):
Worked with Jared to design the TCSP and gather information for the component selection and packaging while
Josh and Jonathan worked on their respective papers. Then Jared & I loaded the Orcad software on the home computer and experimented with Layout.
Unfortunately, it isn't the most intuitive software. We had a hard time finding the exact specs for our parts in the data sheets, but once we did,
we had an even harder time finding the parts in the libraries. And then there was figuring out how to move them from being right on top of each
other... LOL. Either way, tonight was a good learning curve with respect to that software, and we feel much more comfortable about having to
work with it on our upcoming homework.
February 8, 2006 (0.5 hour):
Today we had our TCSP in class, and Jared & I went to Nick's office
hours to talk to him about PCB Layout issues. He explained to us how we can add pins to existing parts, and gave us some ideas on design
constraints, such as minimizing board size and footprints, heat considerations, and RFID range (the later two of which we have already thought
about). We talked a bit about TCP/IP as well and anti-collision technology that we might want to incorporate into our software design.
February 8, 2006 (3 hours):
Tonight I spent a long time editing Josh's paper, Homework 3. He had most of it written already, so all we
had to do was fix up stuff and make sure it agreed with what Jonathan's paper said. Either way, a really long night.
February 9, 2006 (3 hours):
Jared and I spent tonight much like yesterday, except this time we were editing Jonathan's paper. His was
considerably longer and had more technical details, so it took a good amount of time. He hadn't written all of the parts yet, so we helped with
the conclusion and the interface requirements section.
We also received feedback today from Dr. Meyer about our Project Proposal and PSSCs... looks like we're going to be doing a bit of changing
those around and adding a printer! It was too late to incorporate those learnings into these homework assignments, though. Maybe later.
Final copies of the submitted homeworks can be found in these links:
Homework 3
Homework 4
WEEK 05 SUMMARY
Accomplishments: Finished HW3 & HW4, completed TCSP on Design and Packaging Considerations, made final decisions on component
selection, procured more parts, completed PCB footprint, contacted more vendors, researched printer parts.
Weekly Work Total: 11.5 hours
Project Work Total: 32.25 hours
February 17, 2006 (4 hours):
I spent a long time working on the schematic today and actually made significant
progress. Jared showed me how to customize parts (as he had done for the uC), so I was able to lay out the Ethernet circuitry, oscillator,
and most of the RFID connections (which consists of a DSUB9 connector the RS232 level traslator). After working on it all afternoon, I had
accumulated quite a list of questions, which I emailed off to Brian and Nick.
Josh and Jonathan went to office hours this afternoon to learn how to do a power supply design. Since all four of us are CompE's, we were
really in the dark about that part, but Nick made it sound easy. Our only problem now is that we seem to have more supply voltage needs than
they originally estimated, since we need 3.3, 5, and 9V (the printer will run on approx. 12V I think).
We also had our design meeting on Wednesday with Dr. Meyer and company. I think it went really well as they didn't seem to have any
pressing questions or concerns. We should be getting our 9S12NE64 demo board for the semester from Chuck, since
the two boards that Josh was approved for never arrived. We also ordered all of our major components for the
project on Tuesday, most of which have already arrived.
February 18, 2006 (5 hours):
Jared and I spent a long time finishing up the Orcad schematic today. Nick
and Brian got back to us pretty quickly with answers to my questions. Most of my trouble came when trying to
determine which of two seemingly identical components to select in Orcad, such as for the 25 MHz crystal
oscillator and the DB9 connector. We still have a few lingering questions that the TAs weren't able to resolve:
1. Our LCD has a Vee pin that we're not sure what to do with; Nick suggested that it was for the backlight,
but we've already supplied the +/-5 V required for that.
2. Our MAX233A level translator has an "Internal +10 V Power Supply" pin that we're not sure what to do
with; we've already supplied the +5 V power supply for the chip. Nick suggested that we follow the application
notes as closely as possible for our design, but the data sheet doesn't go into detail about the internal
power at all.
After completing all of the net aliases and organizing the schematic in the most visually-appealing way
possible, we generated the netlist (which passed all the design rule tests!) and found a major setback - we hadn't
used surface mount components for all of our resistors and capacitors, and as a result, there were no footprints in
Layout available for those and other headers and miscellaneous parts. After correcting this problem by changing
all of the resistors and capacitors, we generated the auto-layout in Layout. We then started making custom
footprints for all the components, starting with the RS232 connector. The datasheet was helpful, but some of our
other ocmponents are not as well documented online.
Follow the link below to find an image of the current schematic, v1.0:
Orcad Schematic
February 19, 2006 (2 hours):
Tonight I started on the Homework 5 paper, which is my responsibility.
I wrote the introduction and made a skeleton for the summary. The schematic has come along considerably well and
we are learning more about Layout every day. I haven't yet added the power supply
circuit into the schematic... all the supply voltages are simply marked with their required values.
Tomorrow Jared and I are meeting Chuck to get our demo board for the semester and picking up the last
of our ordered parts which seem to have arrived in the mailroom!
WEEK 06 SUMMARY
Accomplishments: Ordered all major components, had first design review, completed Orcad schematic,
began writing Homework 5.
Weekly Work Total: 11 hours
Project Work Total: 43.25 hours
February 21, 2006 (1 hour):
I met the team in the lab today so that we could hopefully get some questions
answered about our power supply design, as well as learn more about how to route parts in Layout. For the power
supply, we've been struggling with the need to produce 3.3, 5, and 9 V supplies. Our printer comes with its own
12 V wall-wart, which we were advised to let be, and use a separate wall-wart for the rest of our needs. However,
with the voltage regulator chips that Jared was looking at that take in 12 V and reduce it to 3.3 and 5, we would
dissipate something like 5 W of power! We spoke with Dr. Meyer about doing a step-up DC/DC converter, so Jared is
doing some research on that - he found some TI parts to sample that we think might do the trick.
As for our questions about Layout, I think the team is just frustrated right now because none of us has
experience using Layout and exactly how to use it hasn't been spoken about in class at all. Thankfully, we found
the tutorials to be very helpful.<\p>
February 21, 2006 (9 hours):
Tonight I got a significant start on the Theory of Operation section of
Homework 5. It really is a lot of work searching through all of the datasheets we've compiled and explaining
the operation of all the pertinent signals. I have some holes in the paper, mostly that I have to clear up with
Jonathan. He was in correspondence with Star Micronics to get us the thermal printer, and they sent us a 7 V DC
regulated power supply when the data sheets say that the printer requires 8 - 13 V. I guess we'll have to contact
them again and see if they know something that we don't.
I also spent a good amount of time working on the TCSP for tomorrow. Taking images of the modules of
the schematic was actually helpful because I found a few minor errors that we had to correct. As of now, the
schematic at least looks complete, with the exception of the power supply circuit.
The PCB is still a rat's nest right now, but we've been working hard on designing custom footprints and, as I
explained, still have many questions about routing that we need to get answered.
February 22, 2006 (6 hours):
The team met in the lab today to accomplish many different tasks. I spent
nearly all of my time writing and completing HW5. I posted it on the site tonight so the team
can read it and provide feedback sometime tomorrow. Jared worked very hard on the PCB Layout and pretty much
started over from scratch again. Nick was a good help to us today, and seeing some other teams' PCB Layouts today
in class for our Schematic and PCB Layout TCSP gave us a much better idea of what we should be doing. We learned
that the RFID tags and key fobs actually have about a 4 - 5 inch range, which is right about
what we expected.
Here is our completed Homework 5 and Schematic
and PCB Layout TCSP.
February 23, 2006 (2 hours):
Tonight I worked with Jared to help him write Homework 6 about the
PCB Layout Design. We actually learned of some additional considerations as we were researching for the paper,
so I guess we'll have to include those in our successive iterations of the PCB (which we're sure we'll have to
do). Jared also helped me with editing my paper. Luckily, we were also able to clarify the confusion
over the power supply for the printer - even though the documentation says it requires 8 - 13 V, the
rep for the company says that the printer only needs 7 V because the actual active range is 6 - 14 V. So
at least we think we've finally finished the power supply design for good!
I also prepared a Design Project Change Order Request to be submitted tomorrow in order to change
our PSSC #5. Dr. Meyer had originally written our PSSC #5 as: "An ability to store a local copy of the
product database in non-volatile memory, and update the database via an embedded web server." The team's original
plan was to have an on-chip database; however, after considering the ideal implementation of our system if it was
to be widely used within a supermarket, we decided it would be better to move the databases off-chip. Thus,
we proposed our new PSSC #5 to read: "An ability to gather product and customer data by querying an external
database (using Ethernet)." The actual wording of this new PSSC was discussed with Dr. Meyer in class a
week or so ago, so we don't really have any doubt that it will be approved.
Here is our completed Homework 6 and an updated copy of our
PSSCs.
WEEK 07 SUMMARY
Accomplishments: Finished power supply design, gave Schematic and PCB Layout TCSP, completed Homework
5 and Homework 6, finished initial PCB layout, submitted Design Change Request for
PSSC #5 to move customer and product databases off-chip.
Weekly Work Total: 18 hours
Project Work Total: 61.25 hours
February 26, 2006 (5 hours):
Tonight I got started on the Formal Design Review Presentation for
later this week. I basically filled in all the slides except the packaging design one... I'm not
really sure what we're going to put there yet. Josh did the packaging design paper, but his CAD drawing
is not at all up-to-date because we didn't have the printer incorporated into our design yet. I'll
probably just ask him to do this slide.
Jonathan and I worked on developing a flowchart for the software logic. I was actually surprised
at how simple it seemed to be. Most of the design is interrupt-based (keypad, RFID), so our main
program is largely just "waiting" for some event to happen. Jared put the flowchart into the computer
so we have a digital copy.
I also made a new block diagram for our overall design, based on suggestions that Dr. Meyer
mentioned in class. It is much more specific now, with bus lines labeled with their widths, which is
something we couldn't have done on the original block diagram anyway because our components were not yet
selected.
Some fruits of my labor tonight:
System Flowchart
New Block Diagram
February 27, 2006 (6 hours):
Jared and I worked today making minor updates to the schematic
and PCB, and I completed the rest of the presentation slides needed for our Formal Design Review tomorrow.
I spent a lot of time practicing since the 35-minute timeline is pretty rigid.
The masterpiece:
Formal Design Review
February 28, 2006 (5 hours):
Today was the Formal Design Review. Dr. Meyer, Nick, and Brian made many suggestions about modifications
to our schematic and PCB, so Jared and I made lots of progress on them today. Nick suggested that we
remove the keypad encoder and just wire the 8 keypad pins to the uC (since we have so many unused I/O pins)
and code it in software. This should save us space on the board by getting rid of the IC. Also, the
micro has internal pull-ups and pull-downs that are programmable, so we are able to remove ALL the SIPS...
that will free up lots of space and make rerouting much simpler for Jared and the PCB.
They made some more really good points that we looked into - Brian was concerned about the voltage
swing on the LCD, at 5 V, obtaining its signals from the 3.3 V micro. We checked the data sheets and found
that for the LCD, V_IHmin = 2.2 - Vdd, and for the micro worst case, V_OHmin = Vdd - 0.4 = 3.3 - .4 = 2.9 V. So,
we won't need a level translator in between.
Since we hadn't actually ordered our discrete parts yet, Nick pointed out that some of our footprints
on the PCB were too small, such as for the caps on the power supply and the 25 MHz crystal. I guess our team
hadn't been too concerned about ordering discrete parts yet because there were supposed to be many available
at the window, and we didn't actually need to do the parts acquisition until the Friday before spring break.
After the presentation though, we decided that we might as well order the parts if we know what we need,
so Jared and I spent the evening searching DigiKey and ordering them all.
Jared is also going to work on rerouting the PCB, since Nick and Brian informed us of more
design considerations to take into account. Our Ethernet circuitry is still too far away from the micro,
which surprised us since the traces on the 9S12NE64 dev board that we got from Chuck aren't incredibly short and we felt
ours were comparable. Nick also said that traces should overlap at 90 degree angles in the Ethernet circuitry,
so we're going to try to work on that. Oh yeah, and apparently we didn't create a net for our copper pour
underneath the voltage regulators... oops.
March 4, 2006 (5 hours):
Jared, Jonathan, and I met in the lab today. Jonathan worked on the
software to try to understand more about Code Warrior. Apparently there is a file missing from the installation
that is required for the NE64.pe. After installing an updated version of Processor Expert, we were able to find it.
It ended up being a waste of time though because we have since decided not to use Processor Expert for the start-up
code. Jared and I sorted through all of the discrete parts data sheets to make new custom footprints for the
larger pieces, such as the polarized caps, the inductors, the Schottky diode, and the crystal. We placed all the
footprints on the PCB, but haven't started the routing yet, hoping to get homework feedback soon.
WEEK 08 SUMMARY
Accomplishments: Prepared for and delivered Formal Design Review, updated schematic according to
Design Review suggestions, ordered and received all discrete parts, began revisions on
PCB.
Weekly Work Total: 21 hours
Project Work Total: 82.25 hours
March 7, 2006 (2.5 hours):
Jared and I went to Brian's office hours today to ask him some final questions
related to the PCB. We are having difficulty finding a 1500 pF polarized cap for the power supply circuit. Since
the capacitor merely connects a pin to ground, Brian told us we didn't need a polarized one, so we were able to get
one from the lab. We were also concerned about whether our DB9 connector was of the right gender - the printer
comes with a male end, and we're making the RFID connector from scratch, but we currently have two male footprints
on our PCB. Brian said it didn't matter if we put gender changers on the connectors or not.
We later made a few updates to the PCB routes and change the pin orientation on
the header for the LCD on the schematic. Since our PCB was fully routed and finished, we decided to do our
Parts Acquisition and Fit early with Brian. He checked us off for everything. We have made a few modifications
after that, merely putting labels on the silkscreen. Tonight Jared and I are going to redline the PCB before
we submit it to www.freedfm.com.
March 9, 2006 (2 hours):
Jared and I redlined the entire PCB design with the schematic prior to
submitting it, and were glad that we found no errors. We then submitted the PCB to www.freedfm.com, though we had
some difficulty determining how to label some of the files (i.e., which ones were "NCDrill" and what to do with those
that didn't match any options... we put "other" in most cases I think). The results came back that we had around
200 "autofixable" errors, which Brian told us had already been taken care of. Nearly every one was the result of a
problem with the solder mask.
Some updated documents:
RFID Xpress Schematic v4.0
PCB submission, top copper
PCB submission, bottom copper
WEEK 09 SUMMARY
Accomplishments: Completed Parts Acquisition and Fit (HW7), redlined schematic and PCB, submitted PCB
to www.freedfm.com and emailed it to Chuck.
Weekly Work Total: 4.5 hours
Project Work Total: 86.75 hours
March 19, 2006 (6 hours):
Jonathan, Jared, and I went to the lab today to continue working on software
development. Since we have now acquired a BDM connector that actually works (3.3V instead of 5V) from Chuck, we
were able to upload the startup code to the uC and run some demos. Right now we're having difficulty controlling
some of the output pins on Port G and Port S... when we connected a 7-seg. LED to do some debugging, we were
getting erratic output. We thought it might be a problem with the DDR bits, especially since Port S is typically
used for serial communication, but we disabled all of that in the control registers. We eventually built a prototype
for the keypad, with its 4 row lines on PTS0-3 and 4 column input lines on PTS4-PTS7. We then wrote a piece of
code using the following simple algorithm:
1. Assert first column, leave all others low
2. Scan each row in that column to see if one is asserted; if yes, output key number to 7-seg LED
3. Repeat steps 1-2 for remaining columns, loop infinitely
We were able to successfully identify some key presses, and found the problem... PTS0 seems to be
driving 3.3V to the keypad as opposed to being an input to the uC. This is contrary to how we have our DDRS
register set, so we're going to work on this problem again later.
Code Listing:
Keypad Polling Code
WEEK 10 SUMMARY
Accomplishments: Ran startup code on uC, prototyped keypad, generated preliminary keypad code.
Weekly Work Total: 6 hours
Project Work Total: 92.75 hours
March 21, 2006 (1.25 hours):
Today Jared and I completed our prototyping of the PIN entry pad. We still
could not figure out why the PTS_PTS0 port is driving 3.3V, and neither could Brian. So, we moved the row input
lines to Port J, which worked as expected. We are now able to correctly identify which key is pressed.
We also added code to compare a 4-digit PIN entered by the user with one stored in memory, and to illuminate
a blue LED if matched and red LED if not. We realized that the fast speed of the polling was registering
many digit inputs when the user just pressed one button, so we added functionality to only capture one key press
per key release. We also removed the 10 kOhm pull-down resistors we were using on the row inputs and programmed
the internal pull-downs on the uC.
At this point, we're not concerned about the problems with the SCI Port 0 on the demo board since our design will
actually implement SCI communication through both SCI ports (as opposed to using it for general I/O, as we
were trying to do in this case) on the microcontroller.
Code Listing:
Keypad Polling Code with PIN Verification
March 22, 2006 (3 hours):
We accomplished a lot in lab today related to the serial communication. Jared
and I began prototyping the RFID reader using the SCI Port 1 on the evaluation board instead of the demo board that
we had been using. Previously, we were having trouble with the Port S0 bit, as it was driving the output high to
3.3 V. However, the SCI port responded accurately when we used the eval board. We were able to generate code to
detect the RFID serial number and display it to Hyperterm. One problem that we predicted actually came true - the
9600 baud rate to transmit bits, combined with the speed of scanning by the RFID reader, actually cause the reader
to detect the same tag multiple times (usually between 1 and 4) for each time it is "passed" over the reader.
However, I have multiple ideas of how to handle this - the first and easiest of which would probably be to store
the most recently scanned RFID serial number in memory and only register a "detection" of a tag if it is different
from this previously scanned serial number.
After our success with the RFID prototyping, we began working on the printer, which also utilizes the SCI
Port (0). Programming the memory switches on the printer was a very interesting task, but the online documentation
was extremely helpful. We set 3 of the 16 switches to be "ON" - the first (S1-1) set the communication protocol as
serial instead of USB, the second (S1-7) set the flow control to XON/XOFF so that no handshaking was necessary,
and the third (S2-1) set the character set to be USA standard (which is actually considered overseas, not
domestic).
We wrote a function to send the RFID serial number bits that were scanned directly to the printer,
which worked well for the most part. The only anomaly that we experienced was a single digit that was printing
out prior to the start bit (a colon) of each RFID serial number... the digit varied from 3 to C to B to 6 in a
seemingly random fashion - I'm wondering if there is something wrong with our baud rate (which was published
directly in the printer documentation) or if those characters are simply stuck in the buffer somehow. We were
happy to realize, though, that those random preceeding digits only appeared when we were transmitting the RFID
data directly to the printer; whenever we programmed specific text to be printed (such as the logo we made for
the top of all the receipts), the digits never appeared.
Code Listing:
RS232 Serial Communication Code
RFID and Printer Prototyping
March 24, 2006 (4 hours):
The team met in lab today to work more on the Ethernet code and the PCB. Our
board came in yesterday, so I completed "Ohm-ing out" the traces and inspecting it under the microscope -
everything looked to be fine. Jared and I worked together to solder on the power supply circuit and test the
voltages. We are getting very clean 3.3, 5, and 12 V signals thus far, but we are going to leave it on for the
night to burn in the circuit.
We found one slight error on our PCB - the footprint for C27, a 100uF capacitor,
was too small. Another cap, C30, is the same value and had a much larger footprint. Luckily enough, we were
able to find another 100uF electrolytic capacitor in the lab that was smaller than the one we ordered from
DigiKey. It is still quite a tight fit, but we were able to solder the pins and have a nice signal across the
cap.
March 25, 2006 (2 hours):
Today we went into lab to check on the power supply circuit and work more on
the Ethernet code. The power signals still looked good, so I continued populating the board by soldering on
all of the bypass capacitors. After doing so, the signals were verified again, and power was being provided
accurately to all the ICs. I also helped Jared with the Ethernet code, since we are still having problems
establishing a link when using the BDM (since the auto-generated code from Metroworks utilizes the serial port,
both of which we are using in our design). We were able to successfully load the code using the BDM after getting
some tips from James Doty. Later, Josh and Jared were able to spoof an ECN computer on the uC, so we are
confident that we've finally figured out how to connect to the internet.
WEEK 11 SUMMARY
Accomplishments: Completed keypad, RFID, and printer prototyping, populated power supply and bypass caps
on PCB.
Weekly Work Total: 10.25 hours
Project Work Total: 103 hours
March 28, 2006 (2 hours):
Today the team met in lab to make more progress on the software development.
While Josh and Jared worked on the Ethernet code, I made our first
Code Module Hierarchical Diagram (made into digital work by Jonathan later that night).
After sketching it out, I began writing a hybrid of code/pseudocode on my
implementation for the main, HandleRFID, PollKeypad, PrintReceipt, and EmailReceipt functions. I also worked with
Jonathan to make modifications to his upgraded Software Flowchart.
March 28, 2006 (3 hours):
Tonight the team met to prepare for the
Software Narrative TCSP tomorrow. We
had several design decisions to make, as all of the code we've developed thus far has been modular (and we didn't
really need to decide how the implementation would work at that time). Our checkout design will be controlled using an
"Interrupt-Flag-Driven-Polling-State-Machine" algorithm. The main program will loop through a series of states
(some examples include "IDLE", "PIN ENTRY", "ACTIVE SESSION", "RECEIPT", "PRINT/EMAIL", etc.), and depending on
the state, will check if a particular flag has been set by an RFID interrupt, keypad press, or an LCD change request.
If that flag was set, then that condition will be handled, the flag cleared, and the state updated. Prior to looping again,
we will verify if a keypad entry is expected in this state; if so, then we will poll the keypad and capture any
data, setting the keypad press flag.
We also decided upon how we will handle an RFID interrupt. We concluded that data on the SCI1 port will
trigger the RFID interrupt, and the ISR will simply set an RFID flag. Inside the main loop, if the flag is set in
a particular state, the HandleRFID() function will be called, where we will strip the serial number off of the SCI1
port and into SRAM. We had previously entertained ideas of storing the serial number in memory during the ISR, but
concluded that this other method of handling would coincide better with our general organization of quick interrupt
service routines and handling within the main loop.
March 30, 2006 (4 hours):
Jared and I worked with Jonathan to help him write the software narrative
paper. Specifically, we discussed implementation issues with the LCD and RFID interrupt handling. I also edited
Josh's paper as well.
Our most recent homework assignments:
HW9: Patent Liability Analysis
HW10: Software Design Narrative
WEEK 12 SUMMARY
Accomplishments: Completed Software TCSP, finalized general software organization, helped complete
HW9 and HW10.
Weekly Work Total: 9 hours
Project Work Total: 112 hours
April 4, 2006 (5.5 hours):
The team met in lab today and really made decent progress on the project. I
spent most of the time soldering the PCB - mainly the oscillator, RS232, and ethernet circuitry. Jared really
wanted to solder the headers, so I let him do that. We were able to load a heartbeat program (lighting an LED)
onto the microcontroller as well. This was a major milestone, as it was the first time we loaded a program onto
our uC. This verified the functionality of the BDM as well as the 25 MHz crystal.
After I finished the RS232 circuitry, we loaded a modified RFID code segment to capture serial numbers
of RFID tags and keyfobs. Jared created a local database to simulate our own, and Jared, Josh, and I were able
to add to the code we already developed. It is now able to search the local database for a serial number and
return the item name.
We haven't tested the ethernet circuitry yet because Josh is still working on understanding UDP and being
able to properly send and recieve packets. However, the board is entirely populated with the exception of the LCD
inverter module (which we chose to leave off until Jonathan has finished his code development on the LCD) and the
GAL22V10 with associated headers (since we might have to program it first, if we even need it at all).
Here are the newest images of the PCB:
PCB - fully populated (top)
PCB - fully populated (bottom)
PCB - oscillator circuitry
PCB - Ethernet circuitry
PCB - power supply
April 5, 2006 (1 hour):
Today we had a progress briefing in lab, and told Dr. Meyer that things
are going pretty well with the project right now. Chuck was able to provide us with a heat-dissipating copper
sheet to attach to our 7 - 3.3 V voltage regulator. Hopefully this will help reduce its operating temperature, as
we learned yesterday that it sinks considerably more current when we're actually running programs on the uC
(something we hadn't noticed when we did the 24-hour power supply burn-in).
Afterwards we attempted to load
some code to test the Ethernet circuit, but it was unsuccesful. I spent a while looking over datasheets and
discovered that at least a few of our pins (including Tx and Rx) on the schematic did not agree with the
Ethernet circuitry in the 9S12NE64 datasheet. Then I had to leave for another meeting, so Josh and Jared took
over. See their lab notebook entries for the solution they developed to the problem, which successfully
enabled us to ping the board by the end of the day.
April 6, 2006 (3 hours):
Tonight Jared and I worked on developing our main code for the program. It was
adapted largely off of the pseudocode that I developed a few weeks ago,
except this time we implemented our I.F.D.P.S.M. (Interrupt Flag Driven Polling State Machine) concept. We
finished most of the state transitions this evening, and have only the CANCEL_SESSION, PRINT, EMAIL,
SESSION_END, and FINISH_SESSION states remaining.
April 7, 2006 (1.5 hours):
Tonight Jared and I finished up the state transitions for the main program
and began including code functions that we have already written during the prototyping phase, such as
HandleRFID() and PollKeypad(). In both cases, modifications had to be made to the original functions. In
HandleRFID(), we removed the functionality that compared a serial number with a local list of serial numbers and
returned a customer name associated with that number, since this will now be handled in QueryDB(). Also, in
PollKeypad(), we removed the functionality that compared the keys entered with a stored PIN, since that is now
handled directly in the main function during the CAPTURE_PIN state.
Also, we decided to modify the way that we
handle PINs... we had originally used an int, and multiplied each digit entered by the appropriate power of 10 to
get a final 4-digit PIN. However, we realized that this would be difficult to deal with if the user pressed the
CLEAR button during PIN entry, meaning he/she wanted to remove the most recent digit. So, we have chosen to
store PINs as arrays of 4 characters.
Main Code and RFID/Keypad functions, v1.0
April 8, 2006 (2 hours):
Today in lab, I designed an output diagram for Jonathan's UpdateLCD() function
that utilized the states assigned in main() to determine what to display to the LCD. I came up with the general
organization of the shopping cart and gave him a state-by-state listing of what needed to be displayed. Jared and
I also began building a larger scale prototype system on the eval board, including the RFID reader, keypad, and
printer, to test the functionality of the main code and RFID and keypad functions we completed yesterday. We're
still working on debugging the compile errors, so hopefully I'll have some completed code to display tomorrow.
April 9, 2006 (6 hours):
Today was a long but successful day in lab. Jared and I continued to debug
the main code, and tried to implement interrupts with the RFID reader on the SCI1 port. However, as of right now,
we haven't been able to get them to work. The interrupt bit on the CCR register is set, we have set the
RDRF and RIE bits in SCI1_CR2, and the interrupt vector table properly points to the RFID interrupt handler.
Yet, neither the eval board nor our uC is able to properly detect an interrupt.
Jared came up with a way to simulate the interrupt just by polling the SCI1 data port each time through the
main loop (just now for debugging purposes). Hopefully we can get some help from Brian or Nick on Monday and
figure out what we're missing. Our eval board is also not properly communicating through either SCI port, which is
odd. We have resorted now to doing most of our debugging on our actual uC, since it is working beautifully.
Since Jonathan had completed UpdateLCD(), we ran it on the demo kit. I helped Jonathan and Jared debug
some errors that he had, especially with the formatting of the shopping cart screen. Afterwards, we were able
to get it working pretty well, as you can see below.
I also wrote the code for the PrintReceipt()
function today (bottom of main program). It built off of the
RFID/printer code that we developed earlier, as well as the data structure
organization that Jonathan determined with UpdateLCD(). The data structure specifies how our queries of the
database will return the user and item information. I tested the code with the printer and made this really
cool receipt!
Receipt!
LCD shopping cart
WEEK 13 SUMMARY
Accomplishments: Completed board population (excluding LCD), developed main, RFID, keypad, and printer
functions.
Weekly Work Total: 19 hours
Project Work Total: 131 hours
April 10, 2006 (2 hours):
Today Jared and I spent more time today trying to get SCI interrupts to work
for the RFID reader, and we were finally successful. We were suspicious of the CCR "I" bit from the beginning,
since we couldn't get ANY interrupts to work, not just the SCI. We thought that it made logical sense that
interrupts were enabled if the "I" bit was set. We tried to de-assert the "I" bit just in case, and it worked.
April 11, 2006 (2 hours):
With the RFID interrupts finally working and Jonathan having made some
special header-to-header cables, we decided to attach the keypad to our board and debug it. We have had to
relocate the 8 keypad wires (4 row wires, 4 column wires) to a different location on our PCB than was originally
planned because we learned after PCB submission that the ATD port cannot be used as output, and then we further
learned that although it can be used for digital input, it does not have a pull device register, and hence will
not allow the rows to be read correctly. The debugging of the keypad didn't go very well since we are getting
strange results - the enter key doesn't register ever, and the "3" key registers as the enter key. More debugging
to come soon, I guess.
I also spent some time making modifications to Jonathan's UpdateLCD() to fix some minor problems with
wording and the display overall. We think that the LCD code is generally complete except that I would like
to work on making a non-trivial function (if time permits) to calculate the length of dynamic fields,
such as the user name and item name, so that when they are displayed to the LCD, they are properly centered
and visually appealing.
April 11, 2006 (3.5 hours):
Tonight the team met to begin preparing for the TCSP tomorrow that focuses
on the FMECA worksheet for HW11. Josh and Jonathan worked on the powerpoint while Jared and I calculated
lambda_p and MTTF values, as well as determined possible failure modes for the design.
TCSP - Reliability and Safety Analysis
April 12, 2006 (3 hours):
After the TCSP this morning, Jared, Josh, and I went to the lab to try to
figure out why the keypad was still not working. Initially, all they keys were being registered properly by
polling the keypad at the end of the main loop, with the exception of the "3" key and the "Enter" key. We
determined, as I said earlier, that the error could not be with hardware because the other 2 columns and 3 rows
worked perfectly. Therefore, we reexamined our logic in the code structure to try to find a fault. We made
many different iterations of modifying the code - using RTI interrupts to poll the keypad, switching rows and
columns on the headers, removing the keypad from our board and prototyping it again on a breadboard to ensure
the proper key presses were actually sending out asserted signals. At one point, the keypad wires had been
attached to Port T, Port S, Port G, and Port H of our uC, and none of them solved the problem.
Jared thought that maye we were dealing with a race condition where the columns weren't being asserted
fast enough on the keypad before we checked if the rows were asserted. We finally had an idea to change the
location within the code where we increment the pollCounter variable
and perform the column strobing. The pollCounter variable is used to keep track of which column is asserted as we
poll the rows to see if any of them are asserted - by knowing the intersection, we can determine exactly which key
was pressed. After moving the column strobbing into the timer interrupt and setting a flag to poll in the main
loop, as you can see in this copy of the main code here, the key presses
on ALL the keys were working properly!
April 13, 2006 (4 hours):
I spent this evening completing the Homework 11 paper - Reliability and Safety
Analysis. I also edited Jared's paper once he completed it.
Homework 11 - Reliability and Safety Analysis
Homework 12 - Ethical and Environmental Impact Analysis
April 15, 2006 (3 hours):
Today in lab Jonathan and I worked on writing code for the Java server app to
maintain a copy of the shopping cart on the server side. I wrote the
MakeReceiptBody() function
that structured the email message to be sent to the server. I also helped Jared to connect the RFID reader,
printer, keypad, and LCD to all of the proper locations on our board, and we began the task of modifying all of our
test code to use the correct port pins for our board. We weren't able to finish tonight, but we'll work on it more
tomorrow.
April 16, 2006 (3 hours):
Today was a monumental day in lab! We completed our integration of all the
peripherals and made many changes to the ports and register settings in the code. We powered up our board to
start testing the states of the main loop. We found that the LCD was not initializing properly because the
reset never flashed and the startup screen wasn't displayed. While Jonathan worked on rectifying that problem,
Jared and I continued to debug the circuit without the visual aid of the LCD and found that the RFID interrupts
were being received correctly and the board was sending accurate user and item packets to the server. It was
also returning the proper matches with user or item information. The keypad was also being polled correctly.
Jonathan was working with some of the wires on the LCD and found that some of the connections were not good, so
he re-crimped the ribbon cables he made while Jared and I had to leave.
When Jared and I got back, Jonathan had left but the LCD was functioning! We ran the main code again
on the board and were very pleased with the results. It properly registered a key fob, identified the user and
prompted for the PIN, correctly identified an incorrect or correct pin, began a "shopping session", identified
RFID tags on items and properly received item data from the server, correctly handled a "cancel" or "clear" request
from the keypad, and registered an "enter" keypress to end the shopping session. We had to make several minor
changes to the code - one to fix the spacing on the shopping cart on the LCD since we had changed our field
length for the item name from 30 to 25, one to adjust the spacing of the total, another to fix an integer overflow
we were experiencing when calculating and displaying the total of the shopping cart to the LCD, and yet another to
properly adjust the total when the user removes an item from the shopping cart. The only things that didn't work
were that it didn't send an email receipt (because we were not connected to the Ethernet at the time) and it didn't
print a receipt. Jared and I were confused because we have tested the printer numerous times and know that it
works, even on our board. However, this time we used an actual gender changer to connect the two male connectors
together, which was the first time (we had made a gender changer on our own for debugging), and we think that
it is possible that the female-female gender changer switches the Tx and Rx pins. This could be causing our
printer problems. Next week we'll probably have to make another proprietary cable for the priner too!
We are elated to have most of the project functioning! Some changes that we anticipate making in the next
few days are changing the LCD to only show the hours and minutes (so that it doesn't refresh every second), adding
in a "default" state to the main loop to prevent it from going into a "zombie state," and working on the RFID
interrupts to minimize the number of "item not recognized" messages we receive and prevent the user from
scanning one item more than once.
Check out the main() function and the
UDP client app here.
Also take a look at the test circuit setup and recent PCB images:
PCB with Keypad and LCD Wires Connected
Test Circuit with Breadboards
Test Circuit with Breadboards Removed
WEEK 14 SUMMARY
Accomplishments: Successfully implemented SCI interrupts, debugged keypad logic on our uC, completed
HW11 and HW12, modified LCD code to properly display messages, completed Ethernet code, debugged
packet sending, wired entire board, got complete board up and executing main code properly.
Weekly Work Total: 20.5 hours
Project Work Total: 151.5 hours
April 18, 2006 (2 hours):
This afternoon in lab Jared and I continued to debug the entire circuit. We
hooked the board up to the Ethernet and emails sent successfully. However, the printer still wasn't working. We
looked at datasheets for the gender changer and used the DMM to find that it was wired straight through, so the
Tx and Rx pins weren't switched as we had thought. We then figured that the problem might be due to a lack of
current on the new power supply for the printer, as we used the 7 V supply that came with it to power the entire
board since it had a higher amperage. But when we moved the printer back onto the demo kit with the new power supply,
it worked fine. We then realized that we had never actually printed from our board with the printer because we had
only just recently bought the new power supply for it, so the problem might be with the SCI0 port. We changed all the
printer code over to operate on the SCI1 port, but it still didn't work. We then changed all the RFID receiver code
over to operate on the SCI0 port to see if it was functional at all, and it worked. I was skeptical of the RS-232 level
translator chip but had to leave for class.
When I returned, Jared found that the error was actually in the schematic - we had wired an active low FORCEOFF pin
on the chip to ground when it was supposed to be wired to +3.3 V. This was disabling the SCI transmission entirely. After
cutting the pin and wiring it high, the printer functioned properly.
This image helps explain the fix that we made:
RSS232 Level Tranlator Fix
April 19, 2006 (3 hours):
Today we had our last progress briefing with Dr. Meyer, and we were able to tell him that
the project (or at least the PSSCs) were entirely functional. Chuck was able to get us copper tape to solder to the 5.0 V
regulator to help dissipate heat from the LCD backlight. Jared and I worked on fixing more bugs in the design, such as adding
comments to the database which differentiate between items and users so that a user cannot "purchase themselves" by swiping
his/her keyfob during a session (previously, the user's name, email, and PIN had been printed to the shopping cart on the LCD).
We found and corrected a bug in the print receipt function that incorrectly printed a '1' as the 1's digit of every total (I had
hardcoded a total of "$1111.11" at the start of the function for space holders and never actually overwrote the last character with
the real total). I also worked through the code adding comments and formatting it to be documentation-ready.
We were ready to tape our PSSC videos when we had a major problem with our circuit operation. After cleaning up our station
for the video, we reorganized the circuit and moved everything (keypad, LCD, RFID reader, printer, board) closer together so it
could all get in the shot. Then, the RFIDs stopped generating interrupts and the keypad began to function erratically.
We determined that the range of the reader had decreased tremendously and was only rarely detecting tags. We think that this
was due to some type of interference from the other components in the design. Luckily this won't be a problem because the
reader is separate from the station and attached via a 3 foot cable. We believe the keypad problems were a result of faulty
connections on the ribbon cables, so we are considering soldering at least one end of the ribbon cable to decrease the possibility
of error (though this would pose a problem if it ever needed to be replaced in the future).
Click here for the most recent copy of our main and supporting functions.
April 20, 2006 (4 hours):
Today in lab we videotaped our 5 PSSCs separately using Chuck's video camera
after he helped us fix problems with the tape. We also got our aluminum faceplate back from the machine shop after
they milled a hole for the LCD and an "X" for our logo. Jared and I drilled the holes for the LCD mounting.
Later in the day, Josh brought in the rest of the packaging, spray painted black. When we put all the
components inside, however, the keypad began acting erratically. On the LCD, we could see that the keypad was
registering keypresses automatically for the user's PIN and could not authenticate the user. We realized that
the back of the keypad, when touched by hand, would register keypresses (since the backing is made of metal). We
found a rubber material that came with the keypad, which we attached to the back of it to try to shield the keypad
from the aluminum. We didn't think that alulminum should be conducting or holding a charge, but somehow, that's
what seemed to be occurring. After mounting the keypad with the rubber shielding, it still was registering
automatic incorrect keypresses. We discovered that the aluminum face probably needed to be grounded, so we
soldered on some additional headers to the PCB where the headers for our GAL22V10 would have been (now unused)
and flywired a ground signal and power signal to them (the extra GND and PWRs will be used for blue LEDs
that will be mounted inside the packaging to illuminate the "X" in the logo). After attaching a ground terminal
to one of the screws on the aluminum faceplate, everything worked perfectly. The RFID receiver was now properly
shielded from the other system components as well.
Here are some of the newest final images of the system:
Packaging - Front View #1
Packaging - Front View #2
Packaging - Rear View
April 21, 2006 (2 hours):
In lab today we taped our PSSCs again, this time in one continuous video
and inside our final packaging (the previous videos were taken before the packaging was complete). Nick also
demo'd our project to ensure that we satisfied all of our PSSCs. Then Jared and I went to Radio Shack to
buy the blue LEDs for the logo and the plexiglass sheet to protect the logo and LCD.
April 23, 2006 (4 hours):
Today I completed the
Senior Design Report and posted it on the website for the rest
of the team to read over.
WEEK 15 SUMMARY
Accomplishments: Identified and fixed problem with SCI0 printer transmission, debugged LCD display and
server communications, completed assembly of project packaging, videotaped PSSC demonstration,
demonstrated PSSCs to Nick, completed Senior Design Report.
Weekly Work Total: 15 hours
Project Work Total: 166.5 hours
April 25, 2006 (2 hours):
This afternoon I got started on the User Manual document, mainly working
on the marketing-style introduction and establishing a skeleton file for the rest of the report.
April 27, 2006 (4 hours):
Jared and I went to Radio Shack today to purchase more blue LEDs of
higher intensity. We mounted them inside the case by flywiring resistors between the LED leads and the
unused header positions for the GAL22V10. We also printed some decals for the case that included our logo and team
name. It looks really neat and professional now.
Final Packaging - Front View #1
Final Packaging - Front View #2
Final Packaging - Front View #3
April 27, 2006 (2 hours):
Jared and I worked together to organize the
Bonus Presentation for ECE270 for tomorrow. Most of the information
was already written in the summary report or in a previous TCSP, so it wasn't too difficult to compile.
April 28, 2006 (3 hours):
Tonight Jared helped me finish the User Manual.
At times it was difficult to write because we wrote it from the perspective of a commercially available product,
which would have somewhat different setup instructions than our prototype system currently does (i.e., populating
the database automatically vs. typing the serial numbers and products in by hand, etc.). We posted it on the site
for Jonathan and Josh to review.
April 29, 2006 (4 hours):
I spent this evening making revisions to my HW5 (Schematic & Theory of
Operation) and HW11 (Safety & Reliability Analysis) assignments and adding them to the final report. Much of
the schematic paper had to be altered due to changes in the port assignments that we were forced to make during
development (such as the relocation of the LCD wiring from the ATD ports which could only be used for input, which
thereby displaced the keypad assignments). Once the report is fully completed, it will be uploaded to the
website.
April 30, 2006 (12 hours):
Jared and I spent this entire day revising and editing the final report.
There were many updates that needed to be made to particular papers, especially the design considerations
and software narrative. I also completed the Version 2 Changes and the Summary and Conclusions sections of the
final report.
Click below to view the final product:
Final Report
WEEK 16 SUMMARY
Accomplishments: Completed exterior design of packaging, delivered PSSC videos in class, delivered
bonus presentation to ECE270 students, completed User Manual and individual sections
of final report.
Weekly Work Total: 27 hours
Project Work Total: 193.5 hours