Raspberry pi 3 vs 2

[siamect]

Thanks everybody for a nice library. I have used it a lot with Rpi2 and it works great but now I'm trying with a Raspberry pi 3 and it is not working.
Just random flickering. I read than someone suggested dependency of HDMI but I have tested both with or without HDMI monitor connected.
I use the latest Raspbian Jessie. Compiling with scons works fine but when I try run the test program (main.c), just flickering...
Once again, thanks for a great library...

[penfold42]

Did you power cycle the pi after plugin in HDMI ?

[siamect]

Thanks for replying!
Yes, i did it many times... and I also went back to the version where RPi3 was added... same problem.

[siamect]

I there anything specific to PI3 i have to do more than just "scons" and then "sudo ./test" ?

[siamect]

Correction... If I take the SD card with a clean Raspbian downloaded today and put it in a Pi3 it fails, just flickering.
If I put the same SD card in a Pi2, clean out the object files executables etc, so I make a really clean scons again, then I get the same fail, just flickering.

So the successful running has always been on an older version of Raspbian... It really is not a matter of Pi2 or Pi3.

Hope this can make it easier to find out what is going on.

[Gadgetoid]

This same problem was reported recently by users of Unicorn HAT: pimoroni/unicorn-hat#56

Using the latest version of Raspbian Jessie something has changed in X which ties up the audio hardware and interferes with the PWM used by this library. You will need to explicitly force your audio to HDMI, whether or not you have an HDMI screen connected, or disable it altogether to prevent this.

Try adding the following to your /boot/config.txt

hdmi_force_hotplug=1
hdmi_force_edid_audio=1

[siamect]

I can confirm this works with RPi2.
With RPi3 the LEDs did not light up at all.
I used the same SD-card for both RPi2 and RPi3.
So there is a difference somewhere.

[Gadgetoid]

That's very peculiar. I'm using an RPi3 at the moment for my primary testing/development setup, and successfully ran this code against one of our Unicorn HATs only yesterday.

Do you have any way to determine if there's a hardware level fault with your RPi3? Is anything else changing in your setup between Pi's?

[siamect]

Sorry for the delay, I'm busy with other things right now and I solved the immediate problem squeezing in an arduino between the RPi and the sw2812b.

However, I have an oscilloscope, I can see what I get from that...

[grahamawelch-zz]

I'm attempting to use the python library on a Pi Zero 1.3. I'm seeing similar issues with random flickering.

As soon as I power up the Pi, the first LED in the strip will light up. Then once I run strandtest.py (or anything attempting to talk to the strip), it starts lighting lots of LEDs randomly and doesn't stop, even once I've stopped sending any instructions to the strip. Unplugging and replugging in the LED strip will resume the random blinking.

I've added hdmi_force_hotplug=1 and hdmi_force_edid_audio=1 to /boot/config.txt, but that didn't seem to make a difference. I've also Forced Audio to HDMI through raspi-config.

I've tested this on both 2015-11 and 2016-5 images of Jessie, on two separate Pi Zero, on two different led strips, using the circuit from http://popoklopsi.github.io/RaspberryPi-LedStrip/#!/ws2812

[jgarff]

Please try blacklisting the Broadcom audio kernel module. There are some
reports that the HDMI changes aren't enough to keep the audio module from
using the pwm.

On Sun, Jul 31, 2016, 8:31 PM grahamawelch [email protected] wrote:

I'm attempting to use the python library on a Pi Zero 1.3. I'm seeing
similar issues with random flickering.

As soon as I power up the Pi, the first LED in the strip will light up.
Then once I run strandtest.py (or anything attempting to talk to the
strip), it starts lighting lots of LEDs randomly and doesn't stop, even
once I've stopped sending any instructions to the strip. Unplugging and
replugging in the LED strip will resume the random blinking.

I've added hdmi_force_hotplug=1 and hdmi_force_edid_audio=1 to
/boot/config.txt, but that didn't seem to make a difference. I've also
Forced Audio to HDMI through raspi-config.

I've tested this on both 2015-11 and 2016-5 images of Jessie, on two
separate Pi Zero, on two different led strips, using the circuit from
http://popoklopsi.github.io/RaspberryPi-LedStrip/#!/ws2812

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#103 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIPem8thWKW24OQy8Gr3K8CVAmMOGd5Uks5qbVp3gaJpZM4JJGUz
.

[grahamawelch-zz]

Thanks for the quick response. I blacklisted the module. I also re-soldered my ground pin between the Pi and the Level Shifter. Everything is working as expected now.
I imagine my poor soldering was the root cause here. Sorry for the confusion.

[philtgarner]

Just wanted to add that the fix @Gadgetoid mentioned about forcing the audio to the HDMI worked a treat on the Raspberry Pi Zero. Much appreciated, I was beginning to get frustrated with the random flickering.

[tom-2015]

How do you blacklist the audio module?
I've tried adding snd_bcm2835 and snd-bcm2835 to /etc/modprobe.d/raspi-blacklist.conf but this didn't solve the problem.

Edit:
I found it, it's in /boot/config.txt

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on

working now

[jgarff]

You also need to remove it or comment it out in the /etc/modules file since
it's loaded explicitly on bootup.

On Sun, Oct 23, 2016 at 5:54 AM Tom [email protected] wrote:

How do you blacklist the audio module?
I've tried adding snd_bcm2835 and snd-bcm2835 to
/etc/modprobe.d/raspi-blacklist.conf but this didn't solve the problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#103 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIPem72CrE-v9A5hTGTMzN6cZrEemZ5Kks5q20r_gaJpZM4JJGUz
.

[mweinelt]

echo "blacklist snd_bcm2835" > /etc/modprobe.d/raspi-blacklist.conf

[Brobes05]

Hello. I am having two issues both with the latest RPi 3 on Python 2.7.9 and 3.4.
First, one one machine, I have the some LEDs working, but only half of the array is lighting up. Does this mean that I have a faulty array? Should I be using python 3?

Furthermore, with another machine (RPi 3 as well) I am constantly getting :
ws.2811_init failed with code -5 (map() failed) with Python 2.7. and with python 3 I am getting errors about NeoPixel not being installed.

Clearly, I have failed to install something correctly, but have followed the instructions on these links:
https://community.zymbit.com/t/control-neopixels-with-a-raspberry-pi/20
https://learn.adafruit.com/neopixels-on-raspberry-pi/software

I am running python from idle. Would running it from the terminal make a difference? Thank you very much.

[ashthespy]

I would like to say that I am also unable to run the compiled test with sudo ./test successfully with my pi 3.

Setup:

I have disabled audio by:

1. Commenting out dtparam=audio=on in /boot/config.txt
2. Checked the /etc/modules file, nothing there
3. Added blacklist snd_bcm2835 in /etc/modprobe.d/snd-blacklist.conf

Hardware:

Have the strip connected to Gnd and GPIO18.
Which brings me to ask if for the pi 3, is GPIO18 still the right pin when following this notation?

EDIT: Got the python version to work both with GPIO18 and 13

[Bzzz]

SK6812 is completely dead when there is a blacklist entry for snd_bcm2835 (running a RPi Zero 1.3).
However, if I load this module after startup (sudo modprobe snd_bcm2835), everything works fine. If the module is loaded automatically via the /boot/config.txt entry, it's just a random mess of colors and positions, both the test and python examples do not obey strip length or intensity limits. An Arduino using the very same 74HCT125 level shifter worked fine all the time, so it had to be a RPi-specific problem.

Not sure what to do with this information, but at least the damn SK6812 is now working, just five hours after setting up the most basic test circuit... ;)

:edit: 74HCT125, not 124

[leachj]

I'm having the same issue, i've tried all of the solutions mentioned including blacklisting and forcing HDMI sound but all I get is random flickering.

[Bzzz]

Pi Zero or 3?
Disabling the dtparam=audio=on line isn't actually necessary when blacklisting is active. I'm running this Pi headless, that is, no display connected at all, only xrdp and ssh active. Can you try that, maybe?
Also, which settings do you use for the example files? Mine are

LED_L = 58 # number of LEDs (length)
LED_W = 34 #number of LEDs (width)
LED_COUNT = 2* (LED_L + LED_W) # Number of LED pixels.
LED_PIN = 18 # GPIO pin connected to the pixels (must support PWM!).
LED_FREQ_HZ = 800000 # LED signal frequency in hertz (usually 800khz)
LED_DMA = 5 # DMA channel to use for generating signal (try 5)
LED_BRIGHTNESS = 255 # Set to 0 for darkest and 255 for brightest
LED_INVERT = False # True to invert the signal (when using NPN transistor level shift)
LED_CHANNEL = 0
LED_STRIP = ws.SK6812_STRIP_RGBW

(the LED_L/_W parameters are not standard, just used for my application - it is safe to delete them and set _COUNT to an integer)

Which level shifter is in place? I had concerns about mine as the output voltage was quite a lot below 5V. However, that is in line with datasheet specs, doesn't change when double-shifting, and also works with Arduino input. I also checked with an oscilloscope and there is not much crap added to the signal. So I ruled out that the 74HCT125 is the culprit in my case...

[leachj]

I'm running this on the pi3 and using the 74HCT125

I was running mine with a display attached but I will try headless. Config parameters look similar but I am running with a w2811 strip. I'll do a full comparison tomorrow

[pintman]

@Bzzz What do mean by "quite a lot below 5V"? How much is it?

[Bzzz]

In the best case just shy of 4V actually, so massively below CMOS hi level. Yet an improvement from the 2.5V of the RasPi, which barely surpasses TTL hi level. Well, LV-TTL levels seem to be the same according to the German Wikipedia page, while the English one has quite different values.

...I guess that creates more confusion than clarification. Sorry :D

[NoSheds]

I'm using 2017-02-16-raspbian-jessie with 5 Adafruit NeoPixel Diffused 5mm Through-Hole LEDs.
I followed the instructions at https://learn.adafruit.com/neopixels-on-raspberry-pi/software. I put the leds onto a breadboard, daisy-chaining output to input in series, powering the LEDs from 3.3V from the PI.

When I tried to run "test", I got nothing. I then tried strandtest.py and got a brief flicker when I started it, but then nothing. I played around with some of the settings in strandtest.py and found that if I changed LED_FREQ_HZ down from 800000 to approximately 10x lower, eg = 80000 and I get some output, very flickery.

I'm running it on a PI3, and it's the most recent version of Raspbian.

I followed this thread's suggestions.
I've edited /boot/config.txt and added

hdmi_force_hotplug=1
hdmi_force_edid_audio=1
and also commented out the line to read
#dtparam=audio=on

I've also Forced Audio to HDMI through raspi-config

I added blacklist snd_bcm2835 to /etc/modprobe.d/raspi-blacklist.conf
I rebooted, and using lsmod, couldn't see anything that implied sound or bm2835.

No joy. Any ideas what I can do? I don't want to use a separate PWM controller - I'd like to use a pi to do it all.

[electrokean]

@NoSheds powering the LEDs from 3.3V will not work. If you're drawing that from the Ras Pi, you could damage the Ras Pi as it can only 50mA from its 3.3V pin, and each NeoPixel can draw 60mA.
You need to power the LEDs from 5V with a suitable power supply connection, and ideally you also need to use a level shifting buffer to raise the Ras Pi data signal from 3.3V to 5V logic levels.
All of this is spelled out quite clearly at https://learn.adafruit.com/neopixels-on-raspberry-pi/wiring - the page prior to the one you linked above.

[NoSheds]

@electrokean Thanks for pointing that prior page out to me - I had not spotted that. I will experiment with different power systems and/or the diode, but it seems to me that the symptoms match a failure with the PWM rather than a power issue. Although the pi may be nominally 50mA officially, I have a 3A power supply powering it, and from what I've read, the 3.3V pin can supply much more than 50mA. If it helps, I tried with just one Neopixel Led connected to the power and it made no difference, which kind-of confirms that whatever the problem, it's not power.

Do you have to do anything with the last data-out pin?

[electrokean]

@NoSheds The 3A power supply is for the main 5V into the Pi. A certain amount of that is required for the Pi itself, plus USB connected devices. The 3.3V header pin on the Pi is only recommended for use when drawing less than 50mA, otherwise you need a separate 3.3V regulator. You also must not draw too much current from the 5V header pin on the Pi, and that is quite easy to do when using a strip of LED pixels. If you have more than about 20 pixels, then you will need them powered off another 5V PSU, and make sure the Pi and LEDs share a common ground.

The data signal coming from the Pi (which is not PWM) is only 3.3V logic, but the NeoPixels are specified to operate with 5V inputs for both power and data signal. The 3.3V data signal may be recognised by the first pixel if you're lucky, but it will almost certainly be unreliable without buffering. The NeoPixels themselves still require a 5V supply for the PWM driver to operate the LEDs, as blue and green LED will often need more than 3.3V to light up at all. If the 5V supply gets too low (e.g over long cables) you'll often see the red LED dominating over the others for this reason.

So you need to address both these issues to get them working properly.

No, you don't need to do anything with the last data out pin from the Neopixel string.

[tom-2015]

I've never had any problems connecting the 3.3V output pin to 5V powered LEDs. But I've experienced problems when putting the LEDs on a breadboard, after a few days everything starts oxidizing a bit and the contact resistance may get too high. This results in strange behaviour like only the first x LEDs working or random colors, reduced brightness,... Moving the LEDs up/down a few times makes everything work again.

I'd suggest to make sure the input signal is correct, use a scope to measure what's coming out of the Pi.
Make sure audio is off, normally there should be a cross over the audio icon on the taskbar of the Pi desktop.
Try soldering the LEDs instead of putting them on a breadboard or buy a LED strip.

[NoSheds]

@electrokean
I hear what you're saying about not drawing more than 50mA, but I've also heard of people drawing much more than that without any problem. I am not running a strip of leds, or more than 20 - I'm running 5. I also tried just running 1, and had no difference at all. I've also heard of many people running them from 3.3v without any problems. You say that the first led may light but not the others, but again, this is not what I'm experiencing. I'm getting colours - mainly blue, but nothing reliable. I am not running a long cable - less than 10cm away from the pi.

All this makes me convinced that it is not power that is the issue.
@tom-2015
I tried this with the LEDs straight out of the packet so at the time, I don't think oxidation was the problem. Also, all the LEDs lit equally, just not predictably or as I would expect. I will look for the audio icon and see what it says. I don't have a scope, so I can't do that.
I'll consider soldering.

[pulcher]

@NoSheds The unreliable colors that you are seeing are more than likely due to the 3.3v not able to raise the voltage high enough, fast enough to trigger a logical 1 reliably. I suspect you are getting way more logical 0's that you are expecting.

[NoSheds]

@pulcher OK, thanks, that makes sense. I can try using the diode method to reduce the supply voltage as listed in the documentation and see if that works first & if that doesn't work, I'll try the other approach.

[electrokean]

@NoSheds as an electrical engineer, I can only tell you the facts under which things are specified to work. It is your choice to ignore a random guy on the internet who tries to help, but you shouldn't expect more help until you at least try fixing the obvious problem first.
The fact it works for someone else, could just mean they were just lucky (or mistaken) as it is completely out of specification, and could stop working or become unreliable at any time due to changes in temperature, humidity, moon phase, etc. Different batches of LEDs could also have different tolerances, or even be fake parts with poorer specification silicon.

[NoSheds]

@electrokean Hi, look I appreciate you trying to help. Perhaps I have been misLED (pun) by the fact that the leds lit up and lit up brightly into thinking that power was not the issue. I know that the recommended power supply for the PI has been uprated, and I know that the power circuitry of the pi has been uprated, and having googled, I've found multiple comments on the Pi forum stating that there seemed to be no official increase in the spec-ed power output of the pi, but multiple people stated they've successfully drawn way more than 50mA with no problems. That, the fact that 5 leds lit brightly, and there being no difference between one and five leds led me to believe that power was not the problem. Also, changing the frequency has an effect of the led lighting up pattern. This again pointed me to the PWM being the problem not power. I did not believe that it was completely out of spec because I did look and I'm sure I read on a spec sheet somewhere that it would work at 3.3v. In fact the very document you pointed me at (https://learn.adafruit.com/neopixels-on-raspberry-pi/wiring) says that it may work directly from 3.3v, but gives two better options. These things led me to thing power was not the issue, but the fact that people had been having problems with the latest version of Raspbian because the sound circuitry was using the PWM that the Neopixels relied on suggested that that was the problem.

This is why I was resistant to your suggestion that power was the issue, and it wasn't until @pulcher 's comment that I understood why power might be an issue.

I will try some of the things suggested (subject to availability of funds, components and time) and see what happens.
Thank you for trying to help.

[electrokean]

@NoSheds yes, but those increases in ratings on the Pi were for the 5V supply, not the 3.3V. I've not seen anything to indicate the 3.3V supply generated by the Pi is rated any higher for later models, so the recommendation of not drawing more than 50mA stands. Also note that there is a big difference between power, voltage, and current, and reading these various posts by random authors who may not understand the difference have probably just misled you.
You very likely have a voltage level problem as we've discussed above, where the logic levels of the pixel data are not correctly recognised as they don't meet the voltage level specifications. To fix this properly isn't hard or expensive, you just can't cut corners and expect it to function or be reliable - that isn't how engineering works.
You just need something like this to go between the 3.3V data signal, and the 5V LEDs. That chip will run off 5V, but is designed to recognise 3.3V logic signals properly and generate and equivalent 5V logic level signal. It is also fast enough to handle the data rates used by the different LEDs. Again, that info is all in the Adafruit page I linked to.
Once you solve this issue, you'll probably find it works, and if not at least we'll be on common ground to help.

[NoSheds]

OK, so using https://learn.adafruit.com/neopixels-on-raspberry-pi/wiring as a plan. It specifies a 74AHCT125. I could only find this at maplin: http://www.maplin.co.uk/p/74hct125n-hct-cmos-logic-rs21x It seems to have the same pin layout and diagram so I tried it. I wired it as per the diagram, with the 5 leds. I modified the streamtest.py (or similar) program so that it would set all 5 leds white, then off, pausing for 1/2 second between each state. Powering from the external PSU at either 5 or 4.5V, the LEDs switched on constant blue, and didn't change. On a whim, I disconnected from the external PSU, and instead connected it to the PI's 5V. Running the program again gave vague flashes of white, but not constant. I will try to try it with a different pi and a different version of Raspbian and see if anything makes a difference

[NoSheds]

Success!
@electrokean my apologies. You're right - the PI can't power it - you need an external PSU.
Without changing anything else, I dropped the Neopixel supply voltage from the nominal 5V, down to 4, then to 3V (it's a variable output PSU). At 3V, it worked. I guess that either the external PSU is running a bit over spec voltage, or the Pi PSU is a bit under 3.3V, or the chip I have isn't as forgiving as it might be.

So it works with Pi3, latest version of Raspbian & my problems were nothing to do with PWM frequency, or audio being in use. In fact I tried it on an old version of raspbian without disabling the audio and it worked.

Thanks for your patience. I did not have a software problem; it was user error.

[electrokean]

@NoSheds Great! Running the NeoPixels at a lower voltage effectively changes the voltage levels that they accept for logic 1 and 0, so they now can properly decode the incoming data stream.
As mentioned though, the blue and green LEDs will struggle to operate at lower voltages, especially as you ramp up brightness, and the NeoPixels are just generally running outside specification.

[electrokean]

@NoSheds not sure why your 74hct125 test didn't work. It is very similar to the 74ahct125.

The T in both part numbers indicate TTL input levels (vs CMOS), which mean the input threshold for a logic 1 is 2.0V, which is compatible with the 3.3V logic levels from the Pi.

The A in the latter part means advanced, and it will operate at lower voltages and also tolerant of 5V inputs even running at lower voltages, thus it can also be used for level conversion in the opposite direction.

A 74HC125 (no T) would not be suitable as it uses the CMOS input levels of 30% (low) and 70% (high) of the supply voltage, and thus at 5V it is only guaranteed to work with 3.5V for a logic 1. With most modern devices, including the NeoPixel I believe, the CMOS input levels are used as CMOS design generally leads to lower power consumption.

[gdudek]

RPI3 problem fixed for me using
hdmi_force_hotplug=1
hdmi_force_edid_audio=1
as described above.

[derbl4ck]

I can confirm that solution, worked for me using RPI3

[gcoates5]

Hello, I am experiencing this problem only after playing an audio file on the 3.5mm audio jack. I've tried 'sudo modprobe -r snd_bcm2835' and 'sudo modprobe snd_bcm2835', in an attempt to reset the service before using PWM0 and PWM1 to control my Neopixels. After which, the only way to fix it is to reboot the pi. Is there a way to do this without having to reboot? My program sequence just lights up the NeoStrip, plays an audio file, and then later lights up another set of Neos. And as I said, the Neos don't work after audio has been played.

neos.main()
neos.stripOne(255,0,0)
os.system("omxplayer /home/roomOne/audioFiles/example.mp3 > /dev/null")
os.system("sudo modprobe -r snd_bcm2835")
neos.circleOne(255,0,0) <-- NOT WORKING

Thanks for any help.

[Gadgetoid]

From what I understand, the use of PWM for analog audio output is handled by the videocore driver blob and once you start it running there's simply no way to control its behaviour and a reboot is the only solution.