Being that we do pulsar research here at PARI, I'll comment on this timing thing. Some pulsars are quite regular; most however do have what are known as 'glitches' and in the case of the Crab pulsar 'giant pulses'; both of these phenomena are unpredictable and skew any timing you might receive from the pulsar. Also, pulsar timing requires some fairly extensive integration of the incoming pulses, as most pulsars miss 'beats' frequently, and pulses vary somewhat in terms of amplitude. Some pulsars exhibit odd phasing effects as well.
Also, pulses have to be dedispersed, which is somewhat complicated to do in real-time, especially in the ideal frequency range for observations (we observe in the 300-350MHz range, with our best sensistivity occurring in the 327 window); the larger the dispersion measure (DM) the more complicated dedispersion becomes. This dispersion makes the initial impulse signal become a chirp signal, and it needs to be 'dechirped'. This makes it difficult to find the instant of the pulse arrival, as it is 'smeared' not a hard edge.
Pulsars are almost uniformly weak sources; with our 26 meter (85 feet) dishes they are still a challenge to receive at 327MHz; and they get weaker as the frequency goes up. Although the difficulty of dedispersing the pulse becomes easier as frequency rises.
We use several pieces of equipment to receive pulsars: RFspace's SDR14 with gating modification is one, and the GNUradio project's USRP is another. We have a specialized receiver that uses analog filter banks to do the dedispersion, but it is not currently in operation.
The most accurate timing soures commercially available that I know of are hydrogen masers; the timing from them easily exceeds the accuracy of pulsar timing. Cesium and Rubidium, along with ovenized quartz, are increasingly inaccurate, but if a pulsar can be accurately timed and the timing fluctuations of the pulsar measured by a source as inaccurate as a Rubidium standard, then the Rubidium standard is more accurate than the pulsar as to timing. That is, in order of accuracy: hydrogen>cesium>rubidium>oven-quartz; the pulsar accuracy is typically between the quartz and the rubidium.
If you are looking for position information (as Global Positioning System implies) triangulation upon several sources (you mentioned four) in the sky is doable; however, at radio frequencies these are not point sources; at 327MHz, for instance, an 85 foot parabolic dish has a 3dB beamwidth of about 2.4 degrees of arc; this is too wide to use for accurate positioning. The common and bright 1420 spectral sources are likewise gas clouds; much continuum radiation isn't from point sources. You will not be able to recieve pulsars with anything but a highly directional antenna; they are just too weak. Of course, in a spacecraft it is easy getting the cold temperatures to cool a low noise amplifier down to get the noise figure where you need it to be; I would question if the Johnson noise in available LNA devices would be low enough even then to make receiving a pulsar (even the brightest) with an omnidirectional antenna possible.
Now, terrestrial observations of pulsars get doppler effects due to the earth's revolution around the sun (also due to rotation, but the diurnal doppler swamps out the daily doppler) that depend upon your location on the earth; to determine position from the observed pulsar's timing would require you to do the local standard of rest calculation backwards, yielding time and location from the variance in pulsar timing and sky location. While this might be possible if you have four pulsars being timed, it would be rather difficult. Timing a single pulsar will not help you, as that is insufficient information to solve for time and location by calculating the local standard of rest in reverse. (that is, you take the measured pulsar period of several (but not too many) pulses, integrate, compare to theoretical yielding the measured doppler, then reverse the doppler calculation ordinarily yielded by the L
According to that Wikipedia article, the most recent ANSI COBOL standard is from 2002. Doesn't sound like a dead language. Hm, the 2002 standard includes OOP and other modern features.
They have. It's called Fortran95, and the GNU Compiler Collection supports it: $ gfortran --version GNU Fortran 95 (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) Copyright (C) 2006 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
This is from a Fedora 6 installation.
I have a bunch (37MB) of highly specialized FORTRAN code out here; there are a number of scientific packages that still use FORTRAN code, because is works and the syntax for FORmula TRANslation is very simple and clean.
You can even do CGI with FORTRAN. (Yes, you can: go to the fcc.gov website and search for FORTRAN).
Code should not be modernized just for the sake of modernization, particularly when the language is not dead (and FORTRAN is not by any stretch dead). The heir apparent for FORTRAN would be Matlab (OSS equivalent is Octave).
With proper design in the decimator, a sigma-delta technique could be used to synthesize extra bits digitally during decimation. This is fairly common; that's how modern CD players get away with 1 bit digital to analog converters, by vastly oversampling and using sigma-delta techniques (along with other; I have the references, but they're at work, and I'm at home). Analog Device's mixed signal handbook lists a few of these techniques. So it is possible, after decimation and digital processing, to synthesize a 16 bit conversion from a 12 bit converter, as long as you vastly oversample the 12 bit converter.
Incidentally, the effective limit is 24 bits; beyond 24 bits at standard +4dBu levels the least significant bit's voltage is below the Johnson noise at room temperature over the audio bandpass; see the Johnson-Nyquist page at wikipedia for an overview.
GNUradio, both in the software and hardware side, is designed to be an experimenter's kit and test equipment. I'm working on using one of mine as a time-domain reflectometer; another use is as a vector network analyzer; it's just a programmable signal generator and detector set with four channels. You can get various RF modules just like with, say, a piece of Agilent test gear. You could take a programmable signal generator with an external modulation input and do the same.
I use mine all the time as a tunable oscilloscope, spectrum analyzer, and signal generator for testing.
That is, after all, what the USRP is sold as.
The beauty is that once you have the Universal Software Radio Peripheral hooked up, you can plumb the software modules (they are actually called 'blocks' in GNUradio-parlance) to make any sort of processing chain you'd like. It is a beautiful and workable design.
Certainly all things have limitations. But, catch this: 1.) The hardware design (schematics, layouts, etc) are OPEN; 2.) The FPGA Verilog code is OPEN; 3.) The software is GPL.
As to the computational power of the CPU, I'm thinking an FPGA coprocessor could be used to great effect; something like a DRC coprocessor in a socket 940 (Opteron socket): see http://www.drccomputer.com/pages/modules.html for details. Run the correlation and other functions in the FPGA and offload the grunt work of the algorithm to the hardware logic you blow into the FPGA.
In my own experience, a continuum analysis (power spectrum integration using cascaded FIR filters) and a simultaneous FFT can run with 65% of a 3GHz Xeon, with all the X11 overhead taking 50% of a second 3GHz Xeon. The hard part is sustaining continuous 32MB/s writes over a period of hours (I have a Dell 2850 here with hardware RAID that can do 150MB/s writes in theory; in practice even that can skip samples). And that is using the GNUradio Python framework; tuned C would likely be less taxing on the CPU.
In contrast, we are working on other projects that are running an order or two of magnitude higher sample rates; one with be sampling 12 channels at 1.5GS/s 8 bits and performing a correlation for probing the interstellar medium using compact extragalactic sources at 2.1 and 8.5GHz. That will require the equivalent of an 800GHz Xeon; only hardware FPGA correlation is anywhere close to fast enough, and even then we're talking $10K high end Xilinx Virtex 4's.
Coprocessing FPGA's are basically required for real-time processing of this sort.
The Right Software: The GNUradio stack. The Right Duaghterboards: The USRP is outfitted with two Analog Devices AS9862 MxFE chips, each possessing two 64MS/s 12 bit ADC's, two 128MS/s 14 bit DAC's, and assorted auxiliary ADC's and DAC's for things like AGC.
The daughterboards themselves are just RF frontends. The DBS_RX, for instance, uses a Maxim satellite receiver chip that quadrature downconverts from the RF directly to plus and minus baseband. One MxFE can do quadrature, and is a good match to the single RF input I/Q output DBS_RX board to 900-2400MHz receive.
The USRP gets this 64MS/s bitstream munged down to a manageable size by use of an Altera Cyclone FPGA, which, using CIC and half-band filters implemented with CORDIC, bitmashes things down to a rate that will fit over the USB 2.0 High-speed interface.
I have two of these personally. At PARI we have four of them. They work. And work well, for radio astronomy.
As to capturing the entire FM band at one fell swoop, I know for a fact that the USRP and a good USB 2.0 High-Speed host can sustain 32MB/s transfers. This becomes an actual sampling rate of 8MS/s in quadrature, which means a full 8MHz band can be sampled at 12 bit precision. The FM band is 107.9-87.9=10MHz wide. At 12 bits, no, you can't get the whole band in. However, the USRP can go 16MS/s at 8 bits (again, in quadrature, which effectively doubles the sample rate), and consume 32MB/s across the USB. Since FM (frequency modulation) doesn't require large dynamic range in terms of bit depth, it is possible that you could get nearly full fidelity audio out of all FM channels simultaneously: but you would need one big honking PC to demodulate in real-time.
As I am a licensed Amateur, I can use this as a transmitter, in the bands and with the modulations to which my license class is allowed. I have the 400-500MHz transciever board; I am of course limited to the 70cm Ham band for transmission, and I of course honor that. It works quite well.
For radio astronomy, I have the DBS_RX board, and it directly tunes several radio astronomy bands, including the Hydrogen line at 1.42GHz. It works quite well for both continuum and spectrum studies, although I still have some bugs (with considerable help for the GNUradio project and other programmers) to work out.
Use an FPGA, such as a Xilinx Virtex Pro, instead of a CPU. It is slower, but open. Xilinx VP2's even have twin embedded PowerPC 405 cores, and Linux is the preferred OS for them.
Yes, they are more expensive. But if volume goes up, Xilinx will make more, and the price can go down.
With the FPGA you can really get control of what's going on.
And this is different from SRC's MAP processors how? Other than the fact that the MAPstation and MAPserver's (running Linux) aren't vapor and have very nice C to HDL compilation tools already bundled. Although they're not cheap.
As to a scholar being president; been there, done that. Got a World War out of it (I know that's a broad sweeping generalization, but, since Everything That Happens During a President's Term is His Fault (TM)....). Woodrow Wilson.
This is not the first time Red Hat has changed PostgreSQL versions in minor releases, so it does have a precedent. (5.0 - PG 6.2.1 -> 5.1 - PG 6.3.2 : 6.0 - PG 6.4.2 -> 6.1 - PG 6.5.2 : 7.1 - PG 7.0.3 -> 7.2 - PG 7.1.3 -> 7.3 - PG 7.2.1 -- two changes in the 7.x cycle!). So this is par for the course.
And this migration (from 7.2 to 7.3) is the most hairy one yet.
I say that being the RPM maintainer for the PostgreSQL Global Development Group. I have been battling this upgradeability situation for over three years now. It isn't pleasant.
Online backup for PostgreSQL has worked since version 6.5, thanks to MVCC. You do not need to take the database down anymore to pull a consistent pg_dumpall snapshot.
However, I have to look at it the same way -- just like I wouldn't judge MySQL by one site, I won't judge the ACS by one site. Nor will I judge AOLserver by one site.
However, when AOL is pumping 28 thousand hits per second out to the net through AOLserver, I _do_ have to sit up and take notice.
Oh, I've run AOLserver for nearly three years on my Linux box -- and it runs smooth as silk. Very easy to develop dynamic pages in, very scalable, and wicked fast.
If you've already narrowed the field down to the two, nothing I say or do is going to turn your mind from that.
So, let's look at the pros and cons:
Oracle: Pro: This is THE RDBMS. Really. There is no RDBMS better than Oracle. Period.
Con: Expensive, like any other commercial RDBMS.
PostgreSQL: Pro: Open Source. Pro: Widely respected -- only Oracle has a more experienced codebase. Pro: Actively supported. Pro: Free. Pro: In the words of Philip Greenspun, who is an unabashed Oracle fan: "> The open source purist's only realistic choice for an RDBMS > is PostgreSQL (see Resources for the URL). In some ways, > PostgreSQL has more advanced features than any commercial > RDBMS. Most important, the loosely organized, unpaid > developers of PostgreSQL were able to convert to an > Oracle-style multiversion concurrency system (see below), > leaving all the rest of the commercial competition > deadlocked in the dust. If you've decided to accept John > Ousterhout as your personal savior, you'll be delighted > to learn that you can run Tcl procedures inside the > PostgreSQL database. And if your business can't live without > commercial support for your RDBMS, you can buy it > (see Resources for a link). (From a LinuxWorld article on AOLserver)
Cons: not as SQL92 or SQL3 compliant as Oracle Con: no referential integrity (yet) Con: absence of outer joins (right now) Con: recovery is not quite there (look for the next version...)
PostgreSQL whips up on MySQL once the word 'transaction' enters the picture.
PostgreSQL's multiversion concurrency control (MVCC) insures that even in the presence of multiple concurrent transactions there can be no deadlock. With large databases, processing large inserts, the deadlock issue is a very real one.
And, most importantly, unlike many other so-called RDBMS's, PostgreSQL passes the RDBMS ACID test.
Natural selection, the theory, holds that mutations occur by random chance, and that useful mutations are kept by natural selection -- ie, a mutation that doesn't result in an advantage dies out.
In the web, there are many thinking persons behind both the sites and the surfers -- it is not by random chance, nor is it driven by survival of the fittest -- it's survival of the smartest, and the richest, which are not accidental occurances.
No, the web was created (In the beginning DARPA created the ARPANET. And the ARPANET was without form, and void, and darkness was upon the face of the deep. And many hackers moved upon the face of the packets. And Marc said, let there be graphics, and there were graphics. And the hackers saw the graphics, that they were good, and they called the graphics "the Web", and the rest they called e-mail and ftp......) Finish the analogy.
Throughout the web's development, it has been guided by intelligence -- not chance.
I have yet to find an application where the two-pronged attack of AOLserver-tcl plus PostgreSQL's extended subset of SQL-92 could not handle.
One of the applications I am working on is an online broadcast AM radio station pattern plotter and coverage predictor, with output in JPEG or DXF format. Of course, PostgreSQL includes GIS features that facilitate this, but, I have yet to have to dig into any other language to perform the work. TCL has a hard time with numerics -- but PostgreSQL doesn't.
Oh well...
Ykybhtlw you grok the meaning of YMMV without expanding the abbreviation.
Frankly, I think that perl is overkill for web work. Why do you need it?
TCL, on the other hand, is a minimalist scripting language that I find very easy to use -- and -- much more importantly -- easy to get it to DO The Right Thing!
And I say that knowing that Z80 machine language (not assembler -- hexadecimal machine language) was my first programming language. Want to see a Z80 joke? 0000: 01 FF FF 11 01 00 21 00 00 ED B0 !
The point is that TCL is an ideal language -- with the AOLserver extensions, mind you -- to do web work in. Web pages are strings; EVERYTHING in TCL is a string. I can write a TCL procedure to do most any task (such as return a full outer join of four tables in my RDBMS) in about five minutes that is likely to be bug-free on the first run. No extra modules to load, no need to specify DBD this and DBI that. Just a few ns_db procedure calls, an ns_return to send the content down the connection, and you're done. Simple, sweet, and easy to work with.
You can then take you procedure and embed it as a string in AOLserver Dynamic Pages (adp's). After all, everything is a string (including procedures).
Gotta love it.
I say all of this with the utmost respect for Larry wall and the perl community -- perl is an ideal sysadmin language (I use it in that role) -- but it is not the best web scripting language, IMHO.
AOLserver, is, to put it bluntly, the best web server on the planet, bar none.
AOL liked it so much, they bought the company that made it, Navisoft. This is the commercial Naviserver -- the very first multithreaded webserver. Go to www.aolserver.com and take a gander.
Features: - Multithreaded for speed - Persistent, pooled database connections for efficiency - Multithreaded tcl extension scripting language that is by far the best way to put out dynamic content -- it beats perl hands-down performance-wise, as well as development-wise - Tightly integrated RDBMS functions - Wear-tested on one of the busiest sites on the Internet -- aol.com - Available for Linux - Soon to be Open Source - Regular tcl API -- as well as a C API, dynamic module loading, etc - highly scalable -- while being lightweight. - Runs circles around CGI for dynamic content when using the TCL API. - Can run any CGI package - Designed for performance -- a Pentium 90 can saturate a 10Mbps Ethernet with dynamic content - Easy configuration and remote administration -- versions through 2.3.3 by a Web-based interface; version 3 by a telnet control port, which will be spiffy.
Oh, just go to the website -- they do a much better explanation.
IMHO, TCL is a much easier language to use for Web scripting -- and I do mean scripting, as opposed to programming -- than perl ever will be. I picked it up in a dozen hours, and was writing highly usable code in two days. It is the basis of our company-wide intranet.
I'll just put it this way -- it works, it's fast, it's lean, and it's mean. And I have a dozen or so intranet applications -- none of which required more than a dozen pages of tcl code.
Also, you have the outstanding ARSDIGITA community system available -- which has to be seen to be believed. It's not flashy -- but it works so solidly that the ARSDIGITA team makes sizable incomes from it.
This is far and away the most useful book I have ever read on the subject of web publishing.
I have used Philip Greenspun's advice, code, and bits and pieces of information for over two years, now. His diatribes were the deciding factors in my decision to base my webserver on AOLserver; and for my decision to back the mighty AOLserver with the equally mighty PostgreSQL (well, 6.1 wasn't really mighty.....;-( but 6.5 is...) I have not regretted my decision.
Philg's book is right on the money. He skips the fluff -- and gives you the stuff.
I do wish the nudes were not present, as I would love to trumpet from the highest hill my recommendation to all -- which I can't, even though the nudes were very tastefully done (none are frontal, BTW.). Oh well, I've pasted over the nudes on my personal copy, so that if anyone comes in my office and picks it up, they won't be offended (my office is in a church.....). Of course it's a free country -- he is as free to publish those pics as I am to paste over them.
It is nice to see Philip's hard work receive some accolades by this site.
And, the book is available for free online -- but, let me tell you, the hardcopy is worth the cost.
My heartfelt thanks to Philip -- and to Slashdot; even though I don't always agree with either.
Well, I guess the winner will probably be a TRS-80 somewhere, as it was the first real personal computer available (I know, I know, the Apple I was available -- but does a bare board really qualify?)
In fact, does any kit computer qualify? Dell really blew it when they didn't define "PC" in the rules.
In any case, if you are the lucky winner with the TRS-80 model I AND proof of purchase (I once owned TRS-80 serial number 0000002 -- gone now), you can get your Dell PC's loaded with Linux and run Tim Mann's excellent xtrs emulator under X -- it will perfectly emulate a TRS-80 model I running in the neighborhood of 50MHz on a P200. So, emulators DO have a good use!
On the topic of installation, I had opportunity to install Mandrake 5.3 (RedHat-5.2-based) on this Toshiba Satellite 225CDS notebook on a virgin hard drive.
From sliding in the CD to finished product was about 30 minutes -- and it was considerably easier than the Win95 installation for this machine!
Whereas the Windows 95 installation required DOS-mode card services for my two PCMCIA cards (Ethernet and modem), the Mandrake installation Did The Right Thing -- this is by far the smoothest install of any operating system I have ever installed -- and I have installed plenty, from Novell NetWare 2.15 to MS-DOS to Win3.11/95/98 to other far more esoteric systems.
I simply picked "workstation" installation, and away it went. No boot floppies, no fuss about PCMCIA, no fuss about the nonexistent floppy -- no fuss at all. The Win 95 installation requires the manufacturers' disks for the PCMCIA cards -- the Mandrake installation Did The Right Thing and loaded the appropriate modules automagically. All I had to do was configure the networking interface (which, with Linuxconf, is a snap), and I was back up.
The Win 95 installation required fdisking and formatting the hard drive from floppy (can't boot from CD!) Win 98 can boot from CD -- but still requires me to swap in the floppy to get the PC-card drivers! Mandrake booted from the CD smooth as silk.
The only fly in the ointment was the poor quality of the XFree86 display, but that is a Cirrus Logic problem.
Slashdot Mirror
Being that we do pulsar research here at PARI, I'll comment on this timing thing. Some pulsars are quite regular; most however do have what are known as 'glitches' and in the case of the Crab pulsar 'giant pulses'; both of these phenomena are unpredictable and skew any timing you might receive from the pulsar. Also, pulsar timing requires some fairly extensive integration of the incoming pulses, as most pulsars miss 'beats' frequently, and pulses vary somewhat in terms of amplitude. Some pulsars exhibit odd phasing effects as well.
Also, pulses have to be dedispersed, which is somewhat complicated to do in real-time, especially in the ideal frequency range for observations (we observe in the 300-350MHz range, with our best sensistivity occurring in the 327 window); the larger the dispersion measure (DM) the more complicated dedispersion becomes. This dispersion makes the initial impulse signal become a chirp signal, and it needs to be 'dechirped'. This makes it difficult to find the instant of the pulse arrival, as it is 'smeared' not a hard edge.
Pulsars are almost uniformly weak sources; with our 26 meter (85 feet) dishes they are still a challenge to receive at 327MHz; and they get weaker as the frequency goes up. Although the difficulty of dedispersing the pulse becomes easier as frequency rises.
We use several pieces of equipment to receive pulsars: RFspace's SDR14 with gating modification is one, and the GNUradio project's USRP is another. We have a specialized receiver that uses analog filter banks to do the dedispersion, but it is not currently in operation.
The most accurate timing soures commercially available that I know of are hydrogen masers; the timing from them easily exceeds the accuracy of pulsar timing. Cesium and Rubidium, along with ovenized quartz, are increasingly inaccurate, but if a pulsar can be accurately timed and the timing fluctuations of the pulsar measured by a source as inaccurate as a Rubidium standard, then the Rubidium standard is more accurate than the pulsar as to timing. That is, in order of accuracy: hydrogen>cesium>rubidium>oven-quartz; the pulsar accuracy is typically between the quartz and the rubidium.
If you are looking for position information (as Global Positioning System implies) triangulation upon several sources (you mentioned four) in the sky is doable; however, at radio frequencies these are not point sources; at 327MHz, for instance, an 85 foot parabolic dish has a 3dB beamwidth of about 2.4 degrees of arc; this is too wide to use for accurate positioning. The common and bright 1420 spectral sources are likewise gas clouds; much continuum radiation isn't from point sources. You will not be able to recieve pulsars with anything but a highly directional antenna; they are just too weak. Of course, in a spacecraft it is easy getting the cold temperatures to cool a low noise amplifier down to get the noise figure where you need it to be; I would question if the Johnson noise in available LNA devices would be low enough even then to make receiving a pulsar (even the brightest) with an omnidirectional antenna possible.
Now, terrestrial observations of pulsars get doppler effects due to the earth's revolution around the sun (also due to rotation, but the diurnal doppler swamps out the daily doppler) that depend upon your location on the earth; to determine position from the observed pulsar's timing would require you to do the local standard of rest calculation backwards, yielding time and location from the variance in pulsar timing and sky location. While this might be possible if you have four pulsars being timed, it would be rather difficult. Timing a single pulsar will not help you, as that is insufficient information to solve for time and location by calculating the local standard of rest in reverse. (that is, you take the measured pulsar period of several (but not too many) pulses, integrate, compare to theoretical yielding the measured doppler, then reverse the doppler calculation ordinarily yielded by the L
According to that Wikipedia article, the most recent ANSI COBOL standard is from 2002. Doesn't sound like a dead language. Hm, the 2002 standard includes OOP and other modern features.
They have. It's called Fortran95, and the GNU Compiler Collection supports it:
$ gfortran --version
GNU Fortran 95 (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
This is from a Fedora 6 installation.
I have a bunch (37MB) of highly specialized FORTRAN code out here; there are a number of scientific packages that still use FORTRAN code, because is works and the syntax for FORmula TRANslation is very simple and clean.
You can even do CGI with FORTRAN. (Yes, you can: go to the fcc.gov website and search for FORTRAN).
Code should not be modernized just for the sake of modernization, particularly when the language is not dead (and FORTRAN is not by any stretch dead). The heir apparent for FORTRAN would be Matlab (OSS equivalent is Octave).
Grab a CVS checkout of GNUradio (see http://www.gnu.org/software/gnuradio/ for the homepage, and http://cvs.savannah.gnu.org/viewcvs/gnuradio/ for the browseable CVS on GNU.ORG), and be sure to grab gr-radio-astronomy module.
With proper design in the decimator, a sigma-delta technique could be used to synthesize extra bits digitally during decimation. This is fairly common; that's how modern CD players get away with 1 bit digital to analog converters, by vastly oversampling and using sigma-delta techniques (along with other; I have the references, but they're at work, and I'm at home). Analog Device's mixed signal handbook lists a few of these techniques. So it is possible, after decimation and digital processing, to synthesize a 16 bit conversion from a 12 bit converter, as long as you vastly oversample the 12 bit converter.
Incidentally, the effective limit is 24 bits; beyond 24 bits at standard +4dBu levels the least significant bit's voltage is below the Johnson noise at room temperature over the audio bandpass; see the Johnson-Nyquist page at wikipedia for an overview.
GNUradio, both in the software and hardware side, is designed to be an experimenter's kit and test equipment. I'm working on using one of mine as a time-domain reflectometer; another use is as a vector network analyzer; it's just a programmable signal generator and detector set with four channels. You can get various RF modules just like with, say, a piece of Agilent test gear. You could take a programmable signal generator with an external modulation input and do the same.
I use mine all the time as a tunable oscilloscope, spectrum analyzer, and signal generator for testing.
That is, after all, what the USRP is sold as.
The beauty is that once you have the Universal Software Radio Peripheral hooked up, you can plumb the software modules (they are actually called 'blocks' in GNUradio-parlance) to make any sort of processing chain you'd like. It is a beautiful and workable design.
Certainly all things have limitations. But, catch this:
1.) The hardware design (schematics, layouts, etc) are OPEN;
2.) The FPGA Verilog code is OPEN;
3.) The software is GPL.
As to the computational power of the CPU, I'm thinking an FPGA coprocessor could be used to great effect; something like a DRC coprocessor in a socket 940 (Opteron socket): see http://www.drccomputer.com/pages/modules.html for details. Run the correlation and other functions in the FPGA and offload the grunt work of the algorithm to the hardware logic you blow into the FPGA.
In my own experience, a continuum analysis (power spectrum integration using cascaded FIR filters) and a simultaneous FFT can run with 65% of a 3GHz Xeon, with all the X11 overhead taking 50% of a second 3GHz Xeon. The hard part is sustaining continuous 32MB/s writes over a period of hours (I have a Dell 2850 here with hardware RAID that can do 150MB/s writes in theory; in practice even that can skip samples). And that is using the GNUradio Python framework; tuned C would likely be less taxing on the CPU.
In contrast, we are working on other projects that are running an order or two of magnitude higher sample rates; one with be sampling 12 channels at 1.5GS/s 8 bits and performing a correlation for probing the interstellar medium using compact extragalactic sources at 2.1 and 8.5GHz. That will require the equivalent of an 800GHz Xeon; only hardware FPGA correlation is anywhere close to fast enough, and even then we're talking $10K high end Xilinx Virtex 4's.
Coprocessing FPGA's are basically required for real-time processing of this sort.
The Right Software: The GNUradio stack.
The Right Duaghterboards: The USRP is outfitted with two Analog Devices AS9862 MxFE chips, each possessing two 64MS/s 12 bit ADC's, two 128MS/s 14 bit DAC's, and assorted auxiliary ADC's and DAC's for things like AGC.
The daughterboards themselves are just RF frontends. The DBS_RX, for instance, uses a Maxim satellite receiver chip that quadrature downconverts from the RF directly to plus and minus baseband. One MxFE can do quadrature, and is a good match to the single RF input I/Q output DBS_RX board to 900-2400MHz receive.
The USRP gets this 64MS/s bitstream munged down to a manageable size by use of an Altera Cyclone FPGA, which, using CIC and half-band filters implemented with CORDIC, bitmashes things down to a rate that will fit over the USB 2.0 High-speed interface.
I have two of these personally. At PARI we have four of them. They work. And work well, for radio astronomy.
As to capturing the entire FM band at one fell swoop, I know for a fact that the USRP and a good USB 2.0 High-Speed host can sustain 32MB/s transfers. This becomes an actual sampling rate of 8MS/s in quadrature, which means a full 8MHz band can be sampled at 12 bit precision. The FM band is 107.9-87.9=10MHz wide. At 12 bits, no, you can't get the whole band in. However, the USRP can go 16MS/s at 8 bits (again, in quadrature, which effectively doubles the sample rate), and consume 32MB/s across the USB. Since FM (frequency modulation) doesn't require large dynamic range in terms of bit depth, it is possible that you could get nearly full fidelity audio out of all FM channels simultaneously: but you would need one big honking PC to demodulate in real-time.
As I am a licensed Amateur, I can use this as a transmitter, in the bands and with the modulations to which my license class is allowed. I have the 400-500MHz transciever board; I am of course limited to the 70cm Ham band for transmission, and I of course honor that. It works quite well.
For radio astronomy, I have the DBS_RX board, and it directly tunes several radio astronomy bands, including the Hydrogen line at 1.42GHz. It works quite well for both continuum and spectrum studies, although I still have some bugs (with considerable help for the GNUradio project and other programmers) to work out.
Use an FPGA, such as a Xilinx Virtex Pro, instead of a CPU. It is slower, but open. Xilinx VP2's even have twin embedded PowerPC 405 cores, and Linux is the preferred OS for them.
Yes, they are more expensive. But if volume goes up, Xilinx will make more, and the price can go down.
With the FPGA you can really get control of what's going on.
And this is different from SRC's MAP processors how? Other than the fact that the MAPstation and MAPserver's (running Linux) aren't vapor and have very nice C to HDL compilation tools already bundled. Although they're not cheap.
www.srccomputers.com
Science is a religion.
As to a scholar being president; been there, done that. Got a World War out of it (I know that's a broad sweeping generalization, but, since Everything That Happens During a President's Term is His Fault (TM)....). Woodrow Wilson.
Regarding PostgreSQL 7.3
This is not the first time Red Hat has changed PostgreSQL versions in minor releases, so it does have a precedent. (5.0 - PG 6.2.1 -> 5.1 - PG 6.3.2 : 6.0 - PG 6.4.2 -> 6.1 - PG 6.5.2 : 7.1 - PG 7.0.3 -> 7.2 - PG 7.1.3 -> 7.3 - PG 7.2.1 -- two changes in the 7.x cycle!). So this is par for the course.
And this migration (from 7.2 to 7.3) is the most hairy one yet.
I say that being the RPM maintainer for the PostgreSQL Global Development Group. I have been battling this upgradeability situation for over three years now. It isn't pleasant.
--
Lamar Owen
Online backup for PostgreSQL has worked since version 6.5, thanks to MVCC. You do not need to take the database down anymore to pull a consistent pg_dumpall snapshot.
And Berkley DB has _what_ license? :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
I'm not the previous Anonymous Coward.
However, I have to look at it the same way -- just like I wouldn't judge MySQL by one site, I won't judge the ACS by one site. Nor will I judge AOLserver by one site.
However, when AOL is pumping 28 thousand hits per second out to the net through AOLserver, I _do_ have to sit up and take notice.
Oh, I've run AOLserver for nearly three years on my Linux box -- and it runs smooth as silk. Very easy to develop dynamic pages in, very scalable, and wicked fast.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
If you've already narrowed the field down to the two, nothing I say or do is going to turn your mind from that.
So, let's look at the pros and cons:
Oracle:
Pro: This is THE RDBMS. Really. There is no RDBMS better than Oracle. Period.
Con: Expensive, like any other commercial RDBMS.
PostgreSQL:
Pro: Open Source.
Pro: Widely respected -- only Oracle has a more experienced codebase.
Pro: Actively supported.
Pro: Free.
Pro: In the words of Philip Greenspun, who is an unabashed Oracle fan:
"> The open source purist's only realistic choice for an RDBMS
> is PostgreSQL (see Resources for the URL). In some ways,
> PostgreSQL has more advanced features than any commercial
> RDBMS. Most important, the loosely organized, unpaid
> developers of PostgreSQL were able to convert to an
> Oracle-style multiversion concurrency system (see below),
> leaving all the rest of the commercial competition
> deadlocked in the dust. If you've decided to accept John
> Ousterhout as your personal savior, you'll be delighted
> to learn that you can run Tcl procedures inside the
> PostgreSQL database. And if your business can't live without
> commercial support for your RDBMS, you can buy it
> (see Resources for a link). (From a LinuxWorld article on AOLserver)
Cons: not as SQL92 or SQL3 compliant as Oracle
Con: no referential integrity (yet)
Con: absence of outer joins (right now)
Con: recovery is not quite there (look for the next version...)
PostgreSQL whips up on MySQL once the word 'transaction' enters the picture.
PostgreSQL's multiversion concurrency control (MVCC) insures that even in the presence of multiple concurrent transactions there can be no deadlock. With large databases, processing large inserts, the deadlock issue is a very real one.
And, most importantly, unlike many other so-called RDBMS's, PostgreSQL passes the RDBMS ACID test.
Lamar Owen
Natural selection, the theory, holds that mutations occur by random chance, and that useful mutations are kept by natural selection -- ie, a mutation that doesn't result in an advantage dies out.
In the web, there are many thinking persons behind both the sites and the surfers -- it is not by random chance, nor is it driven by survival of the fittest -- it's survival of the smartest, and the richest, which are not accidental occurances.
No, the web was created (In the beginning DARPA created the ARPANET. And the ARPANET was without form, and void, and darkness was upon the face of the deep. And many hackers moved upon the face of the packets. And Marc said, let there be graphics, and there were graphics. And the hackers saw the graphics, that they were good, and they called the graphics "the Web", and the rest they called e-mail and ftp......) Finish the analogy.
Throughout the web's development, it has been guided by intelligence -- not chance.
Lamar Owen
WGCR Internet Radio
I have yet to find an application where the two-pronged attack of AOLserver-tcl plus PostgreSQL's extended subset of SQL-92 could not handle.
One of the applications I am working on is an online broadcast AM radio station pattern plotter and coverage predictor, with output in JPEG or DXF format. Of course, PostgreSQL includes GIS features that facilitate this, but, I have yet to have to dig into any other language to perform the work. TCL has a hard time with numerics -- but PostgreSQL doesn't.
Oh well...
Ykybhtlw you grok the meaning of YMMV without expanding the abbreviation.
Yow!
Lamar Owen
Two words:
CONCURRENCY CONTROL
'nuff said -- Philip says it best in his db chapter of his book.
Lamar Owen
Frankly, I think that perl is overkill for web work. Why do you need it?
TCL, on the other hand, is a minimalist scripting language that I find very easy to use -- and -- much more importantly -- easy to get it to DO The Right Thing!
And I say that knowing that Z80 machine language (not assembler -- hexadecimal machine language) was my first programming language. Want to see a Z80 joke? 0000: 01 FF FF 11 01 00 21 00 00 ED B0 !
The point is that TCL is an ideal language -- with the AOLserver extensions, mind you -- to do web work in. Web pages are strings; EVERYTHING in TCL is a string. I can write a TCL procedure to do most any task (such as return a full outer join of four tables in my RDBMS) in about five minutes that is likely to be bug-free on the first run. No extra modules to load, no need to specify DBD this and DBI that. Just a few ns_db procedure calls, an ns_return to send the content down the connection, and you're done. Simple, sweet, and easy to work with.
You can then take you procedure and embed it as a string in AOLserver Dynamic Pages (adp's). After all, everything is a string (including procedures).
Gotta love it.
I say all of this with the utmost respect for Larry wall and the perl community -- perl is an ideal sysadmin language (I use it in that role) -- but it is not the best web scripting language, IMHO.
Lamar Owen
AOLserver, is, to put it bluntly, the best web server on the planet, bar none.
AOL liked it so much, they bought the company that made it, Navisoft. This is the commercial Naviserver -- the very first multithreaded webserver. Go to www.aolserver.com and take a gander.
Features:
- Multithreaded for speed
- Persistent, pooled database connections for efficiency
- Multithreaded tcl extension scripting language that is by far the best way to put out dynamic content -- it beats perl hands-down performance-wise, as well as development-wise
- Tightly integrated RDBMS functions
- Wear-tested on one of the busiest sites on the Internet -- aol.com
- Available for Linux
- Soon to be Open Source
- Regular tcl API -- as well as a C API, dynamic module loading, etc
- highly scalable -- while being lightweight.
- Runs circles around CGI for dynamic content when using the TCL API.
- Can run any CGI package
- Designed for performance -- a Pentium 90 can saturate a 10Mbps Ethernet with dynamic content
- Easy configuration and remote administration -- versions through 2.3.3 by a Web-based interface; version 3 by a telnet control port, which will be spiffy.
Oh, just go to the website -- they do a much better explanation.
IMHO, TCL is a much easier language to use for Web scripting -- and I do mean scripting, as opposed to programming -- than perl ever will be. I picked it up in a dozen hours, and was writing highly usable code in two days. It is the basis of our company-wide intranet.
I'll just put it this way -- it works, it's fast, it's lean, and it's mean. And I have a dozen or so intranet applications -- none of which required more than a dozen pages of tcl code.
Also, you have the outstanding ARSDIGITA community system available -- which has to be seen to be believed. It's not flashy -- but it works so solidly that the ARSDIGITA team makes sizable incomes from it.
Lamar Owen
WGCR Internet Radio
This is far and away the most useful book I have ever read on the subject of web publishing.
I have used Philip Greenspun's advice, code, and bits and pieces of information for over two years, now. His diatribes were the deciding factors in my decision to base my webserver on AOLserver; and for my decision to back the mighty AOLserver with the equally mighty PostgreSQL (well, 6.1 wasn't really mighty.....;-( but 6.5 is...) I have not regretted my decision.
Philg's book is right on the money. He skips the fluff -- and gives you the stuff.
I do wish the nudes were not present, as I would love to trumpet from the highest hill my recommendation to all -- which I can't, even though the nudes were very tastefully done (none are frontal, BTW.). Oh well, I've pasted over the nudes on my personal copy, so that if anyone comes in my office and picks it up, they won't be offended (my office is in a church.....). Of course it's a free country -- he is as free to publish those pics as I am to paste over them.
It is nice to see Philip's hard work receive some accolades by this site.
And, the book is available for free online -- but, let me tell you, the hardcopy is worth the cost.
My heartfelt thanks to Philip -- and to Slashdot; even though I don't always agree with either.
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Well, I guess the winner will probably be a TRS-80 somewhere, as it was the first real personal computer available (I know, I know, the Apple I was available -- but does a bare board really qualify?)
In fact, does any kit computer qualify? Dell really blew it when they didn't define "PC" in the rules.
In any case, if you are the lucky winner with the TRS-80 model I AND proof of purchase (I once owned TRS-80 serial number 0000002 -- gone now), you can get your Dell PC's loaded with Linux and run Tim Mann's excellent xtrs emulator under X -- it will perfectly emulate a TRS-80 model I running in the neighborhood of 50MHz on a P200. So, emulators DO have a good use!
On the topic of installation, I had opportunity to install Mandrake 5.3 (RedHat-5.2-based) on this Toshiba Satellite 225CDS notebook on a virgin hard drive.
From sliding in the CD to finished product was about 30 minutes -- and it was considerably easier than the Win95 installation for this machine!
Whereas the Windows 95 installation required DOS-mode card services for my two PCMCIA cards (Ethernet and modem), the Mandrake installation Did The Right Thing -- this is by far the smoothest install of any operating system I have ever installed -- and I have installed plenty, from Novell NetWare 2.15 to MS-DOS to Win3.11/95/98 to other far more esoteric systems.
I simply picked "workstation" installation, and away it went. No boot floppies, no fuss about PCMCIA, no fuss about the nonexistent floppy -- no fuss at all. The Win 95 installation requires the manufacturers' disks for the PCMCIA cards -- the Mandrake installation Did The Right Thing and loaded the appropriate modules automagically. All I had to do was configure the networking interface (which, with Linuxconf, is a snap), and I was back up.
The Win 95 installation required fdisking and formatting the hard drive from floppy (can't boot from CD!) Win 98 can boot from CD -- but still requires me to swap in the floppy to get the PC-card drivers! Mandrake booted from the CD smooth as silk.
The only fly in the ointment was the poor quality of the XFree86 display, but that is a Cirrus Logic problem.