A Sudden Puff, and the Amplifier’s Final is Gone

We were eating dinner while the Softrock and amplifier were running WSPR at the far end of the living room. Suddenly we heard a loud bang from that area. I went over and smelled a funny odor. The amplifier blew its final MOSFET.

Initially I got a bit annoyed, because the amplifier is really useful (my antenna is low, so the extra power is helpful in making contacts). But then I decided that I will probably enjoy figuring out what went wrong, so I relaxed.

I can’t say I know what went wrong. I did a quick troubleshooting session and discovered the following facts.

  1. The amplifier produces no power.
  2. The final appears to be an open circuit (I didn’t do a lot of measurements, but it is not shorted).
  3. The rest of the amplifier seems fine; the power supply section is working, the bias supply is working, and the transmit/receive switching is working.

When the final blew up, the antenna seemed fine, and the Softrock and antenna kept working without a problem afterward. So I don’t think that the antenna suddenly presented a high SWR that caused the amplifier to fail. I’m not 100%, but I don’t see why that would happen after several hours of working fine.

So what happened to the transistor? I blew up transistors in two amplifiers I built before this one, but in all cases I was able to tell why they failed, whereas here I’m not sure.

Three things can destroy a power transistor: over heating, over current, or over voltage. The MOSFET was not destroyed by over heating. The fan was working fine, and the heat sink was barely warm just after the transistor failed. Earlier that day I tried to run the amplifier without the fan for one 2-minute WSPR transmit cycle, and the heat sink got quite hot. This tells me that the thermal conductivity between the transistor and the heat sink is good; it’s not that the transistor got very hot but the heat sink stayed cool. They were both cool.

This leaves us with over voltage, which can be caused by high SWR, or over current. The amplifier was powered by a 24V, 1.8A switching power supply. The 24V supply puts around 50V on the transistor’s drain with 1:1 SWR, so with high SWR, the drain voltage can probably exceed the 100V limit of the IRF510. As I wrote above, the antenna’s SWR did not seem to suddenly increase, so it’s a bit strange.

The only reason that I can think of for an SWR-related failure is if the output pole T/R relay got stuck on receive while the input pole switched. This would cause the amplifier to produce RF power without any load. In theory one of the components of the output filter might have failed, rather than the relay, but that seemsunlikely.

I didn’t hear of a similar relay failure, but I think it’s possible, especially since the relay is very old (I took it out from some circuit I built about 25 years ago).

Another possibility is that the amplifier went into some wild oscillations. I didn’t see any such things on the bench, but I only tested the amplifier with a 50 Ohm load. The antenna’s impedance should be close to 5o Ohm resistive, but it’s not exactly 50 Ohm, so perhaps the mismatch sent the amplifier into oscillations. But because worked fine for several hours prior to the failure, I doubt that this is what happened.

What do I do now? I think I’ll replace the relay, just in case. I’ll probably also add a 75V Zener diode across the MOSFET, hoping it will fail rather than the MOSFET if something similar happens again. I can also try to replace the IRF510 with a 200V device, like an IRF630. I don’t think that such a device will fail at any SWR with a 24V supply, but they have a much higher input capacitance, which makes them harder to drive. The 1W of the Softrock may not be enough. Another protective measure might be to run the amplifier on a 16V supply I have rather than 24V; the will make it less likely that the drain exceeds 100V.

There’s another little puzzle in this. The audible puff and the odor were probably caused by high current that vaporized the transistor. The high current, in turn, was probably caused by the transistor failing by getting shorted. The vaporization that followed turned the short into an open circuit. I could be wrong, but that’s what I think happened. The puzzle is where did the large current come from. The power supply is rated at 1.8A, and it’s still working fine. 1.8A is not enough to destroy an IRF510; it is rated at 5.6A. So the instantaneous current must have been much higher. So the burst of energy must have come from some capacitor, most likely the electrolytic in the amplifier (either 4700uF or 2200uF, I’m not sure). Does a large electrolytic capacitor have enough energy to vaporize a power MOSFET? I didn’t think so, but perhaps it can. Should I have used a smaller capacitor just so that it can’t destroy the transistor?

If readers with more experience than me have some ideas about what might have gone wrong and how to avoid similar mishaps, I’d love to hear from you.

Roadless Israel in Google Maps Applications

An update: Google has now resolved this problem.

Go to some web site that uses Google Maps to display data (but not maps.google.com itself) and issue a query that returns a location in Israel. Chances are that it will look something like this screen (from QTH locator):

The target of the query, marked by the blue rectangle, looks like the rest of Israel completely roadless. On the right, you can see lots of roads in Jordan. But none in Israel. If you zoom in and enable the satellite imagery, you see that the blue rectangle is in  Tel-Aviv, which has plenty of roads:

If you search in the same web site a location in any other country, you will see all the roads. Here is another query from the same web site, which returns a location in the UK, showing both the satellite imagery and the road network:

This happens in pretty much any web site that uses Google Maps. It happens in OpenAPRS, in aprs.fi, in EveryTrail, and in every other Google Maps web application that I came across. They don’t show roads in Israel. It does not matter whether you visit the web site from Israel or from another country. Roads don’t show up. Try it out in your favorite map-enabled web site.

Interestingly, this does not happen if you go to maps.google.com. You can search a location in Israel and you’ll see roads. You can also search for a location outside Israel and drag the map to Israel and you’ll the roads. But only if you go to the maps.google.com.

I assume that this happens because Google licensed the Israeli road network under a restrictive license that does not allow Google to let third-party web site use this data. The licensor probably wanted to retain the ability to charge a fee from every web site that uses the road map. This strategy might work for Israeli web sites some of which might be willing to pay for the mapping service, but it probably fails completely for web sites with a global audience.

Google, please fix this! Maybe you can work a deal in which you provide the Israeli road map to web sites in which the fraction of Israeli visitors is small (and who are therefore unlikely to ever pay the licensor for these maps).

Failure to Use WSPR to Compare Antennas

Earlier this morning I decided to try to compare my the performance of my three loop antennas using WSPR. Because the WSPR protocol allows you to transmit and receive beacon transmissions and since it records the signal-to-noise ratio (SNR) of each received transmission, I thought it would be easy to compare antennas. I was wrong. It is not easy, even with WSPR.

The plan was to collect around an hour of spotting reports with one antenna, switch to another for an hour, then a third. By comparing the SNR of my signal at some specific remote stations, I would be able to compare the effectiveness of my transmitting loops. By comparing the SNR of some specific remote stations here, I would be able to compare the receive effectiveness.

I ran the experiment and started to look at the data. What I discovered very quickly was that the SNR reports varied considerably even with the same antenna. Each station beacons only every 10 minutes or so, so there is usually 10 or even 20 minute difference between signals of the same station. During this time, propagation conditions along the path change. Here is a graph of the SNR of several stations I received over a couple of hours (the graph only show the stations I received more than 5 times).

It’s easy to see that the SNR changes quickly and dramatically. DK8FT went up by about 10dB in 40 minutes. UA3ARC took a dive of about 10dB at the same time that the signal of OH2GAX was getting stronger. To make sure that this was not something caused by something going wrong at my end, I plotted the SNR of signals received by another station, UA3ARC, over several hours (covering the time in the graph above). The results are similar.

The signal of G4IHZ degraded by 15dB in less than an hour. The correlation between the SNR of the two English stations, G4IHZ and G4CUI, shows that the variations are caused by changes in the propagation along the path (the two transmitter are close so the paths to the receiver are similar).

Clearly, you can’t compare antennas using WSPR using the naive technique that I was using. The differences I saw between antennas were on the same scale as the variation of the reports from a single antenna, so it’s impossible to compare the antennas this way, at least not without filtering the huge noise in SNR that the changing propagation creates.

Other people who took the time to run similar experiments for long periods of time and to average the reports got more robust results. Patrick Destrem switched between two transmitting antenna and averaged the results. He used a computer-controlled antenna switch to switched between the two antennas, so he could use a different one in every WSPR transmission cycle. It is not exactly clear how he got the smooth curves that suggest that his vertical antenna is better than the dipole, but the curve does seem to show this. His plot of all the reports is very noisy, like mine, so the averaging is crucial. I think he fitted a low-degree (probably degree 4) polynomial to all the data points. This fitting is a bit strange, because it suggests reasonable propagation even between 2m and 6am, when in fact there was no propagation at all. Patrick used a similar methodology to compare two receiving antennas, although with a relatively small number of data points.

Stu Phillips compared two transmitting antennas by beaconing from each one for about a week and comparing the reports. This is not as good as Patrick’s rapid-switching method, because propagation in the two weeks is not necessarily the same. He did draw some interesting conclusions from the results, but they the differences were not as dramatic as he hoped they would be.

Charles Preston compared two transmitting antennas by beaconing from them simultaneously, using two separate transmitters. This is even better than Patrick’s rapid-switching method, but this requires more equipment, of course. Unfortunately, he did not collect a lot of data, so it’s hard to draw conclusions from his results.

In hindsight, using WSPR to compare the two transmitting loops was a lousy idea. What I wanted to know was which antenna was more efficient. That is, which one converts more of the input power to electromagnetic waves and less to heat. It probably makes more sense to figure this out with a field-strength meter than with SNR reports from thousands of kilometers away. The WSPR comparisons are probably useful for evaluating the usefulness of radiation patterns, but all my loops should have pretty much the same patterns. I’ll try this again with a field-strength meter to see if I can see a difference.

WSPR vs. PSK Reporter

In the last few days I’ve started experimenting with WSPR, a mode for radio beaconing. You run a program (called WSPR) that sends a beacon transmission once in a while and listen’s to other people’s beacons the rest of the time. The program uploads its reception reports to a web site, wsprnet.org, so you can see who received your beacon signal at at what signal-to-noise ratio.

WSPR is basically an unattended operation. Once the program is running, there is really nothing for you to do. You can check who spotted you and who you spotted, but that’s watching, not doing.

It’s interesting to compare WSPR to PSK reporter, the website that collects and presents PSK31 reception reports.

The main difference is that WSPR is more symmetric. You can both transmit and spot other people’s transmissions. This tells you how well your receiving system works and how well your transmitting system works (it also tell you, of course, whether there is propagation in the path, which it the main objective of WSPR). PSK Reporter is less symmetric. You can leave your receiver on overnight and see in the morning who you received, but you are not supposed to beacon all night to see who can receive your signal and when. What you spot in PSK reporter is not beacons, but actual communication between two stations (or at least, stations attempting to communicate with someone).

The flip side of this is that WSPR is more boring to most people. There is not much to do but monitor what’s happening. PSK31, on the other hand, is an actual activity (unless you are just passively reporting). You have to tune to a signal, see who’s calling, respond to their call, see if they heard you or not, and so on. Even though many people use keyboard macros for the actual communication, there’s still something for the operator to do. I guess many people find this satisfying.

The result of PSK31 being less boring is that more people appear to do it than WSPR. I don’t have actual statistics, but my PSK reporting nights resulted in spotting more stations in many more countries than WSPR spotting nights. More stations and more countries make spotting more exciting, at least to me.

So that’s the main tradeoff. In WSPR you can transmit and see who receives you without human intervention, whereas in PSK31 if you want to see who receives you then you must contact people. On the other hand, there’s more activity in PSK31 than in WSPR.

The other main difference is that WSPR is much more reliable. PSK reporter works by finding a patten that matches “de <callsign> <callsign>” in the text of the transmission. The only error detection mechanism is the exact repetition of the callsign. PSK31 does not have any other error detection or correction built in, so corrupt received text is very common. The probability of having the exactly the same error in both occurrences of the callsign is not huge, but it’s not close to zero at all. My reports (using DM780)  on PSK reporter include quite a few bogus reports. (To be fair, PSK31 was designed for human-to-human chatting, with error detection and correction to be done by the human operators, whereas WSPR was designed for computer-to-computer communication.)

An update: WSPR is not perfect either. I supposedly received callsign 2V2YFX with locator in the ocean near Antarctica. I was the only station to receive it. So WSPR’s error detection is not that strong either, unfortunately.

The web interfaces to both systems are both fantastic, but there are big differences here too. In PSK reporter, the map interface is excellent. You can filter by either transmitter or receiver, or country, band, or mode (PSK reporter collects spots of several modes, not just PSK). The mapped results are color coded by band and are visually compact; they normally show just a marker, not the callsign. If you click on a marker you get more information. The WSPR web site also has a map interface, but it’s not as good. You can filter by callsign, but it will show reports where the call sign is either the transmitter or the receiver; you can’t select only one direction. The results are shows with arcs connecting the receiver and transmitter, which really clutters the map, and with callsigns, which again clutter the map. The arcs have some color and width coding, but I could not figure out what the coding it.

The markers in PSK reporter are decorated so that a very compact visual marker carries quite a bit of information. You can distinguish stations that were spotted recently and stations that have accounts on eQSL.cc or on LOTW (this increases the confidence that the callsign is correct). I wish that the map also marked stations that are dubious; they should not be too hard to classify. Basically, if there are many reporters, than lone reports are probably bogus, because typically many reporters will spot each stations. Obviously single-reporter spots are not always bogus, but as long as they are still shown on the map (with a decoration suggesting they might be bogus), we don’t lose any information.

Both web sites also show database results in a tabular way. Here the WSPR web site is better, with much more control over the queries, good displays that refresh automatically (the maps in both web sites refresh automatically), and with all the historical data available for download in database format.

I am very pleased with both systems. PSK reporter allowed me to collect many reception reports over several nights, including reception of stations in some very far and fairly exotic places. WSPR also allows me to see where my signal is reaching without making macro-style contact (which I don’t like). I am happy to see that my Softrock, 16W homebrewed amplifier, and homebrewed loop antenna reach all the way to Japan, Australia, Canada, and the US. So far running the Softrock barefoot at 1W only reached Europe, but I’m sure it can reach further with patience.

A Tuned Active Receiving Loop

Charles Wenzel presents on his web site a simple and clever tuned receiving loop antenna, which works very well. The antenna consists of essentially three parts: a large wire loop, a varactor diode (voltage-controlled variable capacitor) that forms a parallel resonant circuit with the loop, and an amplifier that transforms the high impedance of the parallel tuned circuit to a low impedance for driving the coax and the receiver.

There are two clever ideas Charles’ design. One is the use of parallel resonance, rather than the series resonance that many active loop circuits use. The use of parallel resonance allows the design to maintain balance without transformers, and I think that it also reduces the significance of Ohmic losses, although they are probably less important in receiving antennas than for transmitting antennas, at least on HF. The other clever idea is the use of a differential video IC, a TL592, as the amplifier. The chip has high-impedance input, high enough bandwidth for HF, and is very easy to use. The amplifier part of the antenna consists of the chip, 5 resistors, and two capacitor. No transformers at all. You can set the voltage gain of the TL592 to values between about 15 and 400; the amplifier sets it to 15.

Charles not only put the design on his web site, he even sent me a few TL592 to try it out! Thanks Charles.

I built the loop out of the same polyethylene-coated aluminum tube that I used for my transmitting loop. I filed away the polyethylene at the ends of a 90cm-diameter loop and drilled holes for screws.

The amplifier is built on a piece of unetched PCB in which I scored pads with a knife. Two large pads with holes are used to connect the amplifier to the loop. I didn’t have the varacator that Charles used, so I used a pair of MV1404’s that I had in parallel, for increased capacitance. The flat ribbon cable that exists on the right carries power and control voltage for the varactors.

Charles’s amplifier includes a relay that can connect an inductor in parallel with the varactor, to cancel out some of the capacitance so that the antenna can tune higher in frequency. I didn’t include one yet.

To tune the antenna, I attached a 10-turn potentiometer to a piece of board to which I also attached the control wires and a 12V jack. Because the voltage limit of my varactors is 12V, I added a 2.7k resistor in series with the 10k potentiometer, to limit the control voltage to a bit over 9V. A 2k resistor is probably more appropriate, allowing the varactors to be biased at up to 10V.

That’s pretty much it, as far as construction goes. I didn’t put the amplifier in a weather proof box, just screwed the loop to it. This is good enough for experimentation, but not for extended use.

How well does it work? It works fantastically. Just outside the balcony, the 90cm loop pulls in lots and lots of signals. One evening I monitored the 7MHz, 10MHz, and 14MHz PSK31 frequencies, and was able to receive many stations on each one of them. I left the software running overnight monitoring 14MHz. The pskreporter.info map below shows the stations I received on all three bands (14MHz in orange, 10 in green, and 7 in blue). I was able to receive numerous European stations, some in the middle east, two in Africa, and several on the east cost of North America. I also logged one Japanese station now shown on the map.

The following night, I left the software running monitoring 7MHz, but with an even simpler receiver, a Softrock Lite II, a $10 kit. The results are just as good, again reaching the east coast of North and South America. The two African stations are spurious reports; they appear to be incomplete call signs that pskreporter.info incorrectly assigned to these countries (nobody else reported them, as opposed to the 14MHz African stations that many monitors reported the night before).

As Charles writes, tuning is not critical. He placed a 4.7k resistor across the parallel tuned circuit, which reduces the circuits Q. I’m curious as to whether the signal-to-noise ratio would improve if I increase this resistor (at the expense of more difficult tuning), but I have not yet tried that. With the 4.7k resistor, my 10-turn potentiometer is more of a liability than an asset.

I was a bit nervous about tuning a receiving antenna. Charles writes that you need to tune for maximum received noise. This is a bit more challenging than tuning a transmitting antenna, where you can tune by looking for a dip in a meter or a LED, but it works. It’s easy when the band is open and you can receive signals and harder when the band is almost dead. You may wonder why one would want to tune an antenna to a band that’s dead, but the point is that you don’t know it’s dead until you tune the antenna. When the tuning is completely off, you receive essentially nothing even when the receiver is tuned to a strong station.

The simplicity of the amplifier seems to come at a certain cost. At some positions of the tuning potentiometer, strong AM station appeared where they don’t actually transmit (that is, in the middle of an amateur band). As I continued to turn the tuning knob, the station would disappear. I think that this happened mostly when the tuning was a bit off, but not completely off. Maybe these were shortwave broadcast stations in the bands above or below the amateur band I was tuned to, but I’m not sure. In any case, it indicates distortion in the amplifier. This is not completely surprising in an amplifier that uses a chip that is not at all designed to sit at the front end of a radio. When I wrote about this to Charles, he wrote that he also experienced some problems, with strong FM stations in his case. It’s a bit annoying, but the antenna is still a joy to use.

I should also add that I forgot to include the 10u capacitor in the circuit. This might have contributed to the overloading; I’ll add it and revisit the issue soon. (Update: I added decoupling capacitors and they didn’t improve the overloading at all.)

There are several other designs on the web for receiving-loop amplifiers. About two years ago I built an untuned loop amplifier designed by John Hawes, which Des Kostryca published on the web. I’ve used it, but I’m not too impressed with its performance. To be honest, I didn’t really compare it to Charles Wenzel’s amplifier when both were using the same loop element, so maybe the loop I was using with Hawes’ amplifier was not good enough. I’ll have to investigate this in the future.

Chris Trask published two designs for receiving loops. Both use series tuning, not parallel tuning, so his designs need to transform the very low impedance of the loop to 50Ω, whereas Wenzel’s design transforms a high impedance to 50Ω. Trask first receiving loop design, published in QEX in July/August and September/October 2003, is an active loop with a 3-transistor amplifier. The circuit is pretty complicated for one using only 3 transistors, using 4 transformers for impedance transformations and for feedback. Trask’s second receiving loop is passive, using varactors for tuning and transformers for impedance transformation, but no transistors or integrated circuits. Chris writes that the designs has very good signal-to-noise ratio that eliminates the need for amplification. I assume that he means that this design is essentially better than his QEX amplifier.

Another example of parallel high-impedance loop tuning is Daniel Wissell’s SLR receiver (in QST, October 1997). The high-impedance tuned antenna is connected directly to the 1.5kΩ-impedance input of an SA602A mixer.

Interestingly, Chris Trask also presents a balanced, tuned, high-impedance active-antenna amplifier, but not for loops but for short dipoles. A short dipole is capacitive, requiring inductance to tune. Therefore, the input network in this amplifier is not suitable for loops. But I assume that the design can be adapted to parallel-tuned loops but simply replacing the input network. Such a design might perform better than Wenzel’s TL592 amplifier, but it is also quite a bit more complex.

In summary, varactor-tuned loops are excellent receiving antennas, and Charles Wenzel’s design is simple and effective. It does appear to get overloaded sometimes.

An Active Whip Receiving Antenna

In my quest to find small antennas that work well I decided to try to build an active whip, a small vertical antenna connected to a preamplifier. The role of the preamplifier in this case is to transform the high impedance of the 50Ω of the receiver and the coax cable.

There are several designs for such amplifiers on the web. The one I built is Chris Trask‘s wideband complementary pull-push amplifier whose schematics are shown on the right. One JFET (the bottom one) functions as a current sink, another to transform the high input impedance to a lower one, and a pair of NPN and PNP transistors to drive the 50Ω load.

There are simpler designs for such amplifiers. Charles Wenzel’s design uses only one JFET and one NPN transistors, and is also wideband. Todd Gale presents several designs, both wideband and tuned narrowband (here and here). All of Todd’s designs use two transistors in a cascode configuration.

Chris’s web site actually presents not one, but two designs. In addition to the one I used, he also presents a design that uses two wideband transformers to eliminate the need for an PNP transistors. I decided to use the simpler design with the PNP transistors, since Chris wrote that the amplifier works reasonably even with the common 2N2907 transistor (but he also writes that it works better with more expensive RF transistors).

I thought that the two extra transistors in Chris Trask’s pull-push design were worth the effort and built that one. I built it into an aluminum box salvaged from some small surplus VHF amplifier, and used a 50cm telescopic antenna as the receiving element. A longer antenna would work better, but that’s what I had. If I find a longer one, I’ll replace it.  Power is supplied through the coax, using a bias T near the receiver and using an RF choke to separate the DC from the RF in the amplifier.

The amplifier does not seem to overload or generate intermodulation, even though it is very wide band. This correlates with Chris’s analysis and measurements. In my usual location, the antenna worked reasonably. I was able to receive numerous shortwave broadcast stations, as well as radio amateurs on 14MHz. On the lower bands, receiving amateurs was more difficult. I didn’t hear anything on the 10MHz PSK31 frequency. On 7MHz I was able to pick up PSK31 transmissions, but very few. Even on 14MHz, signal strengths were weaker than with a 1.25m tuned loop, but that’s not surprising.

I left the receiver and computer working overnight, sending PSK31 reception reports to pskreporter.info. The map shows most of what I received during one weekday evening and night. The data collection was done with a Softrock Ensemble hardware, sdr-radio.com software, and DM780‘s PSK31 decoder and collector. DM780 decodes only some fraction of the signals, not all of them (partially because I use a trial version of VAC to route audio), so these are not the only stations I received. But the map shows that the antenna performs reasonably. You can also see on the map the one 7Mhz station received. The receiver was tuned to 14MHz most of the time, so don’t read too much into this lone reception, but as I wrote, signals on 7MHz were very weak.

The final transistors get quite hot. The dissipate about 300mW each (50mA across 6V). They can dissipate up to 500mW at 25C without a heat sink, so the 300mW is not way too much, but it’s close. Chris wrote to me not to worry about this unless the amplifier is used in the sun in the tropics. Tel-Aviv in the summer probably qualifies as the tropics for this purpose, so I should probably put a heat sink on the transistors.

I can still receive signals when the bias T, and hence the amplifier, is not powered. Signals are weaker, but they are still there. Chris wrote to me that this is caused by the signals leaking through the unpowered transistors.

In summary, this is a reasonable antenna for receiving strong broadcast stations and even for amateur signals on the higher bands. The amplifier does not overload easily. It does not require tuning, so you can quickly jump from one frequency to another, which is nice. With a short receiving element, signals are weak, especially on the lower bands.

Controlling an Si570 from Java and Matlab

I am experimenting with software-defined radio (SDR) code in Matlab. One of the things I wanted was to be able to do is set the frequency of the Si570 that clocks the Softrock Ensemble from Matlab. Rather than write Matlab code to do that, I wrote a Java code to do that; it’s trivial to call Java from Matlab.

The Si570 is controlled through I2C by an AVR microcontroller, which is controlled in turn by a PC through a USB connection. The AVR’s firmware was written by Fred Krom (based on earlier code by Tom Baier). To communicate with the AVR from PC programs, Fred uses libusb, a portable kernel driver and a library that allows user-mode programs to communicate with USB devices.,  Fortunately, there is a Java interface to libusb. All of this software is open source.

I downloaded the library and installed it on Windows XP. This included a jar file (Java library) and a Windows DLL that needs to be copied to c:\windows\system32. Libusb consists of a couple of other drivers that need to be in c:\windows\system32, but they were already there. The test program that comes with Java libusb worked and listed the Softrock’s USB device. I wrote a small class that tries to open the device and read the frequency it is set to. It failed.

The code failed to open the device because Java libusb complained that the device has no endpoints (endpoints are logical USB communication channels). The trouble was that Fred and Tom’s firmware communicate only through the control endpoint, the one endpoint that always exists. The Java library assumes that the device would define at least more endpoint, which is true for most devices. But not for the Softrock’s AVR. I downloaded the sources of Java libusb, found the spot where it checks for the existence of endpoints (other than the control endpoint), and removed this check. Now the code works. Andreas Schläpfer, the developer who wrote the code, wrote to me that he’s fix the library.

Calling my Java code from Matlab was a bit tricky. I had to do two things to get it to work. I had to add the location of the Java binaries to Matlab’s Java class path using the javaclasspath function, and to add c:\windows\system32 to Matlab’s binary search path, which is listed in $matlabroot/toolbox/local/librarypath.txt.

That was it. Now I can set and read the Si570’s frequency directly from Matlab (and from Java code). The firmware has many other features that can be controlled by the PC, but they are less important to me now so my code does not support them.

The Matlab code to receive signals is coming along. By carefully reading part 3 of Gerald Youngblood’s article Software Defined Radio for the Masses and the corresponding text in Steven Smith’s book The Scientist and Engineer’s Guide to Digital Signal Processing (the corresponding text consists of most of this book:-), I was able to implement code that demodulates an SSB signal in the passband of the Softrock. Both sources are available freely on the web.