Cobra 2 touch very slow to resond

I have an application running on a Cobra 2 and I am finding that the touch screen is very poor response time. I often have to hit a button a number of times before it responds.

I have 5 threads in total running. 1 handles the display, 1 handles the GSM modem, 1 handles the HTTP request, 1 handles the sending of data over TCP/IP to a server and the last one handles the Xbee network.

The display is refreshed every second. Sleep is called at the end of the loop with a value 1,000ms

The GSM is checked for any SMS every 10 seconds. Sleep is 10,000ms

HTTP handler is simply waiting for a connection.

The server thread send the data every 2 seconds. Sleep is 2,000ms

The Xbee thread just does a few variable checks to see if we are to send any data. Most of the time is only sends about 1 per day. The sleep is 1,000ms

The Xbee received data is handled with a data received handler. I am using the MFToolkit for this. Data is transmitted by 3 sensors and each one sends every 2 seconds.

Now, if I disable the Xbee thread so that it does not start the data received handler, I get perfect response from the touch screen so I am therefore happy that the issue is not in the other threads. Same effect if I disable the sensors to stop sending and only have the thread started so there is no data being received.

I have looked through the MFtoolkit source and there are thread.sleep calls being made during the polling for data. The code does not use a datareceived handler. All data is polled.

There is no delay in my display code. I can see the clock being updated every second as expected.

I have even tried to set the Xbee thread to lowest priority and no change.

Has anyone else using the Cobra 2 run into issues with touch response?

On my ChipworkX based design, I use interrupt handling to read the touch and it has a similar system reading Xbee with 10 sensors and the response to touch is as fast as it can be.

How is the touch processed on the Cobra 2? I can see that it is via the ADC on the processor so wondering how often this is processed? I would assume that there is no interrupt with this and it is handled via polling?


On the ChipworkX with interrupt driven touch, there is no issue using the same Xbee driver and that was with many more modules sending to it.

Yes. I have stopped the HTTP, GSM and Server threads. Still same result results.

Can you produce a minimal example that reliable reproduces the poor response? As little code as possible. Which Cobra II variant and which display are you using?

Hi John, I’ll see if I can do it but it may be related to the MFToolkits handling of Xbee data so may not be possible to cut it down.

If I can create a basic app with the MFToolkit that has the same issue, you won’t be able to test unless you have XBee modules to talk to it.

I am using the Cobra 2 WiFi with a TE35 display.

My other Cobra 2 with GSM and a fingerprint reader has no issues.

Just thought I would revisit this and update what I found.

I had updated the software to 4.2 R3 and at the same time added some new features. During this update I found that I could not calibrate the touch screen. There was no response to it. During calibration no other hardware has been initialised at this point.

I ended finding that is was the cable from the LCD for touch. After I unplugged and reconnected this it started working and now the application is also stable and touch works fine even with Xbee which I thought was the fault.

Just in case someone else spots this and has similar issues and come across this post during a search.

Hmm, I had a Cobra II system with a T35 which has no touch connection cable in use. And it seemed to be REALLY slow - but working. Button-presses was missed, and the char display was updating at a rate of 5 chars/second = 6 seconds to update 32 letters.

I connected the touch cable, and now it works as it should. I think this is a bug?

Hi Niels,

Did you enable the touch driver in the code?

I am pretty sure this will cause an issue as the ADC inputs will be LOW and the driver is likely to detect this as a touch and try to scan for the touch point. With it always being LOW, the driver is going to be quite busy.

That sounds like a reasonable cause of my problem. I dont see a feature in the current driver to do that. Do you have any pointers as to how it can be achieved?