TL;DR: The Raspberry Pi 3 Model B+ is a nice update that provides, better networking with WiFi now 802.11.b/g/n/ac, Bluetooth 4.2/BLE and Gigabit Ethernet (although limited to 300Mbps). For Makers, the Raspberry Pi Foundation has made it easier to incorporate the RPi3B+ into end products keeping the RPi3B+ in production until at least January 2023 and providing "modular compliance certification" for the wireless module.
- Same mechanical footprint as both the Raspberry Pi 2 Model B and the Raspberry Pi 3 Model B.
- Same GPIO pinout, so no need to change your hats/shields/daughter boards
- Same power supply recommended (5V/2.5A DC via micro USB connector)
- Broadcom BCM2837B0, Cortex-A53 64-bit SoC (System on a Chip), but this time clocked to 1.4GHz, which yields roughly a 10% performance increase over the Raspberry Pi 3 Model B. The chip now has a metallic heatsink and bears the markings BCM2837B0 1FSBG, TA1738 P20 W39-01 N2 W.
WHAT IS NEW:
------------
WIRELESS MODULE:
The product briefing document from the foundation states that the onboard wireless module now supports dual-band 2.4GHz/5GHz IEEE 802.11ac and both Bluetooth 4.2 and BLE (Bluetooth Low Energy).
?
The wireless module in the RPi3B+ is not mentioned in the product briefing document and is hidden under shielding. Prying open the shielding revealed a Cyprus Wireless CYW43455 (datasheet).
- The CYW43455 supports the following WiFI standards: 802.11ac/n/a/b/g/d/h/i
- Security: (WEP/ WPA Personal / WPA2 Personal / WMM /WMM-PS (U-APSD) /WMM-SA / AES (hardware accelerator) /TKIP (hardware accelerator) / CKIP (software support)
- Proprietary protocols (CCXv2, CCXv3, CCXv4, CCXv5, WFAEC
- IEEE 802.15.2 Coexistence Compliance (on-silicon solution compliant with IEEE 3-wire requirements)
- The CYW43455 supports the following future IEEE drafts/standards: 802.11r (fast roaming between APs), 802.11w (secure management frames), 802.11 Extensions:, 802.11e QoS Enhancements (as per the WMM specification is already supported), 802.11h 5 GHz Extensions, 802.11i MAC Enhancements, 802.11k Radio Resource Measurement
The CYW43455 data sheet states that the Bluetooth core supports:
- Bluetooth 2.1 + EDR
- Bluetooth 3.0
- Bluetooth 4.2 (Bluetooth Low Energy)
The Wireless LAN module now has "modular compliance certification", which allows the board to be designed into end products with significantly reduced wireless LAN compliance testing, improving both cost and time to market.
NEW GIGABIT ETHERNET:
The new RPi3B+ has support for Gigabit Ethernet using Microchip's LAN7515 (which is a USB 2.0 to 10/100/1000 Ethernet Bridge with 4-port USB 2.0 Hub). The LAN7515 supports a max number of 6 downstream USB ports and 1 Ethernet Port limited to a maximum throughput of 300 Mbps.
The LAN7515's ethernet controller supports numerous power management wakeup features, including Magic Packet™, Wake-on LAN (WOL) and Link Status Change.
POWER:
The RPi3B+ is Power over Ethernet (PoE)–enabled, but requires the purchasing of a separate PoE HAT.
PRODUCTION LIFETIME:
If you're thinking of incorporating the Raspberry Pi 3 Model B+ into another product, the Raspberry Pi foundation has committed to keeping the RPi3B+ in production until at least January 2023.
HEAT MANAGEMENT:
Due to the BCM2837 now running at 1.4GHz, the RPi3B+, runs relatively warm. The foundation provides the following warning: "This product should be operated in a well-ventilated environment and, if used inside a case, the case should not be covered". Given the optional "open lid configuration" of the official Raspberry Pi case I asked for clarification, and their Director of Product Management came back with: "It only means if you have it in a case the case itself should not then be covered".
> This product should be operated in a well-ventilated environment and, if used inside a case, the case should not be covered
Does this make the B+ model more dangerous in case of overheating?
I have a couple of Pis running inside official Pi case they hold between 35 - 53 degrees. ( 35 meaning unheated room ). I would be sad if I upgrade the devices and then loose my sleep in case of overheating.
I was confused by that too. "You used to require a separate board to use PoE. Now you... still need a separate board to use PoE." Oh well.
Also, as possibly the only person left who really doesn't care at all about wireless... I'm glad there's a refresh, sure, but... I'm meh. I've been pxe booting my pi3s for a while now.
Now, if it had official "clean" debian support (not "raspian") that would be something!
Possibly it will make the official PoE board cheaper? The existing one I have, which works rather well actually, cost almost the same as the Pi, which kinda limits its usefulness (when a PSU costs ~£6 max)
Yes, the old PoE hats had two RJ45's on them, and you needed a short cable between that and the Pi. It's unfortunate they had to put a fan on the new hat though.
I'm not native English speaker and I always prefer text to video, so I don't have to decipher some strange accent. But other people may have different preferences.
As a non-native English speaker, I doubt that. In general listening to English is quite complex for someone that has learnt English only from school; listening to a non native language (especially a quirky spelled one like English) requires quite a bit of excercise to fully understand the various accents and how the words pronounced often illogically associate with those words you've learnt from books. I personally found vastly simpler in the beginning to read text instead of listening to a native speaker talking. That's also why captions in movies help a lot someone learning the language.
I really wish it was easier to find movies in other languages to help learning. I've been half-heartedly trying to learn French the past few years but it's deceptively hard to either find a decent streaming service, or to find torrents with French audio + subtitles.
Strangely it was quite easy when I had a stab at Swedish a few years ago; a number of their TV channels have a free streaming service that you can access from anywhere.
Maybe you may have more luck using legal services such as Netflix. I'm quite sure they have subtitles for most of the languages they support; at least, I'm sure they have them for English, German and Italian. Torrents are often a poor choice with regards to captions, because either you manage to find a source that ripped them from an source in sync with video (such as the DVD), or you have to resort to fan dubs or that kinds of sort.
For some idiotic reason Netflix geofences their subtitles. Here in Sweden you're lucky if there are even the original English subtitles available for the thing you're trying to watch.
I've even managed to find a few shows where they didn't even bother to allow disabling the subtitles!
> For some idiotic reason Netflix geofences their subtitles.
Same clusterfuck as with other copyright things. Different companies have the rights to the subtitles and it depends on what terms Netflix got. One of the reasons [0] I mentioned why piracy is still superior even for someone paying and wanting to pay.
They don’t. I’m living in Singapore, but have family in Germany and Thailand. If you want to have Thai subtitles in Singapore or Germany, you can create a User with Thai set as the UI language, then you also get offered audio and subtitles in Thai.
It’s not documented and totally not intuitive, I only discovered that by accident, but it works very well.
I used Audible (or just download books on tape from other sources) and listen to it at about 80% speeds. It worked extremely well for German because there are a lot of novels I like and have read in English. Same in Spanish.
The good thing about Audible or books on tape, is that you can read along with the exact same text, whereas movies with subtitles are often translated with completely different sentences in an attempt to convey similar meanings from the original language to the translated.
Almost everything I've looked at on Netflix (UK) seems to be available with either French audio or subs. Might be worth a look. Rick & Morty IIRC offered 6 language options.
Amazon Prime Video has all movies and series in English, German, French and a couple of more exotic languages. I think they have a 30 day trial, it might however be different in every country.
Before I came to the US, I studied English on my own to be able to program/do computery-stuff because people on the internets always told me to RTFM. On my first TOEFL (Test of English as a Foreign Language) test for college, I got 29/30 for my reading comprehension and a similarly high score for writing but got 15/30 for speaking and a pretty bad score (not as bad as speaking - don't remember exactly) for listening.
Reading and writing were much easier than listening and speaking to me.
I had the same experience learning French in school as a child. I did really well at reading and writing, but could never understand what the teacher was saying. A couple of years later, in a different school, my classmates were all Hatians that were taking the class for easy credit. I had even more trouble understanding their creole french, and wound up losing all of my comprehension.
Quite the opposite if you learnt English by reading. Text is so much easier to comprehend, you can easily go back and forward, choose your speed, pause, check definitions (the "Look up" dictionary integration in Safari comes handy), etc due to non-linear nature of reading. Irregular English pronouncing rules don't help either.
Never mind that with text it is quite easy to skip all the fluff and get to the info one wants (in this case, the specs and other differences between the 3B and the 3Bplus).
For my purposes, very good. There is a Raspi equivalent image and, afair, a Bananian image. I used the former on my first BananaPi (this runs my NAS). The latter runs a BananaPi I have used as a secondary ADS server (now it serves only as DNS, as I switched all desktops to Linux, see discussion https://news.ycombinator.com/item?id=16582231 as to why). Both run smoothly.
EDIT: I should say (that's independent whether you use Raspberry or BananaPi) that both run for months without intervention. The only thing I found to be important is a good power source. I had frequently file system errors due to dying (somewhat cheap) chargers used as power source. I finally got a switched 50W multi charger (10 outlets á 2A) which I connected all Raspis and Bananas to. Since then, everything works pretty smooth.
I also noticed that. It's only ~280 megabits so seems a bit dishonest to call it gigabit. I guess what they mean is "gigabit ethernet standard" i.e. 1000BASE-T.
Also how does it act once its internal receive buffer is full? Is it possible to get the sender to slow down, or does it have to start dropping frames? Will important things such as ARP broadcasts and DHCP requests just risk getting lost?
When the internal receiver buffer is full, you drop the frames.
Basically any protocol out there has some way of dealing with dropped packets (including UDP's "don't care")
DHCP requests are usually repeated several times for this reason, the first one can get lost (this can and will happen even on a clean and underloaded gigabit homenetwork)
Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time)
Traffic shaping on higher layers usually lets some packages deemed important through while dropping bulk traffic, tcp which is usually used for bulk transfers backs down when packages gets dropped, but that only gets you so far if you keep getting hammered with new connections or the sender acts maliciously.
>Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time)
Not if, it does. The repeats are usually good enough to get into the receiving buffer. If there is constant noise on the interface that it even interferes with basic protocol operation you're probably running something that doesn't know how to throttle the connection properly. Those things are usually best retrofitted with some form of ratelimiting in the kernel.
But yes, in this case you wouldn't be able to do DHCP or ARP. This is also true for any further hops on the network. If the receive buffer is full there isn't much you can do about it other than try again later. And "try again later" is purely a protocol decision.
On an internal network the fix is usually to have a Switch that can ratelimit a peer. Otherwise, there is no protection and you can easily replicate the effect by taking an old switch and patching up a loop. The resulting packet storm can easily shut down larger networks.
On the larger internet, the telco's and ISPs are largely responsible for making sure their receive buffer doesn't get full.
Edit: The Wikipedia article says: "By 1999, several vendors supported receiving pause frames, but fewer implemented sending them.[4][5] Pause frames have several disadvantages.".
Of course you're usually not going to see them even when using Wireshark etc., because they're handled at the MAC hardware level.
I'm not aware how to reliably determine whether link partner has L2 flow control / pause frames enabled. But at least you can check whether it's locally enabled:
Linux:
ethtool -a eth0
macOS:
ifconfig en0 | grep media
Windows Powershell:
Get-NetAdapterAdvancedProperty
Alternatively you can check Control Panel / Network Connections / right click adapter + select Properties / click Configure / Advanced tab / Flow Control value.
Note that above only applies to wired ethernet, not wlan.
There is nothing dishonest about their announcement: they are explicit that speed is limited by the USB bus:
> While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B.
Followed by a table showing 315Mb/s bandwidth, three times that of the 3B but a third that of full-speed Gigabit. And this isn't tucked away in a footnote, it's up front in the middle of the article.
The product page, which is probably what most people see before buying it, simply says 'faster Ethernet':
> 1.4GHz 64-bit quad-core processor, dual-band wireless LAN, Bluetooth 4.2/BLE, faster Ethernet, and Power-over-Ethernet support (with separate PoE HAT)
I'm a bit cross because of the casual assumption of bad faith, when it seems to me they've gone to some effort to do the opposite: make the limitations clear instead of relying on a buzzword.
>We use a magjack that supports Power over Ethernet (PoE), and bring the relevant signals to a new 4-pin header. We will shortly launch a PoE HAT which can generate the 5V necessary to power the Raspberry Pi from the 48V PoE supply.
This is nice though I personally wish they used the same Silvertel PoE module as Arduino which you just solder onto the board. Plus their PoE hat has a spinning fan.
The video mentioned support for PoE (with a HAT) as a feature. Why would they specifically point out an addon that doesn't come with the board as a feature of the board? PoE HATs already exist apparently, and are quite pricy. But I don't consider Arduino ethernet shields saying arduino comes with ethernet.
I’ve been using Pis to stream video from webcams for various experiments and the built-in wireless on the 3 and Zero W was game changing. All the usb WiFi adapters I had tried previously were unreliable or had too much latency. Very excited to try out the improved wireless on this board
I did some experiments with MiraCast (using MiracleCast) with the built in wireless on the RPi3. However I ran into several issues (connections not working sometimes; unreliable connections which would stop after a short time). Later I found a forum post which said that these issues could be related to the built-in wireless not correctly supporting WFD. Maybe the RPi3B+ fixes this issue but someone would have to try that.
> the built-in wireless on the 3 and Zero W was game changing
Definitely, the Pi Zero W is now my go-to controller for almost anything that needs one. The fact that Microcenter frequently sells them for $5 seals it.
I pair them with a $15 aMLC (MLC in SLC mode) industrial MicroSD card[1], and they've been rock solid, no FS corruption on power loss, no Wi-Fi drop outs.
The ability to add the Pi Camera board and have a tiny full HD networked camera with trustworthy "firmware" is a killer feature though, pre-made IP cameras at any price tend to have outdated insecure or even malicious firmware that may or may not be replaceable.
PXE booting is sweet. I develop an OS (Crankshaft) for the Pi, and a lot of times it just has been waiting to write a new OS to the SD card, waiting, plugging it in, realizing I forgot to do something, so I had to repeat. Each time it was 15 minutes of waiting. Pulling the card out and putting it back in, especially with the ribbon cable on the way (and a case too) has been really painful. PXE boot is going to solve that. So I'm very, very excited for this.
In the blog, they mentioned the possibility of having a Pi3A too, so I look forward to that as well. The project I have has not much need for lots of USB ports and ethernet, so having to pay for and power a hub and an ethernet port only add to the power requirements with no added benefit. The Pi3A will be the prime target for me if they release it.
The only thing I wish they had is microphone input (we need the mic input for "OK Google") but I don't think it will happen, so that's one more thing on the wish list.
For any problem, there is always someone who could come up with a brilliant solution and makes me feel like a dummy. That is a great idea I haven't thought of!
PS: Upon further inspection, PXE netbooting is already possible on the 3B under the name of "USB booting," it's just not the default in the hardware, and there might be bugs that are fixed in the new version.
But remember you can always put the very latest bugfixed version of bootcode.bin standalone on an SD card and use that instead of the version in your Pi's bootrom. This also works for older models (Pi/Pi2) that don't have PXE support in their bootrom.
Another possible approach would be to use the Linux kernel's ability to load another kernel and hand it control. Unsure if this works on arm64 but it seems likely. https://linux.die.net/man/8/kexec
That's generally how it's done on non-Pi boards (some of which even have onboard SPI flash that's large enough to hold u-boot). This has the advantage that the PXE code can be upgraded in the field, which is kind of important given how complex and buggy it is.
That documentation you've linked to is just very thorough, there's not that much to it. U-boot doesn't appear to be much simpler so I don't see the point in it, but maybe I'm missing some extra features it has?
That's what I suggest people to use now. The USB microphone needs power and one more USB port. If the Pi had a microphone input, we would have absolutely no need for the second USB port. Not having to have the second USB port means we would need no chip for the 4-port hub. Having the distro supporting the Pi Zero that has 1 USB port has been something I've been dreaming about.
> That's another something I don't know that I don't know!
This is something we don't do well. Situational awareness and expert consults. As a society, field, and individuals.
From grounding elite groupthink, to systematic reviews in medicine, to programming language design, to hardware acquisition, to choosing a javascript library, or crafting its api, to choosing what to eat for lunch. Existing socio-technical infrastructure is painful to use, with highly and variably suboptimal results. And the more interdisciplinary the task, the worse the costs.
Opportunities for improvement are coming. Hybrid human-computer systems, so "I'm planning to do X, can I get a sanity check?" can be addressed with a mix of automation, and AI, and stats, and custom blends of variously-skilled/expensive human expertise.
But there are existing opportunities which are often not taken advantage of. Like maintaining personal review "committees" - people of various expertise to whom you can mention what you are up to, and hope to at least get back a "sounds good"/"have you thought of instead doing X". And like watching for opportunities to mention one's work on fora like HN, to create an opportunity for feedback. :) Engineered serendipity.
Yep, I always thought it was just booting from the USB stick. But nonetheless, having a version that is officially supported and enabled by default is great.
"Just over two years ago, we released Raspberry Pi 3 Model B. This was our first 64-bit product"
Very unfortunate that their in-house developed and promoted OS ("Raspbian") only supports armv7, thus leaving the vast majority that doesn't know about the existence of (or how to use) archlinux ARM an the likes with a 32 bit os. Am I the only one that doesn't get the sense out of this here? Debian supports Aarch64 out of the box I think.
To me, that makes a lot of sense. Having only one architecture to support and one image to rule them all across the product line is quite a great thing to have.
The other day, there was a person who had a "reddit gold" bounty for the first person who can help them get the Pi 0 online. The person basically couldn't get the Pi Zero on the wireless network. They had no USB-OTG adapter or mini HDMI adapter they could use to debug the Pi Zero. I was thinking something along the line of making the Pi USB port a USB-serial gadget, but it was still cumbersome. The "accepted solution" was to pull out the SD card for the Zero, put it into a Pi3B they had, get the 3B online, and put it back to the Zero. I think that was such a brilliant idea.
Making it easy for users to achieve such tasks is often overlooked by us who "know too much" to not care about the efficiency of the new hardware. I don't think it was an accident that the Pi is so ubiquitous in education: They made a lot of right decisions to make their product easy to use.
Yes, but then promoting the Raspberry Pi as "64 bit product" seems almost gimmicky to me. Ok, you switched to an AArch64 chip, but that was simply because it's what your supplier was producing at that time. It makes no sense to me to promote a feature you don't support or make use of, if not for simple and pure marketing reasons.
It would be even easier and less vague to just pop out the SD card, open up /etc/network/interfaces, and edit that to add your network. Pop it back in and go. This is what I've done when setting up a new raspberry pi image without having any peripherals attached to it. I ssh in, configure the system to my liking, then make an image of the SD card for future use. I could even turn this work into a script that downloads new raspbian images, edits them for my purposes, then packs them up to be used later.
That's what the person did -- they put wpa_supplicant.conf to the boot partition -- but somehow the Pi wouldn't connect, and they had no way to debug it to figure out what went wrong.
i had this situation before but i realized i missed a critical step: adding wpa_supplicant.conf BEFORE first boot of the pi0w.
Not saying it's the same issue, but i was scratching my head for a while there.
I'd love to give reddit gold (if I had any) to anyone who could point me to a source for the Pi Zero at the price point it was originally supposed to be selling at: $5.00
I have yet to find it - you can get them cheap, but no where near what the RPi Foundation advertised them at when they first were announced/launched.
It depends where you are. Microcenters generally have them for $5 ($10 for the 'W'), although for Pi Day they're both on sale for $3.14. Sadly, there aren't any near me, but I had a relative who is near them pick up a literal handful last time they came down.
Several online places have them for $5, but shipping 'kills the deal' as they say.
I got my last two Pi Zero units from Vilros[1], they have the Zero W for $10 which is the intended price from the RPi Foundation. To me, it's worth the extra $5 for WiFi/BT with no dongles.
The problem is VideoCore, as the Broadcom firmware and closed libraries are 32bit only.
You can very easily† pop in an ArchLinux ARM AArch64[0] in there and notice that you only get a very basic framebuffer, sound is just not working at all, and the bootloader is quite incomplete. So ARMv7 it is for me, even with ArchLinux ARM and in spite of my wish for better FOSS support from Broadcom or in Linux mainline.
† I find alarm much much better as a distro than raspbian as it's incredibly straightforward to install, maintain, and use, while vanilla debian is downright painful.
Man, I hate how ARM OEMs are screwing up the whole platform as a viable PC-replacement platform, and I really wish they would reconsider some of the money-grubbing choices they made. Having a standardised platform such as the x86(-64) PC platform is fantastic for tinkering and long term support and reusability of your machines; things such as binary only drivers with just 2 year support (coff coff Qualcomm) are an absolute shame.
There is also the fact that UEFI is rather suboptimal. They are adopting UEFI on the server chips because they've failed to develop a new standard. They've missed a chance to improve upon UEFI. Now they are stuck inheriting UEFI's problems because otherwise there would be no standard at all.
I haven't seen an off-the-shelf x86 machine that actually requires binary-only drivers for essential functionality in a very long time. Sure, there is lots of specialized hardware that no one wrote an open source driver for but you don't buy those from Dell or HP.
Most x86 boxen tend to run tons of proprietary firmware but at least that isn't pinning me down on ancient hacked-up kernel trees.
I'm really pretty OK with it. The thing only has 1GB of RAM, so there's not a whole lot of value in having a >4GB address space. Might as well default to having the perf boost and reduction in memory consumption that comes with pointers that are half as big.
People who actually have a use for 64bit on their pis will generally know what to do, and I'm guessing most of of them won't have a whole lot of use for the streamlined UX that is Raspbian's raison d'etre, anyway.
> so there's not a whole lot of value in having a >4GB address space.
Don't most ARMv7 CPUs (like A7, A15, etc.) have 1 TB address space? On LPAE ARM, 64-bit arch will only get you larger virtual address space, but you get same 40-bit address space in both cases.
> reduction in memory consumption that comes with pointers that are half as big
Nothing prevents you from running 32-bit binaries on 64-bit OS, as long as you have 4kB page size.
What use to I have for being able to address a hypothetical 1TB of memory on a computer that's got a fixed 1GB of memory soldered to the board?
I can see having a bit of headroom for virtual memory, but I wouldn't want to actually use it. The non-volatile storage on this computer is an SD card, so paging will be particularly expensive. Are you really going to have more than 3GB of swap? That's a pretty big appetite for thrashing.
Regarding running 32-bit binaries on 64-bit OS, sure, and the code that lives in those binaries will run faster. But you'll still be needlessly taking a hit on the 64-bit kernel and userland.
My implicit point was that addressable memory size is not a factor when choosing between 32 and 64-bit ARM.
Looks like I should have communicated it more clearly.
AArch64 does have some perks, but mostly for out-of-order cores, which RPI3's Cortex A53 is not.
That said, even A53 can benefit from 31 registers in 64-bit mode. Large virtual address space is nice not only for memory mapping files, but to do lazy initialization while keeping high performance direct pointer access characteristics. That way you can have the MMU doing the check and indirection for you instead of slow explicit conditional check in code.
You can mitigate pointer size by ensuring memory accesses are PC-relative. Perhaps there could be support for something similar to x32 ABI [0] as well.
AArch64 codegen does need to generate more conditional jumps or CSELs (like cmove) though. Also function entry & exit code is larger due to lack of LDM & STM (load/store multiple). But on the other hand, stack spills are rarer, thanks to 31 general purpose registers instead of 14 on 32-bit ARM.
Where AArch64 truly shines is when you have a real out-of-order CPU core, for example Cortex A72. There are significantly more opportunities for instruction level parallelism due to dropping instruction predicates and other changes.
It's worse, Raspbian is compiled for armv6 to also support the BCM2835 (Raspberry Pi 1). Here's a performance comparison between a modern 64-bit armv8 Linux on a Le Potato SBC versus armv6 Raspbian on the Raspberry Pi 3:
Or even 4G. Would be nice to have a high-memory variant especially seeing that that would require zero changes in the OS unlike most othet hardware variations.
As far as I can remember, the system-on-chip architecture limits the maximum amount of RAM to 1 GB (I'll try and find an official source, it's probably somewhere in the BCM283x peripherals documentation).
Not to say Broadcom couldn't spin a newer revision of the SoC with a different internal architecture, but for now it seems that >1 GB of RAM would require substantially more effort than just swapping the DRAM module on the board.
The last time I checked out the Asus Tinker it was still suffering from horrendous software support and cost nearly twice as much in the UK (which it still does, £32 vs £55). So unless you NEED those extra features, I strongly disagree.
I bought one and played with it over the holidays and there are a ton of OS options now. There's Armbian support now, which wasn't around at first, and it seems to be very stable and feature complete. The board is significantly more powerful than a Pi 3 with emulators and compiling and just about everything.
You can actually boot Raspbian (or probably any other ARM OS) on Asus Tinkerboard - you only need to copy some files to /boot (including kernel) from TinkerOS and several kilobytes of bootloader after partition table.
(That way you can prepare image that boots both on RPi and Tinkerboard)
yes! for headless/server type applications I think this is the sweet spot right now. In the US, Ameridroid is faster than ordering direct from pine64 (in my experience).
The biggest downside for me is Rock64 doesn't have an OS with the pedigree of Raspbian. I'm running the 'ayufan' minimal ubuntu xenial, and it seems solid. but when I've played around with a monitor in the full xenial build I've seen some crashes and lockups.
Yeah, although adding usable wireless is a big bonus - I wish it had 2-4GB of RAM and I wish you could put the USB ports into gadget mode like you can with the zero, but preferably at least two or more ports that can work with it. Also - I’m really disappointed there’s still no GbE.
You can already get more than 100Mbps out of a Raspberry Pi using a USB Link cable (aka Windows Transfer cable). They are less than $5 online and you get around 160Mbps on a Raspberry Pi 1 (haven't tried it on y Raspberry Pi 3 yet).
They talk about this in the video (at 4'54") -- saying they try to avoid the g-word, calling it 'Faster Ethernet', and in practice you'll get 200-300Mbps.
Why was the title changed? It's misleading right now since there's already a Raspberry Pi Model B+ available for ages. Should be "New Raspberry Pi 3 Model B+" just like on the blog post.
in general, i find the aggressive title changing on hacker news confusing. it’s been happening a lot recently where i can’t find a post by eye where i know i knew the title or where the title was changed away from the exact title of the linked post or article.
In another sense it's quite beautiful though, it encourages me to visit more frequently before the titles begin to decay into things I wouldn't click on.
Amlogic S905X boxes are the better choice for Kodi these days.
You can installi LibreElec, they are cheaper than a Raspberry Pi 3 and they support 4K & HDR and have hardware acceleration for H.265 (HEVC) and VP9.
I've never been entirely comfortable with these HTPC boxes with factory-issued OS, especially connecting to a local network.
Do you have any advice or feedback on Amlogic S905X-based boxes that can have the OS flashed to something more generic (Debian-based, ideally)? Thanks!
A bit worried by the increased power usage for certain applications. For instance I used to power my PI with a cell phone battery pack without any trouble.
There are great guides on how to lower power consumption by turning HDMI off, under clocking, even going as far as turning off the status LEDs. Killing off many of the autostarting services in raspbian or not using raspbian in the first place can also help quite a bit due to peak current draw during boot time. If you don't need networking you can easily get down to almost 10s boot time by disabling networking daemons and dependencies.
Made a project in optics with the pi zero w, camera v2, a touchscreen over GPIO, 4 bright LEDs and a 5V regulator.
As a power source it uses a 9€ 1200mha LithiumIon Battery in 9V battery form. Lives on for 3 hours under full load.
Also using normal 9V batteries I killed them in 5mins - something something internal resistance of non LithiumIon batteries not coping with high current draw.
I'm a big fan of the Raspberry Pi community in general and have used it for multiple applications over the years; most recently as a media center TV box. However, the hardware now feels old and I wish for more of an update from the Pi foundation.
If anyone hear is looking for a true upgrade on the Pi, try the ODROID C2, it's years ahead of the Pi in terms of performance.
I disagree with this though. The price difference between the two isn't insignificant.
If someone intends to deploy hundreds of devices for an IoT application the price difference between the 2 would be one of the reasons to choose the C2; the other reasons would be size and heating problems.
Lots of people say there are superior devices - however the community size and support for Raspberry Pi cannot be overstated.
The price of an Odroid XU4 is significantly proportionally higher and I have no guarantee that certain features or projects are feasible on it. First result from Dec 2017 when searching for "XU4 Kodi" is someone having a problem installing and then saying "I would prefer a version with long term support and wide use base." Well my answer to that is RPi.
I'm merely implying that RPi has a higher chance of certain things working simply because its more popular. I'm not disputing that there are higher performance platforms for "similar" money but it's reliability and a little more certainty that some people are after.
I would love to try one of the ODROID devices, I simply don't have the time. And I love seeing suggestions for these other devices so please don't stop posting them :)
I don't care that much about performance. Support and all stuff I get to play with on RPi is more important. Why would I need more ram or faster cpu to read temperature sensor and send show it on a website?
Then you get people who do projects that would fit on 8 bit processor, like reading sensor and then switching relay depending on sensor value. That is gross overkill.
If you have more ambitious projects like streaming video, which I have seen somewhere in thread, or mining cryptos, maybe RPi is not best choice.
I'm currently working on a project that involves using the Pi for 24x7 1080p video streaming and doing so without hardware acceleration results in lag.
The experience with ODROID C2 on the other hand is superior.
Power over Ethernet is terrific, this means only one cord is now needed for a fully functioning pi (assuming you have the proper Ethernet setup on the other end).
But PoE isn't actually built-in to the Pi, it requires an external hat, purchased separately, and using a PoE hat has been possible on previous versions, yet they decided to announce it now, it's confusing.
They are not announcing PoE now. It is listed next to this particular model's features. The new/updated functionality is even bold (and power over ethernet is not).
I'm aware of the fact, it was just strange how they announced it in the video [0], as if it was a new feature. PoE has been possible on previous versions with a PoE hat aswell, so nothing really new.
Weren't previous PoE hats just ethernet splitters that also had a 5V output to the Pi rails, but still required another Ethernet cable to connect to the Pi's actual Ethernet port?
This is definitely not PoE, just a hack on top of normal ethernet infrastructure. If you use one of these with a normal PoE switch you will fry whatever is connected on the other side, as it won't step down the voltage from 48V to 5V. Both sides need to be using this, but then real PoE is guaranteed to work even on 100m long cables, with this your 5V will end up being <4V with a 100m long cable and potentially useless.
Nope, this is not the ghetto "Passive PoE" variety which uses the 4 wires not needed for 100Mbps to carry power. This is an actual 802.3af/at compliant adapter.
I have 2 in my home (not the exact model I listed because I'm on the other side of the Atlantic, bought them off Amazon Germany), hooked to a Netgear GS110TP (8 PoE copper ports, 2 SFP ).
Actually there's so much stuff drawing power (2 Pi, 2 Ubiquity APs) that I'm starting to worry about the load on the switch.
I wish they would finally expose the data lines for the second camera in their "hobbyist" boards as well. Currently the dual camera setup is supported only by Compute Module, but it's cumbersome to use because the bulky I/O board (and expensive).
The foundation is overlooking the most unique feature of the Broadcom chipset, the 3D video support. They already have implemented the software/driver side, so only thing required is just exposing the pins from the SOC and adding second camera connector – very low hanging fruit. (The Zero board may not have enough space for routing but the bigger boards definitely have.)
To clarify, the "3D video feature" is nothing more than being able to record simultaneously from two cameras and merge the video inputs into side-by-side H264 stream. Combined with hardware H264 encoding with delay of ~100 ms, this is very useful for certain applications (in my case, live 3D video broadcasting from UAV). I'm not aware of any other "tinkerer-friendly" board capable of that.
The hardware accelleration for H264 sounds interesting. Although 100ms is not as ideal as I want but it's reasonable. Is it actually possible to use this feature in practice? Are proprietary drivers an issue?
Also is it possible to browse the web and e.g. watch videos on youtube with adequate performance on an RPi? (different topic)
> Is it actually possible to use this feature in practice? Are proprietary drivers an issue?
I've streamed 3D video over wifibroadcast¹ to OSVR headset, no fundamental issues. The exact lag depends on resolution, fps, etc settings. It would be superb to cut the delay to sub-50 ms range, but that's probably not going to happen as it would require major rewrite of the H264 stack, as currently there are always two full frames in the pipeline, e.g. in 30 fps it makes 1000/30*2 -> ~70 ms delay². (Note that I'm not the author of the befinitiv website.)
The foundation has released open-source driver stack³ (raspivid etc), but AFAIK they have rather limited resources for software development (single ex-broadcom developer?) and limited access to proprietary features (documentation?) of the Broadcom chipset. Many things work but I think the capabilities of the SOC aren't yet fully utilized.
> Also is it possible to browse the web and e.g. watch videos on youtube with adequate performance on an RPi? (different topic)
No personal experience, but RPi 3 should be okayish for lightweight desktop use (YMMV) with 1 GB of RAM being main limitation for multitasking.
I went from never soldering circuitry or working with a schematic to designing a PCB (the CMIO schematics are freely available and easy to reverse engineer even for someone with very limited knowledge), having it printed, and build it myself using 0603 and 0805 SMD components.
It's really not that hard or expensive to do it yourself, and it's a fun little side project. Try it out.
I'm still waiting for an inexpensive Linux board with proper sleep support. Suspend, hibernate, etc., and come back within milliseconds instead of dozens of seconds, and under $30 USD.
This is a nice minor upgrade, good job. That said, I'd love to see a new model with more memory. That would require Broadcom (or some other organization) to develop a revised SoC that supported more control pins, but in a large sense that's a small change, and memory is cheap enough that adding some more memory wouldn't significantly change the price. But it would greatly extend what software the Pi can usefully run. Most software developers don't care very much about memory size, leading to bloat in size. As a result, the little memory limits what applications the current Raspberry Pi can use, including many programs useful for education. I wish them luck!
What I'm missing is on board flash. Even 512MB would be such useful for many usage scenarios to put OS there. SD cards are biggest source of problems on long run RPi's without some tweaking. There are almost none SBC with built in flash (BeagleBone is shiny exception).
It doesn't exactly fill the same niches as the regular RPi but the RPi Compute Module 3 does have 4G of emmc builtin. You can get a compute module and breakout board for $136 on Amazon.
Feel like RPi is heading to a commercial upgrade direction: more cores, higher frequency, faster processors, faster networks, etc. Wasn't RPi originally designed to teach programming and to make a hackable gadget? With that goal, I think a simple (and therefore maybe low performance) system is easier to learn and to hack than more and more fancy and complex architecture. From that perspective, BBC Micro bit is doing the right thing IMO.
Why not upgrade it, though? Keeping it a system for teaching/hacking while improving performance is a win-win, as far as I'm concerned. For commercial applications, I'd think the Compute Module would be a better bet.
I am always impressed at how people can buy a fully functional computer for $35. That said, as an engineer I often cringe at the compromises made. Like "Gigabit Ethernet over USB 2.0". Since the top bit rate of USB2.0 is 480Mbps and GbE is 1250Mbps, USB 2 only has about 1/3 the bit rate to support it.
Now it will be faster than 10/100 ethernet connections but don't expect to send a 100 megabytes/second through it.
So, to be fair, they both refer to it as 'faster ethernet' to try to distinguish it from 'full Gigabit' and say explicitly in the post:
> While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B.
And then show that they're typically seeing 314Mbps for TX/RX in iperf.
1.25Gbps is the "gross" bit rate for 1000BASE-T Ethernet. This is because it uses 8b/10b encoding on the wire (meaning there is a 25% overhead):
https://en.wikipedia.org/wiki/8b/10b_encoding
1000Mbps is essentially the "net" bit rate available to the Ethernet protocol.
exactly right. Different standards claim different things, but ethernet tries to do the "right" thing and have the number in the name be the actual number of bits per second you get through the thing. Unlike say serial ports where 9600 bits per second isn't 1200 8 bit bytes per second, its only 960 8 bit bytes per second because of a start bit and stop bit. This can be even worse on serial protocols with forward error correction where up to a third of the bits going across the wire are for error correction and/or clock recovery.
I'm always so impressed with the supply chain of the Raspberry PI foundation. I woke up today, saw the HN story, and during lunch went to a local store and picked one up. I live in a small-ish town in Sweden. I know it's not like a iPhone release or whatever, but still impressive that they manage to get it out to my local store on release day.
Source: https://raspberry.piaustralia.com.au/blog/new-raspberry-pi-3...
WHAT IS THE SAME: -----------------
- Same mechanical footprint as both the Raspberry Pi 2 Model B and the Raspberry Pi 3 Model B. - Same GPIO pinout, so no need to change your hats/shields/daughter boards - Same power supply recommended (5V/2.5A DC via micro USB connector) - Broadcom BCM2837B0, Cortex-A53 64-bit SoC (System on a Chip), but this time clocked to 1.4GHz, which yields roughly a 10% performance increase over the Raspberry Pi 3 Model B. The chip now has a metallic heatsink and bears the markings BCM2837B0 1FSBG, TA1738 P20 W39-01 N2 W.
WHAT IS NEW: ------------
WIRELESS MODULE:
The product briefing document from the foundation states that the onboard wireless module now supports dual-band 2.4GHz/5GHz IEEE 802.11ac and both Bluetooth 4.2 and BLE (Bluetooth Low Energy). ?
The wireless module in the RPi3B+ is not mentioned in the product briefing document and is hidden under shielding. Prying open the shielding revealed a Cyprus Wireless CYW43455 (datasheet).
- The CYW43455 supports the following WiFI standards: 802.11ac/n/a/b/g/d/h/i - Security: (WEP/ WPA Personal / WPA2 Personal / WMM /WMM-PS (U-APSD) /WMM-SA / AES (hardware accelerator) /TKIP (hardware accelerator) / CKIP (software support) - Proprietary protocols (CCXv2, CCXv3, CCXv4, CCXv5, WFAEC - IEEE 802.15.2 Coexistence Compliance (on-silicon solution compliant with IEEE 3-wire requirements) - The CYW43455 supports the following future IEEE drafts/standards: 802.11r (fast roaming between APs), 802.11w (secure management frames), 802.11 Extensions:, 802.11e QoS Enhancements (as per the WMM specification is already supported), 802.11h 5 GHz Extensions, 802.11i MAC Enhancements, 802.11k Radio Resource Measurement
The CYW43455 data sheet states that the Bluetooth core supports:
- Bluetooth 2.1 + EDR - Bluetooth 3.0 - Bluetooth 4.2 (Bluetooth Low Energy)
The Wireless LAN module now has "modular compliance certification", which allows the board to be designed into end products with significantly reduced wireless LAN compliance testing, improving both cost and time to market.
NEW GIGABIT ETHERNET:
The new RPi3B+ has support for Gigabit Ethernet using Microchip's LAN7515 (which is a USB 2.0 to 10/100/1000 Ethernet Bridge with 4-port USB 2.0 Hub). The LAN7515 supports a max number of 6 downstream USB ports and 1 Ethernet Port limited to a maximum throughput of 300 Mbps. The LAN7515's ethernet controller supports numerous power management wakeup features, including Magic Packet™, Wake-on LAN (WOL) and Link Status Change.
POWER:
The RPi3B+ is Power over Ethernet (PoE)–enabled, but requires the purchasing of a separate PoE HAT.
PRODUCTION LIFETIME:
If you're thinking of incorporating the Raspberry Pi 3 Model B+ into another product, the Raspberry Pi foundation has committed to keeping the RPi3B+ in production until at least January 2023.
HEAT MANAGEMENT:
Due to the BCM2837 now running at 1.4GHz, the RPi3B+, runs relatively warm. The foundation provides the following warning: "This product should be operated in a well-ventilated environment and, if used inside a case, the case should not be covered". Given the optional "open lid configuration" of the official Raspberry Pi case I asked for clarification, and their Director of Product Management came back with: "It only means if you have it in a case the case itself should not then be covered".
reply