BitScope Designs, a manufacturer of embedded mixed signal test, measurement and data acquisition systems, has announced the launch of a new models of their industrial desktop, rack or wall mountable power and mounting power systems with BitScope Blade Uno, Duo, and Quattro supporting respectively 1, 2 and 4 Raspberry Pi 3/2/B+/A+ boards. The blades can also be mounted in a 19″ rack with up to 40 Raspberry Pi boards.
The three systems share many of the same specifications:
- Power Supply
40 Rapsberry Pi Rack with (Older Versions) of BitScope Blade Quattro - Unregulated 9V to 48V DC power, compatible with most 12V & 24V UPS, most DC solar power systems
- 4A (peak) switch mode supply built-in
- 2.1mm socket or industrial power tabs
- Can be used with low cost passive PoE,
- Can power external USB, HDD & SSD
- 5V auxiliary power for example for Pi Display
- Expansion& I/O ports
- Full access to RPi’s I2C, SPI, UART & most GPIO
- Slot for camera connector for each Pi
- HDMI and audio accessible from Pi in BAY one
- Blade HUB I/O expansion sockets for each Pi
- Compatible with BitScope CAP industrial I/O
- Mount System
- Rack mount to build compute cluster solutions
- 4 x 3mm tabs and wall mounting stand-offs
Each model also has specific features:
- BitScope Blade UNO (BB01B)
- Designed for one Raspberry Pi and one HAT
- Power and connect up to 4x BitScopes
- Raspberry Pi power control header,
- 2x USB power sockets
- BitScope Blade DUO (BB02B)
- Designed for 2x Raspberry Pi boards
- Power and connect up to 8x BitScopes
- Individual power and reset inputs for each Pi
- BitScope Blade QUATTRO (BB04B)
- Designed for 4x Raspberry Pi boards
- Power and connect up to 16x BitScopes
- Individual power and reset inputs for each Pi.
The HUB CAP expansion sockets are used to connect BitScope mixed signal scopes & analyzers, which can be controlled by BitScope DSO software running on the Raspberry Pi board with oscilloscope, logic analyzer, wave generator, and other modes of operation.
You’ll find a few more details on the press release, and the new BitScope Blades can be purchased exclusively on Element14 starting at 32.5 GBP (~$41 US). BitScope also has a “Blades” product page, but it is currently referring to the older versions.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
The mentioned ‘Can be used with low cost passive PoE’ means obviously only that the Blades use the usual 2.1/5.5 mm barrel connector most if not all passive PoE splitters use.
Then RPi’s Achilles’ heel (crappy Micro USB for DC-IN) is avoided and the individual boards are powered through the 40 pin GPIO header (5V available as pins 2 and 4, GND on a few other pins) which is both good since the usual Micro USB related problems don’t apply here (max current, voltage drops) but also bad since at least on RPi boards some protection circuitry is leapfroged. But to be honest: all the RPi we use as surveillance cameras are powered identical (passive PoE + buck converter + 5V injected via GPIO header) and we never had a single power related problem.
Would be interesting whether other SBC that clone exactly RPi dimensions and position of connectors (ODROID C1/C1+/C2, ASUS Tinkerboard, 1st UP board, maybe others) can work here or not. But even if powering through GPIO is possible I highly doubt it since all the alternatives are way more powerful than any RPi and (impossible) heat dissipation becomes a huge issue. That’s also the main reason I wouldn’t mention ‘compute cluster’ even if the vendor advertises this use case. You might be able to cramp 40 RPi in 2 rack units this way but without active cooling such a setup could only be used to study the effects of overheating (or to improve throttling settings)
Regarding ODROID-C2 also loosing protection when powered through GPIO header (though I’ve no idea which GPIO pins are used by the Blade): http://forum.odroid.com/viewtopic.php?f=139&t=20485#p135458
Same with C1/C1+: http://forum.odroid.com/viewtopic.php?f=111&t=16287
ASUS Tinkerboard can (and should) be powered through GPIO header: https://forum.armbian.com/index.php/topic/3327-asus-tinkerboard/
For reasons why powerful boards with Micro USB for DC-IN need a different power input see these experiences with MiQi board: https://forum.mqmaker.com/t/miqi-based-build-farm-finally-up-and-running/605
The UP board’s power requirements are too high (same with heat emission): https://up-community.org/forum/public-upboardhw/302-power-connector#1611
And all those RPi alternatives are challenging regarding heat dissipation so you would run in trouble anyway due to the mounting position not allowing any airflow around the SoC at all. But same applies to RPi 3 and RPi 2B too.
Ouch, just realized that those Blade Racks are meant to be mounted vertically?! Doesn’t change a lot regarding heat problems while a rack density of 6 slow RPi per rack unit (40 boards waste 7 RU) isn’t that great. Apart from that I realized that protection circuitry is part of the Blade so now these units become pretty interesting for a specific use case 🙂
@cnxsoft: As usual, thanks for broadening my horizon (on a daily base) 🙂
Why did they make these blades for the SBC RPi and not for the RPi compute module?
@blu
Maybe since the typical use cases require having USB, Ethernet and in Bay 1 also video/audio available? When using the compute module the Blade would’ve to provide what’s already present and accessible (at least USB/Ethernet) on the SBC variants (though pretty limited since it’s just the result of connecting an USB hub with integrated Fast Ethernet to the single USB2 connection every RPi out there suffers from).
All RPi variants except of the unavailable $5 phantom product are already overprized given the BOM so when the blade that is produced maybe in the hundreds/thousands and not millions has to add USB/Ethernet + connectors it would get pretty expensive?
So 64 bit Soc running 64 bit code?
@blu
See also the ‘HUB CAP’ expansion sockets on the back and the use case these Blades were originally designed for BitScope products (if I understand correctly a simple RPi is enough to turn BitScope DSO equipment into a full scope since all that’s needed is connecting display and keyboard/mouse to the attached RPi? And further RPi can be used for high speed data aquisition which requires at least Fast Ethernet being available)
@tkaiser
That’s the thing, though – the standard RPi IO is available on the CM pins as well, while the price of the CM is $5 cheaper than the SBC for batches of 100 (foundation’s official price). So for a scenario where one node on a blade needs full set of IO (video and usb), and the rest just need usb2eth (or plain usb), are the ICs on the SBC (read: the hub) worth the extra $5? I was about to say that the SODIMM format would also allow for much more efficient heat dissipation, but judging by the current blade layout it does not seem heat is much of a problem for BitScope.
@blu
Let’s not talk about how overprized the individual RPi are… ok, just a bit: if we assume the RPi Zero is a loss leader and costs the RPi people more than they earn and say, the BOM of this device is maybe $7 or even $8 then why does RPi A+ or B+ cost that much? It’s just the Microchip LAN9514 (USB hub + Ethernet chip — check the 3000 reel price at eg mouser to get the idea how less RPi people have to pay who order huge amounts of this chip) and all the other components cost less than $1 together.
A 3rd party like BitScope relying on the compute module and producing only batches of thousands has way higher costs adding LAN9514 plus the various connectors to each Blade compared to simply allowing the SBC variant to be used where this stuff can be accessed directly (audio/video only in Bay 1).
And I fear I have to disagree regarding heat dissipation: the SBC are attached to the blade so the SoC is in between with less than 10mm distance to the blade — most probably saving a heatsink will result in less throttling and better performance since with a heatsink attached exactly no airflow will be possible any more and then every heatsink gets rather inefficient. At least that’s what I experienced when starting with all this thermal stuff 3 years ago. Though fun to learn the basics, eg. the necessary distance between heatsink fins so that passive cooling works best: if distance is too small convection won’t work and so on).
@tkaiser
Thanks for the BOM breakdown. So the economy of scale would likely negate the $5 advantage the SOM has, which I can understand.
Re the dissipation, my point was that the SODIMMs would give them more freedom re flow dynamics – SOMs could be oriented either in-line or vertically to the blades, so they could achieve optimal airflow in the chassis. But if the current SBC solution is good enough then more optimal solutions are not necessary, obviously.
@blu
I don’t think that one is able to run in thermal problems when using any RPi with the BitBlades with the original use case in mind (data aquisition and visualization) even if some throttling might occur. But to be honest: Why ‘compute clusters’ especially with Raspberries and then mounted vertically? Wasting 7 rack units for just 40 RPi is a (negative) rack density record, the RPi SoCs are pretty weak when it’s about CPU performance (can any form of GPGPU computing be used here?) and the lack of network/storage bandwidth prevent any reasonable use with other typical cluster use cases. The most promising low-cost SoC for cluster adventures today seems to be Allwinner’s H5 to me and if performance, high bandwidth storage and interconnection are issues then I would choose Marvell or Annapurna labs instead.
Anyway: Just combining a compatible SBC with the Blade still looks promising for a specific use case. I’ll order one BitScope Blade as soon as the new version is available on Farnell to test through.
New article on Element14 about various use cases for Bitscope blades: https://www.element14.com/community/community/raspberry-pi/blog/2017/02/07/raspberry-pi-applications-built-with-bitscope-blade