Week 9: Further Lab experiments with Moo

Last week was shortened due to the 4th of July holiday.  On Monday, July 1st 2013, Denis placed three additional Moos in the 9th row of the rear wall and one Moo on the 9th row of the side wall.  He placed the Moos such that an antenna (half ground and half signal) would be poking into an empty cinder block (note there is very little clearance).  We are hoping that this orientation may allow us to better communicate  with the reader during the curing process by mitigating the effects of attenuation.  In our laboratory experiments, we found that if the signal antenna is poking out of a fully submerged Moo inside water, we can still get a reading.

Inside the lab, Mike and I performed some additional experiments with the Moos to better understand how they would respond in two new environments: subzero temperature inside a mini-fridge and submerged inside wet sand.

Fridge Experiment (7/1/13)

  • We placed a Moo inside of the fridge in a relatively static position along with the reader.
  • Logged data and recorded observations (see google doc Moo/Experiments).
  • TODO: plot data using R (Denis)
  • Observations: Noticed a sudden drop in tag rate several times during experiment.  Not sure what was causing this – maybe a subtle shift or moisture from the fridge.  When opening the door and closing it again or repositioning the Moo inside fridge, we were able to get rate back.

Wet Sand Experiment (7/1/13)

Water Experiment (7/3/13)

  • placed Moo inside very small puddle of water with antenna underneath.  No tag rate as long as water is barely touching the signal (right) antenna.
  • Moo Tx_counter resets after pulling Moo out of water (even after very short amount of time).  This implies that the Moo is not able to receive power from reader nor communicate with water because volatile memory is reset.
  • Ground antenna can be completely submerged inside water without affecting the tag rate.

Possible Ideas to improve communication

  • Measure length of dipole antenna (as a multiple of lamba).  How would performance be affected if we increased (maybe doubled) the length of the Moo antenna.  Re-solder a longer antenna on to the Moo and measure performance affects.  Who is the expert on this? Post question to the Wisp forum.

Reading this Week (with Notes):

Radiation and Antennas (chpt. 9) of Emag textbook: basic principles of antenna design (includes dipole antennas)

  • Most effective performance (max power density) when object is placed at 90 degrees off of dipole axis (i.e. perpendicular position).
  • Current flowing through dipole antenna has symmetrical distribution wrt center of dipole and current is zero at its ends.
  • [Impedance Match] to maximize power transfer to the load, the load impedance must be chosen such that ZL = complex conjugate of Z in (i.e. RL = Rrad and Xl = -Xin).
  • Friis Transmission Formula: Power transfer ratio P_received/P_transmit = Gt*Gr*(lambda/4*pi*radius)^2.  (i.e. Inversely proportional to radial distance squared)

Next Steps (??)

  • begin development of Moo 2.0 PCB Board modifications (have finished and sent before August)
  • begin making poster for ESWeek.  Gather Notes & place info inside google doc.  What editor should I use? LaTeX?  Some Ideas on general format and structure?
  • Test other ideas to improve tag rate before side wall and front wall deployment begins (roughly 2 weeks from now).

Week 8: Moo Concrete + Tag Rate concerns

Last week was relatively slow in comparison to the week before.  Due to rain plus other delays, the contractors were not able to make much progress on the house and we were not able to deploy any additional Moos.  However, this gave us some time to go over to the house to investigate why the the Moos that we currently have in the wall are not transmitting data back to the readers.  Other than one lone tag transmission from the far right Moo on the rear wall, we were not able to get any readings.  While it is expected that the concrete mixture will attenuate the signal, we are still hoping that the tag rate might improve as the concrete dries further.  This has led us to investigate new approaches to getting around this issue.

Possible solutions to improving Moo penetration as of right now:

1. Adding an air-gap around the Moo antennas (possibly using a straw or other contraption to prevent the concrete from hardening right over the antenna).  We found that the tag rate does not suffer nearly as much when the Moo has some air separation.

2. Lengthening/altering the Moo antennas to peak out of the empty cinder blocks.  Since the antenna length is inversely proportional to the transmitting frequency, this may pose some issues.

3. Modifying the transmitting frequency to improve tag rate. While we are bound within certain limits and cannot arbitrarily change the frequency (need a new radios), we may find that there is a certain frequency that penetrates through concrete much better.  The theory tells us that the lower the frequency the better it will penetrate through certain materials.  I will continue to read up on some of the theory behind antenna and RFID design.

Also, it would be nice to know with more certainty if the Moos are not being powered sufficiently or if the problem lies with actually transmitting the data back to the reader.  It will be hard to test this, but I think we could perform an experiment with an unpotted Moo that we probe with the Fluke to see how Vdd is affected by the the water.  We will need a bag to prevent the equipment from getting wet.

Additionally, last week I made some final revisions to the following two google docs regarding the potting process as well as more info on the concrete and temperature measurement philosophy.

1. https://docs.google.com/a/umich.edu/document/d/16Wkrig_IKuzrpk8N1KOeCJ-F8KR8KhrSXs1LUeLVyjw/edit#heading=h.pfvqeful6fy1

2. https://docs.google.com/a/umich.edu/document/d/17-RQcx9tDLwJc1nJJYHpBYMYCrXHmBGo6Rju0_xRYmU/edit

Next steps

1. read more articles on RF signal basics and their properties. (e.g. http://my.safaribooksonline.com/book/certification/cwna/9780470438909/radio-frequency-fundamentals/radio_frequency_behaviors)

2. perform some experiments with air-gaps and/or metal backing to see how tag rate is affected.

Week 7: Moo Concrete Deployment [On-site]

Last week was spent mostly on-site at the house setting up the readers and Moo devices for deployment.  We began by first flashing the 20+ working Moos from the lab with the latest working firmware (see past post for details).  Half of the Moos were flashed to default to a temperature sensor and the other half defaulted to the accelerometer sensor.  After recording the status of each device and encoding its unique ID type in the EPC field, Denis began epoxying the devices to ensure their protection from the elements.  Image

After epoxying the devices, we ran some tests to see how water and moisture would affect the tag rate and overall communication with the reader.  We found that when the Moo is completely submerged in water it is not able to communicate with the reader.  This motivated us to perform some additional experiments to see how the the tag rate would vary with the moisture content of concrete.  After obtaining some wet concrete (mixed with pebbles instead of sand), we performed an experiment to see how the Moo would perform as the concrete dried.  We used the thermal chamber (at 65 degrees) to speed up the drying process.  We found the tag rate increase as the concrete began to dry.  We plan on using this test as a baseline for what to expect from the actual deployment process.  Details of the experiment available below.



After purchasing all of the necessary equipment from Home Depot (Plywood, electrical tape, zip ties, power cord extensions, ethernet cables, etc.), Denis constructed the stand to hold the antenna and readers in a vertical position at various heights (2 ft, 4 ft, and 6 ft).

Photo Jun 19, 8 22 52 AM

The rest of the week was spent on-site setting up the readers at the house and waiting as the concrete blocks got built up to a sufficient level on the back wall.  We agreed upon the following positioning for the Moo devices in order to give us maximum coverage and provide measurements near where the wall had cracked in the past.

Moo Placement – Rear Wall View

We decided to use the duraWall ladder (placed every 2 ft high) to attach the Moo directly to the inner front face of the cinder block via a zip tie.  This allowed us to place the Moos as close as possible to the readers – reducing signal attenuation from the concrete.

Photo Jun 21, 9 58 27 AM

Rear wall before cinder blocks got laid (Wednesday).

Photo Jun 19, 12 59 45 PM

Once the contractors were ready to pour the concrete, we immediately began the data logging from the readers to hopefully capture the curing temperature curve of the concrete.

Photo Jun 21, 11 08 06 AM

First batch of Moos get deployed inside concrete (two temperature-defaulted Moos plus a supercapped Moo).  Note: we experienced more difficulty when trying to reader from the supercapped Moo (middle antenna).

Photo Jun 21, 10 37 08 AM

Second round of Moo’s get deployed at 4 ft high level (one accel and one temp)

Photo Jun 21, 4 41 51 PM

Note: we are limited by the number of reader that we currently have on-site (four total) and thus we will not be able to take measurements from more than four Moos at any one point in time.  Since the wall is being slowly built up (and hence cured in the mean time), we are hoping to capture most of the curing process by repositioning the reader antennas as the concrete dries.

Photo Jun 20, 1 29 39 PM

Next Steps

In the coming week, we will continue to remain on call as the contractors build up the rear wall to the 9th row of cinder blocks.  After this point, all eight Moos will have been implanted in the back wall and we can record all necessary data.

Week 6: Moo Concrete Deployment Cont. (Troubleshooting)

This past week was spent mostly updating the current Moo firmware and troubleshooting issues with the temperature and accelerometer sensor readings in preparation for the concrete deployment next week.  Originally, we had intended on modifying the software from the last deployment, which used a remote procedure call (rpc) command to toggle between three different applications: kill, beep, and read temperature.  However, after struggling for several days to get the firmware to successfully report back the accelerometer (and temperature) readings via the 2B data field (known as ackReply), we decided to completely change direction with how we programmed the Moo devices.  After a string of emails between Ben, Shane, and Andres, I requested a meeting to iron out some of the details that may have been lost over email communication.

Mike and I worked on adding functionality to toggle the accelerometer and external temperature sensors directly by using the existing application (SENSOR_DATA_IN_ID) and calling a new sensor header file (sensor.h) which includes the required functionality to initialize, read, and sample both of these sensors.  After gaining access to the Umassmoo GitHub page, we created a new branch (Moo_Concrete_MI) and committed all of our changes directly to the online repository.  A link to the GitHub branch with the most up-to-date version of the software can be found here.  Note that this software was modified from the software used to run the “Saturn Demo”.  Some superficial changes were made to the Impinj Reader Software Application in order for reader to interpret the 12-bit ADC values correctly.  Using the sensor_counter along with a simple modulus operation, we were able to achieve the toggling function in a few lines of code.  The appropriate sensor data is then sent back via the EPC directly (6 B of data for accelerometer and 2B for temperature).  The first byte indicates the sensor type (0x0B for Accelerometer and 0x0F for external temp sensor).  Though this solution is slightly less elegant than sending a rpc command directly to the Moo device, it requires less memory overhead and results in a significantly better tag rate at short distances from the reader.  Since the concrete will increase attenuation of the signal from the reader, it is very important that we keep the communication between the reader and the Moo devices simple to avoid excess energy consumption.

After logging some “noisy” temp data from the Moo devices, I did some further investigating to figure out some of the sources of the sensor variations and why they seemed to be inconsistent between trials.  I found that the temp Data appeared different if one were to vary the tag rate (i.e. distance from the reader) or step-through the code with the JTAG Debugger.  This led me to further probe several of the pins on the Moo device in order to get to the root of the problem.  Using the Fluke multimeter, I looked at Vreg, Vout, and Temp_Data_Analog to see if these voltages were consistent between experiments.

Below are a list of peculiarities that may need to be addressed in future revisions of the hardware and/or software.

1. Vreg (i.e. output of the voltage regulator) operates at 3.4 V when the JTAG Debugger is connected as opposed to it’s regulated value of 1.8 V when powered strictly by the reader.  Even when changing the configuration of the jumper on the Moo header board, Vreg remains at around 2.8 – 3.0 V when the JTAG device is plugged in.  This will likely cause some variations in the sensor readings (due to multiple power levels) and overall performance of the Moo devices when plugged in.  In order to minimize variations between the plugged-in vs. reader-powered performances of the Moo, we should consider connecting the JTAG (3.4 V) power supply to Vout (i.e. input to the regulator) as opposed to the regulator output directly.  This will allow the regulator to step-down the voltage to 1.8V for the MCU and sensor periphals (hence keeping the operation more consistent).

2. The MSP430 Chip supports an internal Voltage reference of either 2.5V or 1.5V that can be configured via the software and used to keep ADC and sensor readings consistent.  However, I noticed that originally the External Temperature Sensor function (adapted from quick_accel_sensor.h) was set to use the 2.5V volt reference instead of the 1.5V for ADC sampling.  This poses a problem because the functionality (and hence temp sensor data) will be different based on whether or not the JTAG device is plugged in (i.e. the power supply of the MCU changes).  I was able to confirm these differences using some simple math (NADC = 4095 * Vsense/Vref), and modified the code to work with the 1.5V reference generator in order to keep the measurements more consistent.  Note: A 2.5V reference generator will likely get clipped to the voltage supply (Vss = Vref = 1.8V) on the chip and not return a consistent measurement.  I fixed this problem by making a simple modification to the temp sensor code.

3. In the user manual for the MSP430 chip, it mentions that a 10 uF cap in parallel with a 0.1 uF cap should be connected between Vref and AVss- on the chip in order to keep the internally generated voltage more stable.  I did not see this cap present on the schematic and/or PCB board.  While I do not find it to be of critical importance, we should make sure to include this on the next generation of the Moo.

I also spent some time last week modifying the sensor.c file to sample from the internal temperature sensor on the MSP430.  The code was adapted from the int_temp_sensor.h file found on Hong’s old computer.  However, I was not able to get the code to run correctly.  Specifically, the code gets stuck in a infinite loop waiting for the ADC to sample the voltage from the ADC and set the ADC12BUSY pin low.  I have requested a copy of the internal temp sensor code that was used by Ben in the past.

I performed some thermal chamber experiments to help further validate (and/or calibrate) the external temperature sensor on the Moo devices.  I placed the Reader Antenna and Moo device directly in the chamber and swept the temperature from 25 deg C to 60 deg C with a rate of 3 deg C/min and let the device cool back down to room Temp.  The details of the experiment can be found below along with a plot of the data.  As can been seen from the plot, the ADC value (and hence voltage) do indeed decrease as the sensor is heated up.  This agrees with the temp sensor spec sheet provided here.  From the ADC value I was able to to calculate the analog voltage of the temp sensor using the equation: V_temp_analog = 1.5 * ADC_Value/ 4095 and then calculate the expected temperature using the look-up table provided in the spec sheet (using the lowest gain setting).  At 26 deg C and 60 deg C, I found that the expected temp agreed with the actual temperature with less than 2 deg error.

Thermal Chamber Experiment

thermal chamber plot

Next Steps to be completed before Deployment

1. validate all working Moo devices with latest firmware.  Make sure to flash devices with correct serial # (change MOO_ID in mymoo.h to correspond to correct tag identifier listed on device).

2. re-solder antennas onto semi-working (yellow) Moo devices and retest functionality.  record results in google doc.

Week 5: Concrete Deployment of Moo Devices

This week was spent purchasing the necessary parts and modifying the firmware of the Moo devices in preparation for the concrete deployment that will be taking place later this week.  Specifically, we need to make sure that the remaining Moo devices in the lab (more than 20+) are able to successfully run the most recent firmware.  We are also trying to implement additional functionality on the devices that will allow us to read accelerometer data and possibly humidity information directly.  However, this is a stretch as a we will need some additional circuitry to accurately measure the capacitance of the concrete and we likely do not have enough time to gather everything and test it before next week.

Without the original Reader software that was used to toggle the application (beep, kill, temperature sensor) it is difficult to verify that software will perform exactly as intended once we deploy it into the concrete.  However, we were able to successfully beep the Moo device with the piezo element attached by calling the function directly in main.  I plan to perform similar tests to try and kill the device (i.e. erase the memory) and read the temperature data on the device by directly calling these functions in main.  We can then use the debugger to verify that they are returning the correct results.  This will also allow us to learn a little bit more about how the current software is exciting.

We will be soldering capacitors onto 25% of the Moo devices (~5) and distributing them throughout the home.  We visited Professor Fu’s house on Thursday to survey the basement and decide on where we will be placing the devices.  We agree on putting  8 Moo’s on the rear wall, 6 on the side wall, and 6 on the front wall in a parallel diagonal formation.

Next Steps (To be completed before deployment)

-continue to validate Moo firmware.  Add accelerometer functionality to dispatch table and test this using the debugger.  We may need to send the information in 3 consecutive packets (one for each axis) depending on space limitations.  Note: need 2 Bytes per dimension.

-purchase plastic casing for the Moo devices to help improve the sound-emitting ability of the Moos.  Q: Should we epoxy the piezo buzzer? This will likely make it hard for the piezo to vibrate and emit a tone.

-solder supercaps onto 25% of Moos.

-epoxy the Moos and wait to cure (last step before deployment).  Perform some functional tests after epoxy has settled to ensure functionality.  Consider pouring the epoxy in steps and testing in between.

-get ready for deployment… as soon as the contractor’s are ready to pour the concrete.

Week 4: Wolverine MCU Migration

Most of the this week was spent studying the schematic and design files (from Hong’s computer) and comparing the MCU on the current Moo design (Part # MSP430F2618) with the  Wolverine MCU (Part # MSP430FR5969).  Essentially, I have been mapping out the necessary steps that will be needed to make the migration from the current MCU to the Wolverine chip.

More info on Wolverine chip available here.

I spent time studying the schematic design and board layout for several different iterations of the Moo devices (Moo 1.0, Moo 1.1, Moo 1.2, Moo 1.3).  Primarily I was interested in seeing what past work had been done in regards to the board design and how it has progressed through each iteration.   See embedded document below for a brief overview of some of the differences that I noticed.

Comparison of Moo Board Revisions

After looking over the features of each of the different board revisions, I plan to branch off of the design labeled Moo 1.1_03102011.  This design represents the current version of the Moo devices so we know that it is a working design.  The later designs seemed to have been created to test other aspects of the devices, such as…

  • comparison of linear voltage regulator with switching regulator, toggle-enabled
  • new MCU chip, Part # CC430F6137

I copied the appropriate design files from Hong’s computer and plan on working in the Altium Designer 10 environment that is installed on the CAEN computers (virtual connection).

Notes/Questions on Wolverine Migration

  • The Wolverine chip uses a 48-pin QFN package as opposed to a 64-pin LQFP

—> may need to completely reroute this portion of the PCB board, depending on               pin placement and extent of similarity with F2618 chip.

  • Ordered and received 2 Samples of the (prototype) Wolverine Chip. Is there a place that we can go to fabricate (and assemble) 2 boards only? SierraExpress? Should I place another order for Samples (max. 2 chips at a time)?

Next Steps for Migration:

  • make integrated component for 48-pin QFN package with schematic symbol in Altium 10
  • place and route component onto the board.  Study datasheet for details on pin descriptions.

Moo Concrete Deployment Project

Objective: Embed several of our current Moo devices into concrete for real-world testing.

Task: find out which firmware was used in previous concrete deployment.  Need to enable a Kill switch, and possibly OTA updates.

From Ben, current version of firmware found here.

Note: Firmware does have a kill switch, but does not have support for over-the-air updates.

Next Steps:

  • validate Moo devices with current firmware.
  • possibly modify FW to support OTA updates??

Week 3: Choosing a PCB Design Software [Moo]

This week was spent primarily studying the hardware that went into the current version of the Moo (1.1).  I started by attempting to open up the PCB design files that were generated using the Altium Designer W09 software.  After realizing that this software is not available for free online, I started to look into other free PCB designer software that might be easier to obtain.  I created a word document that highlights some of the pros and cons of several PCB design software (Altium Designer, Eagle CadSoft, and PCB artist), see below.

Choosing a PCB Design Software

My Recommendation:

After looking at the various PCB Design software available,  I would recommend using the Altium Designer for future updates of the Moo device.   My initial concerns with this software (i.e. expensive license) have been mitigated after finding out that the software is available on all CAEN engineering computers.  Furthermore, since the previous PCB design files were created with this software, it will take significantly less time to make future modifications to the board.  Also, it is less likely that there will be a problem associated with the board if we only make minor modifications (if necessary) to the microcontroller footprint as opposed to laying out the entire board from scratch with a new software.  I will continue to learn how to use the Altium software in the coming weeks.