Week 14: Moo 2.0 Schematic Design finalizing

Last week, I spent most of my time finalizing the Moo 2.0 schematic design.  I have finally made all of the corresponding connections with the rest of the circuit and have a design that I believe is ready to be laid out.  Attached is a copy of the current schematic design as of this writing.

Moo2.0_draft_080913

I set-up a meeting on Friday to review the design with Ben Ransford, Jeremy Gummeson, and Noah Klugman.  They mostly agreed with the methodology and placement of the connections other than a few suggestions regarding the net name nomenclature and placement of the header board signals.  I plan on making some slight improvements to the design regarding these suggestions and reviewing the schematic with Noah Klugman one last time.  I am hoping to start the layout of the PCB board by Tuesday of this week and have most of it finished by the start of next week.

Notes/Suggestions from the Meeting

  • Change board dimensions (make shorter) to account for the reduced pin count of the headers and smaller size of the MCU.
  • Maybe move transmit_rfid farther away from the Accelerometer inputs to avoid any noise induced from the higher frequency transmit_rfid signal (640 KHz).
  • rearrange external header connections so that it is easier to attach daughter boards for additional sensors (e.g. piezo buzzer, solar panel, etc.)
  • consider replacing the analog accelerometer sensor with a more efficient digital sensor from Analog Devices (ADXL362).  This accelerometer has a built-in temperature sensor, as well, resulting in a more unified design with less components.  It is going to be used on the upcoming Wisp 5.0 design.  It will add some additional complexity to get it set-up in software but it may be worth looking into.  Since it communicates via SPI, I was think of possibly purchasing breakout board (Sparkfun?) that we can connect to the Moo to test its performance before committing to it.  I would like to keep the design changes incremental in case anything may go wrong.
  • Talk with Jeremy about the Program Header board.  It may have a hardware bug regarding the Vdd connection that will need to be addressed.
  • remove the NC (“No Connections”) on the ADXL330.  Some are inconsistently connected to ground or Vdd.  Verified this with the datasheet and Sparkfun’s breakout board.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s