
About the uSB ports sticking out...
...that's what you want, it means that fit flush with any case you have.
You might think that as a purveyor of a nifty compact computer selling in the millions, you’d consider two years after the debut of your first offering that it was high time you tempted back the buyers with a go-faster, more capacious and shinier model. Heck, Apple and others don’t even wait that long: they upgrade products year …
Cases for the B+ are a bit limited at the moment anyway - ModMyPi and Cyntech have got a new one coming along in a couple of weeks that looks fairly neat, and it can be fitted with shims to make the case taller:
https://www.modmypi.com/shop/modmypi-model-b-plus-raspberry-pi-case-black
The B started with 256MB and it was bumped up to 512MB in a later rev.
I think it wouldn't hurt to bump up the processor in a model C. Multi core SoCs sell for a few dollars which is cheap enough to consider throwing into a later Pi. Add a soft reset / standby and suddenly it's useful as a media player or an Android device. The model B could just about power XBMC but it didn't win prizes for responsiveness.
The problem is that once you bump the processor up to something more modern, your software compatibility goes out the window,
The Quad Cores are coming (in a month or two). But they are very different beasts from the Pi and the O/S's they run are sufficiently different that the Pi's biggest asset: it's base of user software, would have to be restarted, reported or redesigned.
While that may not be such a bad thing - it will take the wind out of the Pi's sails and given that there are so many other products already in the SBC multi-processor market, it would be difficult for the Pi to regain its old pre-eminence.
"The problem is that once you bump the processor up to something more modern, your software compatibility goes out the window,"
I don't see the issue really. A Pi runs whatever you load onto the SD card. If dists are built to the new Pi specification then they'll run the same way as they do now. End users download a dist, stick it on a card and boot it. They might have to recompile their code but presumably they wouldn't have bought the new Pi if they weren't prepared to do that.
"The Quad Cores are coming (in a month or two). But they are very different beasts from the Pi and the O/S's they run are sufficiently different that the Pi's biggest asset: it's base of user software, would have to be restarted, reported or redesigned."
No it wouldn't. Most client side software would work exactly the same whether it was on one core or eight cores. Most existing Pi code runs in a single thread or uses threads sparingly. The only change of moving to a multi core processor is that the kernel scheduler allows more processes / threads to run in parallel so the experience is more responsive, particularly if combined with a higher clock speed.
"While that may not be such a bad thing - it will take the wind out of the Pi's sails and given that there are so many other products already in the SBC multi-processor market, it would be difficult for the Pi to regain its old pre-eminence."
I don't see it doing that at all. A more powerful Pi would have wider appeal particularly for people looking to build out desktops, media players from it.
> If dists are built to the new Pi specification then they'll run the same way as they do now.
But they aren't - and they won't.
Let me give you a couple of examples:
First the Allwinner SoCs have a lot of pins (a LOT) that are primarily intended to drive an LCD. If you base a new Pi on these devices, people will see the new features, such as this, and want to use them. That will lead to a fork of the user-base and split the development effort. Not to mention making the boards physical layout a lot different.
Secondly, the reference SunXi Linux ports have a low-level mapping between the processor's hardware pins and their functions. This FEX file is user-configurable and is set up during boot-time. Hence a piece of software that assumes (say) pin PB22 is a serial output pin when a different cut of Linux, or a different version of the same distribution has decided that pin should be a digital input, instead, will fail in weird and improbable ways.
There are many other reasons, but these serve as illustrations that the gap between a Pi and a "next-gen" SBC is large and widening.
And it's reasons like this which are why software compatibility will go out the window and why the processor families are different from each other. Now that doesn't mean the the simple user interface and APIs used on a Pi can't be ported across. But the new SBCs are so much more powerful and have so many additional features that producing products which leave out those features will severely limit their take up - especially as there are established enterprises that are already producing fuil-featured products.
You mean like the Cubieboard2 (Allwinner A20) with an attached SSD sitting next to my desk that gets used as a database server for a group of Pis for a particular application, and the Cubieboard (Allwiner A10) that runs the replicated database, both of which are running Raspbian?
XBMC on the Pi (OpenELEC, Raspbmc, Xbian etc.) can play back full high-profile Blu-ray rips so I don't know what you're on about saying it can't handle MPEG4 HD, that's utter FUD.
I've also no idea about your DVB-T stick, maybe get one with decent Linux driver support next time - plenty of others are using their Pis with XBMC for Live TV/PVR viewing.
The Pi with XBMC does actually make a genuinely good "media box" - it can pretty much play anything you care to chuck at it, either from local HDD (USB attached), from your NAS or streamed from the web.
Sure, the ARM CPU hasn't got the same slick performance as a quad-core i7, but the GPU in the Pi is surprisingly powerful and funnily enough that's the most important thing when playing hardware accelerated videos. And despite being low powered, the ARM CPU still provides a pretty good user experience when browsing around the menus and library in XBMC (officially sanctioned overclocking to 1GHz+ helps improve the UX, of course).
"The Pi with XBMC does actually make a genuinely good "media box"" - Yes. To a point. I received a Pi last year as a present. At first I used it with XBMC to play .TS files from my PVR and video from my NAS, both in another room. It did an okay job, however the lack of proper FF/REW on some file types and the fact that when playing a file the UI was like wading through treacle meant that I moved it on to other things.
So it was then put into service as see whether it was good enough to use as an emulation games machine (Amiga/ST/MAME). It wasn't. It's simply not powerful enough.
It's now running CUPS and acting as an AirPrint server for my 15 year old laserjet printer.
At first I thought of the Pi as a solution looking for a problem. It's clearly found a niche for low power (both electrical and processing) projects, though I'm still not convinced it's the best option for the task it was originally marketed for - the revival of the bedroom coder and getting school kids into programming. A significantly more powerful version (quad core, more memory) would open up a whole load more opportunities.
quote: "At first I thought of the Pi as a solution looking for a problem. It's clearly found a niche for low power (both electrical and processing) projects, though I'm still not convinced it's the best option for the task it was originally marketed for - the revival of the bedroom coder and getting school kids into programming. A significantly more powerful version (quad core, more memory) would open up a whole load more opportunities."
A significantly more powerful unit would also incur a significant increase in base cost. The Pi was designed as a sub-£30 computer, primarily because that price point struck a good balance between kit capability and ease of finding the funds.
You can get some extremely capable miniPCs (e.g. the Zotac range or the Intel NUC range) but they are an order of magnitude more expensive than the Pi. If, as a parent, you can spare £300+ then get a miniPC for them to play with. If you can't, then £30 for a basic unit that they can still learn to use, and is a full general purpose computer to boot, is a bargain.
I used to bedroom code on a single core 1MHz machine with 64kB of RAM, and moved on to an 8MHz single core with 512kB RAM. Compared to those the Pi is a monster of a machine ;)
Running Raspbmc myself, it works very well for such a cheap device. Yes, the UI might not be the smoothest all the time (a minimal skin is recommended), but I use it for media, not to gaze at the menus. One really great thing about it is it supports HDMI CEC, provided you have a compatible TV you can use the TV remote to control it. If you subscribe to Spotify (third party clients require a premium account) just grap a .zip for Spotimc, copy it over and install, no further tinkering is required. And transmission-daemon makes a great web frontend for getting... um, Linux distros, to play. Regarding overclocking, it is very easy (the stock Raspbmc build is already overclocked slightly), but if you like to overclock it further and prefer stability/longevity, heat sinks are reasonable investment. You can get them from ModMyPi for example if you don't want to tinker.
You need to research difference between MPEG4 H.264 DVB-T (SD & HD) (or DVB-T2 MPEG4 H.264 HD) and ripped discs. It's not a driver issue. The Pi was NEVER intended as a Media Box solution (it's not even cost effective as one). It'san ARM SoC chip for cheap phones (that use a separate ARM SoC for the phone functions on a break out board for learning and experimenting with HW controlled by your own SW.
Obviously some people simply don't get it!
Also a media box that can't use SATA drives directly is pretty crippled.
I'd not buy a Chromecast or Apple TV. But there are good DIY solutions far better than a Pi for media if you don't want a Roku.
"You need to research difference between MPEG4 H.264 DVB-T (SD & HD) (or DVB-T2 MPEG4 H.264 HD) and ripped discs. "
I think you need to research the meaningless gobbledegook you just threw out. H264 is a codec. DVB-T and DVB-T2 are broadcast protocols for encapsulating data in streams. As far as a decoder is concerned it is of supreme indifference where the video / audio came from as long as it conforms to the spec.
"The Pi was NEVER intended as a Media Box solution (it's not even cost effective as one). "
The Broadcom Soc in the Pi was designed to go in blu ray players, satellite boxes and so on and hardware decoding of H264 and AAC is unlocked. It's the very definition of a media solution.
Yes you can do whatever you want with it. But why bother doing stuff that other hardware does far easier and slicker.
Most people's TV's already play media these days or they have a games console, or blue ray player that does, and if none of those apply then a Roku or android dongle are cheaper than a Pi and better at the job as well.
The Pi is strongest at doing stuff other hardware doesn't do.
Actually, the SoC in the Raspi was designed to go in to mobile phones as a media processor (and other stuff). The GPU was specifically designed for H264 decode at 1080p30, encode for camera at the same speed. It has fast 3D and 2D graphics for running games. The ARM itself was added as an bolt on goody.
And the EXACT SAME SOC was used in the Roku2 - which as I am sure you are aware is a media box.
So it's media credentials are actually really quite good. The ARM is a bit weak for real speedy UI stuff, but we use it at home to stream stuff wirelessly from the PVR and NAS, and also use one in a motorhome as a wireless AP so the sprogs can stream stuff to their tablets on the move. Works fine with XBMC.
I do tend to overclock to 900Mhz (simple config change)which does make an appreciable difference.
If I dare make a possibly ill-educated comment: surely the issue with moving to a new SoC would be that the existing Broadcom is an ARMv6 device whereas anything newer is probably ARMv7. Which would make maintaining binary distributions of anything more troublesome — hardly an impossible problem, but a bit more awkward. In the intended environment, it'd at least mean remembering which pile of SD cards goes with which type of board.
As to price, I imagine there may be a calculation that with ARMv8 now filtering into mobile phones, there's about to be a whole generation of ARMv7 parts that remain incredibly capable but are suddenly a lot easier to get a good deal on just because of the realities of marketing.
There's also the fact that Broadcom has provided full documentation to the Videocore IV, which isn't standard industry practice — GPU internals remain entirely proprietary — and would be very unlikely to occur with a new SoC. So that would introduce a new round of binary blobs and impediments to the bare metal programmers.
"It's an educational device, not a device that allows you to pirate movies and stream them around your home.."
Interesting. And there were people thinking that a device built around a media SoC, which has a LAN port, an HDMI output, H264 and AAC hardware decoding unlocked and 2 major media player dists might reasonably be used that way.
The negativity about wanting the Pi to improve and become more suitable in more situations is absurd and baffling.
> It's not a Media SoC. Not in the sense of Home Media, It's support for media on a phone device!
Gosh, you're right! I must stop using it as my HTPC immediately! And you're right, no SATA interface - what was I thinking having a fanless device that barely uses any power in the living room and NAS tucked away where I can't hear it. Glad you enlightened me.
So, anyone who uses media streaming is a pirate? I'm ripping all my DVDs to a load of reclaimed hard drives in an old tower case, and using Raspbmc to play them on my TV - should I cower in fear at the thought of the police beating down my door and hauling me up before the beak? My long history of VHS useage would surely count against me.
On a serious note, I did intend to use the Pi for the kids to learn programming on, but it's just too damn handy as a cheap, versatile, media player (and I get to reclaim shelf space from the DVDs, too)!
"which is cheap enough to consider throwing into a later Pi."
What I find fascinating about the Pi, along with the attendant commentary in tech rags, is that it challenges the assumptions that bigger, more, whatever superlative you wish to use, is intrinsically better. Sure, sometimes, as in the above comment, it may just be a wish rather than a critique of what the Pi's founders and its foundation intended and have achieved. It's almost like the pushback that occurred at the height of the Enlightenment, when the starkness of method was balanced by the rise of Romanticism. And the creative outpouring that has accompanied the Pi bears out that assertion quite well. The Pi says it need not be all about the philosophy of Improvement, but can be about what's within your grasp and within your capability. So it's appealing to people for whom mainstream technology would hold little interest, but still really is technology.
Having said that, I'm still doing traditional tech with one of mine, safely tucked away in an Austrian data centre, thanks to the generosity of free Pi hosting companies.
CPU - same
RAM - same
USB throughput with a 5 port hub (4 external + 1 internal USB Ethernet) - tiny fraction lower
[Model B has a 3 port hub (2 ext + 1 int USB Ethernet) - slightly faster but not by very much really]
SD card - bye bye standard, hello micro.
It is basically a mobile phone without a screen, baseband processor, antenna, battery and camera, although you can buy that optional these days for what 20ish.
If they stick to this CPU, the only easy upgrade path left to them is to add more RAM. I think that the chip can support 2GB and it will probably happen when they can no longer source 512MB cheaper 1GB/2GB. At some stage in electronics old components ends up costing more than new.
It's a BIG waste of time, the number of ports is irrelevant, it is the number of CONTROLLERS that matter.
Many of these SOCs have Two or three independent controllers , where as some others do stupid things like string internal peripherals off exposed usb hubs ,because it's cheaper……
Unfortunately if the user does something stupid and causes a controller to shutdown then you have an SBC with dead internet, KB and other IO even if the CPU is still running.
Pi has long had major issues with its USB chain for exactly this reason.
Best bet is to always buy SBC kit that has atleast two controllers and ensure that the damned internet is not run off the same controller that the external user connection is……
I have an old 2.5-inch laptop hard drive in a bus-powered caddy, but the B+ couldn’t provide it with sufficient power
By default the Pi B+ will provide the USB ports with 600mA of current, which may not be enough to spin up your HDD. However if you add the setting
max_usb_current=1
to config.txt (a file in the root of the FAT partition - create it if it doesn't exist), you are able to increase the current supplied to USB devices by another 600mA, to 1.2A, which should be sufficient to power your HDD - no hub required.
However, you will require a decent 2A+ PSU to supply increased current to the USB ports.
Some additional details here.
If you have a power-hungry USB drive, check the drive connector. If it's Mini-USB it likely came with a Y-cable having two A-connectors, one power only. You can use a seperate USB-power wart, or two connectors in a proper USB hub. These cables are cheap from the usual net-sources.
Powering this sort of kit is one the the reasons I bought a Pimoroni PiHub.
I bought that product when it was reviewed here, and it fully lives up to the recommendation. There's a lot of expensive crap out there. If your USB-hub is running warm, it's a bad sign. This one delivers the power, and stays cool.
One of the minor annoyances with the previous Pi was the lack of USB ports, so one had to use a USB Hub, and it might as well be a powered hub, and then both the hub and the Pi lacked power steering diodes, so that the hub back fed +5Vdc out the host cable, and the Pi happily accepted power via its USB port, so that turning off the Pi's AC adapter left the system powered on. Silly.
Open hub, cut +5Vdc trace, so that hub now *requires* its own power supply, and doesn't back feed the overly-accepting* Pi (* is there a word for that?).
Yes, yes, ...I did write "minor".
I find it amusing how, after being named explicitly after the original BBC Micro Models A and B, the corresponding Raspberry Pis mimicked the sales pattern of the latter, i.e. the cheaper but less powerful Model A being outsold by the far more popular Model B which went on to be the canonical version of the machine. (*)
Being an enhanced replacement for its predecessor rather than a radically new model, the Raspberry Pi Model B+ seemingly mirrors the BBC Micro B+, itself essentially an upgraded version of the BBC B with 64K and some other improvements.
It was also quite short-lived and AFAIK not that well-known. (Personally, I wasn't even aware of its existence at the time). Since the B+ was quickly superseded by the more obviously upgraded BBC Master (**), does this mean the new Pi is likely to be replaced soon with a new Pi Master featuring numeric keypad, cartridge slot and 128KB memory? ;-)
(*) Though to be fair, the Pi Model A came out some time after the Model B IIRC
(**) I remember when a BBC Master arrived in my primary school class. I happily played around with the various settings, safe in the knowledge that anything which got messed up could be fixed by simply turning it off and on again (i.e. clearing the RAM). Of course, junior smartass didn't realise that the shiny new Master stored these settings in battery-backed RAM and hilarity, er... panic ensued when the keyboard repeat rate remained stubbornly messed up and the nice man from Acorn (or wherever) had to come in and reset them.
Yep, I remember the non-volatile RAM settings very well. As a student, I actually produced a bootable floppy for my school that would reset the NVRAM and restore all the default settings automatically as well as doing some other self-testing modelled on PC BIOS testing - I can't remember exactly what. It came in handy a few times when people had managed to mess up a BBC Master with random * commands.
"Being an enhanced replacement for its predecessor rather than a radically new model, the Raspberry Pi Model B+ seemingly mirrors the BBC Micro B+, itself essentially an upgraded version of the BBC B with 64K and some other improvements."
There were two B+ models - one with 64K and one with 128K. I found myself with the former.
"It was also quite short-lived and AFAIK not that well-known. (Personally, I wasn't even aware of its existence at the time)."
Neither was I until I bought a second hand BBC, and discovered it was something a little more. :)
The extra RAM was handy for getting tape-based games to run from disc, when they were tight on memory: A little extra RAM was used for the disc interface, so software would load at a higher location and have less memory to play in, which some didn't take kindly to - but with the extra memory, you could load a tape-based program (from disc) into a higher location anyway, disable the interface and set the memory map as per a tape based system, move the software down in RAM and run it.
The shuffling of the programmes down was something that was done way before the B+ or B+128. You would load a small piece of machine code into the cassette buffer or somewhere, *LOAD the cassette image into a higher memory, and then move the data down before changing the video mode.
Some of the ROM toolkits did this for you. I think that both DISK DOCTOR and the ROM based BEEBUG monitor had this feature.
What the B+ and B+128 did do, however, was allow the disk subsystem to use 'shadow' memory for the various disk buffers, meaning that PAGE remained at &0E00, rather than the &1900 that was normal for a machine with Acorn DFS on either the Intel 8271 or WD1770 disk controllers, or &1A00 for a system with disk and Econet, or &2100 (I think) for a system with ADFS (yes, you could get ADFS for BBC Model B's, it was used to run the 10MB hard-disk in a Level 3 Econet server).
They also moved the screen into shadow memory so that memory up to &7FFF was available regardless of the screen mode. The primary use for the extra 64KB of memory in the B+128 was to hold RAM copies of sideways ROM packages. I have an ATPL Sideways RAM board for that (but only 16K of static memory) so I never invested in a B+ or B+128, or a Solidisk add on shadow RAM board.
Must have a play again sometime.
The B+ was the first BBC to route the write line to the paged ROMs, wasn't it? So you'd also be unable to use sideways E00 solutions on a regular B, at least without minor motherboard modifications (i.e. finding a write line anywhere and adding a patch wire).
The ATPL board had some jumpers, but I think that it synthesized a write enable from the address bus.
As a result, you could not move the various buffers (like the disk buffers) or worksapce for DFS into sideways RAM. There were hacked DFSs (I think the Watford DDFS was one) that could work in shadow mode, but it did that by changing the addresses of the buffers in the code, not re-directing the addresses.
The Solidisk board for the Model B was more sophisticated, but I believe that it required a wire either inserted into one of the chip sockets in parallel to the chip pin, or a fly lead soldered to the board.
The way that the ATPL add-in worked was basically that any write to an address above &8000 got directed into the (single) bank of static RAM, regardless of the ROM select register. Some ROM providers got canny to this, and during ROM setup, would do a write to overwrite some of the ROM image (Wordwise was the first one that I came across) to cause the initialisation to crash the BEEB if it was running the ROM image from RAM. This could be prevented by adding a switch to the write-enable line of the static memory (there was a solder link and pads for a switch on the ATPL board) that would disable the writes to the RAM. The sequence would be load the image, write protect the RAM, and reset the BEEB (in fact you did not need to reset the BEEB, there was an OSCLI call to initialise the new image - something I used to enable switching between the runtime and compile ROMs in RAM of the Acornsoft ISO Pascal system, which came as 2 ROMs).
Back to Wordwise, when I got a Master 128 (at work), which did not have a write defeat switch for the sideways RAM, I hacked Wordwise to remove the offending code in the image to still allow it to work. Not that I used Wordwise. If I was using the BEEB as a word-processor, I preferred View, but if I just wanted an editor, I used the one built in to the ISO Pascal runtime. Most of my documentation was actually done on my (well, work's, but I was the sole sysadmin, so it was "mine") UNIX box using nroff and a Qume Sprint 5 daisy-wheel printer.
"The shuffling of the programmes down was something that was done way before the B+ or B+128."
Yes, it was - but with the extra memory to play with, it could be done differently. I wrote a fairly generic1 bit of 6502 code for the purpose - which, I'd guess, probably did similar things to the ROMs you mentioned. Not that I can remember in any great detail now.
I wish I still had that computer.
1. Fairly generic for the stuff I had, tweaked slightly for some which were a little nastier, IIRC.
I guess having more USB ports can't hurt, but it's not something that I would have put very high on the wishlist: with my everyday Pi I use a powered USB hub that provides both the power for the board and the extra USB ports (a D-LINK - DUB-H7, if you want to know. Excellent little piece of tech).
On the other hand I sometimes use the video output (not everything has HDMI even nowadays, and HDMI is also more fickle), so I'd miss that. Up until last year I still had a TV set hooked up to a Pi's video output with sound going to an external system.
I've three Pi - Model B units. One is the original 256MB model, the other two have 512MB.
They're nice little devices to have on the LAN for playing about with, but just need that little bit extra to make it really useful. I appreciate that they are intended to be educational devices and to that end, they're excellent and offer excellent value for money.
My next buy will be a Banana Pi, for its slightly faster CPU, double the RAM, gigabit ethernet and on-board SATA. Much better bang for buck, making the Banana Pi a lot more useful, for the extra 60-70% in cost.
However, it's the Minnowboard Max, dual core / 2GB that I'm waiting for. That's a real low voltage SBC with all the versatility of a larger, more power-hungry unit.
I've got a slightly ridiculous home LAN / lab, using 30-odd internal IP addresses, including physical devices and a load of virtual hosts on a dedicated vSphere hypervisor. Don't want the 100Mbit ethernet Pi's taking up more switch ports, it's the Banana Pi and Minnowboard Max units that will be getting added to it from here on in.
The ODROID-W might be of particular interest to Pi owners, especially those wanting to use LiPo or other battery power. That uses the same SoC as the Pi does and runs the exact same software as the PI -
http://hardkernel.com/main/products/prdt_info.php
Only 30 addresses? My DHCP server struggles to allocate addresses even though it has ~100 to play with (the other 100+ addresses are in reserved ranges for static IP addresses). And I have used something like 30 of these static addresses for machines I want to have fixes addresses - like the main laptops for each of the kids so that I can monitor/arbitrate who is using the most traffic as well.
I have seven adults in the house, with WiFi mobile phones, tablets and eBook readers, laptops and larger gaming rigs. Add to this all the consoles and hand-held games, set-top boxes, and a smattering for the infrastructure devices (WiFi hubs and routers) and we've used up a significant part of a Class-C subnet just in one house! I'm really not looking forward to transitioning IPv6 (I'll probably set up an IPv4 island when I have to!)
Hmmm, wonder if its fixed the for me achillies heel, sd card corruption.
As I had multiple sd cards go bad, none of which were removed during operation (in fact, they weren't even disturbed, because they were wall mounted), I dug into it, and it was apparently a issue caused by the way the soc handled sd/usb connectivity being a bit of a fudge. As micro sd is a subset of sd, I'm left wondering if this fixes any of it.
And before the usual apologists say weak psu, bad sd card and all the other blah blah reasons trotted out on the pi forums, we ran four pi's in a test bed on a common rail regulated lab psu. 1 of them behaved impeccably, the other 3 randomly corrupted their sd cards with a week or so of stability testing. We bought the whole "its fake sd cards" like trotted out and tried various brands of sd cards, slow speed low capacity ones from the dawn of time, genuine oem's from reliable suppliers etc. In fact at one point we dual booted one with its base partition on sd and everything else on usb drive, and that one managed to corrupt both the sd card partition AND the usb stick.
The one good one could cope indefinitely with sd cards which had previously corrupted in the other 3 without a glitch. The only differential we can come up with in environment is we bought the first one early on in the b's release to evaluate, then ordered the other 3 much later to build out with. I note they changed assembly details between the two purchases.
The various patches which played with timings and slowed down the io helped a bit, but it never cured the problem enough to be able to rely on them to just keep working, which when you take a sbc and leave it somewhere to do its job for a year uninterrupted is a supremely important quality.
The worst about it was the continued denial, the fud spread on forums as it all being user error etc.
For us, too late, we've abandoned it as a platform now in favour of a more stable compettitor although I did wonder if the model c would fix it as it goes to a true flash chip, which is what broadcom designed the soc to work with in the first place.
Posting anon, because Ive got enough egg on my face recommending them in the first place without publically identifying myself as the culprit. Great toys though.
SD card corruption.
The corruption caused (actually increased the frequency) by overclocking was fixed some months ago.
Corruption caused by wearing out the cards might be an issue, SD cards do have limited write cycles, so avoiding excessive writing can increase life considerably. Turn off logging to card. Leaving them for a year might be hitting that sort of issue, in fact I would think it quite likely if you haven't taken precautions to reduce write cycles.
Your particular job would be better served by the compute module by the sound of it.
James, read my post again. We took the "bad" "corrupt" sd card and wiped it, and reused it in the "good" first model b, and that one was rock solid stable. In fact we could deliberately hard power cycle it and the card would survive without corruption in that unit without fail. If it was wear issues on the sd media, why would the first board be so stable with the same combination?
None of the others stayed up longer than a fortnight. The year was a flippant dream. The first reliable B is still screwed the wall of the office still running off the lab psu and still stable though now we have repurposed it as the office media server.
None of our pi's were overclocked, none were logging to the card or doing excessive writes. They were all running the exact same version of operating system and software.
Maybe we were just really really unlucky, but we couldn't risk a repeat of that.
I actually have a similar experience I bought 2 B's a few months ago(seriously would have held off if I knew the B+ would have came out 2 weeks later...), and the one keeps corrupting the OS install every few boots which I find is quite aggravating(I use it in a 1/9th scale arcade machine).
I know its not the SD card as I ordered 3 of them at the same time, and my model A has had no issues with the same card(or others in the past), the other B I really am not sure on as I set it up to function as a NAS that I've yet to leave online for any time.
And once I reinstall the OS its all good to go. I've had SD cards corrupt, and go bad so I know how to tell a bad card as they would not work like normal which the card that keeps getting corrupt allows.
Oddly enough the same issue as yourself, although luckily it wasn't a personal purchase. A guy recommended these boards singing their praises and by the end just ended the project. It's what put me off personally getting one. I had a play around and as far as I could tell it was the board at fault. It was meant to be used on a welcome screen to play networked videos on reception. El cheapo unit, stick it in and let it work by itself.
Been eying the price of the B+ and some stock equipment. Wonder if the new power regulator has indeed fixed the issue. Something about the whole affair put me off getting one until now. Hopefully the B+ is a lot better, still weighing up getting one.
As old fashioned as it is to swap cartridges like this I love it, but only for the Pi. I love being able to flash up 30+ SD cards for students with Minecraft, Scratch, you know, all the good stuff, and just give them to the students to use on the school Pis.
Some have partner-purchased some Pis through us (we deduct $10 off the price and absorb the cost of shipping) and they are welcome to take the SD card home with them to continue messing around. One student brought in their own SD card they'd made them self with Quake 3 and MAME on it. When he noticed me watching he got scared thinking he was going to be in trouble for using the school hardware to play games.
He got an A for that little programming unit after he showed me how he compiled MAME on his own...
My pi runs rasplex fine, the plex media server is on an HP 36l microserver (which also is a hyper v host).
You can use a pi for whatever you want, after all you bought it.
I might get another one to use as an additional plex client just to annoy people who think it should be used for educational purposes.
Our company was going to try these out for an education product line we developed for low income families.
The problems were the paucity of mounting holes and the fact that one connector was offset to the 0.1 inch matrix.
Now we have switched to a TI product. What a pity.
Frankly, I really like this evolutionary approach to improvements/upgrades. I can decide to buy new/replacement units now, or I can wait until there is an incrementally more desirable version in a year or three. I'm going to buy at least one now, however. The update rate and unit price are both low enough that I can afford to own at least one of every new version.
For me the biggest single improvement on the B+ is they have finally sorted out the power, on the older models just inserting or removing USB devices would crash the thing and it would seem to crash anyway after a couple of weeks of continuous usage (I use mine for internet access to my home network via SSH/SCP, the SD card boots the OS off of a 500Gb USB drive to reduce SD card failures), the Model B+ just doesn't crash.
As always on these forums it seems there are people who would buy a moped and then complain they can't use it to win a Grand Prix, the Pi is what it is, and the primary focus was for teaching, I have a couple of Pi's a Beaglebone Black and an Arduino, they all work well and they all have their strengths and weaknesses, I much prefer the Beaglebone for projects, but then again that was the reason it was created.
Reading a lot of the posts here it reminds me of the talk when the iPad came out "You can't program on it!", "no good for writing long complex documents!", seems like people don't have the concept of "the right tool for the right job", everyone wants the computer equivalent of a Swiss army knife!
We are delighted with the RPi model B+ and our industrial customers seem to like the new board as well. Our Proto Armour for Raspberry Pi B+ enclosure kit is a rugged solution for tough OEM applications. It started shipping shortly after the new board came out and is available for purchase from our store at:
http://store.mobileappsystems.com/110149/
Tom Skwara
MobileApp Systems
Makers of Proto Armour for Raspberry Pi