Colour matrix connecting - ideally requires firmware change

[chrisruk]

No description provided.

[mutesplash]

I'm having this problem more frequently with the new firmware that was released with 0.5.8

Not being detected during list
"P0: no device detected"

Disconnecting while using
"P0: timeout during data phase: disconnecting"
"P0: disconnected"

[blueskiestailwinds]

When I run hat.get() repeatedly, Matrix will appear as a device once or twice every 8-9 times. Every other time it shows nothing in its port. Repeatable in all ports with 2 matrices.

 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': 64, 'connected': True, 'name': 'Matrix'}
 hat.get()["C"]
{'typeid': 64, 'connected': True, 'name': 'Matrix'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': 64, 'connected': True, 'name': 'Matrix'}
 hat.get()["C"]
{'typeid': 64, 'connected': True, 'name': 'Matrix'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}
 hat.get()["C"]
{'typeid': -1, 'connected': False, 'name': 'Disconnected'}

[chrisruk]

@blueskiestailwinds Can I just clarify if that output was generated from running a script multiple times, such as via bash:
or was it generated from running something like:

from buildhat import Hat
h = Hat()
while True:
    print(h.get())

Thanks

[blueskiestailwinds]

Thanks for the response.

Neither exactly, but it was nearest to the latter:

from buildhat import Hat
h = Hat()
while True:
    print(h.get())

To be precise, I ran

from buildhat import Hat
hat = Hat()
hat.get()["C"]

then manually up arrow, enter, repeat as fast as I could for a dozen times or so. So the queries were not as fast as a loop would have been. I added the ["C"] slice just to clean up the output for posting here.

[chrisruk]

Thanks for that, are you running buildhat from the PyPi package, installed via pip?
If so, could you show me the output of:

pip show buildhat

Or did you install from git?

[blueskiestailwinds]

I installed buildhat via pip.

Ooops... terminal had some junk in it. This is better:

pi@buildhat:~ $ pip show buildhat
Name: buildhat
Version: 0.5.8
Summary: Build HAT Python library
Home-page: https://github.com/RaspberryPiFoundation/python-build-hat
Author: Raspberry Pi Foundation
Author-email: [email protected]
License: UNKNOWN
Location: /home/pi/.local/lib/python3.7/site-packages
Requires: gpiozero, pyserial
Required-by:

[mutesplash]

You're not picking up PR #126 then, I think? That might be the problem. I started to wonder if that was the case for myself, but I caught this glitch with the Matrix again while trying to reproduce your issue, just not with your specific tests.

[chrisruk]

Yeah, if you don't mind, if you could install from git that might be worth trying

pip3 uninstall buildhat # to remove the existing buildhat install 
git clone https://github.com/RaspberryPiFoundation/python-build-hat.git
cd python-build-hat
pip3 install . --user

I haven't been able to replicate your specific problem currently from the git main, however I do know of an issue where
if you run a script by doing say 'python3.9 test.py' it can fail to detect the matrix, which I'm looking into. (I think it's possibly because the 'list' command is showing the matrix as being disconnected, due to its repeated connections/disconnections)

[blueskiestailwinds]

chrisruk, you're awesome. I have both matrices working now.

[chrisruk]

Cool :), thanks @mutesplash :)

Also @mutesplash I've been testing this - #141
Which for me helped get the matrix work more reliably from a script:

Unplug matrix, leave for a few seconds, plugin matrix, leave for a few seconds:

Create script called test.py:

#!/usr/bin/python3
from buildhat import Matrix
print("run it")
m = Matrix('C')
m.clear(('red', 10))

In bash terminal:

while [[ 1 ]]; do python3.9 test.py; done

Which runs for me ok with the pull req, but fails without it after doing
Unplug matrix, leave for a few seconds, plugin matrix, leave for a few seconds:

Traceback (most recent call last):
  File "/home/pi/Repositories/python-build-hat/test.py", line 7, in <module>
    m = Matrix('C')
  File "/home/pi/Repositories/python-build-hat/buildhat/matrix.py", line 13, in __init__
    super().__init__(port)
  File "/home/pi/Repositories/python-build-hat/buildhat/devices.py", line 55, in __init__
    raise DeviceInvalid('There is not a {} connected to port {} (Found {})'.format(type(self).__name__, port, self.name))
buildhat.exc.DeviceInvalid: There is not a Matrix connected to port C (Found Disconnected)

[mutesplash]

So, don't unblock BuildHAT during init after the list serial command is issued (but not reboot) for an extra 3 seconds to account for Matrix bouncing around. If the issue only occurs after a listing, either in reboot or a listing, it sounds like maybe the firmware is tickling it wrong during that command?

I made three test programs to try and simulate the script without having to restart it: hammer hat.get(), hammer Matrix.select()/Matrix.on()/hat.get(), and hammer destroying the Device class' BuildHAT singleton (which revealed that the serial port doesn't get closed on shutdown due to file handle exhaustion). None of them seemed to draw out a bug, but the last test I had to put in a small delay because it would either reboot the HAT on init (my reboot patch) or just get stuck in the HatState.OTHER (official repo) because when it reconnected to the serial port, it would get partial listing text from the last iteration and run out of patience with the "incdata" variable. So, that might not have been a successful test if you're finding it with the shell script.

I will make some modifications to try hammering the listing to see if that drags out the bug. The trick is knowing when the list is done sending. I've tried making modifications to the list parsing before to make it more "robust" but have not created anything I would consider commitable.

[chrisruk]

Without modifying the firmware, the only thing I can think of is just giving more time prior to running the users script, to allow the event loop to power on the matrix as in the pull req. as the matrix continuously connects/disconnects unless you power it on. I can probably cut the delay short, if the matrix is connected and powered on though, during that time.

I ran the script in a while loop, via bash, as that causes the list command to be used, rather that the event loop updating connection info.

The issue is sometimes that calling list, the matrix would be 'disconnected' at that point in time, but by waiting X seconds after the list command, the matrix connects again and is powered on.

[chrisruk]

I've committed a small change today that waits 3.5s prior to issuing the 'list' command, so that the 'loop' function has time to try to apply power to the matrix. This does slightly delay programs though.

[chrisruk]

Just added a new firmware that should prevent the matrix disconnecting repeatedly