The Raspberry Pi Model B+ Q&A thread

[tlc]

B+ audio enhancement...
I have tested B+ audio (via analog output) and yes, personally, the reproduction itself sounds a bit more real and rich than it is at B or A models. And default output level is aprox 3db louder. Thanks for that enhancement.
But I have found that there is some slight level of noise hearable from my B+ model in case that a "silence" is played.
I have tested it using a couple of headphones only (have no opportunity to test it with profi sound equipment or osciloscope yet).
Level of this noise is not affected by volume control, and is hearable only when "silence" or very low signals < -20db music (wav/mp3) or < -40db 1kHz signal (wav) is beeing played. When the signal is higher and fades out to silence then after aprox 2 seconds the noise reappears.
Model B and A have no hearable noise - it is clear silence when clear silence (wav/mp3) is beeing played.
I have tested it with "omxplayer -o local" (latest software and firmware (6.Aug) + firmware from 1.Aug - (and additionally on A and B with SW+FW from 18.Jun 2014)).
It seems to me that some kind of signal compression or ALC is used somwhere at the sound path.
Does someone other noticed this behaviour? Or does someone know if there is some kind of ALC used at B+ model?
Looking forward to release of the full B+ schematics...

[with ice cream]

I switched from a B, rev. 2, to a B+ and at the same time changed the audio output from a USB sound card to the 3.5 mm jack. I also detect some noise during audio playback (mpd/mpc with alsa) but, due to the output method switch, cannot confirm if that is a B+ specific issue. It had been using the USB card for quite a while but I don't recall that there was noise like that beforehand.

What is bothering me even more is a rate slowdown when using espeak. The longer a phrase the more robotic it gets. Longer sentences sound almost comical.

[rpdom]

Note that the PWR LED is now connected to an undervoltage supervision chip. The PWR LED will flash (or go out) if the PSU voltage drops below ~4.63V.

Is there a way to read input voltage with 'vcgencmd measure_volts' or something similar?

No. There is no ADC on the power input. There is a simple circuit that turns the LED off below about 4.63V. That is all.

You can however monitor the LED status by checking the value of GPIO 35 (1 = on=normal voltage, 0 = off=low voltage)

[SomeGuy42]

No. There is no ADC on the power input. There is a simple circuit that turns the LED off below about 4.63V. That is all.

You can however monitor the LED status by checking the value of GPIO 35 (1 = on=normal voltage, 0 = off=low voltage)

That will work for me. Thank you very much for the info.

[Damage]

Quick Question are all Raspberry Pi B+ made in the UK (Wales)?

I am looking to buy one in the next few days from 'Amazon' (sold by Amazon). I know they are not the recommended supplier but I want to buy other items at the same time, so it makes life easier to get them all from one place. I have read reviews on amazon claiming that people have purchased other models of the Raspberry Pi that were 'made in China' and did not work as well as UK model. Do these sound like fakes? If all are make in the UK then getting it from Amazon should give me a UK version.

Thanks for any info you can give.

[plugwash]

Quick Question are all Raspberry Pi B+ made in the UK (Wales)?

As I understand it all Pi's made for the global market are now made in wales and have been since before the B+ was introduced. So it would follow that all B+ Pi's made for the global market were made in wales.

I have no idea what is going on with the red Pi's made for the chinese market. I can't find any evidence of a red B+.

I am looking to buy one in the next few days from 'Amazon' (sold by Amazon). I know they are not the recommended supplier but I want to buy other items at the same time, so it makes life easier to get them all from one place. I have read reviews on amazon claiming that people have purchased other models of the Raspberry Pi that were 'made in China' and did not work as well as UK model. Do these sound like fakes? If all are make in the UK then getting it from Amazon should give me a UK version.

Early raspberry pi's were made in china as at the time the raspberry pi foundation could not find a UK factory who could meet their requirements regarding price and production quantity. Later a sony factory in pencoed wales contacted them and offered their services.

Due to high demand and limited ability to ramp production at the factory in wales there was a long period of overlap when Pi's were made in both the UK and china. During this time it was widely observed that the sony factory in wales did a much better job of maintaining consistently high quality than the chinese factories did.

Counterfeits are unlikely as the margins are slim and the broadcom SoC is difficult to obtain (though at least one company has managed to get hold of them and made a device that is software compatible with the Pi but in a different form factor).

[JakeWisniewski]

Have the changes made to the B+ allow a usb touch screen monitor to be powered by the pi? In the past (model b rev. 2) a powered usb hub was required due to brown out issues.

[fruitoftheloom]

There is a setting to enable maximum power draw of 1.2A on the USB Bus whether this will be enough is dependent on whatever else is plugged in:

https://projects.drogon.net/testing-set ... berry-pi-b

[Charly86]

Well,

That's strange, I'm just curious, why the old existing GPIO 28,29,30,31 have not been routed onto the new connector and used some of the new GPIO instead (which where unused until now because not available) to control new hardware things such LAN NReset !!!

Assigning new functions to existing GPIO 28 to 31 just break anything that were using them. I'm just curious and I would like to understand, there may be a good reason for that I would be aware

[AndrewS]

Because it makes all of the Bank0 GPIOs (0 -> 27) available on the header http://elinux.org/RPi_BCM2835_GPIOs

[jojopi]

Because it makes all of the Bank0 GPIOs (0 -> 27) available on the header

But the official advice is not to use GPIO0/1 for anything other than HAT EEPROMs. 0/1 and 28/29 could just as easily have been the other way around.

I do not see the advantage in having a full bank anyway. If anything it means you get only one bank's maximum load of 50mA, instead of two.

Incidentally, has anyone revealed how the B+ manages to route so many more GPIOs out from the BGA than had been possible in previous revisions?

[wallarug]

I thought GPIO 0/1 were used for the CAM interface? and that is why it was changed from revision 1 to revision 2.

[AndrewS]

I thought GPIO 0/1 were used for the CAM interface? and that is why it was changed from revision 1 to revision 2.

On the Rev 1 Model B Pis, GPIOs 0/1 (I2C-0) are connected to P1 pins 3/5, and GPIOs 2/3 (I2C-1) are connected to the CSI (camera) port.
On the Rev 2 Model B Pis, GPIOs 2/3 (I2C-1) are connected to P1 pins 3/5, and GPIOs 0/1 (I2C-0) are connected to the CSI (camera) port.
On the Model B+ Pis, GPIOs 2/3 (I2C-1) are connected to the P1 pins 3/5 (now renamed as the 'GPIO' header), and GPIOs 0/1 (I2C-0) are the 'DNC' pins 27/28 exclusively for use by the firmware to interrogate the EEPROM on HAT boards at bootup. GPIOs 28/29 (I2C-0) are connected to the CSI (camera) and DSI (display) ports.

(AFAIK, on the B+ the firmware 'de-activates' I2C-0 on GPIOs 0/1 after bootup, and then 'activates' I2C-0 on GPIOs 28/29 to talk to the camera post-bootup)

[wallarug]

I thought GPIO 0/1 were used for the CAM interface? and that is why it was changed from revision 1 to revision 2.

On the Rev 1 Model B Pis, GPIOs 0/1 (I2C-0) are connected to P1 pins 3/5, and GPIOs 2/3 (I2C-1) are connected to the CSI (camera) port.
On the Rev 2 Model B Pis, GPIOs 2/3 (I2C-1) are connected to P1 pins 3/5, and GPIOs 0/1 (I2C-0) are connected to the CSI (camera) port.
On the Model B+ Pis, GPIOs 2/3 (I2C-1) are connected to the P1 pins 3/5 (now renamed as the 'GPIO' header), and GPIOs 0/1 (I2C-0) are the 'DNC' pins 27/28 exclusively for use by the firmware to interrogate the EEPROM on HAT boards at bootup. GPIOs 28/29 (I2C-0) are connected to the CSI (camera) and DSI (display) ports.

(AFAIK, on the B+ the firmware 'de-activates' I2C-0 on GPIOs 0/1 after bootup, and then 'activates' I2C-0 on GPIOs 28/29 to talk to the camera post-bootup)

So has the camera SDL/SDA bus changed again??

EDIT: incorrect info.

[AndrewS]

Firstly, The camera uses SDA/SCL bus not the I2C bus.

http://en.wikipedia.org/wiki/I2c#Design

[wallarug]

Firstly, The camera uses SDA/SCL bus not the I2C bus.

http://en.wikipedia.org/wiki/I2c#Design

Hahahaha, I got confused. Still learning. But you didn't answer my last question.

[AndrewS]

The camera firmware (running on the GPU) still uses I2C-0 on the B+ (same as on the B) but it uses GPIOs 28/29 to talk to the camera over I2C-0, rather than GPIOs 0/1. But this is all buried away deep inside the GPU firmware (i.e. not accessible from the Linux / CPU side), so is nothing you need to worry about All the camera software will continue to work just as before, with the GPU firmware doing all the necessary magic behind the scenes.

[wallarug]

The camera firmware (running on the GPU) still uses I2C-0 on the B+ (same as on the B) but it uses GPIOs 28/29 to talk to the camera over I2C-0, rather than GPIOs 0/1. But this is all buried away deep inside the GPU firmware (i.e. not accessible from the Linux / CPU side), so is nothing you need to worry about All the camera software will continue to work just as before, with the GPU firmware doing all the necessary magic behind the scenes.

Sounds like fun. I did not realise that you would access the same "ALT" function on different pins. That would explain a lot.

[AndrewS]

Sounds like fun. I did not realise that you would access the same "ALT" function on different pins. That would explain a lot.

Probably not at the same time, because it can lead to bugs: http://www.raspberrypi.org/forums/viewt ... 43&t=84000

http://elinux.org/RPi_BCM2835_GPIOs shows all the ALT settings of all the pins. And if you wade through http://www.raspberrypi.org/documentatio ... uration.md you can see which GPIOs have which ALT settings applied by default on the different Pi models.

[pnelsonsr]

Have had problems with the SanDisk microSD 32GB card. Can someone recommend a card that works well with the B+? I was looking a Kingston or Lexar.

[AndrewS]

Have had problems with the SanDisk microSD 32GB card.

There's no such thing as "the" SanDisk microSD 32GB card - all manufacturers sell a dizzying variety of cards of different sizes / classes / sub-brands / prices

Can someone recommend a card that works well with the B+? I was looking a Kingston or Lexar.

AIUI there shouldn't really be any reason for any SD card (at least name-brand ones) to not work with the Pi, assuming you're using a distro downloaded from http://www.raspberrypi.org/downloads/
Have you tried using H2testw to check your card isn't faulty?

This is really a question for the trouble-shooting thread, rather than the B+ Q&A thread.

[pnelsonsr]

There's no such thing as "the" SanDisk microSD 32GB card - all manufacturers sell a dizzying variety of cards of different sizes / classes / sub-brands / prices

while you are correct, what I have found was that others have had problems with SanDisk cards so I just wanted to make sure that any recommendation wouldn't include a SanDisk microSD is all. I want to try something else.

AIUI there shouldn't really be any reason for any SD card (at least name-brand ones) to not work with the Pi, assuming you're using a distro downloaded from http://www.raspberrypi.org/downloads/
Have you tried using H2testw to check your card isn't faulty?

This is really a question for the trouble-shooting thread, rather than the B+ Q&A thread.

I thought that SanDisk being a major player was a good option. But I have had nothing but problems. So I wanted to try something else. I have not tried H2testw on the card but I did purchase another SanDisk card thinking that it must be a bad card, but I got the same results.

The reason I came here was because I am setting up a raspberrypi B+ and wanted to get a recommended microSD card to try with my Pidora distro.

[blachanc]

while you are correct, what I have found was that others have had problems with SanDisk cards so I just wanted to make sure that any recommendation wouldn't include a SanDisk microSD is all. I want to try something else.

Can you live with 8GIG?

if yes, than my answer is the noobs card...

official_noobs_card

Ben

[jamesh]

There's no such thing as "the" SanDisk microSD 32GB card - all manufacturers sell a dizzying variety of cards of different sizes / classes / sub-brands / prices

while you are correct, what I have found was that others have had problems with SanDisk cards so I just wanted to make sure that any recommendation wouldn't include a SanDisk microSD is all. I want to try something else.

AIUI there shouldn't really be any reason for any SD card (at least name-brand ones) to not work with the Pi, assuming you're using a distro downloaded from http://www.raspberrypi.org/downloads/
Have you tried using H2testw to check your card isn't faulty?

This is really a question for the trouble-shooting thread, rather than the B+ Q&A thread.

I thought that SanDisk being a major player was a good option. But I have had nothing but problems. So I wanted to try something else. I have not tried H2testw on the card but I did purchase another SanDisk card thinking that it must be a bad card, but I got the same results.

The reason I came here was because I am setting up a raspberrypi B+ and wanted to get a recommended microSD card to try with my Pidora distro.

Hmm, I've used quite a few Sandisk devices with no problem....but usually less than 32GB.

[mahjongg]

sandisk is one of the brands that is faked the most.