cancel
Showing results for 
Search instead for 
Did you mean: 

Has anyone else noticed an issue with calibration in TouchGFX v4.10?

ZFree
Associate II

We recently upgraded from TouchGFX v4.8 to v4.10. Our calibration was working perfectly with v4.8 but it suddenly began to fail consistently after we upgraded to v4.10. After spending two days researching this issue I think that I may have found an issue with the TouchCalibration::setCalibrationMatrix function provided by TouchGFX v4.10. Since I don't have access to the source of setCalbrationMatrix all I can give you is a simple explanation of our method and the results from v4.8 and v4.10 as comparison.

We use 3 points to do the initial calibration. They are: {160,240}, {300,384}, and {640,150). We capture the adc values each time the user hits each of those points and then we pass both the touch point values and the adc values to the TouchCalibration:setCalibrationMatrix function. Once this is done we ask the user to tap once more on another point to verify that the calibration is correct. The touch point for that verification point is {400,240}. This worked reliably on v4.8 but with v4.10 we typically get {460,240} for the verification point instead of {400,240}. I even went back and put the adc points that we got from touching {160,240},{300,384}, and {640,150} (i.e., our test points) from v4.10 into the version with v4.8 and it gave back {400,240} after the calibration.

Has anyone else seen this +60 pixel offset around the x-axis after calibration with v4.10?

11 REPLIES 11
Martin KJELDSEN
Chief III

Hi @ZFree​,

How did you do the upgrade? Simply through the designer? Are you sure no drivers have changed? Etc. TouchCalibration code has not changed between 4.8.0 and 4.10.0. Are you able to do a diff between the two versions of the application that you have?

Thanks.

/Martin

ZFree
Associate II

Hi Martin,

Thanks for replying to my message. Yes, we upgraded through the designer. Yes, I am positive that no drivers have changed. Yes, I am able to do a diff and I see no changes occurred with respect to the TouchController. I went ahead and quickly implemented my own calibration algorithm based on this: http://www.lysator.liu.se/~kjell-e/embedded/doc8091.pdf

and all is working now just as it did with v4.8. Unless we can find a satisfactory resolution to this issue I will just use my calibration method instead of TouchCalibration::setCalibrationMatrix.

I understand that nothing changed on your end between v4.8 and v4.10. This is very surprising. I went back and verified the dimensions of the screen did not change between 4.8 and 4.10. They did not. I checked the image sizes for the targets that the user taps to calibrate. They were the same on 4.10 as they were on 4.8.

Here's another anecdote to consider. After I wrote the original question last Friday I went back and re-ran my test using a different unit and found that the 60 pixel offset was not consistent from device to device. I ran the exact same test as I did with the original hardware unit. When I tapped the verification target at {400,240} I got back {430, 300} (i.e., 30 pixels off on x and 60 pixels off on y) instead of the {460,240} I got with the original unit after calibration. At this point, I decided that I had no other choice but to implement my own calibration algorithm so I did and it works just fine.

Any suggestions on where to look? Any ideas on what may have caused this? Please advise.

Thanks,

Zach

ZFree
Associate II

Martin,

After thinking about this some more I wonder if you could try a simple test with some reference points and the matching measured points to see if we get similar results between 4.8 and 4.10? Here are some touch values (i.e. reference points)

0) {160,240}

1) {300,384}

2} {640,150}

And here are the matching display values (i.e., measured points):

0) {906,2140}

1) {1587,3238}

2) {3218,1418}

Now if i pass these arrays to TouchCalibration::setCalibrationMatrix(refPoints, scrPoints) and then make a subsequent call to TouchCalibration::translatePoint(point) where the point is defined as {2069,2143} then the point gets translated to {402, 245} with 4.8. Running the exact same test using the same initial reference points and measured points will give {449, 321} after the call to TouchCalibration::translatePoint with {2069, 2143} with 4.10. Is this something you could try on your end with the same numbers?

ZFree
Associate II

Hi @Martin KJELDSEN​ ,

Please see above. I just realized you may not be getting notifications about my replies since I wasn't tagging you in my two earlier replies.

Thanks,

Zach

Hi,

Yea, it's better to tag to be absolutely sure i'll get a notification. I don't think i'll have time this week, but i'll make a note to test it this monday. Is that allright?

/Martin

ZFree
Associate II

@Martin KJELDSEN​ ,

Monday works just fine.

Thanks for replying,

Zach

ZFree
Associate II

Hi @Martin KJELDSEN​ ,

Any update on this issue? Have you had a chance to try the simple test with the points I provided in my earlier post?

Thanks,

Zach

DWann
Associate III

Was this issue ever resolved? I'm experiencing a similar problem with TouchGFX 4.12.3.

After a 3 point calibration routine, I'm finding that the calibration is significantly off. In my attempt to track down the issue, I did the following:

  1. Inside my touch controller class, I took the raw coordinates, transformed them using TouchCalibration::translatePoint(), and dumped them to a serial console.
  2. Inside a TouchGFX screen, I added a box that covers the full screen that has a click listener. When the screen is clicked, it dumps the click coordinates to the serial console.

I'd expect the coordinates to be identical, but that isn't the case. The x coordinate is off by about 2 pixels, and the y coordinate is off by about 30 pixels. It seems like there is a bug occurring somewhere AFTER the coordinate transformation. Does this shed any light on the cause?

Martin KJELDSEN
Chief III

Hi @DWann​,

I've attached the TouchCalibration source code - might help you make more sense of it.

As far as i understand you, the coordinates you dump to serial calling translate() manually and the coordinates in your view (handleClickEvent(ClickEvent& event)) are different? That should not be possible since the transformed coordinates are what is being passed to the view.

Just want to be sure that you're not returning the transformed from your TouchController, in which case you would be translating the already translated coordinates.

/Martin