Having a little trouble bringing blinky lights back to life

Andrew Silverman

unread,

Sep 24, 2021, 4:52:48 PM9/24/21

to [PiDP-11]

So my PiDP11 had been left in my office for, well, the entire pandemic. I just went in to pick it up and I'm now trying to bring it back to life. The boot partition had been corrupted at some point, so I created an all new card with the latest RPi OS, and then followed the site instructions to redownload all of the PiDP11 packages and system images.

The system is clearly up and running, and I can see output in the terminal on my PC, and I can get it to boot the desired image by setting the front panel switches. I can also use the lamp test switch and all LEDs light as expected. However, none of the Address or Data LEDs blink the way they used to, either in the Blinky or IDLED images - I do get the ConsPhy, Data Paths, and Kernel LEDs, and those first two rotate around as expected with the rotary switches. However I get no parity, Address, or Data LEDs regardless of what I do.

Does anyone have any idea why I'm not getting any blinky light output here?

Thanks,

Andy

Heinz-Bernd Eggenstein

unread,

Sep 24, 2021, 6:43:53 PM9/24/21

to [PiDP-11]

That sounds like most everything is ok, but the communication between the process controlling the blinkenlights and the SIMH process is not working. Strange.

So after you installed the latest RPi OS from an install image (this is currently the version codenamed "Buster") you will want to get it to up-to-date with all the chages since the install image was created, just to be sure (and reboot afterwards).

Usually this is done with
sudo apt-get update
sudo apt-get upgrade

But since Debian recently switched Buster to "oldstable" and the brand new "bullseye" to "stable", this won't work anymore. E.g. see https://www.raspberrypi.org/forums/viewtopic.php?t=318302 , long story short, you need to use

sudo apt-get update --allow-releaseinfo-change

instead of " sudo apt-get update " just once.

OK, so after you made sure the new Raspberry Pi OS is really up to date, does the problem persist?

HB

Anton Lavrentiev

unread,

Sep 24, 2021, 7:03:20 PM9/24/21

to Heinz-Bernd Eggenstein, [PiDP-11]

There used to be a script to check the pidp11 hardware without the whole shebang of simh and rcp server... I guess it'd be easier to start with that to see if everything is okay on the hardware part first.... Could be that some soldering corrosion happened during the year+ of the system being left alone? Hope you'll be able to find it quickly!

Good luck

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/811c8a26-364d-48a6-9fdd-45aa094cd9ban%40googlegroups.com.

Dave Johnson

unread,

Sep 24, 2021, 7:06:54 PM9/24/21

to Anton Lavrentiev, Heinz-Bernd Eggenstein, [PiDP-11]

Something that might be worth checking is the insulation on top of the USB jacks — if the pins have managed to poke through while sitting in the car it could cause issues

-- ddj

Dave Johnson

On Sep 24, 2021, at 7:03 PM, Anton Lavrentiev <anton.la...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr2SRcWUX-xM6Gq4L20HtpBv1Bq4g46nZ6eRjvCKTcwqtw%40mail.gmail.com.

Andrew Silverman

unread,

Sep 24, 2021, 7:34:17 PM9/24/21

to [PiDP-11]

I had already done the update/upgrade when I wrote the original note, but not the --allow-releaseinfo-change. So I just did that and there were no un-upgraded packages afterwards, so no net change.

Andrew Silverman

unread,

Sep 24, 2021, 7:49:59 PM9/24/21

to [PiDP-11]

Re: insulation, good thought, but doesn't appear to be the issue.

Andrew Silverman

unread,

Sep 24, 2021, 7:53:23 PM9/24/21

to [PiDP-11]

I found the test.py script in the installation directory and ran that. It was able to sequence through every LED correctly without a problem, although the script fails with a python error when it reaches the switch tests, I suspect it's probably a Python 2->Python 3 thing. However, I know it's reading switches correctly.

So I think we can rule out a hardware problem at this point - I can only think that we're looking at some kind of software error since everything was installed completely fresh today from the official OS image downloader (then updated per above), and the tar.gz's from the PiDP site (and the install script ran successfully). Still scratching my head!

Neil Higgins

unread,

Sep 24, 2021, 8:04:19 PM9/24/21

to [PiDP-11]

Andy, your PiDP has COVID - probably picked it up from a Telephone Sanitiser. Wrap it up in a soft blankie, let it recuperate for a couple of weeks, and all should be well. ;-)

If that doesn’t work, I’m suspecting (absent a schematic to look at) a dry joint on the line driver IC. Have look with a magnifying glass for a dull or cracked-looking solder joint.

Andrew Silverman

unread,

Sep 24, 2021, 8:35:13 PM9/24/21

to [PiDP-11]

I am thinking that perhaps the issue is solder related in that the blinky duty cycle may be encountering too much resistance to light the LEDs but when on solidly in the test script it's enough to get them to light. I think that'll be my next avenue of investigation.

Thanks folks-

Heinz-Bernd Eggenstein

unread,

Sep 25, 2021, 4:19:59 AM9/25/21

to [PiDP-11]

> I am thinking that perhaps the issue is solder related

I doubt it, I think the hardware is just fine. The test.py code manipulates the GPIO pins directly to test the PiPD-11 PCB, and this seems to work just fine. What is not working tho is SIMH driving the LEDs , after an OS software update, which could be caused by a problem with the remote-procedure-call subsystem.

So if you are otherwise running out of options, my instict would be to restore the thingy to the state in which it worked last time ==> try re-install on a separate SDcard with an older version of Raspbian (if only to exclude a hardware problem). You can find pre-pandemic images of Raspbian here : http://downloads.raspberrypi.org/raspbian/images/

Good luck!

Cheers
HB

Andrew Silverman

unread,

Sep 25, 2021, 12:40:00 PM9/25/21

to [PiDP-11]

Well, I tried going back to the first available Buster image (2020-02-13) and I see the same behavior. Kernel/Cons Phy/Data Paths light when the sim is running the blinky but none of the A/D LEDs. And even those three are just a tiny bit dim/flickery. So why would RPC work for some but not others? I think I'm back to my original theory and am going to investigate the solder integrity. I can also scope the un-lit LEDs and see whether there's any signal reaching them to help verify, if I get desperate.

Johnny Billquist

unread,

Sep 25, 2021, 1:26:05 PM9/25/21

to pid...@googlegroups.com

Didn't you say the lamp test worked?

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/a3ed5ad7-c234-47df-b8d5-1669b6238248n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/a3ed5ad7-c234-47df-b8d5-1669b6238248n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Andrew Silverman

unread,

Sep 25, 2021, 1:34:25 PM9/25/21

to [PiDP-11]

Yes - the lamp test works and so does the Python test script. When the sim is isn't running the lamp test doesn't work, so I suppose it seems conceivable that this is really still software. I think I may try an even older Wheezy image or something. Is anyone running Buster successfully? I have to imagine someone would've said something in the last year if it wasn't working.

Johnny Billquist

unread,

Sep 25, 2021, 2:07:15 PM9/25/21

to pid...@googlegroups.com

Then it obviously can't be a soldering issue. The lamp test operates the
lamps in exactly the same way as the normal running system.

Seems to me it has to be something in the connection between
simh and the server that deals with the front panel.

Johnny

> <https://groups.google.com/d/msgid/pidp-11/a3ed5ad7-c234-47df-b8d5-1669b6238248n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/a3ed5ad7-c234-47df-b8d5-1669b6238248n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/f84fb21f-d83f-46fc-bd65-050352cd6854n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/f84fb21f-d83f-46fc-bd65-050352cd6854n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Andrew Silverman

unread,

Sep 25, 2021, 2:29:30 PM9/25/21

to [PiDP-11]

If it is, then I'm totally confused as to what the problem could be. I went all the way back to a clean Stretch image from 2018-10-09, copied everything on and installed the sim (had to rebuild the client because it expected a newer version of GLIBC), and _still_ no blinkies on the A/D leds, but lamp test works and the top row/dial leds too, all switches work.) Sad now. :(

Happy Bear

unread,

Sep 25, 2021, 4:09:12 PM9/25/21

to Andrew Silverman, [PiDP-11]

Suggest you check the voltage @ the LEDs. Maybe its just not high enough to light them.

ted

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/84155241-2e9e-4ecd-93f6-718206de46can%40googlegroups.com.

Andrew Silverman

unread,

Sep 25, 2021, 8:21:05 PM9/25/21

to [PiDP-11]

The lamp test works - all LEDs come on simultaneously.

Johnny Billquist

unread,

Sep 25, 2021, 8:30:52 PM9/25/21

to pid...@googlegroups.com

Then the test switch wouldn't/shouldn't work either. Then all lamps go on.

Johnny

On 2021-09-25 22:09, Happy Bear wrote:
> Suggest you check the voltage @ the LEDs. Maybe its just not high enough
> to light them.
>
> ted
>
>> On Sep 25, 2021, at 11:29, 'Andrew Silverman' via [PiDP-11]

>> <pid...@googlegroups.com <mailto:pid...@googlegroups.com>> wrote:
>>
>> If it is, then I'm totally confused as to what the problem could be.
>> I went all the way back to a clean Stretch image from 2018-10-09,
>> copied everything on and installed the sim (had to rebuild the client
>> because it expected a newer version of GLIBC), and _still_ no blinkies
>> on the A/D leds, but lamp test works and the top row/dial leds too,
>> all switches work.) Sad now. :(
>>
>> On Saturday, September 25, 2021 at 11:07:15 AM UTC-7 b...@softjar.se

>> <https://groups.google.com/d/msgid/pidp-11/f84fb21f-d83f-46fc-bd65-050352cd6854n%40googlegroups.com?utm_medium=email&utm_source=footer

>> <https://groups.google.com/d/msgid/pidp-11/f84fb21f-d83f-46fc-bd65-050352cd6854n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>>
>>
>> --
>> Johnny Billquist || "I'm on a bus
>> || on a psychedelic trip
>> email: b...@softjar.se || Reading murder books
>> pdp is alive! || tryin' to stay hip" - B. Idol
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "[PiDP-11]" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to pidp-11+u...@googlegroups.com
>> <mailto:pidp-11+u...@googlegroups.com>.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/pidp-11/84155241-2e9e-4ecd-93f6-718206de46can%40googlegroups.com
>> <https://groups.google.com/d/msgid/pidp-11/84155241-2e9e-4ecd-93f6-718206de46can%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/FCF3B7BF-1DEF-4011-91C3-D8B3B1848064%40gmail.com
> <https://groups.google.com/d/msgid/pidp-11/FCF3B7BF-1DEF-4011-91C3-D8B3B1848064%40gmail.com?utm_medium=email&utm_source=footer>.

Andrew Silverman

unread,

Sep 25, 2021, 11:15:33 PM9/25/21

to [PiDP-11]

Most recent update: I downloaded the full Blinkenbone source from github so that I could compile the server API test app, and I have verified that it is able to connect to the server and turn on any of the LEDs including the ones not working with SimH. This leaves me at a bit of a loss, since it seems that the hardware is perfectly fine.

I also tried downloading an older copy of the pidp11 tar to see whether perhaps there had been a more recently introduced bug, but didn't find any differences in behavior there.

So in summary: Hardware seems fine. No matter how new or old the OS image is, or the pidp11 tar, the A and D LEDs refuse to light from SimH. I also note that the Halt switch on the panel does not halt the simulator, but the state of the switches can be read fine when SimH is paused and you ask for the realcons status. So all I can think at this point is that the RPC communication between SimH and the realcons panel is borked, but I have no idea how to troubleshoot further - is it environmental to the OS setup in some fashion, or is it a bug in SimH? I find the latter hard to believe, since nobody else is having the same problem that I am. Very frustrated...

Erik Hanson

unread,

Sep 25, 2021, 11:57:07 PM9/25/21

to [PiDP-11]

Just to rule something out, is the power supply fine? Is it the same power supply as before? If powering the PiDP board via the RPi, it could be that while the RPi is idle there's enough current and test programs, lamp switch, are fine... but while simh is running (loading down the CPU) the voltage sags. RPi power supplies tend to be 5.35vdc, for example, to compensate for high CPU load where a generic/cheap 5vdc supply will droop. I'm not sure I believe this is your issue any more than the cold solder joint idea, but it's something to think about, and cross off the list of possibilities.

Hope you figure it out.

Andrew Silverman

unread,

Sep 26, 2021, 12:17:50 PM9/26/21

to [PiDP-11]

Yeah, pretty sure that's not it. (Same PSU as before, lamp test lights everything up just fine with sim running, etc.) Since the events occurring on the panel are those handled within the realcons server itself I'm becoming increasingly convinced that there is some kind of communication failure between SimH and the server, but there's nothing obviously wrong within SimH's show/set commands to the server. :-/

Andrew Silverman

unread,

Sep 26, 2021, 12:45:50 PM9/26/21

to [PiDP-11]

In case it helps anything, I started the realcons server with the option to log to the journal and I can see that it's clearly getting connected over RPC and enumerating the various controls, and then after two rounds of "getcontrolvalues" followed by "setcontrolvalues", it goes into an endless loop of reading the control values. Perhaps that much is normal. However, I don't see anything that indicates that other APIs are being called to update any of the LED states at any time.

Example:

Sep 26 09:38:01 pidp11 blinkenlightd[7008]: Start

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=11/70, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=0)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=SR, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=1)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=LAMPTEST, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=2)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=LOAD_ADRS, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=3)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=EXAM, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=4)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=DEPOSIT, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=5)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=CONT, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=6)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=HALT, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=7)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=S_BUS_CYCLE, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=8)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=START, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=9)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDRESS, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=10)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=DATA, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=11)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=PARITY_HIGH, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=12)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=PARITY_LOW, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=13)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=PAR_ERR, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=14)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADRS_ERR, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=15)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=RUN, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=16)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=PAUSE, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=17)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=MASTER, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=18)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=MMR0_MODE, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=19)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=DATA_SPACE, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=20)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDRESSING_16, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=21)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDRESSING_18, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=22)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDRESSING_22, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=23)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDR_SELECT, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=24)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=DATA_SELECT, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=25)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=ADDR_SELECT_FEEDBACK, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=26)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=DATA_SELECT_FEEDBACK, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=27)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=PANEL_LOCK, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=28)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.name=POWER, ...

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=0, i_control=29)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: i_control > controls_count

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanelinfo(i_panel=1)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: i_panel > panels_count

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_getpanel_controlvalues(i_panel=0)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[0].value = 0x0 (3 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[1].value = 0x1 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[2].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[3].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[4].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[5].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[6].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[7].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[8].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[23].value = 0x4 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[24].value = 0x2 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[27].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: result.values[] += control[28].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: blinkenlight_api_setpanel_controlvalues(i_panel=0)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[9].value = 0x0 (3 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[10].value = 0x0 (2 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[11].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[12].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[13].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[14].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[15].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[16].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[17].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[18].value = 0x1 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[19].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[20].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[21].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[22].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[25].value = 0x0 (1 bytes)

Sep 26 09:38:13 pidp11 blinkenlightd[7008]: control[26].value = 0x0 (1 bytes)