Knowledge Amulet Prototype


Description of the How the Prototype Works:

  • The main pieces involved are: the Knowledge Amulet device, a paired Android phone running the Knowledge Amulet app, and the backend Knowledge Amulet web server.
  • The user has an account on the website, and there are multiple “Knowledge Sources” in the database that are associated with particular categories and RFID codes.
  • When the android app boots up, it connects to the knowledge amulet via bluetooth.
  • When an RFID tag is scanned with the amulet, the code is sent via bluetooth to the android phone, which then tells the web server (via WiFi/HTTP) that this user has encountered this particular knowledge source.
  • The web server records this data for the user in the database and responds to the android phone with the updated status of the user’s “knowledge profile” (i.e. this user now knows 21% science things, 50% art things, 18% history things, etc).
  • The android phone then computes how the LEDs should light up based on this profile, and communicates this data via bluetooth back to the amulet, which lights up the LEDs accordingly (i.e. 20% of the leds are green for science, 50% are red for art, 18% are blue for history, etc).
  • To summarize, the basic data pipeline looks like this:

Parts Used / Explored:

Issues Encountered / Prototyping Process:

  • The RFID chip can’t supply enough current to activate an LED and buzzer when a tag is scanned.
The RFID chip was the first component I began to play around with. First, I just wanted to make sure it worked, so I hooked up the BZ pin (which, according to the datasheet is held high for a second or two after a tag is scanned) directly to an LED and buzzer. However, the LED and buzzer never went off, and I assume this was because the RFID chip couldn’t supply enough current to the components. With a bit of experimentation, I settled on hooking up the BZ pin to the base of an NPN transistor and then attaching the LED and buzzer directly from the 5V power supply to the emitter/collector junction, which worked well.
  • The RFID chip can output data in multiple different formats depending on pin configuration.
My next step was to figure out how to read the data coming out of the RFID chip when a tag gets scanned. To do this, I hooked the Rx/Tx ports of chip directly to the Tx1/Rx1 ports on the Arduino Mega and wrote a small sketch to display the data coming in. This didn’t work right away, and eventually I realized this is because the RFID chip can output data in different formats (and the serial format that the Arduino was expecting was not the default setting). Reading through the datasheet again, I realized that a few pins that I didn’t think I needed to use (FP,RST) actually needed to be tied to 5V or GND to configure the chip to use the serial format. Once I did that, the Arduino read in the tag data fine.
  • The bluetooth chip is configured by default to speak at 115200 baud whereas the RFID chip uses 9600 baud
I next wanted to get the Bluetooth chip working. Setting the RFID chip aside temporarily, I hooked the Bluetooth module’s Rx/Tx ports directly up to the Arduino’s Tx1/Rx1 ports and wrote a short sketch to try read and write some data via bluetooth.
The first issue I encountered was that the bluetooth chip was configured by default to speak at 115200 baud, whereas the Arduino was expecting 9600 baud. So I wrote a quick arduino sketch that allowed me to type commands into the arduino Serial Window to configure the bluetooth module, and using the commands detailed in the datasheet, I was able to configure the module to speak at 9600 baud.
  • The Rx/Tx ports are not reversed when dealing with bluetooth
After getting the bluetooth module speaking to the arduino directly, I wanted to make sure it could actually speak to another device via bluetooth. So I paired the bluetooth module with my computer, exported a Serial Port for the device, and wrote a short ruby program to read and write data to the port.
The issue I encountered here was that I had assumed that when writing data to the bluetooth module from the ruby program, the data would arrive on the Rx port. Similarly, when reading data from the bluetooth device, I assumed the data had to be pushed onto the bluetooth’s Tx port. This is how it normally is with most IO devices (and is also how the RFID chip works). However, with the bluetooth module, the ports are reversed, which I think is a result of how the bluetooth protocol works. When a third party device is paired with a bluetooth device, it is almost as if the third party device is embodied from WITHIN the bluetooth device and controls its Rx/Tx ports directly, rather than talking to it as if it were a remote device.
  • Bluetooth chip deals with 3.3V whereas RFID chip and Arduino deal with 5V
Once the RFID and bluetooth modules were working independently, I wanted to get them working together. Upon first hooking the two up together, they simply didn’t work. Upon reading through the datasheets, I had a hypothesis that this was because the bluetooth module uses 3.3V whereas the RFID chip and Arduino use 5V, so they wouldn’t be able to communicate with each other. I tried using a transistor to amplify the signal from 3.3V to 5V and upon inspecting the signals with an oscilloscope, it seemed as though my hypothesis was right. The yellow line (bluetooth Tx port) seemed to be much smaller than the blue line (amplified signal). It still didn’t work however, so I spent a while trying to get rid of the weird skewing and reversing I saw in the amplified serial data by swapping out the transistor I was using for other types of transistors (NPN vs PNP for example). Eventually, however, by using the oscilloscope’s measure function, I realized that the output of the bluetooth module was indeed 5V (not 3.3V…which I assume is due to all the circuitry on the breakout board) and actually didn’t need to be amplified. Somehow, after that realization, the original circuit I tried before all this transistor stuff suddenly worked again, and I have no idea why it didn’t work before.
  • Surface mount parts are hard to prototype with.
The plan for the final device is to use 12 of the WS2801 ICs and 12 of the RGB LEDs. So I bought some of those parts to build the prototype with, but Sparkfun didn’t have a breakout board for them. I tried using cardboard and copper tape to make my own breakout boards, but they were just too fragile and too difficult to work with. Eventually I found an LED strip laying around that had all those ICs and LEDs all integrated and chained up, and I decided to use that for my prototype instead.
  • The LED strip uses lots of current and takes away power from other components.
Initially when hooking up the LED strip to the rest of the circuit, the RFID reader stopped working. I presumed this was because the LED strip was using too much power and didn’t leave enough for the reader to function correctly. I spent a while building a separate power source just for the LEDs, but nothing I tried was able to supply enough current to the LEDs to light them up brightly (see video below in which the LEDs fade out after a few seconds). Eventually I tried the original circuit again, and magically everything worked without hindering the reader’s performance. Again, no idea why it didn’t work before.

Lessons Learned:

  • Don’t prototype with surface mount parts unless you can also easily get or make breakout boards for them.
  • Trust in Sparkfun breakout boards. They’re awesome and handle tricky power and voltage level issues.
  • Power supply stuff is annoying.
  • When something doesn’t work, leave it alone for a little while then try again later. It’ll probably work then.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>