[Solved] Red and Green leds swapped?


#1

Hi,

Since yersterday I have a weird problem. I was tinkering around with Docker and the Matrix Voice. This worked well to a reasonable degree but I could not get the Mic Array running.

I decided to to a clean stretch install, after the setup the hal worked ok but I noticed that the mic_energy was green instead of red.
After that I did the everloop demo and to my surpise that was red instead of green!
So, somehow the led for green and red seem to be swapped.

Also, when I now do fgpa_info this info returns:
MATRIX device has not been detected
IDENTIFY = 0
VERSION = 76b9807c

The MATRIX device has not been detected message also pops up when I install MalOS.
But, installing the hal demos works normally, without any error…

Is there anything I could have done which resulted in this behaviour?


#2

they have released a new fpga version where the byte order in communicating with the everloop was changed to RGBW and not GRBW as before. i have updeted my python lib to take note of this. maybe you have to rebuild or update your tools.

fpga_info on a voice should return:

IDENTIFY = 6032bad2
VERSION = 10007

#3

Hmm, ok that would explain that.
This release was probably a couple of days ago, I will investigate that thnx!

fpga_info returns:

MATRIX device has not been detected
IDENTIFY = 0
VERSION = 76b9807c

This is a fresh download/build of matrix-init, so that is a strange “error”.
The device works as expected, I can run all the demos.


#4

are you running the matrix-init in a container only forwarding the spi device? as the voice is programming the fpga on every boot from flash, so it works without any matrix-init. i think you have to flash the voice directly on e.g rasbian not using a container to get the latest firmware on it. maybe it would work inside a container if you forward more devices / GPIO and run the init script by hand, as normaly container do not start any systemd services.

that is benefit of a voice - the FPGA is programmed directly from flash and do not need the init scripts, only if a firmware update is available, the creator needs the init script every time when repowerd.


#5

This matrix-init is without any docker containers, but a raspbian stretch install, so that’s why I find this a strange error.

For my other expiriment I have a contrainer running MalOS, but the host has no matrix stuff installed in any way. (A HassIO install to be specific, but I have used clean raspbian as well)
I can run the everloop node app remote from my MacBook or from another container, this will correctly access the malos contrainer and I am able to control the everloop :slight_smile:

What I want is to be able to listen to the MicArray port (I have forwarded that port when running the container, as I have the Everloop port) from a remote machine (or another docker)
Ultimately to have:

  • a docker running Malos, publishing the ports to the host
    This part is up and running
  • create other containers to utilize the malos docker
    For the everloop, this is already working. I can control it from another container or another source (i.e. my macbook) :slight_smile:
    But the MicArray needs work (as in: does not work yet)
    I don’t understand why yet, because it is using the same way to connect.

The parts in the bullits still work, so that is the strange part.
I am getting strange results from fpga_info, but everything still works.
I thought I had broken things because of the red and green switched, but that was a release apparently :slight_smile:


#6

Ok, so I got the same problem again (sort of).

I still do not understand why and how I can now update the FPGA version like you said @loom?

they have released a new fpga version where the byte order in communicating with the everloop was changed to RGBW and not GRBW as before

fpga_info is now outputting:
IDENTIFY = 6032bad2
VERSION = 10008

Which seems to be correct when I check this file:

It’s not that I get any errors, I am just curious about what to change.


#7

they recently changed the led to fix it in the kernel module, maybe this is causing the “problem” and you need to recompile it. i did not install the latest kernel modules, as it still has some crucial problems in my point of view and i had not time to fix this myself.
the FPGA gets updated with the normal apt update procedure and a reboot.


#8

Aah, so the trick is in the kernel modules!
Then they probably forgot to implement that in the matrix-creator-init code, for which I think the file system_voice.bit should be changed.

So if you only use the matrix-creator-init you will still have the original byteorder, but that will switch as soon as you install the kernel modules :smiley:

Thnx for the info!