Web Waterfall Display for Radio

ScreenshotI’ve created a waterfall display using HTML5, you can try it (at the moment) at server1.perens.com/canvas.html

Currently this is displaying random numbers rather than real radio data. But it shows that you can do this using HTML5, and it works well on a phone. Touch events work, and you should be able to drag the displayed band up or down in frequency with a mouse or touch.

This, combined with the audio control panel work and the certificate work also discussed in this blog will make a full web front panel for radio transceivers. No software installation, portable to everything but iOS (catch up, Apple!) should run on Chrome, Firefox, and Opera (I’ve only tested the waterfall on Chrome).

Apps are dead when you can do this in HTML5. You can even package it as an app, and it looks like one to the user, and it can even use offline storage, but it all runs in the browser.


Using the ARRL Logbook of the World Certificate to Validate Yourself to Web Services as a Licensed Radio Amateur

The ARRL operates Logbook of the World (LotW, for short), a modern replacement for the QSL cards that Amateurs exchanged to confirm their contacts. Part of the LotW infrastructure is an X.509 cryptographic certification authority, which certifies licensed radio amateurs and includes their callsign as part of the certificate.

We can use these certificates to validate that web service clients are licensed radio amateurs, or not. This allows Amateurs to provide use of their transceivers on the net as a service, without violating the rules of their radio regulators. Our software is ready to do this, what remains is for our potential users to get their certificates and load them into their web browsers.

If you haven’t used LotW before, you can learn how to get started here. Getting started takes a few days for a U.S. Amateur, and potentially a few weeks for other Amateurs. Once you’re set up, ARRL will issue your cryptographic certificate in their own file format. But it’s easy to extract your certificate as a PKCS12 file that is accepted by Google Chrome. Firefox doesn’t load ARRL’s certificates at the moment, and I have yet to test Opera.

Fedora, Red Hat, and Centos users: if the next step breaks, see the end of this page.

To extract your certificate, start the Trusted QSL program. On Linux, it’s called “tqsl”. Press the tab for “Callsign Certificates”.  Your callsign is shown on the left. Click on your callsign to highlight it. Then, click on the icon to the left of “Save the callsign certificate for <your-callsign>”.  The program will open up a file-select box, all filled in to save your callsign certificate in your home directory as <your-callsign>.p12, with the callsign in upper-case. Save the file. Leave the password fields blank. We’ll remove the file when we’ve loaded it into the browser, so we won’t need the confusing file password.

Now, you should have <your-callsign>.p12 in your home directory. Start Google Chrome.  Use the Chrome menu to open the Google Chrome settings. Click on “Show advanced settings…” on the bottom of the page. Scroll down until you see the “HTTP/SSL” heading. Press the “Manage certificates…” button under that heading. The Certificate manager opens. Click on the “Your Certificates” tab, and click the “Import…” button. A file-select box opens. Find and open the <your-callsign>.p12 file – remember, the callsign is in upper-case. Chrome will ask for a password, leave it blank (to correspond with leaving it blank when you saved the file) and press “OK”.

Now, the certificate manager should show your certificate under the “Your Certificates” tab. Press “Done”.  You now have your certificate loaded. You can close the browser tab with the settings, or just type in another URL.

To verify that your certificate works in Chrome now, use Chrome to browse to https://server1.perens.com/validate.html The “s” in “https” is important here, nothing about certificates works without using “https” rather than “http”. Chrome will ask you to select your certificate. Choose the certificate with your name and “(Logbook of the World Production CA)”.

Oops, Chrome now says “Your connection is not private” because I’ve not purchased a server certificate (they cost money today, but I hear that EFF will be providing free ones soon). Press “Advanced”. Then, press “Proceed to server1.perens.com (unsafe)” – it’s not really unsafe, you won’t be entering your credit card number or any other private information there.

If everything’s working, you should see a screen like this:

    Bruce Perens
    bruce at perens dot com
    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

If that’s what you see, You are validated on the Internet as a Licensed Radio Amateur!

If your certificate didn’t pass to the server, you will only see your ip_address, hostname, and user-agent. If your certificate is out-of-date or you’ve presented my server with a certificate that isn’t signed by ARRL, the certificate_is_valid field should show false instead of true.

Remove the <your-callsign>.p12 file, for security’s sake. We don’t want anyone who isn’t a Licensed Radio Amateur getting your certificate and using it to control radios! You can always save another copy using the Trusted QSL program.

Please email your results to bruce at perens dot com.

* For Fedora, Red Hat, and Centos users, if saving the .p12 file breaks: Set OPENSSL_ENABLE_MD5_VERIFY=1 in the shell environment before running the Trusted QSL program. The easiest way is to edit your .profile to include a line like “export OPENSSL_ENABLE_MD5_VERIFY=1″, then log out and log in again.




Algoram Demonstrates Web Radio Front Panel

Algoram is currently demonstrating its web radio front panel at server1.perens.com . This is a web application that allows you to talk and listen, and control the transceiver, wherever you are.  The demo just repeats your voice back to you, our next version will control an actually transceiver but we’ll have to use password validation to make sure only hams use it.

This will be used with Algoram Katena (Whitebox) as the main front panel, using your phone or tablet to control the radio. If you save it on the home screen, it runs as a full-screen app. It currently runs on Windows, Linux, Mac, Chromebook, Android, and Kindle Fire HD as long as you have a modern version of Chrome, Firefox, or Opera. This is the exact same software on all platforms, no porting.

Our next step will be building all of the graphical tools that users are used to, waterfall, meters, etc., using the HTML5 canvas.

iOS is the only platform we can’t support so far. It will have to wait until Safari supports getting the microphone from the browser.  While Chrome, Firefox, and Opera stay up to date with evolving web standards, Safari does not, and Chrome is handicapped on iOS because Apple forces Google to run Apple’s own version of the web rendering engine on that platform, rather than Google’s up-to-date one.

Funny how for the high Apple price, you get a system that doesn’t keep up with evolving web standards as well as an Android that costs 1/3 as much. We hope that iOS 9 solves this particular issue, but we have no way of knowing whether it does or not at this writing.

On the Kindle Fire HD, which comes with the also-behind-the-times “Silk” browser, the process of installing an up-to-date version of Chrome is really quite simple. Would that getting around Apple’s restrictions was so easy.

Algoram at Dayton Hamvention 2015

Algoram had a 20-foot-wide space in the Arena, the most desired space at Hamvention. We used half of it to sponsor a FreeDV table, and the other half to show our product. I took these photos before the show floor opened on Saturday, they don’t show the big crowds we got. Click on the photo for a larger one.

Algoram Booth
Algoram Booth

I have to re-print that table banner in 2×6 feet rather than 3×6. The last line got eaten, it says “Third-Party Repairable”.

FreeDV Booth, sponsored by Algoram
FreeDV Booth, sponsored by Algoram

That’s Gerry N4DV at the FreeDV table. You can also see the SM1000 and a sign explaining it.

IMG_20150517_081742I am standing in the D-STAR booth to take this photo. That’s right, we were right across from D-STAR! If you back up, or crane your neck, this Kenwood sign was looming over us. Perhaps we should build something to take care of that next year.100_5555-compressedHere is the Whitebox “Charley” prototype we were showing, top side.

100_5557-compressedAnd this is the bottom side.

On Doing Kickstarter Right

Updated: April 9, 2015.

Once upon a time, there was a group of folks who wanted to make a handheld wireless back-country tablet. They tried out something vaguely like what they wanted to do using some embedded system evaluation boards, prototyped their physical design using computer graphics, and raised over USD$700,000 via a self-hosted drive, but one that looked very much like Kickstarter. Then they moved to China, where they contracted a firm to actually design and then manufacture their device.

A lot of us raised our eyebrows at that point. They took all of that money before they actually had a design? When criticized about that, they would obnoxiously say “yes, making this is hard” rather than making any substantive answer. But they had no idea how hard it was.  People who actually were a lot more experienced than they could not really get through to them about what was already going wrong at the start of their project. When told that their wireless plans weren’t about to meet with FCC approval, they ignored the advice and deleted comments from their blog.

In general, they lived in complete denial. It looks like they are paying for it now, along with their sponsors.

The last update posted on their site, as I write this, says they are going for a new manufacturing company and a complete redesign of their product, two years after crowdfunding. They probably have used up enough funds by now that they can’t really deliver their device to all of the customers who put up money, if they ever deliver at all.

I don’t want to be these guys.

The way to avoid being them is simple. Don’t take people’s money before you have what you are going to build, already tested, working, and through a short manufacturing run.

The first thing that this means is that you need to be capable of the job. You can’t just take people’s money and then hire someone to do the work. Second, you must spend years prototyping, and probably drop tens of thousands of dollars of your own funds into the project before you ask anyone else for funding. You will also need to buy the tools, which in the case of wireless devices costs many thousands, even if you are able to get the equipment of distressed cellular companies for cents on the dollar as we can (see the Boat Anchor talk).

Things will go slower than you like, because you’ll be spending time on your day job, etc. But in the end you will have a high probability of success when you actually do your kickstarter.

The good news is that is where Algoram is. We’ve spent years in design and testing. We have a working design in our second PCB turn which was fabricated for us by a U.S. firm. Our third PCB design is currently at the manufacturer. If this turn meets all of our goals, we’ll do a kickstarter and sell it, fabricating in the U.S.

Going to Asia for manufacturing is obviously cheaper, not just because of the labor but because the parts supply is radically different from the U.S. But there are well-known horror stories about parts substitution, etc. We’re not going to make our sponsor group wait while we learn about that.

Of course, you never get the disaster you’ve planned for. I’m not saying we’re goof-proof. But we’ve done a lot to reduce risk.

About the Creation of the Open Source Definition and the Debian Social Contract

There is a great deal of confusion or worse about the creation of the Open Source Definition and the Debian Social Contract. The story reported in a number of places, including on Debian’s own web site, contains significant mis-statements. I am setting down the entire story here to clear that up.

I last wrote about the OSD in 1999 for the O’Reilly Open Sources book. That chapter is on the web now.

The Open Source Definition started as a Debian project document called the Debian Social Contract, specifically a portion called the Debian Free Software Guidelines. The Debian Social Contract started with two events:

The first was an email conversation between Ean Schussler and Donnie Barnes of Red Hat which Ean copied to me. In that conversation, Ean stated to Donnie that Red Hat had never stated its social contract with the developer community. I realized at that point that neither had Debian stated its social contract, and that writing it down would be a good idea.

The second was a request regarding whether a package was suitable for inclusion in Debian, which I believe was made by Erik Andersen. We knew that we wanted the system to be Free Software, but we didn’t actually have a definition of what Free Software was.

Combining these two events, I decided to write down Debian’s Social Contract and Free Software Guidelines. I initiated the project to do so on the Debian developer mailing list.

Although Ean was critical in introducing the very idea of a Linux distribution having a social contract with the free software community in that email to Donnie, Ean didn’t actually suggest that the Debian developers write down their own social contract, because the conversation was about Red Hat. It was my idea that Debian should do so. I initiated the project on the debian-devel mailing list by sending a draft to the list, and then took changes and ideas from the developers over the next month until we were satisfied with the text.

In some venues it is reported that Ean’s conversation took place with Robert Young (Chairman of Red Hat) rather than Donnie Barnes, and there is a statement attributed to Young on the absurdity of Red Hat making such a contract. The conversation I witnessed was with Donnie, not Robert, and that conversation led to my work on the Debian Social Contract. Perhaps Ean had a conversation with Young that I did not witness.

Richard Stallman had written a definition of Free Software, today referred to as The Four Freedoms, in an issue of The GNUs Bulletin which was distributed in paper form at MIT. It was present on the January 1998 FSF web site at that time as a brief version with only three freedoms, and can still be viewed via the Wayback machine.

I did not base the Debian Free Software Guidelines on text of the Four Freedoms (then the Three Freedoms).  Indeed, I may not have been able to view the FSF web site. This was summer 1997, and the oldest copy I can find of the FSF web site is from January 1998. Whatever browser I had access to then was primitive and we didn’t use the web for as much as we do today. However, I was fully aware of the FSF’s philosophy, and I believe that Richard published the Three Freedoms years before I created my own document.

I sent my completed Debian Free Software Guidelines to Richard. I got back “That’s a good definition of Free Software.” Richard didn’t point out the Three Freedoms text at the time. I believe the Four Freedoms text became more important once Richard felt a need to distance himself from the Open Source campaign. I have always believed that Open Source is a gentle introduction to lead business people into Richard’s philosophy. Any friction between Free Software and Open Source was unnecessary, unfortunate, and due to personalities that are not relevant today.

The Debian Free Software Guidelines were written to fit the licenses we had at the time. So, it was strongly influenced by the BSD license, the MIT license, the Artistic License 1.0, and the GPL (also by Richard and a lot more specific than the Three Freedoms). We had no legal assistance available to us, and thus the document had no review by an attorney. It’s held up astonishingly well despite that lack. However, were I to write it today it would probably be written in the form of a list of license terms that would be allowed, rather than license terms that would be prohibited.

In early February 1998, about 8 months after the Debian Social Contract and the Debian Free Software Guidelines were published, Eric Raymond approached me with the idea of creating the Open Source initiative, after a meeting at VA Research (later called VA Linux Systems) where the topic was discussed in my absence and Christine Peterson (of the Foresight Foundation and then wife of nanotechnology pundit Eric Drexler) suggested the name Open Source. I proposed to Eric to adapt my Debian document to be the Open Source Definition, and did so by changing the name and adding a few paragraphs introducing Open Source. Some years later, the Open Source Initiative board added rule 10 to the definition. There’s nothing wrong with rule 10, but I feel it was actually implied by other rules in the document.

Having edited the Open Source Definition, I published the first announcement of “Open Source” and the “Open Source Initiative” on various mailing lists, Slashdot, and other early weblogs. Some of these still exist today. This was the first public use of “Open Source” in its modern context. Web searches reveal a few uses of the words “open” and “source” together before that time, but those uses did not couple the concept of rights as well as source code that has applied since the creation of the Open Source Initiative.

Fixing /dev/input (evdev) permissions on Linux

Linux uses the evdev interface and /dev/input/event* to provide an interface to USB joysticks, game controllers, pedals, buttons, etc. In general the /dev/input/event* devices can only be opened by root. This is to prevent keystroke logging security attacks. But we don’t want to have to be root to run DVS and access a USB pedal or button.

Modern Linux systems manage devices using udev. You can place a rule file in /etc/udev/rules.d/ to cause the permissions on some event devices to be more suitable to DVS users. But we don’t want to break the system security while doing so. Thus, this udev rule which I’ve written this morning excludes keyboard devices, and pointer devices (mice, tablets, touchpads, touchscreens). It gives all other devices permission to be read by members of the audio group which we were already using to access audio devices (the other choice was the games group). The DVS program is made set-group-id “audio” at installation time.

The consolekit subsystem might provide a better permission mechanism, but I haven’t explored it yet.

Become root. Put this rule in /etc/udev/rules.d/99-algoram-evdev.rules:

# Relax security on input devices that aren't keyboards or pointer devices
# (mice, touchpads, tablets, touchscreens). This allows non-root access to
# game controllers, etc. In this case, we use the "audio" group to provide
# that access. Perhaps consolekit could provide a better permission mechanism.

Once that’s done, run these commands:

udevadm control --reload
udevadm trigger

These reload the udev rules and re-run them. The permissions on files in /dev/input should now be appropriate for DVS users. Mine are:

drw------- 2 root root      60 Aug 22 08:05 by-id
drw------- 2 root root     140 Aug 22 08:05 by-path
crw------- 1 root root  13, 64 Aug 22 10:53 event0
crw-rw---- 1 root audio 13, 65 Aug 22 10:52 event1
crw------- 1 root root  13, 74 Aug 22 10:53 event10
crw-rw---- 1 root audio 13, 66 Aug 22 10:52 event2
crw-rw---- 1 root audio 13, 67 Aug 22 10:52 event3
crw-rw---- 1 root audio 13, 68 Aug 22 10:52 event4
crw-rw---- 1 root audio 13, 69 Aug 22 10:53 event5
crw-rw---- 1 root audio 13, 70 Aug 22 10:53 event6
crw-rw---- 1 root audio 13, 71 Aug 22 10:53 event7
crw-rw---- 1 root audio 13, 72 Aug 22 10:53 event8
crw-rw---- 1 root audio 13, 73 Aug 22 10:53 event9
crw------- 1 root root  13, 63 Aug 22 10:53 mice
crw------- 1 root root  13, 32 Aug 22 10:53 mouse0

As you can see, some devices have restrictive permissions because they are security critical. Others can be accessed by members of the audio group. – Bruce Perens K6BP

Algoram Digital Voice Server status

Class relationship of the device drivers.
Here’s a nice page from the developer documentation, describing the class relationship of the various device drivers, etc.

Aogoram Digital Voice Server works on Linux so far using David’s “FreeDV API”. I am going to split the FreeDV API code into three pieces, the codec, modem, and protocol framer, before I release the program.

This is because one of the main purposes of DVS is to be easy to modify, and I want people to be able to change protocol framers, the modem parameters, etc., and experiment with new protocol versions for FreeDV-like communications.

The other big to-do is to make it a bit easier to configure, and to write user documentation. It would be difficult for anyone else to figure out how to make it work until I do that.

If you want to look at the code, you can have anonymous GIT HTTP access through git.algoram.com/dvs/ . You can casually look at source online through gitweb.algoram.com. The developer documentation is at doc.algoram.com/dvs/.

– Bruce Perens K6BP