April 2004, Issue 165

BasicCard 101 (Part 2):
Use in a Liquid Nitrogen Monitor

---

CARD FIRMWARE

Table 1 shows a list of the commands that I’ve defined in the BasicCard for this application. The last column in this table indicates where the command is used: The LN² Dispenser is labeled “AVR.” The PC application personalizes the card and later reads the accumulated total usage (labeled “PC”). The balance reader is the little key fob device that comes with the development kit.

Table 1—These six commands are implemented in the BasicCard for this application. As you can see, some commands are used by both the LN2 dispensing controller and the PC application that personalizes and reads the cards.

The PersonalizeCard command, which the PC application uses to initialize the card with user information and zero out the balance, is the only command that requires encryption in order to work. This guards against the possibility of fraudulent card production. ZeitControl’s Visual Basic API, which is part of the development kit software, includes support for encryption. This command is only used by the PC program that personalizes the cards, and that is written in Visual Basic. Although not a concern in this application, the fact that the BASCOM AVR BasicCard library does not currently support encryption could be a disadvantage in other applications.

For this application I used the BasicCard ZC3.9 enhanced card, because it was included with the development kit. However, the lesser models of the card would work as well because this is a simple application. In the first part of this series I gave you some hints on how to program the BasicCards by supplementing the instructions in the user manual. 

AVR FIRMWARE

Next, I’ll describe the program that runs on the ’8535, which controls the ² dispenser.  After some initialization of the ports, the program basically enters a loop. The program prompts you to insert the card and then waits for this to happen. The ReadCardData command is then issued to the BasicCard, and the user information contained in the card is displayed on the LCD. You are then prompted to enter the amount of ² needed. This amount is first added to the BasicCard’s balance variable, and then the program waits until you indicate you’re ready for the dispensing to start. It then activates the relay for the amount of time necessary to dispense the necessary ².

This is where calibration is needed. When dispensing ², it takes a little while for the transfer tube to become chilled enough to pass the liquid. Thereafter, the liquid flows steadily, with the amount dispensed being proportional to the time the valve remains open. After this amount of time, the program waits until the card is removed, and then goes back to the start of the loop. Calibration involves determining the initial chill time and the time/liter parameters empirically, and storing them as calibration parameters.

It’s important that this calibration can be done in a way that’s both convenient for the operator of the generator and secure from tampering. To that end, I designed the program so that when it sees a card with an account number equal to zero (the operator account), it goes into a calibration routine and prompts the operator for an initial (transfer tube chilling) time, as well as the number of seconds required to transfer 1 liter of ². These parameters are subsequently saved to EEPROM in the ’8535 and used in all future liquid transfers, unless the calibration is changed.

If you remove the card before entering the desired number of liters to dispense, the LCD indicates that the card has been removed prematurely and returns to the start of the loop. 

CARD ISSUER PROGRAM

Photo 2 shows a screen capture of the Visual Basic Card Issuer application. This program is run on a secure PC because it is used to personalize the BasicCard with the username and account number, and to set the initial balance variable to zero. Obviously, anyone with access to this program can insert their card and wipe out its balance easily.

(Click here to enlarge)

Photo 2—This is a screen shot of the PC application that initially personalizes the BasicCard and reads out its balance periodically.

After start-up, the program waits until a card is inserted. It checks that the card has the proper program in it for this application. It does this by reading the applicationID variable contained in the card’s EEPROM. If it matches, the program displays the user information and the current balance. If it’s a new card that’s been programmed with the ² application but not yet personalized, it will show blank fields and allow you to enter the applicable name/account information and also a balance amount (typically zero for a new account).

There is also a provision to cancel the last transaction. The amount of the last transaction is shown, and there is a button to subtract this amount from the accumulated total. The purpose of this function is to allow the operator of the machine to cancel a transaction if the machine fails to deliver ² as requested (i.e., the tank is empty or a valve sticks).

I also included a box that displays the type of card that has been inserted into the reader. This card-specific information is returned by all smartcards as part of the answer-to-reset (ATR) routine, which is invoked at card insertion.