Beacon is a free, distributed peer to peer application that allows ham radio operators to share with each other observations of successful band propagation events.

Beacon in the simplest sense is like a traditional "bulletin board". Notices are posted to the board, and notices are read from the board. In the case of Beacon, these notices constitute "band open" announcements or assertions.

Every announcement in Beacon therefore alerts users to propagation conditions between two different parts of the world. In this way it is useful to hams who want to make contact to those parts of the world at that moment, but also perhaps to scientists seeking realtime information on propagation phenomena. The latter would require lots of Beacon users on a consistent basis.

No. Web Start will periodically check for Beacon updates, and will not download the entire 4Mb every time you run the app. Only when the Beacon app has been updated will Web Start download the new version.

When the developers at JXTA.org release new versions of their library jar files and I deem it worthwhile to use the new library, I will upload that to the Beacon Web Start area on my site. Because the JXTA.org folks sign their jar files with an "ephemeral" key, you will have to do an 'Accept' in Web Start on their signature each time I upload the new jar file.

All computers running Beacon are called peers. When an operator running Beacon makes a contact that he/she wishes to make known to the rest of the Beacon user community, the basic contact information is entered into the Beacon user interface and published to the Beacon network.

The contact information in Beacon parlance is called an advertisement. Other Beacon users can query the network for these advertisements, and in turn learn about the contact and therefore learn that propagation conditions supported the contact. Those other users can then attempt to contact that part of the world, too, if their QTH matches one of the QTH's in the advertisement.

Beacon conducts its JXTA network business on TCP port 9701. Java Web Start network business occurs on port 80, as it is http-based.

Within a minute or so of startup, you should see an entry or two in one of the band tabs in the Beacon user interface. This assumes that the network is up and that there are Beacon users who have published a band opening advertisement within the last hour.

I wanted to include some notion of who published the advertisement, but felt with whom the contact was made did not further Beacon's fulfillment of its goal. That goal is to simply make known propagation conditions from one part of the world to another, and not necessarily to identify all parties to a contact.

Yes, it would be more precise but not necessarily better. While the publisher of an advertisement knows her Lat/Long, she does not necessarily know the Lat/Long of the other station. For this version of Beacon, I stuck with the simpler fixed subregion model, which is information already gathered during a contact. For Beacon purposes, subregion is sufficiently precise to indicate basic band openings between two points on the globe.

The current default is one hour. After one hour, the advertisement expires and will not be returned in response to network queries. Advertisements may persist longer, depending on when the expiry routine in the JXTA platform runs.

Yes, and no. DX clusters tend to identify the remote station by callsign, in hopes that someone can call that station to make a DX contact. Beacon does not seek to replace DX clusters, but to distill the information for purely propagation conditions purposes.

Moreover, because Beacon runs on your local machine as a standalone application, a version of it may also be developed in the future that integrates with your logging program, such that entries made to that logging program are automatically published on the Beacon network.

Web Start does a good job of checking digital signatures on all the libraries, or jar files, it downloads over the Internet and which eventually run on your machine. Like your web browser, it has the ability to verify signatures produced with certificates issued by well-known certificate authorities (CA), such as Thawte or VeriSign.

I can't afford any digital certificates ("cert") from a well-known CA that would actually support proving that I am who I say I am. And using one of the free "email" certificates that several CAs offer doesn't really prove a whole lot about whether I am who I say I am, either. So rather than me go through the trouble of acquiring a low-cost cert that doesn't prove much, puts my personal information in yet another commercial database on the Internet, and which will expire someday anyway, I just produced and signed my own certificate.

This self-signed cert is technically and computationally valid but otherwise cannot be verified by Web Start as having been signed using a cert issued by a CA it knows about. Hence, the scary messages.

I don't plan to use commercial certs to sign Beacon's jar files, and I plan to continue to use Web Start to distribute it. If you choose not to install Beacon because you cannot come to believe that I am who I say I am, and that I signed the jar files myself, then that's up to you. You would, however, receive no greater assurance of the integrity of the software had I produced a .exe or .zip file and asked you to download and run it. You'll just have to take my word for it that I am who I say I am, that I signed the jar files, and to look past the scary Web Start warnings. In retrospect, the language Web Start uses to discourage you from installing signatures it cannot vouch for are a bit over the top. Be wary, yes, but don't scare people.

The JXTA platform and Bouncy Castle jar files were signed in the same way by their respective developers, and therefore the same applies to these signed jar files. Those jar files are distributed off my web site, but were signed by their respective developers. You'll have to take my word that they are distributed in the good form I found or compiled them, Web Start's warning notwithstanding. The alternative is not running Beacon.

Technically, yes. However, I ask that you PLEASE NOT do that unless you use Beacon as the basis for a completely different JXTA application (which I encourage!), complete with unique peergroup ID. I make available the Beacon source code in the great amateur spirit of transparency, elmering, and information sharing.

Beacon, like any application, relies on its application data integrity. In this case, that means the format and purpose of its advertisements, their uniform display, etc. If you modified Beacon and ran it amongst the other unmodified Beacon peers, it may not play well with them.

So, on behalf of all Beacon users: read the Beacon source code and learn from it. Write your own JXTA application with what you learn. But I am the only person who should modify the Beacon code for its stated purpose. Otherwise, mayhem on the Beacon network could result, and the value of the AE6RT Beacon network would be lost. If you find a bug in Beacon or wish to see other features, drop me a note. I will fix and add features as time allows, and if you are a experienced Java and JXTA hacker, maybe you can work on the official Beacon distribution with me.

If you have questions about Beacon internals or want to know more about writing JXTA applications, by all means drop me a note. I'm happy to discuss your goals with you!

Thanks!

Thank Java for that. It is resource intensive. It may take a good half a minute for Beacon to come up on a PIII 800MHz machine, and that's after the necessary jar files have been downloaded over the network. Once it's up, performance and responsiveness should improve, but the Java virtual machine will still want many tens of megs of memory to run. If you have an old machine with less than 64Mb of memory and you are short on disk space, Beacon may not work well for you. Your mileage may vary.

No. There are two other Web Start-based ways to run Beacon.

• Open a terminal window and type javaws http://www.petrovic.org/Beacon/beacon.jnlp
• Open a terminal window and type javaws and select Beacon from the existing entries, or make a new Beacon entry with the URL above.

It is technically possible by some definition, but please don't do it. You will at the very least confuse your machine.

Yes. But I felt more was better than less. Whether configuring Beacon with your QTH information at startup or selecting a QTH representing the contact's position, choose the QTH that most closely matches. For Beacon purposes, close enough is probably good enough.