August 17, 2012: Updated the system (SDR firmware and software) for continuous coverage of 0 to 29 MHz! Also the user interface got a few new features: memory channels and a squelch.
October 18, 2012: I've (temporarily?) installed an experimental preamp to
improve the sensitivity on higher frequencies. Reports about whether this
is an improvement would be appreciated.
(Unfortunately, the preamp gets overloaded by the local pager transmitter
on 26950 kHz, hence the many spurious signal in that area now.)
November 24, 2012: Over the last couple of months, the system has been extended by a WSPR receiver, which monitors all amateur bands for WSPR signals, and a chirp receiver, which shows propagation possibilities to a number of locations.
December 11, 2012: An automatic notch filter has been added, albeit only for SSB and CW. It can be turned on and off using the tickbox near the S-meter. Reports about this would be appreciated.
December 24, 2012: Today day marks the 5th anniversary of the WebSDR! Exactly 5 years ago, I (PA3FWM) activated the first experimental version of the WebSDR, albeit only a recording and not public yet. Live reception followed a few days later, and public announcement after more developent in April 2008.
December 25, 2012: Welcome to the participants in the LF Non-Directional Beacon (NDB) enthusiasts' 164th Co-ordinated Listening Event (CLE), using this receiver from 25 till 31 December! More information is on the NDB list info site and on the CLE page there (see CLE164). Participation is also open to non-members of the NDB list, so feel free to give NDB hunting a try!
January 6, 2013: Just a note: during the NDB (Non-Directional Beacon) listening event over the Christmas break using this WebSDR, a total of 387 beacons from 49 (radio) countries were reported, by 25 participants. The best DX was a beacon from 4738 km away, at Cape Verde. Details are at http://www.ndblist.info/cle.htm, under "CLE164 combined results".
January 21:Recently there has been a lot of fuzz about security problems with Java. Because of that, some software distributors no longer include Java, or install it such that it asks for permission to run the Java applets on this page. In fact, it may ask three times, because there are three Java applets (waterfall, audio, and Java version test) on this page. This is (unfortunately) normal now.
January 28:I've integrated the java version test applet into the audio applet, so now you should need to give Java permission only two times.
March 2: The receivers shows lots of spurious signals today, e.g., broadcast signals from around 9.5 MHz appearing around 19.44 MHz higher in the 10 m amateur band. There was a power failure in the building this morning, and I think the SDR hardware did not initialize properly after that, causing this problem. I'll reset the hardware in the next few days when I visit the radio club room again (I can't do that remotely from home).
March 3: Restarted the system; the spurious signals are now gone.
Update July 7, 2013: Added lots of frequency labels using data from http://www.eibispace.de/
Update August 20, 2013: If using the HTML5 audio, the received audio can now be recorded (see the controls just below the S-meter).
Update October 8, 2013: There's now a special (and experimental) version of this page for use on devices with small screens (smartphones and tablets). It is at http://websdr.ewi.utwente.nl:8901/m.html and should work with Safari on iOS 6 (and newer) devices, and with recent Firefox versions on Android devices.
Update December 15, 2013: Several small updates. There's now a possibility to make a graph of
the received signal strength, recorded audio filenames are more meaningful, the problem of duplicate
lines in the chatbox should be gone, and the waterfall controls have been rearranged a bit.
Unfortunately, I haven't been able to fix the problem of the audio suddenly stopping
(only in Firefox with HTML5) yet.
Update February 9, 2014: Several small updates.
It's now possible to tune using the keyboard (frequency up/down, mode selection).
If you have a USB tuning knob which can be programmed to produce key presses,
you can now use it for tuning. Also, it may be useful for blind users.
Since intercepting keypresses can also be disturbing the normal use,
it needs to be explicitly enabled, using a checkbox just above the waterfall.
The Firefox HTML5 audio issue seems to be a bug in Firefox,
which I've reported.
Update February 28, 2014: I've made a workaround for the Firefox HTML5 audio bug; I can't prevent the bug from happening, but after detecting that it happens, the audio is now automatically restarted.
Update March 26, 2014:
The previous workaround only worked correctly on some Firefox versions;
on others, it caused the restarted sound to be interrupted continuously.
I've now fixed this too (tested on the current Firefox 28).
If you still have problems with HTML5 audio stopping in Firefox, please let me
know (by e-mail to pa3fwm@websdr.org).
April 3, 2014:
There currently are frequent (about once per minute or so) interruptions
of the sound and the waterfall, with each interruption lasting about 2.5 seconds.
This is independent of the browser being used.
It turns out this is caused by a problem on the gigabit ethernet
connection between the SDR board and the server computer: for some
reason, this ethernet connection is resetting spontaneously,
which takes about 2.5 seconds each time.
I'll of course try to fix it, but do not yet know the cause, so this may
take some time.
April 8, 2014: Yesterday, we removed dust from the SDR board's fan, and since then the intermittent ethernet problem has not occurred again; so apparently the ethernet circuit was getting too hot due to lack of ventilation.
May 27, 2014:
Since a week or so, the system occasionally fails and then only gives periodic
brief bursts of audio. This is caused by a problem on the ethernet connection
between the SDR board and the server computer, and persists until I manually
reset that connection. Sorry for the inconvenience; I will of course try to
permanently fix it, but that may take some time.
More details for those interested: the link between the SDR and the server is
a gigabit ethernet link. On such a link, both sides "negotiate"
what speed to use, and the problem occurs when they have accidentally negotiated
to use 100 Mbit/s. That is not nearly fast enough to transport all data from the SDR
to the server, hence the interruptions.
I think the problem is on the SDR board, since improving the cooling of the
board recently helped a bit to improve the stability of the ethernet link.
But finding the real cause is not easy; it may be a bad contact or so.
Since one chatbox user apparently thinks he/she knows better and tells people
the problem is not in the ethernet connection, here
is an extract from the kernel log showing the relevant ethernet messages.
Update June 3, 2014: Last Wednesday, I moved the fan on the SDR a bit so there's a bit more airflow over the ethernet chip. I didn't expect much of it, but we haven't had a single ethernet interruption in the 6 days since then! (However, the chip shouldn't need so much cooling, so there must still be something wrong in that part of the circuit.)
Update June 19, 2014: Since yesterday, most of the time there has been a strong noise, making the lower frequencies up to about 3.3 MHz unusable. So far, we only know that it seems to originate outside our radio room, since it disappears if we disconnect the antenna cable. We'll try to hunt it down further soon.
Update June 21, 2014: Yesterday around lunch time, I went out with a portable mediumwave radio to try to find the source of the noise. However, while doing this, the noise disappeared spontaneously, and it hasn't come back, yet. The cause is still unknown. If it returns, we'll search further...
Update October 8, 2017:
Last week, the antenna kept us busy.
On Monday evening, we finally got it indoors to fix the intermittent problem
that had plagued it for several months. The cause seems to have been a broken
wire off the output coupling capacitor. Fixed this.
On Thursday, the antenna failed. There was a storm that day and apparently water had sneaked in
(apparently it wasn't quite waterproof after Monday's repair).
After a preliminary repair (i.e., drying and waterproofing) the antenna worked for a while but failed again.
On Friday, we found the cause of this, an apparently mis-bent wire touching a metal-can transistor.