Explorer HAT issues

[gbaman]

There is a few issues with Explorer HAT support inside ScratchGPIO 7.
At the NI Raspberry Jam, we found the touch inputs unusable for the workshops. The inputs worked for a short period of time, after which they would lock up. This frustrated the kids and made the library unusable.
Although I am not sure why this is, one suggestion I do have is pull down a recent copy of the explorer hat library from https://github.com/pimoroni/explorer-hat
As the copy in Scratchgpio is 9 months old.
Am trying to figure out, does ScratchGPIO actually use the library itself or do it itself using the cap touch library etc?

[cymplecy]

I haven't looked but I normally cheat by placing a copy of exertanl py libs
in scratchgpio folder - I promise to look at it over coming week :)

Simon

On 29 November 2015 at 12:17, Andrew Mulholland [email protected]
wrote:

There is a few issues with Explorer HAT support inside ScratchGPIO 7.

At the NI Raspberry Jam, we found the touch inputs unusable for the
workshops. The inputs worked for a short period of time, after which they
would lock up. This frustrated the kids and made the library unusable.

Although I am not sure why this is, one suggestion I do have is pull down
a recent copy of the explorer hat library from
https://github.com/pimoroni/explorer-hat
As the copy in Scratchgpio is 9 months old.
Am trying to figure out, does ScratchGPIO actually use the library itself
or do it itself using the cap touch library etc?

—
Reply to this email directly or view it on GitHub
#13.

[gbaman]

Ok, cool. We have a big primary school workshop coming up in a week or 2, so would be great to be able to use Scratchgpio with the Explorer HAT in it.

[cymplecy]

em - all seems to work OK here.
It might be an issue as to how the touch inputs are used.
When one is touched - it latches to value 1
To reset it broadcast touchreset (to reset all inputs)
or use touchreset 4 to reset number 4

[gbaman]

It works fine at the start, but after a few mins of use, they start to randomly lock up. We had tinfoil attached via croc clips to the inputs. They worked for the first few mins then locked up with the only way to unlock them was to restart ScratchGPIO which helped for a while.
Also better documentation might be an idea, given I didn't even know you could use touchreset 1, only knew you could do touchreset for all pads.

[cymplecy]

By lockup - do you mean the touchreset didn't work?

Have you got any scripts used?

Re documentaion - I'll knock something up a bit better :)

[gbaman]

Yeah, it refuses to reset. I think the kids had it that when as soon as it has been detected, it reset them, but even after getting them to add half a second delay, it didn't help either.

[cymplecy]

Could it be that they were just being triggered straight away again. If using tinfoil they could be picking up a lot of signal?

Any chance of running a test at your end?

BTW I've been running mine for past hour and all working fine

[gbaman]

Will give it a go when I get a back home later. But the weird bit was when they moved to Python doing similar things, it just worked without any issues.
It is interesting though that with Python, it was less sensitive. With Scratch it could detect a hand being near while Python required you to touch it. Maybe updating the library will help?

[cymplecy]

"It is interesting though that with Python, it was less sensitive. With Scratch it could detect a hand being near while Python required you to touch it. Maybe updating the library will help?"

Sounds like over-sensitivity is the issue then - I'll try out adding some foil to mine to see if I can replicate at this end as well

[cymplecy]

Latest module from Pimoroni Github used to update sghGC_captouch.py and bug with loading/saving project in middle of session sorted in dev Version http://simplesi.net/scratchgpio-development-testing/