Troubleshooting
| Issue | Possible Cause | Try | |
|---|---|---|---|
| Cannot connect via WiFi | pi-Stomp is out of range | Move pi-Stomp closer to WiFi router, or computer if in Hotspot mode. Reboot by cycling the power. | |
| Cannot connect via WiFi | Raspberry Pi is not booting | Make sure Red LED on pi is lit. If not, check power. Is SD card properly etched and mounted? | |
| Cannot connect via WiFi | Patchbox wifi config not correct | If LCD display is displaying a pedalboard, Long-Press PBoard knob until System Menu displays. Select/click System Info. Select/click Enable Hotspot. Try connecting via ssh to pistomp.local (patchbox.local for patchbox based OS). Repeat network configuration | |
| Cannot ssh to pi-Stomp from computer | Error message: “The ECDSA host key for pistomp.local has changed” | From computer: ssh-keygen -R pistomp.local | |
| LCD is lit but all white or stuck on pi-Stomp logo | Audio card not properly configured | ssh to the pi-Stomp. Run ~/pi-stomp/util/change-audio-card.sh, then enter the number corresponding to the audio card you have installed. Then power cycle. | |
| … LCD is lit but all white or stuck on pi-Stomp logo | Error encountered by mod-ala-pi-stomp service | ssh to the pi-Stomp. Run sudo journalctl -fu mod-ala-pi-stomp to see the log for the service and hopefully discover the error. If nothing is obvious, check the other dependent services: sudo journalctl -fu mod-ui, sudo journalctl -fu mod-host, sudo journalctl -fu jack | |
| No audio passing when pi-Stomp is processing is enabled | Incorrect routing | Check cabling (eg. instrument > In1, Out1 > amp) and assure it's consistent with the routing of the current pedalboard shown in MOD webui. Make sure the path thru plugins from input to output isn't broken. Better yet, connect a purple virtual cable straight from In1 (Hardware Capture 1) to Out1 (Hardware Playback 1). Check to see if the other (eg. In2/Out2) works. | |
| … still no audio passing | Multiple causes, so see if you can at least get audio output | From the MOD Web UI, add a plugin named “Square” (use search bar). Connect it's output to the one you're testing. If the plugin is enabled and you can't hear anything, the problem is likely not just on the input side of things but a problem with your audio card (see next possible solutions) | |
| … still no audio passing | Audiocard Configuration | ssh to the pi-Stomp. Run alsactl -f ~/pi-stomp/setup/audio/STATEFILE restore where STATEFILE is: audioinjector.state, hifiberry.state or iqaudiocodec.state as appropriate for the particular card you have installed | |
| … still no audio passing | Volume is down | Turn Volume knob up. Make sure input gain is not too low - From the System menu, select/click Input gain, set value to 0 or greater. | |
| … still no audio passing | Audio services in bad state | Restart the audio (Navigate to the System menu, select/click Restart sound engine). If the LCD isn't displaying anything, you can restart the jack service via ssh: sudo systemctl restart jack | |
| … still no audio passing | Hardware | Add a plugin named “TinyGain” (use search bar) to the current pedalboard and connect its input to the capture input. When your instrument is creating a signal, does the readout on the TinyGain change? If so, you're likely getting some signal in, if stuck on a low value (-30dB or lower like -inf) then the problem is likely audiocard configuration or hardware | |
| … still no audio passing | Buffer chip (U3) inserted badly | Make sure the orientation is consistent with the build instructions and that it is well seated in the socket | |
| … still no audio passing | Bad wiring | If the jumpers are either not making a good connection or wires are swapped (L to R / R to L) then you won't likely hear anything because it doesn't match your pedalboard routing. Make sure the wiring is consistent with the photos in the build instructions. | |
| Audio passing but either too quiet or distorted | Input gain not matched to input source | Follow Audio Setup instructions. If it's still too quiet or distorted, check if the plugins on the pedalboard are responsible or choose another pedalboard, like 'Default' | |
| No Audio from Headphone jack | Headphone jack only gets processed audio | Make sure the pi-Stomp is not bypassed. Control its volume via the System Settings Menu (Long-Press upper encoder) | |
| Can't get past Hardware Test | Hardware issue exists or user error (pi-Stomp v1.x) | It's advisable to pay attention to which test is failing. If you just want to move on despite the issue, ssh to it and run 'touch /home/patch/pi-stomp/pistomp/.hardware_tests_passed'. If you'd like to run the tests again: 'rm /home/patch/pi-stomp/pistomp/.hardware_tests_passed; ps-restart' | |
| Audio Glitching | Overworked CPU | In the Web UI, see if the CPU meter is going above 75% or many XRUNS are logged (more than 100). If so, try switching to 256 Frames (click on control next to XRUNS), or removing plugins from your pedalboard. CPU intensive plugins like generators, simulators, pitch shift and some distortions are the usual hogs. | |
| … still glitching | Unnecessary processes/services running | If you've installed additional software, those processes might be hogging the CPU. Try shutting them down, see tips below. | |
| … still glitching | Throttling due to Overheating | To determine if throttling is happening, run vcgencmd get_throttled. 0x0 = No throttling, 50000 = has throttled since boot, 50005 = is currently throttling. If throttling is happening, run the following to see the CPU temp: vcgencmd measure_temp. The range of operation for a Raspberry Pi is -40 degrees C to +85 degrees C. 45 to 60 degrees is typical. At 80 degrees, it will start to throttle. If yours is running over 65 or so, you should probably add additional heat management. Extra heat sinking, enclosure venting, etc. | |
| … still glitching | Throttling due to low power supply voltage | If your pi is throttling (see previous), run: dmesg and look for errors/warnings about low voltage. As long as the pi is receiving 4.7v or so, the low voltage is not a big concern. To disable throttling run: echo avoid_warnings=2 | sudo tee -a /boot/config.txt, then reboot | |
| Analog Controls (Tweak, Expression, etc.) not working | Not configured in default_config.yml | See the Configuration File Guide |
Hardware Debug Utility
A very clever pi-Stomp user added an awesome utility for verifying that attached hardware is working correctly.
From an ssh session:
ps-stop ps-run --host test
This brings up a curses UI in the terminal.
From here you can toggle footswithes, tweak knobs and the encoder. If you see the corresponding change in the UI, the control is probably working. The Capture volume and Headphone volume only work if using the AudioInjector sound card.
To return to normal operation:
Control-C ps-restart
No Processed Audio
If you've done the above and still don't hear audio being processed, it might be time to check the input circuitry.
First make sure processing is enabled and not bypassed. The “power” icon at the top left of the LCD should be green. If it's grey, make it green by navigating to it, then clicking the encoder.
“Signal Tracing” is a common technique for debugging audio issues. Essentially, we'll be using the cable going to your amp as a signal sniffer. You can use a pair of alligator jumper cables connected like this.
The instrument is plugged into the input jack. The cable going to the amp is grounded (green jumper). And the amp cable tip becomes a signal probe by connecting it (yellow jumper) to a short stub of non-stranded wire . When the wire stub is touching a component/pad with a live signal, you should hear the instrument coming thru the amp. If you don't hear it, a component or circuit board trace before that point is the likely culprit.
Below are the points to probe (numbers in fuchsia font). The text in [] suggests the components and circuit board traces to check if you Don't detect signal at that point.
- Input Jack
- Via [Check solder pad of Jin jack and trace to via]
- R1 [Relay could be malfunctioning or in bypass mode. C1 may be bad. Bad solder joints on Rly, C1 or R1]
- R2 [Trace or bad solder between R1 and R2]
- U3 pin3 [Trace or bad solder between R2 and U3]
- U3 pin2 [U3 chip is misoriented/badly seated in socket; U3 is fried or not powered correctly - check voltage between pins 4 and 8 (yellow dots) is around 3.0 volts]
- Hin Left [Bad solder of S3 socket, Hin Header or trace between them]
General Hardware Troubleshooting
The dmesg command shows kernel logs which may contain useful information when debugging hardware failures.
dmesg | less
enter ‘q’ to exit.
General Software Debugging
Services
Most all of the software important for pi-Stomp to run correctly are linux services. Some of the most relevant services:
amidiauto.service - the automatic MIDI interconnection service.
jack.service - the Jack backend service. If it has failed or its logs are indicating errors, you will not hear any audio.
modep-mod-host.service - the LV2 plugin host which uses jack to process audio
modep-mod-ui.service - the service which serves the MOD webui for configuring pedalboards
mod-ala-pi-stomp.service - pi-stomp software/firmware which monitors all input devices, drives the LCD and interacts with modep-mod-host and modep-mod-ui.
touchosc2midi.service - the TouchOSC2MIDI bridge service. If it is not running, TouchOSC Apps will not work.
systemctl & journalctl
The systemctl command is used to control services. The journalctl command is used to view the log output of services. Below are some common uses.
Command usage
systemctl --help journalctl --help
Status listing of all services
sudo systemctl status
List services which failed to run:
sudo systemctl list-units --failed
Restart a service
sudo systemctl restart <SERVICE-NAME>
Stop a service
sudo systemctl stop <SERVICE-NAME>
Show a running log of all services
sudo journalctl -f
Show a running log of a specific service
sudo journalctl -f -u <SERVICE-NAME>
Search the log for errors
sudo journalctl | grep 'error'