Support Suite

Below is a brief description of each parameter in the APR  customization window: 

1. Tap Speed - range 1..6
   Tap speed 1 corresponds to setting with minimum emphasis on tap and maximum emphasis on drag.  Emphasis being frame to frame timing and algorithmic patience to seek out a drag pattern rather than ending drag abruptly; abrupt drag end can make “window resizing” more difficult. 
2. Rapid Consecutive Tap Debounce Amplitude Ratio Minumum (second tap/first tap) in percent - range 40..80; default 50
   Some people touch one button and get two touches.  The first touch (intentional) has a certain amplitude (loudness), the second touch comes quickly and is generally of lesser amplitude.  This parameter establishes the minimum ratio of the second amplitude to the first above which the second touch will be accepted.  The time window during which this ratio rule applies is (22-tapSpeed)/41 seconds.  So roughly 0.4-0.5 seconds depending upon tap speed selection.  This rule ONLY applies for this time window after a tap and in a certain XY area centered around the tap location.
3. X locale in which tap amplitude debounce is effective 65537 is full screen width - range 0..6554; default 2000
   This parameter defines the X-axis distance on either side of the touch where the amplitude ratio rule/filter is applicable (for 0.4-0.5 seconds after the tap depending upon TapSpeed setting).  Note that this distance is a function of screen size.  66537 corresponds to X-axis width of the display.  Measure this distance D on your monitor and set this number X so that X*D/65537 = the area that you feel this rule should apply.  A good rule would be to make it comparable to the button size (say 40-80% of button size)
4. Y locale in which tap amplitude debounce is effective 65537 is full screen height - range 0..6554; default 3000
   This parameter defines the Y-axis distance on either side of the touch where the amplitude ratio rule/filter is applicable (for 0.4-0.5 seconds after the tap depending upon TapSpeed setting).  Note that this distance is a function of screen size.  66537 corresponds to Y-axis height of the display.  Measure this distance D on your monitor and set this number Y so that Y*D/65537 = the area that you feel this rule should apply.  A good rule would be to make it comparable to the button size (say 40-80% of button size)
5. X locale in which timed debounce is effective 65537 is full screen width - range 0..6554; default 3000
    In addition to amplitude ratio rule/filter for "debounce", there is a second filter that is simply based upon time and area.  The active time (after a tap) for this filter is much shorter - (6-integer value of (TapSpeed/2)).  Here is the table for this equation:
   TapSpeed        FilterActiveTime
   1                        6/41seconds
   2                        5/41 seconds
   3                        5/41 seconds
   4                        4/41 seconds
   5                        4/41 seconds
   6                        3/41 seconds
   For the selected FilterActiveTime, a second tap in the XY area defined by this and the next parameter is rejected.  4/41 is 97mS.  I have been told that it is not humanly possible to intentionally and repeatably touch at this rate of speed. 
   Please set XY parameters for this filter by the same method as for parameters 2&3.  To render this filter ineffective, you can make these parameters close to 0.  Making these parameters large could affect rapid touch "112 issue".  It is recommended to set these parameters to encompass 40% of button size for best “112” performance.  “112 issue” refers to very rapidly touching 1,1&2 buttons on a keypad and not getting desired response.
6. Y locale in which timed debounce is effective 65537 is full screen height - range 0..6554; default 4000
   Please see description for parameter 4 as applied to Y axis.
7. X locale in which drag is connected to previous untouch 65537 is full screen width - range 0..6554; default 600
   IF an INITIAL_TOUCH coordinate is within a configured distance of the last UNTOUCH coordinate (with no time limit), then the last UNTOUCH coordinates are substituted in lieu of the freshly computed (somewhat random) INITIAL_TOUCH coordinates.
   In Paint or Draw type programs, if you draw a line and then pause (till the drag is dropped) and then continue with the drag, you will see that the new drag does not pick up exactly where the old drag left off.  This is because the APR algorithm treats the new drag as if it could happen ANYWHERE on the screen so it does not assign preference to the precise starting point.  Even though the drag physically begins from the same location as previous drag drop (finger is still paused there), the new APR INITIAL_TOUCH is a probabilistic/random number in the general vicinity of the previous drag end.  Worse yet, the drag has to actually progress a tiny fractional distance from starting point before the signal is recognized ( <11mS).  For POS this is a negative when a customer pauses in mid signature and the result is a "disconnected" letter.
   Parameter values for 6&7 are measured as defined in 2&3 above (value*monitorWidth/65537).
   Set this parameter so that drags connect in a pleasing manner BUT tapping an ICON close to a previouly tapped ICON does not result in the wrong tap due to INITIAL TOUCH coordinate substitution.  Make these parameters tiny if drag connect is not an important feature.
8. Y locale in which drag is connected to previous untouch 65537 is full screen height - range 0..6554; default 800
   See above
9. drag score threshold baseline (no velocity); range 150..220; default 180 
   Once an INITIAL_TOUCH coordinate is sensed and reported, the algorithm shifts to DRAG state and modified criteria associated with DRAG state.  This is necessary to provide pleasing DRAG performance which is often used to evaluate a technology in the selection phase of a customer project.  Drag matchScores are typically not as good as tap matchScores depending upon choice of stylus.  While the APR algorithm senses the correct coordinates during a drag, the associated matchScores (matchScore is a figure of merit on the validity of the sensed coordinate; it is a major criterion used to determine if the sensed point should reported as a TRUE touch).
   Drag coordinate matchSocres must each exceed a threshold on a frame by frame basis.  This threshold is computed as dragScoreThresholdBaseline + dragVelocity*VelocityKonstant
   Making this baseline value progressively higher will result in progressively poorer drag performance, but may help in certain "112 issue" scenarios where the tap on the 2 key is detected BUT it is appended to the previous tap on the 1 key as a drag coordinate. 
10. drag velocity adder to threshold baseline proportional to velocity - range 150..200; default 170
    This is the VelocityKonstant term in the drag threshold equation described above.  Making this baseline value progressively higher will result in progressively poorer drag performance, but may help in certain "112 issue" scenarios where the tap on the 2 key is detected BUT it is appended to the previous tap on the 1 key as a drag coordinate.  A small increment to this value (say 15-30) in conjunction with a higher TapSpeed index and smaller debounce regions may help the "112 issue" at the cost of slightly poorer drag performance.  
11. Drag Tenacity
    This value X represents x/41 seconds of time during which the APR algorithm patiently waits for logical drag extension coordinates to be sensed.  This number ONLY takes effect (12 - tapSpeed)/41 seconds after INITIAL_TOUCH is sensed and DRAG mode is invoked.  This means that in the first 6-11 frames, this number is forced to 1.  This means that to enable rapid tapping, drag tenacity is not invoked right away but ONLY after time confirms that the user is indeed dragging.  For this reason, reducing this parameter does not result in easily noticeable tap performance improvement.  You may notice improvement in appropriate dimension/sector given this a-priori understanding of how this parameter is used.
12. Drag Smoothing level
    The APR algorithm senses somewhat random coordinates even in a smooth drag situation.  This is fundamentally due to the probabilistic method of scoring the calibration data against random touch data as well as the interpolation of essentially noisy measurements.  Smoothing is implemented by averaging the previous 5 coordinate values in an effort to mitigate the randomness of each coordinate.  Smoothing drag data in this manner causes the cursor to lag 5 frames behind the present drag position.  5 frames is 5/41 seconds or 122mS.  This translates to a larger cursor lag distance at faster drag velocities.  This syndrome is known as "drag lag".

    The APR algorithm effectively mitigates drag-lag by changing the number of averaged coordinates based upon drag speed "break-points".  At low speed, when smoothing is most needed, 5 coordinates are averaged and drag-lag is not noticeable due to slow drag speed.  As drag speed increases, fewer coordinates are averaged bringing the cursor closer to the stylus.  Smoothing level parameter defines drag speed break points to be lower and closer for lower parameter settings.

    Make this parameter 0 for no smoothing.  Nominal value is 4-6.

13. spare at the moment, saving for future use; default 0
    Unused at this time
14. Parameters related to technology under development
15. Noise threshold for lightest touch with best signal quality- range  0..1023; default 320
    Generally reducing these noise threshold values for the lightest touch levels will result in accepting more marginal touches BUT could also result in increased susceptibility to false touches. 
16. Noise threshold for lightest touch with slightly degraded signal quality than line above
    
17. Noise threshold for lightest touch with worst case signal quality