Compare Single Board Computers(sbc.compare)
sbc.compare
Compare Single Board Computers
https://sbc.compare/
84 comments
Hey! So I was quite surprised to see my site posted on here so soon after hitting the "go live" button, and thanks for your comment.
I wrote a blog post about why I made the site at https://bret.dk/introducing-sbc-compare/ if anyone's interested, but to TL;DR it, I didn't set out to create a site like this, it was a side quest after creating the automation and database to support my reviews, which do indeed focus on the hobbyist trying to explore Raspberry Pi SBCs and their many alternatives.
I have full specifications and hardware capabilities hidden behind a feature flag at the moment as I'm working my way through adding all of that data (currently at 80 SBCs in the database, and I'm only adding those I own and have run tests on) so there should be something similar to what you're asking for soon. Thanks again!
I wrote a blog post about why I made the site at https://bret.dk/introducing-sbc-compare/ if anyone's interested, but to TL;DR it, I didn't set out to create a site like this, it was a side quest after creating the automation and database to support my reviews, which do indeed focus on the hobbyist trying to explore Raspberry Pi SBCs and their many alternatives.
I have full specifications and hardware capabilities hidden behind a feature flag at the moment as I'm working my way through adding all of that data (currently at 80 SBCs in the database, and I'm only adding those I own and have run tests on) so there should be something similar to what you're asking for soon. Thanks again!
After that, have a look at pcpartpicker.com, motherboards section. They have feature selectors, like number of usb ports, power connector type and so on. Very useful to find boards.
Thanks for your great work! I would love to be able to search by processor (eg look for all boards with an iMX95, for example) as well as search for things like audio I/O channels, I2C pins, etc. Super useful website!
Hmm, the search by SoC should work already, but there have been a few regressions with the search functionality that I need to fix it seems. Notes on the other bits too, it’ll take a couple of weeks I imagine but we’ll get there!
I’m interested in alternatives to Raspberry Pis right now and software support is a concern. Do you have any recommendations?
Any refurbished/used x86 is almost always a better choice than a the newer RPi's. By the time you get done bringing the RPi up to the spec you need, it's almost always more expensive and less reliable than something x86.
If you fit the envelope, the Beaglebone Black has been out forever. It's not fast. It's doesn't have super modern interfaces (Displayport, PCI-E). It's not super tiny.
However, it is solid. It actually runs in the 500mA USB envelope and doesn't need a heat sink. It has eMMC so you don't have to fiddle with garbage uSD cards. It is incredibly well documented thanks to TI. It has a useful number of I/O pins (unlike the measly amount on the RPi). It has tons of the kind of basic hardware interfaces that you need to interface to things. The real time processors on it can often substitute for FPGAs. There are industrial versions for $10 more than the standard $50. And the software follows bog-standard mainline Debian rather than being some weird, undocumented, bodged-up thing that needs to boot from the GPU.
If you fit the envelope, the Beaglebone Black has been out forever. It's not fast. It's doesn't have super modern interfaces (Displayport, PCI-E). It's not super tiny.
However, it is solid. It actually runs in the 500mA USB envelope and doesn't need a heat sink. It has eMMC so you don't have to fiddle with garbage uSD cards. It is incredibly well documented thanks to TI. It has a useful number of I/O pins (unlike the measly amount on the RPi). It has tons of the kind of basic hardware interfaces that you need to interface to things. The real time processors on it can often substitute for FPGAs. There are industrial versions for $10 more than the standard $50. And the software follows bog-standard mainline Debian rather than being some weird, undocumented, bodged-up thing that needs to boot from the GPU.
Also anyone who is creating battery-powered projects would be interested in power consumption figures.
I for one learned way too late that an ESP32 (whichever model really), despite being massively more complicated, will typically have a much smaller quiescent current in deep sleep than a 555 timer - even the CMOS implementation.
I for one learned way too late that an ESP32 (whichever model really), despite being massively more complicated, will typically have a much smaller quiescent current in deep sleep than a 555 timer - even the CMOS implementation.
About 65 boards in I realised there was a slight error with how the idle power consumption was being recorded, so I had to scrap all of that data :( The last 15 or so do have this, but I made the decision to backfill that data as and when I need to check something on those boards, or just on the next round (I plan to update every X months or so, assuming there are worthwhile updates)
Happy to hear you'll be including this data.
I've already found my board, but this is not my last battery-powered project.
I've already found my board, but this is not my last battery-powered project.
It's really incredible how far chips have come. With the right configuration, an SAMD21 mcu can go down to double digit nano amps !
Additionally it would be excellent to have a "community support estimate" score so that one might factor in how much of a support bus-factor is at play.
Under the Test Environment collapsible I have the OS version and kernels tested at least, but I could definitely look at adding something extra to help make things more obvious on that front
What factors of cost and power consumption are Intel x86 compared to ARM SoMs
Intel IoT boards generally hover around 10 W at idle. ARM SoMs usually 5 W. You need to order some prototypes for testing of course.
Pricing is quite different from supplier to supplier. Usually around 50 - 100 € Here are a couple suppliers for NXP boards:
Toradex (Switzerland): https://www.toradex.com/
Phytec (Germany / India): https://www.phytec.com/products/
Variscite (Taiwan): https://variscite.com/
Intel boards usually cost around 100 € - 150 €
Pricing is quite different from supplier to supplier. Usually around 50 - 100 € Here are a couple suppliers for NXP boards:
Toradex (Switzerland): https://www.toradex.com/
Phytec (Germany / India): https://www.phytec.com/products/
Variscite (Taiwan): https://variscite.com/
Intel boards usually cost around 100 € - 150 €
Feature request: if the cells in a row are all identical, either exclude the row, de-emphasize it, or merge the cells so it's visually apparent that they're all the same.
Example: Raspberry Pi 4 vs Raspberry Pi 5 (https://sbc.compare/9-raspberry-pi-4-2gb/14-raspberry-pi-5-4...). Architecture is ARM. But it's repeated for each column, which makes the reader have to look carefully at each cell to see whether it really is different.
This is a pet peeve, particularly when a company's "compare versions" page lists dozens of identical dimensions across the product line, making finding the differences into a dreary where's-Waldo game.
Example: Raspberry Pi 4 vs Raspberry Pi 5 (https://sbc.compare/9-raspberry-pi-4-2gb/14-raspberry-pi-5-4...). Architecture is ARM. But it's repeated for each column, which makes the reader have to look carefully at each cell to see whether it really is different.
This is a pet peeve, particularly when a company's "compare versions" page lists dozens of identical dimensions across the product line, making finding the differences into a dreary where's-Waldo game.
Good point! Added to my to-do list :)
Performance is cool, but if you're already building a giant database of SBC information, I/O, peripherals and features seem like a much more important thing to add.
Just in the Orange Pi lineup, there are so many different models and so little structured information about them, that the best source still seems to be the google sheet that I created in 2017 and has been continously updated by various community members over the years [0]. And that's all one manufacturer!
Things like which type and how many video outs, USB ports, if it has onboard flash, DSI/CSI, pinout compatibility... are so much more important and so much harder to get than performance numbers, which usually boil down to the SoC plus a small margin for thermal and power design of the board.
If this site were open source (and time + knowledge of stack permitting), I'd take a stab at adding a way to include that info as well, maybe even through crowd-sourcing.
[0] https://docs.google.com/spreadsheets/d/14QDXdMR1a1kc0gpRpTzI...
Just in the Orange Pi lineup, there are so many different models and so little structured information about them, that the best source still seems to be the google sheet that I created in 2017 and has been continously updated by various community members over the years [0]. And that's all one manufacturer!
Things like which type and how many video outs, USB ports, if it has onboard flash, DSI/CSI, pinout compatibility... are so much more important and so much harder to get than performance numbers, which usually boil down to the SoC plus a small margin for thermal and power design of the board.
If this site were open source (and time + knowledge of stack permitting), I'd take a stab at adding a way to include that info as well, maybe even through crowd-sourcing.
[0] https://docs.google.com/spreadsheets/d/14QDXdMR1a1kc0gpRpTzI...
I hear you! Like I mention to others in the thread, this functionality is already there, I just need to finish populating all of the data. To get over a mental block I had to decide whether I'd continue trying to add each feature before an initial launch (and be there forever) or give myself a shot of motivation by getting an initial performance comparison feature set out there and iterate as I go along.
As soon as I have all of that data in there (I think I'm at around 30-40% so far, the initial batch of testing has been a slog, data entry for this took a back seat) I'll be enabling that option and it will all be there to view on comparison pages, and search for to help find/compare on a deeper level.
As soon as I have all of that data in there (I think I'm at around 30-40% so far, the initial batch of testing has been a slog, data entry for this took a back seat) I'll be enabling that option and it will all be there to view on comparison pages, and search for to help find/compare on a deeper level.
I completely get it, it's great that you launched it quickly, I've gotten stuck on that before too, where I just kept working on a thing to make it "ready for launch" until I ran out of steam and never ended up launching it.
It's a really cool site, I'll defenitely be keeping an eye on it and if you ever go the crowdsourcing route, hopefully also contribute.
And I'm sorry for being yet another lazy HN commenter who didn't read far enough down the thread before opening their mouth (keyboard?) :)
It's a really cool site, I'll defenitely be keeping an eye on it and if you ever go the crowdsourcing route, hopefully also contribute.
And I'm sorry for being yet another lazy HN commenter who didn't read far enough down the thread before opening their mouth (keyboard?) :)
No no, it's OK, I think I was a bit frazzled last night so I was likely a bit short heh, sorry!
I'm happy to see this exist; I've considered putting together something similar using the data I compile for https://sbc-reviews.jeffgeerling.com/ - but it's surprisingly complex.
One of the hardest things is settling on specific tests, and ensuring tests are run in an extremely standardized environment. I do my best, but a test lab I am not.
It's good to have a quick way to get relative comparisons, even if imperfect.
One of the hardest things is settling on specific tests, and ensuring tests are run in an extremely standardized environment. I do my best, but a test lab I am not.
It's good to have a quick way to get relative comparisons, even if imperfect.
And until you decide to execute on that plan, I'll enjoy this little bit of attention :D Thanks again for the support!
None of it really matters until there's a competitor that has software support 1/10th as good as Raspberry Pi.
TI's "Beagle" ecosystem has software support at least 1/10th as good as RPI, maybe even 2/10ths.
Not one but two full Debian ports are more than enough to me.
https://www.armbian.com/download/
https://dietpi.com/#download
Things may differ a bit in the educational field because of the vast community the RPi can count on, but Linux is Linux, I don't see why a school shouldn't use a different platform and make the solution of problems, if any, part of the learning process.
https://www.armbian.com/download/
https://dietpi.com/#download
Things may differ a bit in the educational field because of the vast community the RPi can count on, but Linux is Linux, I don't see why a school shouldn't use a different platform and make the solution of problems, if any, part of the learning process.
Support usually means all the components, not only the OS image.
This include firmware and drivers for Wi-Fi/Bluetooth module on the board, proper DTS and/or schematics to understand which power rails go to where, maybe even silicon bugs.
Bootstrapping the OS image is one of the simplest part I'd say.
This include firmware and drivers for Wi-Fi/Bluetooth module on the board, proper DTS and/or schematics to understand which power rails go to where, maybe even silicon bugs.
Bootstrapping the OS image is one of the simplest part I'd say.
Agreed, I would only consider Arduino or ESP32 as alternatives, which naturally don't even have the resources for UNIX clone, which is akin to going back to 16 bit home coding, booting straight into the game or demoscene.
This. Your SBC's ecosystem/support is 10x more important than its specs.
Newer Raspberries also rely on third-party components they have limited control of.
VL805 USB chip in RPi 4 and 5 has known bugs since 2020 which are still not fixed.
VL805 USB chip in RPi 4 and 5 has known bugs since 2020 which are still not fixed.
Check out Libre Computer if you haven't already!
I noticed Luckfox Pico Mini isn't included there. Runs Linux. Few bucks on AliExpress: https://www.luckfox.com/Luckfox-Pico-Mini-A
Realistically, I don't think any of the tests I have would run on something like that, I'd need to look at different types of tests, and then they wouldn't really be comparable with the rest. Though, I don't think most people would really be thinking "Hmm should I get a Luckfox Pico Mini A, or a Raspberry Pi" but the feedback surrounding these smaller boards has been interesting, so never say never, but I don't think it's within the scope I had in mind just yet.
> "Hmm should I get a Luckfox Pico Mini A, or a Raspberry Pi"
You're correct that they aren't really comparable. But a lot of the time a RPI is a monumental overkill of biblical proportions for what is needed.
You're correct that they aren't really comparable. But a lot of the time a RPI is a monumental overkill of biblical proportions for what is needed.
Unfortunately it seems not to have any wireless connectivity.
Correct. They do have one, more expensive, with wireless: https://www.luckfox.com/Mini-PC/Luckfox-Pico-Zero?sort=p.pri...
Similar (but without comparisons): https://hackerboards.com/
Uuh hackerboards has comparisons, for example https://hackerboards.com/compare/raspberry-pi-foundation-ras...
Love when actually useful sites appear. Fits the same category of sites like the one LTTLabs is working on
No video encoder information! As a roboticist, the number one thing I look for when comparing SBCs is whether they have hardware encoders for h264 video. Pi4, Jetson Nano, and Orange Pi 5 all had one, but some newer boards like the Pi5 and Orin Nano don't. It would be awesome to have that part of the spec be included in the data/comparison.
I wish there were any SBCs under 10 bucks. Remember the promise of the RPi Zero being 5$? That promise never came true.
It was, but for a very restricted number of users. For like 2 years people hoped to get a RPi Zero at $5 and as a result didn't buy boards by the competition (OrangePi, NanoPi, etc) which were becoming really good and cheap, although not at that price, if memory serves the NanoPi Duo (first model) was around $12. That move was the reason that pushed me to abandon the RPi for other brands and never look back.
No searching by PCIe support it seems :'(
(Or I'm too stupid to use it.)
btw: https://geizhals.eu/?cat=mbarm - but also no search by PCIe there
(Or I'm too stupid to use it.)
btw: https://geizhals.eu/?cat=mbarm - but also no search by PCIe there
I have full specification capability hiding in the background and once I've filled out all of the data, you'll be able to do just this!
if LattePanda for $178 is on the list might as well throw in the Quieter 4C:
https://www.amazon.com/MeLE-Mini-Quieter-4C-Astrophotography...
very impressive N100 device. i run EndeavourOS with KDE/plasma on mine. i swapped out to a faster and more efficient single sided 4TB nvme.
it's fanless and idles at ~4.5W according to the USB-C cable's lcd power readout.
https://www.amazon.com/MeLE-Mini-Quieter-4C-Astrophotography...
very impressive N100 device. i run EndeavourOS with KDE/plasma on mine. i swapped out to a faster and more efficient single sided 4TB nvme.
it's fanless and idles at ~4.5W according to the USB-C cable's lcd power readout.
It's a great device. Power efficient, standard x86_64 Intel so great Linux support, lots of expansion options for USB and M.2.
Making a carrier board for the Mu is definitely not for beginners though. It's got loads of high speed I/O lines. Even actual engineers find high speed PCB design daunting. Also, the functions of those HSIO lines are hardcoded into the firmware. You need special BIOS builds for a board with PCIe or USB 3. Change too much stuff and you're going to have to ask the manufacturer to support your configuration.
Making a carrier board for the Mu is definitely not for beginners though. It's got loads of high speed I/O lines. Even actual engineers find high speed PCB design daunting. Also, the functions of those HSIO lines are hardcoded into the firmware. You need special BIOS builds for a board with PCIe or USB 3. Change too much stuff and you're going to have to ask the manufacturer to support your configuration.
The quite renowned Odroid Hx are also missing.
I guess I'll reply here and cover both of the comments :D There are currently 80 SBCs in the database, and they're all boards that I've obtained over the last few years. It's a side project/hobby and buying many more boards would be a very expensive affair :( New boards will be a mixture of those that interest me, and those that vendors (very kindly) send to be included on the website. Sadly, as much as I'd love to, I can't do a Pokémon and catch them all, so there will be some missing!
Do you accept donations of hardware to be tested and added to the site?
I do accept them from vendors directly (and it has no bearing on how I run the tests) but I've not taken any from individuals before. I'm not quite sure how I'd do that logistically, but if there's something interesting then I'm open to discussing it!
I'm currently in talks with a few of the vendors to start filling the database with missing boards from their ranges so we should have more data available in the coming weeks. There should be 2 BeagleBoard (Eco Green and PocketBeagle 2) arriving tomorrow/Tuesday to expand their range on the site!
I'm currently in talks with a few of the vendors to start filling the database with missing boards from their ranges so we should have more data available in the coming weeks. There should be 2 BeagleBoard (Eco Green and PocketBeagle 2) arriving tomorrow/Tuesday to expand their range on the site!
As for donations from individuals, I have seen folks who do this kind of thing get a P.O. Box or use a mailbox service provider/remailer[0] to maintain their opsec, though that is an added expense. It would likely be easier to accept donations earmarked for equipment purchases, but that requires a bit of trust and reputation, but you have to begin where you are, which is pretty good so far, as you are doing your own tests on your own equipment in your possession. I’m sure many would be willing and able to donate funds and/or hardware, if the option were presented to them, but I don’t know if that is worth the added efforts involved in engaging with the community.
Directly engaging with vendors for donations is somewhat fraught with concerns of its own, as ideally you are doing blind purchases so that vendors can’t give you known-good units, but rather are giving you units that the vendor doesn’t already know are going to be subject to enhanced scrutiny.
Maybe get in touch with the OpenWRT folks to see if you can test the OpenWRT One? I believe they’re using a modified BananaPi design.
https://openwrt.org/toh/openwrt/one
> OpenWrt One is based on the MediaTek Filogic 820 SoC and has WiFi 6, dual-band, 3×3/2×2, 1x 2.5Gbit WAN, 1x 1Gbit LAN, 1GB DDR4 RAM, 256 MiB NAND, 16 MiB NOR (for recovery), M.2 SSD, USB-C Serial console and USB 2.0. Power Over Ethernet (POE): an IEEE 802.3af/at compliant device can power the device via the RJ-45 2.5 Gbps WAN connector.
https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-O...
> OpenWrt One uses Mediatek’s MT7981B SoC with a dual-arm Cortex-a53 core at 1.3 GHz, 1 GB DDR4 RAM and 256 MiB SPI NAND storage. It also integrates 16 MiB of additional protected storage as a system backup, dual storage hardware to ensure that the onboard system is unbrickable, and finally integrated M.2. 2230/2242 NVMe PCIe 2 X1 ports can be used to add external storage. And with a battery holder for an internal clock, OpenWrt One offers a USB 2.0 Type-A and a mikroBUS expansion port to provide more interfaces to a host of technical possibilities
> OpenWrt One is the first board design with OpenWrt opensource communtity.and designed in collaboration with Banana Pi that will also handle manufacturing and distribution of the router board. The OpenWrt One/AP-24.XY router should provide a source of income for the project, for example, to cover the cost of hosting and OpenWrt conferences, with Banana Pi selling the board through their distribution network, and for every device sold, donating to the Software Freedom Conservancy (SDC) with the funds earmarked for OpenWrt.
[0] Techlore on YouTube interviewed the operator of such a service in the video linked below. I won’t name the company as this is not a review or endorsement (pun intended), as I have not used their service, nor can I speak to their operations, but the interview is a decent explainer of the service itself from the point of view of an operator of such a service, and other competitors in that field are also named.
https://youtube.com/watch?v=idSBvjaaFSk
Directly engaging with vendors for donations is somewhat fraught with concerns of its own, as ideally you are doing blind purchases so that vendors can’t give you known-good units, but rather are giving you units that the vendor doesn’t already know are going to be subject to enhanced scrutiny.
Maybe get in touch with the OpenWRT folks to see if you can test the OpenWRT One? I believe they’re using a modified BananaPi design.
https://openwrt.org/toh/openwrt/one
> OpenWrt One is based on the MediaTek Filogic 820 SoC and has WiFi 6, dual-band, 3×3/2×2, 1x 2.5Gbit WAN, 1x 1Gbit LAN, 1GB DDR4 RAM, 256 MiB NAND, 16 MiB NOR (for recovery), M.2 SSD, USB-C Serial console and USB 2.0. Power Over Ethernet (POE): an IEEE 802.3af/at compliant device can power the device via the RJ-45 2.5 Gbps WAN connector.
https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-O...
> OpenWrt One uses Mediatek’s MT7981B SoC with a dual-arm Cortex-a53 core at 1.3 GHz, 1 GB DDR4 RAM and 256 MiB SPI NAND storage. It also integrates 16 MiB of additional protected storage as a system backup, dual storage hardware to ensure that the onboard system is unbrickable, and finally integrated M.2. 2230/2242 NVMe PCIe 2 X1 ports can be used to add external storage. And with a battery holder for an internal clock, OpenWrt One offers a USB 2.0 Type-A and a mikroBUS expansion port to provide more interfaces to a host of technical possibilities
> OpenWrt One is the first board design with OpenWrt opensource communtity.and designed in collaboration with Banana Pi that will also handle manufacturing and distribution of the router board. The OpenWrt One/AP-24.XY router should provide a source of income for the project, for example, to cover the cost of hosting and OpenWrt conferences, with Banana Pi selling the board through their distribution network, and for every device sold, donating to the Software Freedom Conservancy (SDC) with the funds earmarked for OpenWrt.
[0] Techlore on YouTube interviewed the operator of such a service in the video linked below. I won’t name the company as this is not a review or endorsement (pun intended), as I have not used their service, nor can I speak to their operations, but the interview is a decent explainer of the service itself from the point of view of an operator of such a service, and other competitors in that field are also named.
https://youtube.com/watch?v=idSBvjaaFSk
I do have a ko-fi available in the footer of the website, and if someone wants their donation to go towards a specific piece of hardware then I'll most certainly do what I can to honour that, or return it if I can't.
On the samples from vendors front, yeah, that's definitely a concern, though in the years I've been working with manufacturers and had samples from them, I'm fairly confident that no "golden sample" binning is going on as I've had quite a few shockers, hah! Not to say that it couldn't/wouldn't happen, I wouldn't want to introduce that doubt. Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
On the samples from vendors front, yeah, that's definitely a concern, though in the years I've been working with manufacturers and had samples from them, I'm fairly confident that no "golden sample" binning is going on as I've had quite a few shockers, hah! Not to say that it couldn't/wouldn't happen, I wouldn't want to introduce that doubt. Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
> I do have a ko-fi available in the footer of the website, and if someone wants their donation to go towards a specific piece of hardware then I'll most certainly do what I can to honour that, or return it if I can't.
That’s pretty good of you to mention, as I didn’t notice the footer when I visited to see if you already had tested the OpenWRT One before posting my suggestion to test it. Perhaps you could mention that you would make a best effort to test hardware suggested by donors, if you haven’t already done so on the site? I approve of you asking for donations openly, as your time and efforts are worth something to you and to visitors, and if you communicate that it’s a two-way street, with some incentives to donors in that they can help suggest what you spend their donations on, I think that your transparency and good faith are more likely to be rewarded with more and larger donations that a simple “buy me a coffee” pitch might otherwise attract.
> Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
I think such a disclaimer/disclosure would assuage (m)any concerns most folks would have on that front!
You seem to have a good grasp on what you’re doing here. Do you share/open source your testing methodology and/or code run to derive your data?
Edit: I see now that you have some of your testing methodology posted. I would suggest gathering as much room temp data during testing as possible, and maybe even re-running the test suite at variable temperatures as much as possible if you can, so you can plot performance over time with different cooling setups in different ambient temperature conditions, as many folks use SBCs in (semi) permanent indoor and outdoor installs in less-than-ideal environments and enclosures, usually with little to no cooling.
If you were to share your complete test scripts, temp probe/jig setup, etc., other users could reality-test their own hardware against other devices in an apples-to-apples way.
That’s pretty good of you to mention, as I didn’t notice the footer when I visited to see if you already had tested the OpenWRT One before posting my suggestion to test it. Perhaps you could mention that you would make a best effort to test hardware suggested by donors, if you haven’t already done so on the site? I approve of you asking for donations openly, as your time and efforts are worth something to you and to visitors, and if you communicate that it’s a two-way street, with some incentives to donors in that they can help suggest what you spend their donations on, I think that your transparency and good faith are more likely to be rewarded with more and larger donations that a simple “buy me a coffee” pitch might otherwise attract.
> Perhaps, like my review website, I should add a quick note/indicator of whether a board was obtained directly from a vendor, or if it was purchased.
I think such a disclaimer/disclosure would assuage (m)any concerns most folks would have on that front!
You seem to have a good grasp on what you’re doing here. Do you share/open source your testing methodology and/or code run to derive your data?
Edit: I see now that you have some of your testing methodology posted. I would suggest gathering as much room temp data during testing as possible, and maybe even re-running the test suite at variable temperatures as much as possible if you can, so you can plot performance over time with different cooling setups in different ambient temperature conditions, as many folks use SBCs in (semi) permanent indoor and outdoor installs in less-than-ideal environments and enclosures, usually with little to no cooling.
If you were to share your complete test scripts, temp probe/jig setup, etc., other users could reality-test their own hardware against other devices in an apples-to-apples way.
I'm discussing some other bits with Banana Pi so maybe I can ask about that, I'd need to look into the device to see how viable it is, let's see! I can definitely add the "How did you get this board" disclaimer there somewhere
I don't know if I'd release everything as is, there's a lot of hard coded nonsense that I'd need to filter out and after testing 80 boards, I have a bunch of improvements I want to make. Opening up the test scripts to others isn't/wasn't a high priority item, as I didn't even plan on making this site initially :D
Room temperature data is also nice, but I'll need to draw a line somewhere, on average these tests take around 3-4 hours to run, and with 80 boards right now, best case scenario is 10 straight days of testing (in reality, more with setup and.. life). I could use data on the most popular boards and only do a handful, but I probably have to limit the scope at this point and clearly state the testing conditions and how it may differ in your real world setup.
I can definitely do more to expand on the testing process though, and I can look at sharing the exact commands that are run with my automation so that users can at least mimic the benchmark runs if not the full automation. I really appreciate the responses and feedback, though, so thank you!
I don't know if I'd release everything as is, there's a lot of hard coded nonsense that I'd need to filter out and after testing 80 boards, I have a bunch of improvements I want to make. Opening up the test scripts to others isn't/wasn't a high priority item, as I didn't even plan on making this site initially :D
Room temperature data is also nice, but I'll need to draw a line somewhere, on average these tests take around 3-4 hours to run, and with 80 boards right now, best case scenario is 10 straight days of testing (in reality, more with setup and.. life). I could use data on the most popular boards and only do a handful, but I probably have to limit the scope at this point and clearly state the testing conditions and how it may differ in your real world setup.
I can definitely do more to expand on the testing process though, and I can look at sharing the exact commands that are run with my automation so that users can at least mimic the benchmark runs if not the full automation. I really appreciate the responses and feedback, though, so thank you!
Question. Are the RPi, Orange Pi, etc. suitable for use in professional hardware, or are these considered hobbyist products?
Raspberry Pi products can be found in a lot of industrial/professional setups, especially things like their compute module range(s) that can be dropped into off-the-shelf, or custom carrier boards. Others can be a bit more hit and miss, though Libre Computer are up there with great software support, and will have their own compute modules available soon.
Most professional high-volume projects wouldn't use Raspberry Pi as it is, because those boards contain functions they don't need. So they would design their own board which will be cheaper and more compact by including only functions they need.
That's why there's "Compute Module" SoM with minimal functionality. It is made for professional designs.
But if you want to produce low volume product or you're 100% fulfilled with Raspberry Pi, there's nothing "unprofessional" about it. PCB is PCB.
That's why there's "Compute Module" SoM with minimal functionality. It is made for professional designs.
But if you want to produce low volume product or you're 100% fulfilled with Raspberry Pi, there's nothing "unprofessional" about it. PCB is PCB.
Looks cool but no microcontroller boards yet. I didn't get any results for "RP2350" for example.
Those aren't SBCs
what is the difference?
I'm sure there are exceptions to these but: SBCs have micro*processors* not microcontrollers. What's the implication? SBCs run Linux. What's the implication? You can develop a set of programs and stacks on a big desktop, and kinda just copy-paste boom it's on an embedded device. Often including networking, USB, HMI, cameras, etc. All can be done on a microcontroller (though you'd want something with more power than a pico), but not copy paste.
Not sure the most specific definition. But in an easy to understand way, SBCs run an OS like Linux or Windows, while microcontroller boards have a single program flashed directly on to them which directly interacts with the hardware.
Microcontrollers are super cheap and have incredibly low latency so they are great for when you need to do something like pulse an output pin with sub millisecond accuracy, but have very very little compute compared to a real CPU and can’t run normal software.
Microcontrollers are super cheap and have incredibly low latency so they are great for when you need to do something like pulse an output pin with sub millisecond accuracy, but have very very little compute compared to a real CPU and can’t run normal software.
SBC are easier to program for, you can trivially ssh in later and fix/update things.
Meanwhile mcu are… tricky.
For an example I wanted to measure co2 level. It took me about a week to write it in raspberry pi zero w2. It captures data, stores it in sqlite, then every so often transfers to Postgres.
To do the same in esp32 took a couple months ( including storage and updates)
Meanwhile mcu are… tricky.
For an example I wanted to measure co2 level. It took me about a week to write it in raspberry pi zero w2. It captures data, stores it in sqlite, then every so often transfers to Postgres.
To do the same in esp32 took a couple months ( including storage and updates)
Ngl it sounds like you architected that wrong then? The ESP32 should've issued an API request to some other server that runs the sql and whatnot. That shouldn't take months. I've done that in like a few minutes with adafruit's stuff
It’s easy to do something that will work for weeks. It’s hard to do something that will last years.
For example, how does it handle wifi going down? Does it recover gracefully? Does it manage to save the data during downtime and reupload it all afterwards?
How does it handle updates through wifi? OTA updates are important for 10 devices deployed, but is not easy.
For example, how does it handle wifi going down? Does it recover gracefully? Does it manage to save the data during downtime and reupload it all afterwards?
How does it handle updates through wifi? OTA updates are important for 10 devices deployed, but is not easy.
Honestly I would much rather handle that sort of project in an embedded environment and not something running linux.
esp-idf has answers for all those questions. You can hook up an SD card to buffer measurements when the network is down, reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected, and OTA updates are a solved problem with many different strategies to choose from.
esp-idf has answers for all those questions. You can hook up an SD card to buffer measurements when the network is down, reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected, and OTA updates are a solved problem with many different strategies to choose from.
>Honestly I would much rather handle that sort of project in an embedded environment and not something running linux.
That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
>OTA updates are a solved problem with many different strategies to choose from.
No. Just no. Esp32 provides nice libraries to do update but acquisition/logic/code to use that is up to you. You still have to write a lot of code around the libraries and more importantly — debug and think of how to use it.
For example — let’s say you pushed an update that crashes early in boot (or other points). No problem, you’ve designed an AB update system so you just roll back to A.
Not so fast because A partition will try to update back to the botched update after roll back. Causing device to go into a update/crash loop and killing the esp32 in the process (flash has a limited number of erase cycles)
So you say “ok I’ll just store the update number in flash and only update 3x times before blacklisting”.
Well congrats now you gotta go write more code! And this time you get to have fun with nvs library which is great but not trivial. And once again if you make a bug you’ll face either a dead and recoverable device or dead for real device.
>reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected
Oh god no. Take a look here: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s...
Specifically this part:
>Generally, it is easy to write code in "sunny-day" scenarios, such as WIFI_EVENT_STA_START and WIFI_EVENT_STA_CONNECTED. The hard part is to write routines in "rainy-day" scenarios, such as WIFI_EVENT_STA_DISCONNECTED. Good handling of "rainy-day" scenarios is fundamental to robust Wi-Fi applications.
How well does your code handle “I’m connected to Wi-Fi but don’t have an IP?” Or it has an ip but can’t hit your server? Or it can’t hit dns? There’s a bunch of errors and transitionary state that just sucks.
Meanwhile you mention “just buffer the data in SD card”. Once again, write a pile of code, and then put a layer on top of it to store your data. This is a more straight forward problem but adding data to SQLite file and then sending it out is just so much easier.
And then you have to work with time. “Just buffering data” also requires keeping track of time because now you can’t use receive time as your capture time. Now you gotta write more code to synchronize the time on esp32 to your server which is a solved problem on Linux.
That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
>OTA updates are a solved problem with many different strategies to choose from.
No. Just no. Esp32 provides nice libraries to do update but acquisition/logic/code to use that is up to you. You still have to write a lot of code around the libraries and more importantly — debug and think of how to use it.
For example — let’s say you pushed an update that crashes early in boot (or other points). No problem, you’ve designed an AB update system so you just roll back to A.
Not so fast because A partition will try to update back to the botched update after roll back. Causing device to go into a update/crash loop and killing the esp32 in the process (flash has a limited number of erase cycles)
So you say “ok I’ll just store the update number in flash and only update 3x times before blacklisting”.
Well congrats now you gotta go write more code! And this time you get to have fun with nvs library which is great but not trivial. And once again if you make a bug you’ll face either a dead and recoverable device or dead for real device.
>reconnecting is usually as simple as a loop that tries to reconnect if you're not currently connected
Oh god no. Take a look here: https://docs.espressif.com/projects/esp-idf/en/stable/esp32s...
Specifically this part:
>Generally, it is easy to write code in "sunny-day" scenarios, such as WIFI_EVENT_STA_START and WIFI_EVENT_STA_CONNECTED. The hard part is to write routines in "rainy-day" scenarios, such as WIFI_EVENT_STA_DISCONNECTED. Good handling of "rainy-day" scenarios is fundamental to robust Wi-Fi applications.
How well does your code handle “I’m connected to Wi-Fi but don’t have an IP?” Or it has an ip but can’t hit your server? Or it can’t hit dns? There’s a bunch of errors and transitionary state that just sucks.
Meanwhile you mention “just buffer the data in SD card”. Once again, write a pile of code, and then put a layer on top of it to store your data. This is a more straight forward problem but adding data to SQLite file and then sending it out is just so much easier.
And then you have to work with time. “Just buffering data” also requires keeping track of time because now you can’t use receive time as your capture time. Now you gotta write more code to synchronize the time on esp32 to your server which is a solved problem on Linux.
> That’s because you haven’t done it. There’s a lot more code to write in embedded case and lots of pitfalls to fall into.
I haven't done _this particular_ project, doesn't mean I'm not confident in working on embedded systems. So yes, I still stand by my statement that I would much rather do this sort of project in an embedded environment.
Your pessimistic "no. just no." style of writing doesn't convince me. Every problem you listed is an engineering problem you have to consider no matter what platform you're on, and none of this theoretical project is novel. There are solid approaches to each problem, whether it's in an embedded context or something like Linux.
I'm just saying that _I_ personally would prefer to handle it in an embedded context.
I haven't done _this particular_ project, doesn't mean I'm not confident in working on embedded systems. So yes, I still stand by my statement that I would much rather do this sort of project in an embedded environment.
Your pessimistic "no. just no." style of writing doesn't convince me. Every problem you listed is an engineering problem you have to consider no matter what platform you're on, and none of this theoretical project is novel. There are solid approaches to each problem, whether it's in an embedded context or something like Linux.
I'm just saying that _I_ personally would prefer to handle it in an embedded context.
Clicking on “ARM” only seems to show Raspberry Pi’s and not the other ARM boards listed on the site.
I've noticed a couple of issues with the search and filtering this evening, I'll have to look at it tomorrow. In the meantime, https://sbc.compare/arm (there's also /risc-v and /x86) may help a little here!
That’s a nice list, thanks!
Is there a SBC that can run entirely off PoE+ and that can take a couple SATA or M.2 drives?
It's a little bigger than what I imagine you're looking for, but the Radxa 5 ITX (not the ITX+) has 4 SATA ports, PoE+ (via a separate module), 2x2.5GbE, and the RK3588 SoC - I've been testing OpenMediaVault on it for the last couple of weeks and it's been pretty solid. If you're fine with M.2, the Radxa ROCK 5B+ has 2 M.2 M-Key connectors, the same RK3588 SoC, and PoE via a HAT bought separately.
Otherwise, there are dual NVMe HATs for the Raspberry Pi 5 but you'll be splitting a single PCIe Gen 2 lane across both drives (unless you go for the much more expensive HATs that have a Gen 3 PCIe switch on them to then share a single Gen 3 lane across them!)
Otherwise, there are dual NVMe HATs for the Raspberry Pi 5 but you'll be splitting a single PCIe Gen 2 lane across both drives (unless you go for the much more expensive HATs that have a Gen 3 PCIe switch on them to then share a single Gen 3 lane across them!)
That looks about the right size, I think: my goal was to put it on top of my ubiquiti dream machine and directly wire it, but I’m limited in terms of power supply because of the number of outlets in the area.
I wonder why a lot of SBC comparisons leave out the Intel up-board line of products.
Idle power and sleep power are important for embedded applications.
to the author: thanks for making this. Can you tell us about how long it took you to develop this site, and what technology stack you use for it? How did you make it?
Did the up in price on RPis ended up being permanent?
Nice project!
This is actually pretty terrible. Apart from the things “okanat” said, the site is a nightmare in terms of UI and extremely buggy. I didn’t realize modern websites could get this bad.
If you could share a little more on what you actually mean, that would help a ton. I’m not a developer, I put this together as I went, learning along the way. It’s not perfect, and I’m aware of some issues, but if you’d be so kind to expand on “pretty terrible” then maybe I can see if it’s already known, or something I should add to the list.
How so? Where are the bugs you speak of? I don't find the UI to be nightmarish either. Can you point to specific issues the site maintainer can look at?
If this is the worst modern website you've seen, you're very lucky.
If this is the worst modern website you've seen, you're very lucky.
I've been clicking my way around the website for a while now. I haven't seen any bugs or glitches. Could you give an example of what's failing for you?
Before getting into benchmarks I would actually look which hardware capabilities a specific SoC supports first (eDP, HDMI or LVDS, USB ports, i2c, GPIO pins etc). Then I would check whether the manufacturer actually maintains mainline Linux kernel drivers or keeps an up-to-date downstream kernel. I look at their frequency for updates. For media systems having HW acceleration is crucial. Most ARM vendors do a crappy job of providing good open source drivers for this.
Similarly I go and check their Yocto BSPs. If I don't like their organization, that's going to affect my final decision. If it is a power-sensitive project, then the special modes and extra driver support for various sleeping modes come into play.
(Most of the time Intel just wins with those criteria because ARM ecosystem is a mess of proprietary blobs. However there are manufacturers like NXP and MediaTek who do release passable drivers and when power consumption is important they get selected or if the product is very price-sensitvie)
This website looks alright maybe for hobbyists for pure CPU loads with very well cooled systems. I don't find it very useful without the actual engineering details, adding those would massively benefit the website.