The problem is not the flash used, it is the file system. Files can be open in RAM. If the RAM image is being flushed back to the flash when power is lost and part is not copied, you have a corrupted file system. You have to be able to do some fast writes to avoid that with any system that writes to the flash even without a file system... or you don't care about corrupted data. Under Linux corrupted data can be it won't boot.
-- Rick
So? Do the math for energy.
-- Rick
Indeed, that module came with wires that plugged on to the Pi header and fits in the standard Pi case I had. I was going to make a wee switching PSU like you but I'm time poor and cash rich so a ready made solution got the job advanced much more quickly.
They do! But at least a 7805 or the LDO versions are not as outrageous a solution as the valved (tubed) Hifi mob suggesting equipment sounds better with 5AR4/GZ34 in the PSU than silicon diodes!
I haven't looked but I'd be surprised if you need more than 2 chips from Maxim to make a brownout/powerfail/reset generator and battery charger. Maybe a small inductor and FET needed as well.
Exactly.
In fact, if you have capacitance C at voltage V, it can store 1/2 CV^2.
If you want to double the voltage to store four times as much energy, you'll need four capacitors in series-parallel, each storing the original energy.
Conservation of energy can be relied on. ;-)
-- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
A slight digression.
Indirectly that can be true :)
If you have the *right* valve rectifier for the job you only get full HT when all the valves have warmed up, this results in longer life for electrolytics
- especially early stage ones that may not be rated for the full voltage at the reservoir.
The output valves also aren't at risk of cathode stripping - damage that is caused by full HT while the heaters are only half way up to temperature.
So, damaged caps and half dead valves definitely won't sound as good as pristine ones :)
Oh, and if you do put silicon diodes in to replace a valve rectifier, at least make some attempt at putting a thermister between them and the reservoir cap.
-- W J G
That's not a useful calculation of energy. That may be the energy you have to put in to charge up the cap, but it's not what useful energy you can get out to power a device. Consider the minimum voltage. The original approach had a delta V of just 0.5 volts leaving most of the energy in the cap at the end. Then consider how much more of the energy in the caps can be used to power the device when the cap starts at 40 volts.
-- Rick
Ensuring the HT rises with the heaters is the corrent engineering solution when replacing the rectifier. But I'm talking about where people will tell you Telefunken or Gold Lion GZ34 "sound better" than other rectifiers. ;-)
Which is no doubt why ageing had such a dramatic effect on the 'scope traces I saw.
I've never never looked at alkalines resistance: they have seemed OK when I've used them as superior replacements for standard primary cells.
Going back to NiMH, it was known in RC aircraft flying circles that if you didn't fully charge the batteries driving the radio & servos during the night before you went flying you were just asking for trouble due to the self-discharge rate. I've certainly had had remarkably poor results using NiMH in cameras etc., though more recently some of the own-brand hybrid chemistries (Maplins Hybrid) and Sanyo Eneloops have been a lot better and, in fact have even come close to meeting their advertised capacities and lifetimes.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Agreed.
-- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
They may take quite a LONG time to dismount if the network has dropped off ... :(
My Pi hangs somewhere around the "shutting down NFS ..." bits if I have NFS mounted, and do a shutdown when the network lead is pulled out.
I find a normal shut down is done in < 40 seconds, which is fortunate because I fire off a hardware "cut my power in 50 seconds" timer from the shutdown scripts, for going to runlevel 0.
-- --------------------------------------+------------------------------------ Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk
Yes to both - gel cells are a particular type of lead acid battery construction, although personally I tend to use the term slightly more loosely to mean any of the more convenient lead acid types - i.e. maintenance free, sealed, not fussy about orientation. For example most of the UPS "gel cells" around here are actually absorbed glass mat if I remember correctly.
As for charging, yes, they are fine on continuous float charge - a voltage source is all you need. It does pay to get the voltage set accurately though, and the ideal float voltage is temperature dependent, so a degree of compensation is advisable if the ambient temperature deviates noticeably from typical room temperature.
-- Andrew Smallshaw andrews@sdf.org
UBIFS /is/ a file system. The Flash used is quite relevant, as it determines the type of files systems that can be used. For example, it is not possible to run something like UBIFS on an SDcard, as UBIFS must do its own FTL (which is possibly its main advantage). The use of an SDcard also stops a journaling file system such as Ext4 from being reliable as it could be.
The particular embedded system I was thinking of was designed for reliability. There were two root filesystems, each on their own partition. The boot code could choose to boot from either. A cryptographic hash of every file was checked at boot time. The root FS was mounted readonly (except during software updates, which would only affect one root FS at a time). Config files were stored in their own RW partition, and all accesses relating to config changes were done by reliable atomic updates that took the Flash failure modes into account. All other files were in TMPFS in RAM.
This clearly wasn't a Raspberry Pi, but it also didn't have Raspberry Pi pricing :)
Regards, Allan
Of course the Raspberry Pi can do the same thing, it is just a matter of software and the designers chose to not go through this for the default Linux system. Anyone can decide to write a system more like what you wrote, and I think it has been done.
(I have read about Raspberries running from a read-only root filesystem with all R/W in RAM or on some other device like a USB stick, that are supposed to be much more resistant against sudden power drops)
The design aims of the filing system are important here: UNIX/Linux systems are designed to maximise i/o speed, hence the extensive buffering and lazy write-back -the latter being why Raspbian is particularly susceptible to filing system corruption if the power is killed or the SD card is yanked out of a running system.
OTOH, many dedicated real-time systems are optimised for file system integrity and treat disk i/o performance as secondary to integrity. As a result, the disk buffers may be no bigger than one sector per open file and the sequence of operations when a new block is being appended to a file will be modified to suit, i.e. the new block is written *before* the file's pointers etc are modified to add the block to the file. This should make the FS relatively impervious to damage if its is on an SD card, but may shorten the card's life by comparison with Raspbian usage because it would tend to do more physical writes than a massively buffered FS would need.
I guessed that UBIFS was a real-time optimised FS, but a quick search says that it is flash-optimised and does write caching. From the description this is just enough to let a sequentially written file block fill before being flushed to the flash device.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
You can easily tune this behaviour of Linux! For example, you can pass the sync option to the filesystem mount. Or you can tune the buffer writeback policy.
The performance loss of doing this is dramatic. I once noticed that XBMC had mounted the boot partition sync in an attempt to reduce the chance of corruption during a kernel update. The result was that the kernel updates took so long that even more corruption occurred because people were "impatient" (= not prepared to wat 15 minutes for the update to complete) and powercycled the Pi halfway through the update.
It also increased the frequency of write errors, probably because SD cards write in much larger pages than the FS block size so the number of card writes increased dramatically.
That's not altogether surprising, seeing that its effectively turning off most of the extn go-faster features. I once noticed that
That does surprise me somewhat. There is, of course, an alternative - try replacing ext2/3 with UBIFS for flash storage. It would be interesting to see what the speed difference is between ext2/3 running in degraded mode and UBIFS running as its is designed to be run.
BTW, when I mentioned real-time systems I was thinking about Microware's OS-9, whose standard disk filing system which worked exactly as I described. Despite being a conventional UNIX-like directory + file structure it was almost incorruptable, even in the face of power failures. My system was run off a portable 3kw generator in the middle of a field quite a lot over the years and, in addition, there were inevitable software crashes during development because everything was written in C and all processes ran in a single address space, but I don't recall any disk corruption from these unexpected stoppages over the 20 years or so I used it (1992-2012): the only disk errors I can remember were due to failing disk drives. IOW, if you set out to write a bullet- proof disk filing subsystem its possible to get quite close to the ideal
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
It probably would be similarly affected when SD cards would have been used as storage instead of floppy- or harddisk drives.
The problem with flash storage is the large page size. When a flash write transaction is interrupted in the middle, the area being corrupted is not necessarily limited to the block being written. This renders the normal journalling aspects of a filesystem inoperative.
Yes, that is going to affect almost all disk filing systems that get ported to flash. All have smallish blocks (256B for OS-9's rbsh filing system and 256 or 512 for virtually everything else I can think of) while IIRC the native block size for flash is nearer 4KB.
But, that's not the main flash gotcha because a single page failure will probably only screw up a few files. What stuffs it completely is when its interrupted during the block shuffling and remapping that happens during wear levelling. And unfortunately there's nothing an OS-level filing system can do to guard against failures during that because it all happens at a lower level thats controlled by the flash array's own firmware where its invisible to the OS.
About all we can do is try to make sure that the flash memory isn't removed and the power isn't turned off while the OS is booted up and running.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
On 12 Mar 2016 21:49:00 GMT, Rob declaimed the following:
The flash controller inside the SD card probably contributes massively to this. Cheaper controllers may only keep two streams ("allocation units" per
Using a card that can maintain, say, 6 active streams would reduce the rewrite/erase cycles as it can do internal updates to journals/data/inodes/what-have-you before having to flush them to the physical memory of the card
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
No experience of this, but what would be the implications of maintaining the supply to the card via (say) a supercap while shutting down all external I/O?
I will admit I don't have a clue how data is transferred - I would assume some form of serial interface.
-- W J G
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.