Acceptance Window Optimization
When manual coin programming is used to create the coin signature parameters for one of the six Coin Memories, the average and distribution of the six sample coins read automatically provide excellent security for the acceptance of coins. However, there are special circumstances where special care or additional action is required in order to provide excellent acceptance security. These special circumstances are include:

• Different Batches Of Non-Identical Tokens Purchased Over Time

• New Batches Of Government Minted Coins Have Different Lower Cost Alloy

• Another Coin Or Token For Use Elsewhere I Virtually Identical To Yours

• A Counterfeiter Has Produced Slugs Virtually Identical To Yours

Different Batches Of Tokens. Over the years, many establishments will purchase numerous batches of tokens. Unfortunately, the record of the industry does not include exercising very tight control over the alloy composition, particularly when purchased from different mints. One can use Hyper Terminal to connect to the serial port and look at the metal readings of a number of tokens purchased over the years and separate them by reading. If there is more than one group that are separated by four or more counts in the metal readings, each group should be programmed in as separate coin types. If the metal readings are three counts or less apart they may be programmed into a single Coin Memory, but the group of 6 sample tokens used in the Learn Procedure must contain some tokens from both groups of tokens so that the upper and lower limits of the overall group become part of the learned coin signature.

Different Batches Of Coins. Over the years, some governments have decided to change the metal alloys of their coins to save money. Notable changes include the US penny, the Canadian nickel, and the Canadian quarter. For these coins, there is one or more quite distinct alloy version, thus requiring them to be learned as at least two coin types. In each of these cases it is not possible to mix the two types and hope that they can be learned as a single coin type. Trying to do so will result in 100% rejection because the average value learned is just too far from the measured values of either coin.

A Nearly Identical Coin, Token or Slug. Sometimes a second Unwanted Shadow Coin can have its parameters overlapping the distribution of the Valid Coin and fit within the acceptance window of the Valid Coin. Examples of this include a.) a 0.984 70/30 brass token and a 0.984 85/15 brass token,  b.) a $1 alloy 752 casino token and a lead slug, and c.) a Brazilian 25 Centavo coin and a "smashed to larger diameter" 10 Centavo coin.  The typical solution to this problem is to tighten the acceptance limits. While in some cases this may help, in the example shown in Figure 2, there becomes a serious trade-off between eliminating the Unwanted Shadow Coin and reducing the rate of acceptance for the Valid Coin, neither of which is desirable.    

In order to simultaneously eliminate the Unwanted Shadow Coin and maintain a high rate of acceptance for the Valid coin, provision has been made to teach IDX Xeptors the properties of the Unwanted Shadow Coin. Having done so,  when the Xeptor finds that a deposited coin falls in the acceptance window of both the Valid Coin and the Unwanted Shadow Coin, it will further look more closely at the individual errors from all of the measurements made, each with their own probability distributions, and use them jointly to determine which of the two coins the three properties most closely match. This method has been proven quite successful for achieving excellent discrimination in these tough situations.

Tight-Metal Security.  Firmware version V3.0s (s only) and all of V4.0 have the ability to increase the normal metal security by setting bit 6 of SysConfig. By doing so, an additional overall test of the ensemble of metal readings is conducted and provides a means of measurably tightening the acceptance window with virtually no impact on normal coin acceptance rate. It is automatically invoked when the BadCoinCount flag is set. To set bit 6 of SysConfig use the "s" command to add 40 Hex to the current value of SysConfig. For example, if SysConfig is currently 08 (see System Report with "R" command) then you would use the command "s48" followed by "S" to save the change to EEPROM.

Tight X-Mark Security. All X-Mark Xeptors have the ability to increase the security in reading of the X-Mark minted facets. In normal operation, the X-Mark sensors allow a fair amount of variation in reflected signal strength from the facets and require a successful read of the X-Mark on only the leading or trailing edge of the coin... but not both... so that the system maintains a very high acceptance rate even after years of wear and dirt accumulation on the X-Mark facets. However, on rare occasions there are tokens that not only have have the same alloy and diameter, but also have minted graphics having patterns that in the right orientation may mimic the reflection of a valid X-Mark facet.

Xeptors have two tools to increase X-Mark detection security in these circumstances. By setting Bit 4 of SysConfig the signal threshold required for valid detection is doubled and can significantly reduce false detection due to graphics on other otherwise similar tokens. By setting Bit 5 of SysConfig, it is then required that the X-Mark be detected on both the leading and trailing edges of the coin, dramatically reducing the probability that false detection because of the graphics will happen in both places.  the graphical. Both automatically invoked when the BadCoinCount flag is set. Use the  "s" command to set bits 4 and 5 of SysConfig which adds 30 Hex to the current value of SysConfig. For example, if SysConfig is currently 08 (see System Report with "R" command) then you would use the command "s38" followed by "S" to save the change to EEPROM.