I think that many computer applications, and to some extent certain kind of programming, are a little too much like watching TV, and harm your brain rather than enhancing it. Of what's going on today, I think the Make-magazine stuff is probably the most exciting and most likely to provoke actual thought... Kids doing robotics is pretty close to what kids doing ham radio was when I was young. Below is a meandering story of how I got from a 5 year old ham to today, back into ham radio, and reading Slashdot too.
In kindergarten, I remember bringing electrician's hot-side testing screwdrivers to show-and-tell ("Now you just stick this screwdriver into the electric socket and the neon bulb will light if it's the hot side"), and rigging up telephone networks with old handsets and batteries. After having learned morse code at age 5 and gotten on the air under my father's call (he got his license in response to my interest), I finally learned enough to read the whole test and got my license at age 7. Now my kids are about the same age, and found learning morse code to be fun; they talk to each other, and recently had a poster accepted at a peer-reviewed conference, comparing speed and errors in Morse code and typing! (Ok, it was the 2nd grade science fair.)
Soon I got interested in computers, but there weren't any actual ones to distract me; well, there was one in town, and it used punched cards. It was a Honeywell Special 200, the first IBM Clone, though it was a clone of an IBM 1401... Then there were the PDP-8's that were connected to Stanford via phone line for one of the first "computer-aided instruction" projects. I met the guys who maintained the Model 28 teletypes for them and they got their ham licenses after my father and I got ours...
When two-meter FM became popular, I helped establish the first local repeater, probably the only one within 100 miles. We had to do HAAT testing and I learned about altimeters, topographic maps, and government forms... By the time I graduated from high school and went to MIT, I found other pursuits -- PDP-10's, Lisp, classes... I pretty much got off the air. But ham radio gave me an entre into an entire world that wasn't available when I was growing up.
After a few years spent exploring 4x5" photography, I started doing some wireless mobile device work, and poor signal strength led me to get up on the roof and install a 1.9Ghz repeater. I felt a strange familiar feeling, and when my wife said, "I don't care how many antennas you put on the roof," I filed the fact away. When a co-worker shows up with a Yaesu VX-2 two-meter and 70cm handitalki that receives DC-to-daylight and said it was $120, I went ahead and bought it. I'd kept my ham license renewed, and used it once or twice in the intervening 20 years, but I had to re-learn lots of stuff. I wore the HT on my belt (along with two calculators and a slide rule, a hiptop, and a blinking LED pen) for the Halloween party at PARC and won what can best be described as the five-sigma prize...
A bit of web surfing led me to QRZ.com, EHam.net, and of course ARRL, and I found out about a local club meeting taking place that night. So I went with the co-worker, and found a bunch of pleasant nerds, schoolteachers and librarians, firefighters, electronics designers, computer scientists, and other random people.
At the club meeting, a satellite communications engineer told me about recent developments in DSP-based communications that used a PC sound card to modulate and demodulate; my extensive 20-year stint in programming made me think this might be interesting, so I bought a
CSS is great. They should have done what they did just before the CSS switchover and used
CSS alternate stylesheets so the View/Page Style menu in Firefox and other CSS compliant browsers would let you see the stylesheets.
I filed a bug a while back that said that stories that are as yet unmoderated should express CSS classes. An alternate stylesheet offered only for moderators would let you switch to the moderator view of the world; it would be the same page, but the styling would emphasize comments that nobody had moderated or read yet.
Alternate stylesheets could have been used for the pink/green thing:
A lot of the middleware that converts data to HTML and back can go away when you use the right XML tools. XSLT does a good job of presenting static pages, and it can be fast if you cache the results as well.
But for dynamic pages (and forms) XML to XSLT to HTML leaves some big gaps:
The hierarchical XML data gets flattened out into name/value pairs in HTML form fields.
For the return trip HTML->?->XML, XSLT doesn't work; you can't run the transform backwards.
For dynamic pages, you're left with JavaScript or the dreaded "postback."
These are some of the reasons we updated the W3C HTML forms module to take account of XML data directly.
How does it fix the above problems?
The hierarchical XML data your PHP or other server-side code outputs is transmitted directly to the web browser, where it remains while the user futzes with only the nodes that the form specifies. The middleware that converts the XML data to web browser data is just printing the XML.
When the form results are submitted, they come back directly in XML, so there's no need to pick apart the name=value pairs and try to put them back into your data. The browser just posts the XML directly back as XML to your PHP or servlet.
For forms, as the data changes, the UI changes with it. If a node disappears, or appears, or if a value changes, entire sections of UI can appear and disapear just by listing a dependency on that data. And if you want dynamic pages, you can use the background submission feature to retrieve instance data asynchronously, and the presentation changes automatically.
Nice work if you can get it, you say? Well, as everyone knows Microsoft hasn't yet implemented XForms. (Heck, they haven't even implemented CSS, though we hear they do have it as a goal now.)
So what can you do today:
Use Mozilla or FireFox XForms 0.4.
It's a one-click install download from the Mozilla website.
Yes, it's beta. Yes it has bugs. Yes, IBM and others are fixing them. But it's open source.
Use FormFaces for most modern browsers (Firefox, IE, Safari, Opera)
FormFaces is a cool JavaScript/AJAX application that you import into your web page with a one-line include, and it does everything described above.
If you need cross-browser support right now, want dynamic AJAX forms, and want to interface to XML, this is your best bet, if you can tolerate a JavaScript program in your browser (i.e., it's done using AJAX). It's available under GPL and commercial licenses.
Use Chiba for backend processing
Chiba is an open source Java-based back-end that converts your XHTML+XForms page into either an AJAX page or a static HTML page (good for Sec 503 compliance).
Chiba is a great choice for applications that have a Java back end, as it puts less load on the browser than the large JavaScript engine of FormFaces, but I put it below FormFaces here because of the emphasis on PHP. (But, about half of Chiba is an XSLT transformation so a PHP port is possible.)
Use Formsplayer as an IE plugin
FormsPlayer is a deluxe XForms processor plug-in for intranet applications using Internet Explorer, and has lots of other features as well, such as sidebar support.
Why spend that much ($350+), when you can order a dirt-cheap shortwave radio for maybe $40 and just use a simple 455 kHz to 12 kHz adaptor?
SDR is a broad topic. Wide-band digital modes such as the 12KHz wide DRM or even narrow ones such as HamDream are a simple example.
SDR involves a variety of techniques, but the basic idea is using an A/D at an early stage, and performing operations traditionally done with RF components with DSP software instead.
In its extreme, an SDR has a broadband RF amplifier and a DSP.
Some systems use a tuned RF filter before the RF amplifier to improve dynamic range and reduce overload, and others put the DSP after the first analog mixer. Ham equipment that uses IF DSP does this, such as many of the ICOM radios.
Then there are devices that then mix down to somewhere around the audio range, at least to the 0-96KHz or 0-48KHz range handled by many popular PC sound cards. The RF signal is detected by a an I-Q detector, which produces two signals In Phase and Quadrature (90 degrees out of phase). You might notice that this is a decomposition of a periodic wave into real and complex parts, given v=cos(omega)+j sin(omega). Thus, DSP techniques such as FFT can be applied in the complex domain. If you're seriously interested in this math, look up the Hilbert transform. It lets you modulate or demodulate directly in the DSP, and as a result the transmit and receive software and hardware are very similar. (And wouldn't the Professor on Gilligan's Island like to know that you can make a receiver into a transmitter without using coconuts!)
Anyway, once you get the I-Q signals into the two channels of the sound card, you get a view of the RF spectrum all at once, up to the bandwidth of your sound card sampling. So, if you have a 48KHz sound card you get 48KHz of band scanned simultaneously, and can pick and choose what frequency you want to demodulate, and how you want to demodulate it in software (AM, Single-Side Band, FM, various digital modes such as the aforementioned DRM=digital radio mondial). See here and here.
The SoftRock 40 and its replacement, the SRv5, surface mount kits costing in the $30 range, do this. They're an excellent introduction to SDR techniques, without requiring DSP chip programming. People are doing fun things with them. It's not a transmitter yet, but it will be soon with another board and a ham license).
For software, among others, there is Gnuradio, and also SDRadio, a Windows app. And there's DTTSP, a SourceForge project that runs in Linux and also releases a DLL used by the FlexRadio people. DTTSP has a number of front ends in development, in Java and other languages.
A step up is the FlexRadio SDR-1000, alluded to above. It's a 100W transceiver that does the same thing that the SoftRock does, but does a better job, and also use a VFO that allows it to pick what frequency range it operates on, rather than being limited to a particular crystal-controlled band as the stock SoftRock does. It also costs quite a bit more, and they use a 96KHz sound card to get good quality.
TVs need custom interfaces, not web pages. With technologies such as SVG and XForms, HTML turns into custom interfaces. As one of the editors of the XForms 1.0 recommendation, I know this to be true, not because I wrote part of the spec, but because I came to the party with needs for this kind of stuff. XForms 1.0 is lacking some stuff out of the box, but the implementations that are out there fill the gaps, and their feedback is going into XForms 1.1 (which I am not presently part of).
So yes, you can write the kinds of custom interfaces that appliances need using these technologies. Not solely using them, but that convergence will come as a few more things get added to the mix. And the advantage is that the data layer interface of URLs, GET/POST, and XML is totally separate from the presentation layer, and so it's really easy to write new clients without doing screen scraping; every UI and client and device is on equal footing because the people who write the first UI do the groundwork.
using the XForms <submission> tag, you can also do asynchronous HTTP POST of XML, of any instance in the page, and direct the results to come back to any instance. When the instance comes back, the UI automatically recalculates itself, and any UI widgets or groups (i.e., entire <div>s) that were bound to non-existent nodes suddenly appear in the UI when the data updates and the nodes appear. You can even make submission happen automatically when fields are exited or when menu items are changed, so forms can be completely dynamic with absolutely no JavaScript; just plain markup.
As Rachel Ray says, "How cool is that?"
Lately I've been using FormFaces (an entire XForms implementation for IE, Safari, and FF/Mozilla in AJAX/JavaScript) and Chiba (a Tomcat-based back end that outputs either plain HTML with no JavaScript for no-brainer ADA compliance, or AJAX-enhanced HTML for dynamic forms). These implementations are running neck-and-neck with the Firefox/Mozilla native one, and are catching up to the very advanced IE plugin FormsPlayer.
If you want to see how to do the the dynamic XML features you get from HTTPXMLRequest but in a standards-compliant way and using simple markup, see XForms for HTML Authors.
P.S. Since I got bashed for not saying this before, I have to add that I was one of the editors of the XForms 1.0 recommendation. Since I post under my real name and list the info on my website (and at the top of the spec;-) I hadn't realized I needed to point out explicitly that I helped. But I'm not involved in selling implementations, only in using them.
Unlike most PC case mods that remove shielding and cause radio interference, this one actually adds shielding! Not that iPods are likely to be poorly shielded.
Not really true. If you bring up a Gnome file dialog and just start typing a file name Gnome will open a text box and allow you to enter the file name with tab completion. It took me about a year to find this, and I was just mightily annoyed in the meantime. Having a visible type-in window allows the user to discover the feature. Having it invisible makes it nearly impossible to discover. Even now I find it inexplicably doesn't work for me sometimes.
As for history, I started using EMACS in 1979 at about version 134, when it was written in TECO on DEC PDP-10s. When RMS stopped maintaining it to move on to the GNU project he had just started, I took over its maintance for a year or so. One of the things I added in 1981 was M-$ (which I called "correct word spelling") and m-x check buffer spelling (which is a much better name than the present m-x spell-buffer).
If you use XML you should try James Clark's NXML Mode which uses Relax NG schemas. It gives you on-the-fly validation and completion when editing XML. Relax NG is very easy to use, especially in its Compact RNC form, which looks a lot like BNF but is isomorphic to the XML representation of the RNG Schema.
At work, I find it easy to develop Emacs-lisp scripts or even simply keyboard macros to do large refactoring jobs in Emacs. I often find that I'm the only person who can accomplish tasks that cut across programming language boundaries.
I used Emacs for several years to take real-time minutes for various W3C working groups, and made great use of the dabbrev-expand function (which I bound to meta-space). I like to think of it as an approximation to a Hidden Markov Model. In fact, at a Face-to-Face meeting in Cambridge, MA, I was able to type an entire sentence that the person sitting next to me spoke by typing only Meta-Space (and judiciously using only one or two letters to redirect the completions), a feat that lead many to believe that some form of magic was involved...Thereafter when others asked how our group had such complete minutes, people always responded, "Oh, he uses Emacs."
I met a guy in the parking lot at Ham Radio Outlet who had just come back from installing free metro wireless links (not 802.11, but point-to-point for patching up missing fiber) along the LA-MS gulf coast, with a volunteer organization called Radio Response.
Re:From TFA (and other materials on the subject)
on
HAARP Amping It Up
·
· Score: 1
"virtual VLF antenna"... The HAARP Wikipedia entry shows the HAARP operating at 3-10Mhz, which puts it squarely in HF (3-30 MHz, 100-10 meters wavelength), not VLF which is 1000 times lower in frequency (3-30 KHz, 100 kilomter to 10 kilomter wavelength)
There is nothing wrong with using JavaScript and XML and even using browser features like the HTTP posting facilities in common browsers. It's just that you have to take special efforts to make it accessible, and there's no specification for doing so, and it's not a defined standard, so people will have to muck about trying to come up with stuff that works.
When non-technical people hear about AJAX, they think that they're going get something like GMail or Microsoft's promised Web Office and it's going to be as easy as making a web page in HTML, but it's not.
I see you agree with me that the those pages, while they may be snazzy, are not accessible because the back-end framework that created them wasn't designed to make it so. My point is that if you code to standards such as XHTML and XForms, you can still get dynamic page stuff, but you need no JavaScript, and you don't have to blaze your own trail to define ways to do it. The W3C is an industry consortium, and the members define the standards, and implement them.
SVG and CSS are two great examples of W3C standards that are moving forward in both standards and implementation CSS 2.1 is a refinement of technologies that are used for both snazzy look and feel and for accessibility, and if you use CSS in your web pages, you will find that they are almost automatically more accessible, becuase it's designed that way. The same is true with XForms -- it's a specification designed by industry, through the W3C, and is implemented in a variety of web browsers, web plugins, and non-web products.
I've had nothing (at least so far;-) to do with writing any of the software I've mentioned. (OK, I do admit filing the occasional bug report against Firefox if that counts.) I just happen to have read about them as products for filling the gap between the new standards and today's browsers.
My point about AJAX vs web standards is that the web standards are designed to fit device independence and accessibility needs AND provide the features that people need for dynamic pages and good graphic design, without using libraries of JavaScript which either aren't accessible, aren't portable across devices, or which require a lot of design work on the part of the page authors to figure out how to make them so. With XHTML, XForms, and CSS, you know you are going down a path that leads to accesibility and device independence.
As for my having been an editor of the XForms 1.0 Recommendation, it's true, I was. I use my real name and a real home page to post on Slashdot, because I want to, and certainly have never hidden it.
In any case, when you choose web technologies, please consider features such as device independence and accessibility, and plan for how you're going to implement them, if they should be necessary. As I said in my original post (days ago), if you're going to provide your software to US government agencies or contractors (think NASA) you need it to be accessible.
One good option I see today is writing your web applications on the server side generate XHTML+XForms and then transcoding that into plain HTML for accessibility, or DHTML/AJAX for dynamic pages, and I think this is much better than writing JavaScript by hand and then trying to go figure out how to separate the presentation from the data. Some packages for doing AJAX may offer you this separation and an easy route to Sec. 508 compliance and WAI approval; some, as the parent poster points out, might offer enhancements that can degrade seamlessly and whose absence won't be missed (including Google Suggest), but others won't (including Google Maps, apparently). I mentioned some software packages that I think can help in this goal, and an approach for doing so. There may be other approaches, but please do your own due diligence and plan ahead when adopting these technologies for dynamic pages.
This irritates me.... This is not true.......newbie web developers who read this are going to think that they have to choose between AJAX and accessibility. I can understand why you find it irritating, and I can see your point about it not being true.
But let me elaborate: AJAX is not a specification, so almost no statements about it in general can be true or false. If AJAX means the poster children of Google Maps, GMail, etc., then my statements stand: they are not accessible, and they are not device independent. Now, Google and other companies may have plenty of people working on their own server-side technologies to make the stuff that seamlessly degrades as you suggest, but that's what I call a backend UI framework that produces HTML or DHTML depending on the situation. That's compilation in my terms, but I didn't mean to be leading any one astray by using that word; anyway, the point is, it's not a bunch of hand-authored HTML code with a little JavaScript thrown in.
When people have Javascript turned off, they get the basic version seamlessly. Perfectly accessible, none of the complicated nonsense you claim is necessary.
There is a tremendous amount of hair for doing this in the general case. And yes, as other posters have noted, if you have the right server-side framework for generating the output, it can work. I was suggesting some server-side framework that do just that, so I have no quibbles on that. The suggestions I made do it with standard markup languages as their input, so you retain the advantages of accessibility, device independence, and separation of concerns that come from the work that went into the development of those standards.
But I do disagree with you on the question of UI frameworks. I do agree it's possible to write plain old HTML and put in JavaScript that seamlessly degrades, but that's not what the hype about AJAX is about, and newbie developers would do well to understand that as well.
For bystanders, try this: go to http://maps.google.com/ and turn off JavaScript, or go to Linux and use a text-based browser with http://maps.google.com/ to try to get directions from one address to another, in text. It simply won't work, and it's not going to, because the framework that Google uses to do the impressive stuff for Google maps isn't designed for that kind of environment. But if you want to use a UI framework that can seamlessly degrade, or offer a good UI experience in both the JavaScript-enhanced world and the 508c / text world, you have a lot of work and careful planning to do. The post I made lists some frameworks that let you do this in standard ways using W3C designed technologies built from the ground up for accessibility, device-independence, and rich desktop clients.
>So we should ditch Javascript, but keep Asynchronous Javascript And XML? Isn't that like dumping gas-powered engines but keeping gas-powered cars? Yes, see XForms.
AJAX, being a random collection of JavaScript hacks, doesn't offer any accessibility.
So you can't use it in software that might be sold to, for example US Government customers -- no national laboratories, no NASA, etc.
UNLESS -- you write your own accessibility aids and write your own UI framework that compiles into both an AJAX version and a web accessible version. That's a tall order. However, there is help.
You can write your web pages in HTML with XForms and let XForms handle the dynamic page aspects, and then offer up the HTML+XForms as the accessible version. (See the DHTML Accessibility Roadmap.)
Everything that the AJAX cloud of applications does with the XMLHTTP object and updating the DOM on the fly to display choices can be done with XForms.
Then, you can use one of these mechanisms to convert the server-side XHTML+XForms file into AJAX:
FormFaces A pure AJAX library that runs in today's browsers. It's stunning to see how simply this works.
Chiba A server-side engine in Java that integrates with TomCat or other Apache web server technologies to produce HTML that works in today's browsers. Plus, the plain-old-HTML output of Chiba is accessible right now, in addition to the XHTML+XForms file itself. (Caveat: Full AJAX implementation is in development, according to the mailing list.)
Orbeon Ops, like Chiba, Orbeon converts to HTML for today's browsers in its Java back end, but rather than integrating into your TomCat or Coccoon framework, it comes with its own framework that helps you separate presentation from content and write your applications.
If you want to serve up the XHTML+XForms directly, and not rely on any AJAX technologies, try these:
Mozilla XForms for Mozilla and FireFox, an XPI that's available for recent betas and nightlies, this one-click install adds native XForms support to these browsers. Still in Beta, but with plenty of developers, it should be a full implementation.
FormsPlayer for Windows provides full support for XForms in Internet Explorer via a plug-in. Plug-ins are not everyone's cup of tea, but then neither is Mozilla;-). You can get the AJAX benefits of dynamic page updating and yet still retain accessibility with any of the server-side or JavaScript engines above, but if your target deployment is Internet Explorer, you can gain tremendous access to advanced features inside IE with this plug-in. (Plus it has some neat Konfabulator-like tools such as SideWinder.)
So, try them out, and see how much easier it is to write accessible code and properly separate your data and presentation layers when you use XHTML, CSS, and XForms. Then, choose a middleware solution or a browser-based solution and go forward knowing that you can meet architectural requirements without getting bogged down in JavaScript toolkits.
>For example, if I can only get 50% of the way to the Shannon limit using hardware in a real-world environment, could I boost that number by ignoring symbols that are indistinguishable and just let error correction (like reed-solomon) take care of the missing parts?
Yes, it's called "coding gain" and it can be measured in dB. If you want to get the results you would have had with twice as much signal to noise ratio, you need 10*log(2)=3dB coding gain. Unfortunately, putting in forward error correction reduces the data rate or increases the bandwidth, so you need to make sure you're coming out ahead.
If you're interested in experimenting with these topics, try reading about ham radio digital modes for HF (3-30Mhz). The cost of entry is low, and with open source software such as gMFSK it's possible to do your own experimentation. You might start with this historic article that started a new set of experimentation on a phase-shift keying modulation scheme called PSK31, which packs all the power into a tiny 31Hz wide bandwidth. You can read a less technical description, or read about other modulation techniques using multiple carriers (MFSK, Olivia, which uses Walsh functions for FEC and can be copyable with low power in noisy conditions).
For a long overview of HF digital mode performance in practical circumstances, see this paper from the Radio Society of Great Britain.
There's also plenty going on in UHF as this 900 Mhz work is doing, but it's a little harder to experiment there, but if you are already comfortable building 802.11 equipment and have the skills necessary there, there's plenty to do. Some hams recently conducted Earth-Moon-Earth bounce communcations using 47GHz (which I heard one of the 24GHz pioneers say would never happen!).
And at the other end of the spectrum, US, Australian, and European hams are experimenting with LF in the 137KHz region (under special license in the US) and have made super-slow communications across the oceans. There are challenges here as well, and the data rates are extremely low, not unlike the 76KHz signal that we used to send to our nuclear submarines underwater, which I think is roughly one bit (a repeated "don't-blow-it-up don't-blow-it-up don't-blow-it-up...).
We have made some assumptions (especially about the loss in the urban envorinment), I would echo the optimistic assumption you mentioned earlier about the noise floor at 900Mhz, which is much higher in an urban environment than in the middle of a Florida swamp. I would suspect these two (signal loss, noise gain) will easily eat up the 10dB margin you calculated (factor of 12).
> Okay, so what did they do, other than being "hams in space" and novelty contacts for average amateur radio operators? In my post I reported that over 5 years they have had contacts iwth over 200 school groups. Follow the ARISS link I provided to find out more.
I think students talking to a live astronaut or cosmonaut in space of significant educational value, and will help interest more kids in careers in science and technology. We should applaud the ISS crewmembers who take their time to do this.
...Five years ago this week, the International Space Station Expedition 1 crew of US astronaut and Expedition 1 Commander William ''Shep'' Shepherd, KD5GSL, and Russian cosmonauts Yuri Gidzenko and Sergei Krikalev, U5MIR, became the first humans to live aboard the ISS.
The initial Amateur Radio on the International Space Station (ARISS) station gear was already aboard the space station by the time the first crew launched. Later in the month, the Expedition 1 team installed and activated the VHF gear on FM voice and packet under the US call sign NA1SS and the Russian call sign RS0ISS.
Each of the 12 crews that have lived on the ISS to conduct assembly and research activities has included at least one US radio amateur. The Expedition 12 crew Commander Bill McArthur, KC5ACR, and Russian cosmonaut Valery Tokarev will remain on the ISS until next April. Over the years, crew members have conducted nearly 200 ARISS school group contacts and numerous casual QSOs.
Slashdot Mirror
I think that many computer applications, and to some extent certain kind of programming, are a little too much like watching TV, and harm your brain rather than enhancing it. Of what's going on today, I think the Make-magazine stuff is probably the most exciting and most likely to provoke actual thought... Kids doing robotics is pretty close to what kids doing ham radio was when I was young. Below is a meandering story of how I got from a 5 year old ham to today, back into ham radio, and reading Slashdot too.
In kindergarten, I remember bringing electrician's hot-side testing screwdrivers to show-and-tell ("Now you just stick this screwdriver into the electric socket and the neon bulb will light if it's the hot side"), and rigging up telephone networks with old handsets and batteries. After having learned morse code at age 5 and gotten on the air under my father's call (he got his license in response to my interest), I finally learned enough to read the whole test and got my license at age 7. Now my kids are about the same age, and found learning morse code to be fun; they talk to each other, and recently had a poster accepted at a peer-reviewed conference, comparing speed and errors in Morse code and typing! (Ok, it was the 2nd grade science fair.)
Soon I got interested in computers, but there weren't any actual ones to distract me; well, there was one in town, and it used punched cards. It was a Honeywell Special 200, the first IBM Clone, though it was a clone of an IBM 1401... Then there were the PDP-8's that were connected to Stanford via phone line for one of the first "computer-aided instruction" projects. I met the guys who maintained the Model 28 teletypes for them and they got their ham licenses after my father and I got ours...
When two-meter FM became popular, I helped establish the first local repeater, probably the only one within 100 miles. We had to do HAAT testing and I learned about altimeters, topographic maps, and government forms... By the time I graduated from high school and went to MIT, I found other pursuits -- PDP-10's, Lisp, classes... I pretty much got off the air. But ham radio gave me an entre into an entire world that wasn't available when I was growing up.
After a few years spent exploring 4x5" photography, I started doing some wireless mobile device work, and poor signal strength led me to get up on the roof and install a 1.9Ghz repeater. I felt a strange familiar feeling, and when my wife said, "I don't care how many antennas you put on the roof," I filed the fact away. When a co-worker shows up with a Yaesu VX-2 two-meter and 70cm handitalki that receives DC-to-daylight and said it was $120, I went ahead and bought it. I'd kept my ham license renewed, and used it once or twice in the intervening 20 years, but I had to re-learn lots of stuff. I wore the HT on my belt (along with two calculators and a slide rule, a hiptop, and a blinking LED pen) for the Halloween party at PARC and won what can best be described as the five-sigma prize...
A bit of web surfing led me to QRZ.com, EHam.net, and of course ARRL, and I found out about a local club meeting taking place that night. So I went with the co-worker, and found a bunch of pleasant nerds, schoolteachers and librarians, firefighters, electronics designers, computer scientists, and other random people.
At the club meeting, a satellite communications engineer told me about recent developments in DSP-based communications that used a PC sound card to modulate and demodulate; my extensive 20-year stint in programming made me think this might be interesting, so I bought a
A lot of the middleware that converts data to HTML and back can go away when you use the right XML tools. XSLT does a good job of presenting static pages, and it can be fast if you cache the results as well.
But for dynamic pages (and forms) XML to XSLT to HTML leaves some big gaps:
These are some of the reasons we updated the W3C HTML forms module to take account of XML data directly.
How does it fix the above problems?
Nice work if you can get it, you say? Well, as everyone knows Microsoft hasn't yet implemented XForms. (Heck, they haven't even implemented CSS, though we hear they do have it as a goal now.)
So what can you do today:
Here's a quick example:
Let's suppose you have a book list you want to view, avaialble at http://example.com/books/list.
If you want to display this data
Geeks are more hams every day with their antenna farms.
Try reading about tower review, or join in on Tower Talk.
Better yet, get a ham license. The technician test isn't even that hard.
I don't suppose there's any online sites for predicting a pass over a given location?t ml
http://science.nasa.gov/Realtime/jtrack/Amateur.h
Why spend that much ($350+), when you can order a dirt-cheap shortwave radio for maybe $40 and just use a simple 455 kHz to 12 kHz adaptor?
SDR is a broad topic. Wide-band digital modes such as the 12KHz wide DRM or even narrow ones such as HamDream are a simple example.
SDR involves a variety of techniques, but the basic idea is using an A/D at an early stage, and performing operations traditionally done with RF components with DSP software instead.
In its extreme, an SDR has a broadband RF amplifier and a DSP.
Some systems use a tuned RF filter before the RF amplifier to improve dynamic range and reduce overload, and others put the DSP after the first analog mixer. Ham equipment that uses IF DSP does this, such as many of the ICOM radios.
Then there are devices that then mix down to somewhere around the audio range, at least to the 0-96KHz or 0-48KHz range handled by many popular PC sound cards. The RF signal is detected by a an I-Q detector, which produces two signals In Phase and Quadrature (90 degrees out of phase). You might notice that this is a decomposition of a periodic wave into real and complex parts, given v=cos(omega)+j sin(omega). Thus, DSP techniques such as FFT can be applied in the complex domain. If you're seriously interested in this math, look up the Hilbert transform. It lets you modulate or demodulate directly in the DSP, and as a result the transmit and receive software and hardware are very similar. (And wouldn't the Professor on Gilligan's Island like to know that you can make a receiver into a transmitter without using coconuts!)
Anyway, once you get the I-Q signals into the two channels of the sound card, you get a view of the RF spectrum all at once, up to the bandwidth of your sound card sampling. So, if you have a 48KHz sound card you get 48KHz of band scanned simultaneously, and can pick and choose what frequency you want to demodulate, and how you want to demodulate it in software (AM, Single-Side Band, FM, various digital modes such as the aforementioned DRM=digital radio mondial). See here and here.
The SoftRock 40 and its replacement, the SRv5, surface mount kits costing in the $30 range, do this. They're an excellent introduction to SDR techniques, without requiring DSP chip programming. People are doing fun things with them. It's not a transmitter yet, but it will be soon with another board and a ham license).
For software, among others, there is Gnuradio, and also SDRadio, a Windows app. And there's DTTSP, a SourceForge project that runs in Linux and also releases a DLL used by the FlexRadio people. DTTSP has a number of front ends in development, in Java and other languages.
A step up is the FlexRadio SDR-1000, alluded to above. It's a 100W transceiver that does the same thing that the SoftRock does, but does a better job, and also use a VFO that allows it to pick what frequency range it operates on, rather than being limited to a particular crystal-controlled band as the stock SoftRock does. It also costs quite a bit more, and they use a 96KHz sound card to get good quality.
TVs need custom interfaces, not web pages.
With technologies such as SVG and XForms, HTML turns into custom interfaces.
As one of the editors of the XForms 1.0 recommendation, I know this to be true, not because I wrote part of the spec, but because I came to the party with needs for this kind of stuff. XForms 1.0 is lacking some stuff out of the box, but the implementations that are out there fill the gaps, and their feedback is going into XForms 1.1 (which I am not presently part of).
So yes, you can write the kinds of custom interfaces that appliances need using these technologies. Not solely using them, but that convergence will come as a few more things get added to the mix. And the advantage is that the data layer interface of URLs, GET/POST, and XML is totally separate from the presentation layer, and so it's really easy to write new clients without doing screen scraping; every UI and client and device is on equal footing because the people who write the first UI do the groundwork.
> are already well advanced with implementations of SVG, DOM, CSS, PNG, JPEG2000 and XForms.
/>
/>
;-) I hadn't realized I needed to point out explicitly that I helped. But I'm not involved in selling implementations, only in using them.
Only Firefox/Mozilla has XForms; sadly Opera and Safari don't.
XForms, by the way, is the only stanrd to incorporate all the stuff that XMLTTHPRequest does, and it does so in a very easy way.
For example, if you want to load up your del.icio.us tags you just do this in the <head>:
<instance src="http://del.icio.us/api/tags/get"
Then you can list them like this in the HTML <body>:
<repeat nodeset="/tags/tag">
<output ref="."
</repeat>
using the XForms <submission> tag, you can also do asynchronous HTTP POST of XML, of any instance in the page, and direct the results to come back to any instance. When the instance comes back, the UI automatically recalculates itself, and any UI widgets or groups (i.e., entire <div>s) that were bound to non-existent nodes suddenly appear in the UI when the data updates and the nodes appear. You can even make submission happen automatically when fields are exited or when menu items are changed, so forms can be completely dynamic with absolutely no JavaScript; just plain markup.
As Rachel Ray says, "How cool is that?"
Lately I've been using FormFaces (an entire XForms implementation for IE, Safari, and FF/Mozilla in AJAX/JavaScript) and Chiba (a Tomcat-based back end that outputs either plain HTML with no JavaScript for no-brainer ADA compliance, or AJAX-enhanced HTML for dynamic forms). These implementations are running neck-and-neck with the Firefox/Mozilla native one, and are catching up to the very advanced IE plugin FormsPlayer.
If you want to see how to do the the dynamic XML features you get from HTTPXMLRequest but in a standards-compliant way and using simple markup, see XForms for HTML Authors.
P.S. Since I got bashed for not saying this before, I have to add that I was one of the editors of the XForms 1.0 recommendation. Since I post under my real name and list the info on my website (and at the top of the spec
Unlike most PC case mods that remove shielding and cause radio interference, this one actually adds shielding! Not that iPods are likely to be poorly shielded.
Not really true. If you bring up a Gnome file dialog and just start typing a file name Gnome will open a text box and allow you to enter the file name with tab completion.
It took me about a year to find this, and I was just mightily annoyed in the meantime.
Having a visible type-in window allows the user to discover the feature.
Having it invisible makes it nearly impossible to discover.
Even now I find it inexplicably doesn't work for me sometimes.
As for history, I started using EMACS in 1979 at about version 134, when it was written in TECO on DEC PDP-10s. When RMS stopped maintaining it to move on to the GNU project he had just started, I took over its maintance for a year or so. One of the things I added in 1981 was M-$ (which I called "correct word spelling") and m-x check buffer spelling (which is a much better name than the present m-x spell-buffer).
If you use XML you should try James Clark's NXML Mode which uses Relax NG schemas. It gives you on-the-fly validation and completion when editing XML. Relax NG is very easy to use, especially in its Compact RNC form, which looks a lot like BNF but is isomorphic to the XML representation of the RNG Schema.
At work, I find it easy to develop Emacs-lisp scripts or even simply keyboard macros to do large refactoring jobs in Emacs. I often find that I'm the only person who can accomplish tasks that cut across programming language boundaries.
I used Emacs for several years to take real-time minutes for various W3C working groups, and made great use of the dabbrev-expand function (which I bound to meta-space). I like to think of it as an approximation to a Hidden Markov Model. In fact, at a Face-to-Face meeting in Cambridge, MA, I was able to type an entire sentence that the person sitting next to me spoke by typing only Meta-Space (and judiciously using only one or two letters to redirect the completions), a feat that lead many to believe that some form of magic was involved...Thereafter when others asked how our group had such complete minutes, people always responded, "Oh, he uses Emacs."
I met a guy in the parking lot at Ham Radio Outlet who had just come back from installing free metro wireless links (not 802.11, but point-to-point for patching up missing fiber) along the LA-MS gulf coast, with a volunteer organization called Radio Response.
If it is Emacs, yes.
I now use Emacs to control my Elecraft K2.
"virtual VLF antenna"...
The HAARP Wikipedia entry shows the HAARP operating at 3-10Mhz, which puts it squarely in HF (3-30 MHz, 100-10 meters wavelength), not VLF which is 1000 times lower in frequency (3-30 KHz, 100 kilomter to 10 kilomter wavelength)
Maybe Amazon and Del.icio.us can get together and agree on a REST API for tags.
This sounds like great news to me. Solar cycle 24 should be just about beginning shortly after this thing gets operational. Try this RSS feed of solar weather from hfradio.org.
There is nothing wrong with using JavaScript and XML and even using browser features like the HTTP posting facilities in common browsers. It's just that you have to take special efforts to make it accessible, and there's no specification for doing so, and it's not a defined standard, so people will have to muck about trying to come up with stuff that works.
;-) to do with writing any of the software I've mentioned. (OK, I do admit filing the occasional bug report against Firefox if that counts.) I just happen to have read about them as products for filling the gap between the new standards and today's browsers.
When non-technical people hear about AJAX, they think that they're going get something like GMail or Microsoft's promised Web Office and it's going to be as easy as making a web page in HTML, but it's not.
I see you agree with me that the those pages, while they may be snazzy, are not accessible because the back-end framework that created them wasn't designed to make it so. My point is that if you code to standards such as XHTML and XForms, you can still get dynamic page stuff, but you need no JavaScript, and you don't have to blaze your own trail to define ways to do it. The W3C is an industry consortium, and the members define the standards, and implement them.
SVG and CSS are two great examples of W3C standards that are moving forward in both standards and implementation CSS 2.1 is a refinement of technologies that are used for both snazzy look and feel and for accessibility, and if you use CSS in your web pages, you will find that they are almost automatically more accessible, becuase it's designed that way. The same is true with XForms -- it's a specification designed by industry, through the W3C, and is implemented in a variety of web browsers, web plugins, and non-web products.
I've had nothing (at least so far
My point about AJAX vs web standards is that the web standards are designed to fit device independence and accessibility needs AND provide the features that people need for dynamic pages and good graphic design, without using libraries of JavaScript which either aren't accessible, aren't portable across devices, or which require a lot of design work on the part of the page authors to figure out how to make them so. With XHTML, XForms, and CSS, you know you are going down a path that leads to accesibility and device independence.
As for my having been an editor of the XForms 1.0 Recommendation, it's true, I was. I use my real name and a real home page to post on Slashdot, because I want to, and certainly have never hidden it.
In any case, when you choose web technologies, please consider features such as device independence and accessibility, and plan for how you're going to implement them, if they should be necessary. As I said in my original post (days ago), if you're going to provide your software to US government agencies or contractors (think NASA) you need it to be accessible.
One good option I see today is writing your web applications on the server side generate XHTML+XForms and then transcoding that into plain HTML for accessibility, or DHTML/AJAX for dynamic pages, and I think this is much better than writing JavaScript by hand and then trying to go figure out how to separate the presentation from the data. Some packages for doing AJAX may offer you this separation and an easy route to Sec. 508 compliance and WAI approval; some, as the parent poster points out, might offer enhancements that can degrade seamlessly and whose absence won't be missed (including Google Suggest), but others won't (including Google Maps, apparently). I mentioned some software packages that I think can help in this goal, and an approach for doing so. There may be other approaches, but please do your own due diligence and plan ahead when adopting these technologies for dynamic pages.
Leigh.
This irritates me. ... This is not true. ... ...newbie web developers who read this are going to think that they have to choose between AJAX and accessibility.
I can understand why you find it irritating, and I can see your point about it not being true.
But let me elaborate: AJAX is not a specification, so almost no statements about it in general can be true or false. If AJAX means the poster children of Google Maps, GMail, etc., then my statements stand: they are not accessible, and they are not device independent. Now, Google and other companies may have plenty of people working on their own server-side technologies to make the stuff that seamlessly degrades as you suggest, but that's what I call a backend UI framework that produces HTML or DHTML depending on the situation. That's compilation in my terms, but I didn't mean to be leading any one astray by using that word; anyway, the point is, it's not a bunch of hand-authored HTML code with a little JavaScript thrown in.
When people have Javascript turned off, they get the basic version seamlessly. Perfectly accessible, none of the complicated nonsense you claim is necessary.
There is a tremendous amount of hair for doing this in the general case. And yes, as other posters have noted, if you have the right server-side framework for generating the output, it can work. I was suggesting some server-side framework that do just that, so I have no quibbles on that. The suggestions I made do it with standard markup languages as their input, so you retain the advantages of accessibility, device independence, and separation of concerns that come from the work that went into the development of those standards.
But I do disagree with you on the question of UI frameworks. I do agree it's possible to write plain old HTML and put in JavaScript that seamlessly degrades, but that's not what the hype about AJAX is about, and newbie developers would do well to understand that as well.
For bystanders, try this: go to http://maps.google.com/ and turn off JavaScript, or go to Linux and use a text-based browser with http://maps.google.com/ to try to get directions from one address to another, in text. It simply won't work, and it's not going to, because the framework that Google uses to do the impressive stuff for Google maps isn't designed for that kind of environment. But if you want to use a UI framework that can seamlessly degrade, or offer a good UI experience in both the JavaScript-enhanced world and the 508c / text world, you have a lot of work and careful planning to do. The post I made lists some frameworks that let you do this in standard ways using W3C designed technologies built from the ground up for accessibility, device-independence, and rich desktop clients.
>So we should ditch Javascript, but keep Asynchronous Javascript And XML? Isn't that like dumping gas-powered engines but keeping gas-powered cars?
Yes, see XForms.
So you can't use it in software that might be sold to, for example US Government customers -- no national laboratories, no NASA, etc.
UNLESS -- you write your own accessibility aids and write your own UI framework that compiles into both an AJAX version and a web accessible version.
That's a tall order. However, there is help.
You can write your web pages in HTML with XForms and let XForms handle the dynamic page aspects, and then offer up the HTML+XForms as the accessible version. (See the DHTML Accessibility Roadmap.)
Everything that the AJAX cloud of applications does with the XMLHTTP object and updating the DOM on the fly to display choices can be done with XForms.
Then, you can use one of these mechanisms to convert the server-side XHTML+XForms file into AJAX:
If you want to serve up the XHTML+XForms directly, and not rely on any AJAX technologies, try these:
So, try them out, and see how much easier it is to write accessible code and properly separate your data and presentation layers when you use XHTML, CSS, and XForms. Then, choose a middleware solution or a browser-based solution and go forward knowing that you can meet architectural requirements without getting bogged down in JavaScript toolkits.
Here's another RF-based location search. The software is all OSS.
>For example, if I can only get 50% of the way to the Shannon limit using hardware in a real-world environment, could I boost that number by ignoring symbols that are indistinguishable and just let error correction (like reed-solomon) take care of the missing parts?
Yes, it's called "coding gain" and it can be measured in dB. If you want to get the results you would have had with twice as much signal to noise ratio, you need 10*log(2)=3dB coding gain. Unfortunately, putting in forward error correction reduces the data rate or increases the bandwidth, so you need to make sure you're coming out ahead.
If you're interested in experimenting with these topics, try reading about ham radio digital modes for HF (3-30Mhz). The cost of entry is low, and with open source software such as gMFSK it's possible to do your own experimentation. You might start with this historic article that started a new set of experimentation on a phase-shift keying modulation scheme called PSK31, which packs all the power into a tiny 31Hz wide bandwidth. You can read a less technical description, or read about other modulation techniques using multiple carriers (MFSK, Olivia, which uses Walsh functions for FEC and can be copyable with low power in noisy conditions).
For a long overview of HF digital mode performance in practical circumstances, see this paper from the Radio Society of Great Britain.
There's also plenty going on in UHF as this 900 Mhz work is doing, but it's a little harder to experiment there, but if you are already comfortable building 802.11 equipment and have the skills necessary there, there's plenty to do. Some hams recently conducted Earth-Moon-Earth bounce communcations using 47GHz (which I heard one of the 24GHz pioneers say would never happen!).
And at the other end of the spectrum, US, Australian, and European hams are experimenting with LF in the 137KHz region (under special license in the US) and have made super-slow communications across the oceans. There are challenges here as well, and the data rates are extremely low, not unlike the 76KHz signal that we used to send to our nuclear submarines underwater, which I think is roughly one bit (a repeated "don't-blow-it-up don't-blow-it-up don't-blow-it-up...).
We have made some assumptions (especially about the loss in the urban envorinment),
I would echo the optimistic assumption you mentioned earlier about the noise floor at 900Mhz, which is much higher in an urban environment than in the middle of a Florida swamp. I would suspect these two (signal loss, noise gain) will easily eat up the 10dB margin you calculated (factor of 12).
> Okay, so what did they do, other than being "hams in space" and novelty contacts for average amateur radio operators?
In my post I reported that over 5 years they have had contacts iwth over 200 school groups. Follow the ARISS link I provided to find out more.
I think students talking to a live astronaut or cosmonaut in space of significant educational value, and will help interest more kids in careers in science and technology. We should applaud the ISS crewmembers who take their time to do this.