The PaLFi Demo app is a built-in application for OpenTag. “PaLFI” means Passive Low Frequency Interface, and it is a TI product line for 134.2 kHZ half-duplex, RFID systems. ISO 18000-2 HDX is possible to implement on these devices. Likewise, it can be used as a side-channel for DASH7 networks, a source of asynchronous events, or even potentially as a method for wireless charging. The PaLFI demo app is a good application to use if you want to start developing these types of applications, because in this app the PaLFI-OpenTag interface is already implemented and attached to the OpenTag kernel.
The PaLFI demo app contains two sub-applications within OpenTag, and it also needs a PaLFI Gateway device.
A relatively normal OpenTag application that acts as a gateway and listens for packets coming from the Slave device. The Master supports the full API, so any kind of behavior can be commanded from the client. Almost any OpenTag platform can support this application.
A special OpenTag application that runs on a board including a TI TMS37157 (or similar) PaLFI transponder. The TI RF430F5978 SiP contains a CC430 core and a TMS37157 core in a single package, so it is an excellent device for use with the PaLFI Slave.
PaLFI LF Gateway
Additionally, the PaLFI demo app needs a PaLFI LF Gateway/exciter. This firmware is pre-loaded onto the TI RI-ACC-ADR2 board, and there is a PC-based client program that comes with this board which you can use to send PaLFI messages. There is also a PaLFI-Gateway (TMS3705) driver and stack firmware codebase that is distributed with OpenTag, but it is experimental. The PaLFI PHY is software-generated, so it generates a lot of interrupts and tends to require its own MCU.
The PaLFI Demo Application is somewhat unique, because there are not many components that support PaLFI. All components that do support PaLFI are from TI.
Here is a guide to compiling and running the PaLFI demo app using CCSv5 from TI. Other toolchains are possible, too, and they will be documented in the future.
The PaLFI demo is part of the mainline OpenTag distribution. The best way to get it is through Git, but archived packages are available occasionally. See the Code Archive for more information on downloading the mainline distribution.
Once you have downloaded the codebase, put it somewhere easy to access. There is a main directory called “OpenTag_M2.” Inside that directory, there is a directory called “apps/demo_palfi/” which is where the PaLFI demo project is stored.
Important: Preparing File Linking
You will need to map a Drive B, or alternatively manipulate the project file to find the codebase. There are instructions from the link above, which apply to all OpenTag projects in CCS. If you do not do this, the project will not load or compile.
Once you map drive B (or do file-linking adjustments), the CCS project is ready to build and load.
Click on the Project folder you want to compile (Master or Slave), then use Project→Build Project. It should build without errors if you have done everything properly.
Common Errors and Resolutions
I will assume that you are using a eZ430 wireless USB Stick for the Master and a RF430 Fob for the Slave. Both of these boards are loaded (and debugged) via SpyBiWire, using the eZ430 debugger tool. A picture of this setup is shown below, using the RF430 Fob board, and this setup is very similar to the one used by the USB Stick.
Important Note for the RF430 Fob Board
You need to make sure that board is supplied with 3.3V or more when it is being debugged (or loaded via the debugger). The battery included with these boards will quickly get drained below 3.3V, and when this happens, the debugger will not work. The wires in all these pictures are connecting Vcc to a 3.3V source (they are also connecting an I2C bus, but I2C is not required).
Make sure you have a suitable LF Gateway board and the RF430F5978 EVM Software (for Windows) that is made available by TI. Without the Fob board or the master board connected, we can validate that the board is working. In the WakeUp Mode tab, press the “Send Wake Pattern” button and verify that an LED on the LF Gateway board blinks. If you select “continuous transmission,” then the wakeup will be generated once per second.
There is also a trimming feature, which can be used with the Fob board by holding-down the left button (during the trimming process).
Once you turn-on the slave, it will go into default idle runtime. It should look something like this video below. Each 1 second there will be a short listening event. Each 4 seconds there will be a short beacon event. The beacon event is helpful, because it caches (and resends) the latest application data acquired by PaLFI (more information on this later).
There are three user buttons on the board, and they are near each other. The other button, which is near the power switch, is the reset button. If you push the middle-button or right button, a manual process will run, and a DASH7 message will be transmitted. You can see the beacon LED blink when the message gets transmitted.
If you hookup the LF Gateway to your PC and run the PaLFI Demo App, you can send wake-up signals that the Slave will detect asynchronously. This behavior is quite similar to the button-event behavior, except that there is data interaction with the PaLFI core. Additionally, if you hold-down the left button, an LF Trimming process will occur. One thing to note is that the communication between the PaLFI core and the MCU is quite slow. After the PaLFI process runs, the Idle-time behavior will most likely get a little-bit out of synchronization because the PaLFI processing task is blocking the initialization of one of the Idle processes (listen or beacon).
The final step in the PaLFi demo setup is to validate the Master. If the LF Gateway works, the Slave works, and the Master works, then everything is working.
The Master (USB Stick) will turn-on when you plug-it into a USB port. It will work with Mac, Linux, or Windows, but with Windows you need to make sure to install the driver stored in
OT_ROOT/otplatform/msp430f5/usb_cdc_driver. Once it turns on, the LED (on the antenna side) will blink a few times, and then it will wait 5 seconds for the computer to discover it. After the 5 seconds is over, it will go into normal runtime. During normal runtime, it listens almost all the time. Occasionally, it will send a beacon. There is only one LED, and you can detect the beacons when the LED flashes (quickly) more brightly than when it is on for listening.
When the Master receives a message from the Slave, it will print the message in OTcom. The message will look something like below: (to do)
This message is formatted in binary when it is sent over the air, and the Master converts it into formatted text before it reported to OTcom over MPipe. OTcom can also take some types of unformatted data (and format them into text itself), but this message is NDEF-encapsulated text. OTcom is recommended to download (it is free), but you can probably read it over other console apps as well.
The format of the message is not too difficult to understand
|ID||8-Byte Device ID of the Slave, in hex|
|Data||8 Bytes of data, in hex, from the PaLFI message that gets forwarded over DASH7|
|Event||A Wakeup Type A|
|B Wakeup Type B|
|1-8 PaLFI button number that was pushed (only 1 and 2 supported on RF430 board)|
|RSSI||3D LF RSSI from Slave, in dBm (there is a list of three values)|
|Temp||Temperature detected on Slave|
|Volt||Voltage detected on Slave|
MPipe is a standard interface for OpenTag, which usually connects a server to a client over something like UART or USB. Other communication ports are possible. MPipe is not required for the Slave, but it can be helpful for debugging, or possibly for other purposes.
The RF430F5978 does not have an available UART, because the only UART on the CC430 is used to communicate from the CC430 core to the PaLFI core (actually, it is SPI, but the UART resource is unavailable due to this SPI on USCIA0). The second serial interface is available, and it supports SPI and I2C (but not UART). Pins 2.0 and 2.1 are available through the 8 pin header on the Keyfob board, and they can be used as the MPipe if they are mapped to I2C on USCIB0.
If you want to use the I2C for connecting to I2C devices, then there is nothing more you need. If you want to use it for debugging, then you need a converter that can bridge the I2C port into something available on a PC (such as a USB port). FTDI makes an I2C-USBCDC bridge called the FT201X which can serve this purpose. There are also two convenient modules for this part (via Mouser): UMFT201XB-01, UMFT201XA-01.