Highlander (HLD) Account closed
Registered: Dec 2018 Posts: 3 |
Quote: even then - you never want to do this. in hardware you always want to do small things in regular intervals, never one huge operation that has to happen "now".
What could work here would be to make the compression format actually be based on a vector of the magnetic phase change information for all tracks, i.e., indicating if a phase change occurs on each given track (or possibly half-track) at each time step. It probably wouldn't compress as well as doing it track-by-track, but I think it would solve the problems that have been raised, in particular, being insensitive to the current bit rate on a given track at a given point in time, and keeping all tracks in sync. It doesn't solve the question of how you acquire the image, but it should at least be implementable in an FPGA easily, and allow regular SD reads to feed it. For writeability, the compression would have to be carefully thought out, so that the compressed size is relatively constant, but the in-memory requirement for the whole disk would at least be solved, assuming you can write to the SD card fast enough, which might be a problem, since 6 complete revolutions per second x ~80 half tracks x ~1MHz sample rate = 480mbit/second (= ~60MiB/second!) raw. Since flux change rates are reasonably low, and limited over a given time period, it should be possible to reduce that figure by some reasonable factor. It might still be impractical. My feeling is that ~1MiB/sec would be required for practicality, which means ~60x compression being required. I'll have to think about the numbers more, as well as what the flux change density is etc, to see if it could be done. |