#51

Thanks Will,

write-on-shutdown is not an issue for me - it seemed to be perhaps a timing issue on boot up, and in general there was weirdness on the raspberry pi - as if the rotation degrees weren’t really being properly interpreted as I was only getting 180 degree rotations, regardless of whether I specified 90 or 180, but because I’m on fairly deprecated hardware (40h logic boards), and rolling my own grid code in any case, it’s not worth trying to fix at the serialosc layer (even if that is the issue) - I’ve just coded my own rotation handling functions within the python script I’m using.

so with regard to the boot up issue, I just reset the config for one of the grids to have a 0 degree rotation and adjusted within my own script, and that has dealt with the problem.

I probably still need to look at some kind of “hardening” for serialoscd in terms of detecting if it crashes and automatically rebooting, but I’m hoping that once I’m no longer hacking on the sequencer script itself, then serialoscd crashes will become a thing of the past.

time will tell :slight_smile:

#52

detecting if it crashes and automatically rebooting, but I’m hoping that once I’m no longer hacking on the sequencer script itself, then serialoscd crashes will become a thing of the past.

do you have any more details about those crashes?

#53

cheers @wrl for pointing O_NOCTTY flag is the correct way to open serial terminals- turns out my insane stty incantation fails sometimes when you’re trying to use beaglebone UART as a midi port. Kind of means I have to use a bit more cffi dark magic to read raw serial terminals from common lisp rather than using common lisp’s binary file primitives, but that is a small price to pay for things actually working… thanks again - you are my UNIX hero!

EDIT:
Thought I’d nailed down broken midi/uart ports after reboot, but no such luck…

EDIT:
weeeee! finally got all the midi stuff working cleanly on boot but yea the code that handles uart setup is really inelegant - a dark incomprehensible mass of stty commands and arcane cffi calls! So finally I have a headless system booting cleanly and repeatably into a boomerang-synched step-sequencer. Feels like a good achievement, however rotten is some of the plumbing!

Definitely need to start documenting these techniques a bit more systematically in a more sane format than frantic lines posts…

#54

Hi @wrl. What I’ve noticed is that I sometimes get a segmentation fault when plugging in my grid. Bear in mind that I have two 40h boards in a case with a small hub connecting them to a Raspberry Pi, so my assumption is that

a) this is a strange setup

b) having two grids connect close together in time because of being connected to a hub might cause issues.

After a crash it seems to take a few cycles of connecting and disconnecting the grids before serialoscd will start without a seg fault.

The issue is a bit hard to reproduce. I haven’t looked into any logs to see what might be revealed there, but will see what I can collect next time it happens.

#55

gnarly. can you get me a backtrace?

#56

Having a bit of a problem here. When a grid is plugged into an RPi and just about any LEDs light up, the board starts making noise that resembles capacitor noise like the one described in the 2015 grid noise fix thread.

With no LEDs lit the noise goes away. It’s clearly the RPi board, not the grid. Did anybody else notice such behaviour? Is there anything that can be done to fix it? :thinking:

#57

I’ve not run into that problem, so I’m not much help.

I’ve run two 64 grids from a raspberry pi - I’ve connected them via a powered hub, and directly to the pi.

I think I did check that the power supply I’m using for the pi had amps to spare, so that things didn’t get flaky once the grid started to pull power, though it should be limited to USB specs in any case.

are you running a 128 grid off the pi? maybe there’s an issue with running the larger grid directly from the pi itself instead via a powered hub?

apologies if you’ve thought of all these things already…

#58

Yeah, running a 128 grid kit. Powered hub is not an option, unfortunately, because I intend to run this entire setup from a portable phone charger battery (and with a battery powered speaker), so I’d prefer to keep the number of devices and wires to a minimum :slight_smile:

#59

if its a pi 3 then you definitely need the full 2.5A available. i’ve also found that it’s happier with a hair over 5v for some reason - the official supply is 5.1v.

i haven’t actually tried two grids but did find 5.1V @2.5A to be necessary to reliably run a 2016 m128, a custom soundcard based on cirrus cs4272, and a USB trackball.

and have found the effects of insufficient power to be potentially pretty bad, like fsck errors leading to filesystem corruption.

… and just to be clear, i know that power consumption has been discussed further up in the thread. but that was 2015. pi3 takes a lot more than pi2 (4 cores!)

1 Like
#60

Hey all I’m a bit late to the party but have found this thread extremely helpful for what I’m trying to do.

Unfortunately Serialosc is not working properly on my raspberry pi 2.
When I tried to run it after installing it would say “command not found” so I followed rknLA’s instructions to use the 1.4 stable release commit and this helped a little, but now serialoscd is only working intermittedly and never creating the config file that I need.

Does anyone know how to fix this and get the config file?

#61

version 1.4 had a bug causing serialosc to crash sporadically on linux, so i’d suggest using the latest master instead.

you can as well use pre-compiled raspbian packages that are known to work on armhf, but remove serialosc that you’ve installed with ./waf install if you’re going to use those.

#62

hey thanks for your response! I was actually just trying to get your ppa going but theres no distribution template for raspbian/Jessie?

I suppose I should upgrade to Stretch?

#63

“bionic” dist works great with stretch, but i haven’t tested it with jessie.

#64

I have tried following the instructions very carefully and looked around the internet for help but I cannot get this done.

After I add the repository to my sources.list and run the keyserver command then when I try update I get:

The repository ‘http:/ppa.launchpad.net/artfwo/monome/ubuntu bionic release’ does not have a release file.
Updating from such a repository can’t be done securely and is therefore disabled by default.

I can see the signing key there on your page but I don’t know what to do with it!

#65

That should be ‘http:/ppa.launchpad.net/artfwo/monome/ubuntu bionic main’, have you copied the command to add repository exactly as it’s typed in the docs?

#66

Ah, it did say main but there was another typo (an extra ‘/’). Thanks for the tip!

#67

from here

I run ./waf successfully in /libmonome, but when I run ./waf configure in /serialosc, it throws an error:

Checking for libmonome : not found
The configuration failed

there is a config.log file, but I am not sure which bits are relevant to this discussion.

this is on a RPi 2 with Raspbian Stretch Lite.

ideas?

edit: this issue could be related to gcc-multilib? when I try to apt-get install gcc-multilib, it tells me:

E: Package 'gcc-multilib' has no installation candidate
#68

You could ls /usr/lib to check if libmonome is installed there properly. (that’s where it is on my pi 3)

1 Like
#69

doesn’t look like libmonome is in /usr/lib. :confused:

#70

try ./waf configure and re-compiling libmonome again?