The main receiving window. Receiving the station "End Room" who's sending Unreal media.
J-QAM
A QAM soundcard modem.
Description:
Able to use the soundcard to send and receive data up to about 100kbs
on a standard soundcard by implementing the QAM modulation scheme. I'm
sure faster rates would be possible with the new higher-speed sound
cards, but the computer would need to be fast to cope with the workload.
Data can be two way or one way. Data can be sent via the RS232 port,
via UDP packets, Files, or by using "Unreal Media Server" with a live
source.
Features:
Speeds up to 100kbs with a standard sound card.
QAM16 and QAM64
Eight state TCM encoding.
Between 1% and 50% Interleaved RS forward error correction.
Blind equalization, frequency tracking.
Blind carrier frequency and symbol rate detection.
Packet type of data structure.
Able to perform multimedia streaming (sound and video).
Able to send files in continuous rotation with unused bandwidth
(sending of web page type content).
The story:
this program is something I have wanted to create ever since I was a
child when I heard about using different phases and amplitudes to send
data over telephone lines. QAM which stands for quadrature amplitude
modulation is exactly what this is. compared to modulation schemes like
FSK (frequency shift keying), QAM in contrast is unbelievably
complicated. QAM's advantage though is that this is much more efficient
than FSK. QAM is used in satellite TV, digital TV, telephone modems etc.
My specific aim was to create an application to send data using a simple FM transmitter from one computer to another computer using a computer sound card. what I had in my mind was to have one computer send data via a small transmitter while another one received it. I was not concerned about latency at all. I was also not concerned about fast turnaround of a radio frequency channel.
As far as I am aware no one has made a program like this for a computer's sound card, and I'm just too excited to spend a long time writing a manual and checking for all the bugs in the program, and given that no one is paying me a cent to do this I don't believe that I should. It has taken me about six months to create the first version of the program, and about 15 months to create the most recent version of the program. there are programs that are able to send data using the sound card but normally they use FSK which means they are unbelievably slow, also they tend to be aimed towards HAM operators that transmit very long distances over frequencies that contain a lot of noise or fade, ie HF. there are a couple of programs that don't use FSK the ones I know of are WinDrm, Dream, DIGTRX, these use OFDM which is from what I read superior to QAM over fading channels and is a very interesting modulation scheme indeed. Apparently Charles Brain G4GUO wrote a program for sending QAM using the sound card but I know nothing of it. None of these programs however will allow you to send video and audio at 80kb/s. So clearly there was a need for a program like mine. Also I can't believe no one has done something like it before, so I would like to be the first, if at all possible. This also gives me an incentive to put it on the web quickly. True, theirs I'm sure will be far more robust being sent via HF radio waves than mine, but maybe it will spark some interest in programs that use QAM and OFDM instead of FSK, and that is good.
THE FUN STUFF (streaming media):
I have tried some of the other media service with my program but they
all have major problems. VLC in UDP streaming uses far too much
bandwidth for what data gets through. Windows media server crashes my
computer. and real media server is just too confusing to use. so I went
for the only other one that I could find which was unreal
media server. it's main disadvantage is the player is kind of
sensitive to packet drop out. VLC can still be used with my program if
you want to give it a go.
with unreal media server you need to download both the server and the live server to stream video. My program imitates a unreal media TCP server which unreal media player can connect to. if you have not changed any of the TCP settings in my program, then, unreal media player will require localhost:1579 , unicast, TCP, live source alias=video. unreal media server will require setting up to have a live source with a alias called "video"
The main receiving window. Receiving the station "End Room" who's
sending Unreal media.
The ubiquitous constellation display and
also a frequency spectrum display.
TV being streamed.
Recently I have put a lot of work into making the demodulator (receiver) totally automatic. The demodulator is now able to detect all the settings the modulator can choose. On the demodulator side all one has to do is to press the start button and and the program will do the rest. this should make the set up of the demodulator easy. on the modulator side the set up is pretty much the same for all versions of the program.
for video streaming from one end of the house to the other a
common setting I use for the modulator set up is
freq=11300
alpha=0.1 (Root raised cosine variable.
wikipedia will explain all)
gamma=0.54 (fraction of a wave per constellation point. theoretical
limit is 0.5. don't go that low though)
modfir=500 (number of terms for modulation convolution, bigger is
better but increases latency)
constellation type=QAM64
samplerate=96000
RS error percent=20%
frame period=300
interleaving length=400 (this is big and
produces a lot of latency)
the data rate of this works out to be
((100-20)/100)*(11300/0.54)*5=83.7kbs.
if you want to know how gamma, the center frequency, alpha,
and bandwidth are related the following two equations explain this
relationship.
 |
J-QAM user manual V2. (a users manual for version 2.0a) |
|
|
J-QAM user manual v1.1 ish. (a users manual for version 1.1 ish) |
I have now added the ability to my program to be able to send web pages, sound files, video clips, programs, and whatever else in continuous rotation. this has a web based interface. It allows you to send other data in addition to streaming media or whatever in previously unused bandwidth. it has an FTP server to allow changing of the files and data to be sent. it makes one way transmission of data seem more interactive than just watching TV or audio.
Of course this requires a fast computer, no 386s allowed. mine is 2200
Athlon. it's slower than I would like for video. if you want to send
audio and video but you're computer can't hack the speed, then an
alternative could be using my
AV
sender program with a data transmitter like
Daniel's
data transceiver. this will use much lower CPU resources, but
as this is not synchronous data transmission its error correcting
abilities is weak so I would recommend just buying a faster computer.
In version 2.0a I have added a frequency spectrum display, it looks
pretty but if you really want to know what the frequency spectrum
really looks like then
I suggest you use a program like spectrum laboratory to see how the
settings change what the wave looks like. Here is an example of what
the frequency of the wave looks like after it has traveled from one end
of my house to the other through a little FM transmitter.
The reason it slopes down is due to high frequencies being attenuated
in the transmitter and in the receiver. the equalizer in my program
corrects this.
even though my sound card only goes up to 48000 I have found that setting my program to 96000 allows me to get very good results. I'm not 100% sure why this is, I do know though my program is called at 96000 times a second, which means it will not have to fudge the numbers quite as much. I can only assume this is the reason. In version 2.0a the program determines the carrier frequency by running a FFT on almost all sound cards seem to be 48000
Getting the signal from one computer to another:
there are two main ways to do this, either connect the sound cards up
directly using some wire, or transmit the sound via radio waves. the
wire method is fairly self-explanatory. For the radio
transmitter method, most any transmitter should do. There are a
plethora of one and two transistor FM transmitter circuits on the
Internet, any one of these that can be plugged into the sound card
should allow you to test my program.
Version 2 is quite different in its underlying structure from
the past versions. below are two interactive pictures that explain the
structure.
(Click on the components in the images!!!)
The Modulator.
The Demodulator.
For historical reference the block structure for versions around 1.2 are here.
| For more information on what I have written on how digital QAM works click the links below. Also, checkout wikipedia's QAM page. | |
|
|
The basic idea of digital QAM. (A discussion on how digital QAM works) |
| |
Recovering Carrier And Symbol timing. (A discussion on how to recover carrier and symbol timing) |
I have now done a long distance test of over 1km. I used a 1W transmitter using J-QAM version 1.1a. The terrain in between the transmitter and receiver was relatively hilly so the signal was relatively weak at the receiver. I tested it using QAM16 at freq=7kHz, alpha=0.35, gamma=0.75, making a speed of 28.8kbs with a bandwidth of 14kHz. the decoded signal had a very acceptable mean squared error (MSE) although from time to time it fluctuated quite a lot. my program said it had an MSE most of the time of around 10ish, and occasionally would fluctuate to values in the range of 40ish. My MSE is the mean squared error of the received path to the closest codeword path defined by the TCM scheme, also the numbers don't really have any known units. Multipath was not a problem for this test as I thought it might be. the main problem was little bursts of errors causing packets to be lost. This is a major problem for any practical application, especially for one-way communication as in my test. I was streaming audio in my test and the little bursts of errors caused very annoying interruptions in the audio stream. on making this program I was hoping that TCM would cure all the errors during transmission, I did not really think about burst errors. From what I've read TCM corrects for AWGN (the hiss heard on radio's) well, but it's unable to correct any burst errors. this isn't really surprising, for burst errors if you have only one-way communication, you need to somehow spread the data out temporally. Since version 1.1a I have added interleaved BCH forward error correction to version 1.2a, this should resolve the burst error problem totally at the expense of using 25% of the bandwidth. I have yet to test this out, although hopefully I should do it shortly.
In version 1.3a I have rewritten the data formatter and deformatter routines. This was needed as the error correction of version 1.2a was flawed. The scrambler is now an additive one. The error correction is RS with a block length of 255. The most important thing with the new code, is that it takes advantage of the synchronous nature of QAM. The "RS Error Percent" setting tell the program how much bandwidth to use for error correction. The "Frame Period" is how often sync frames are sent, they are 5bytes long and are sent every "Frame Period"*255 bytes. "Interleaving Length" is the number positions the interleaver can take, it acts like a buffer to spread data temporally, this resolves burst errors, it causes data to be delayed by "Interleaving Length"*"Interleaving Length" byes. I have only done a test from one end of the house to the other using little FM transmitters, but from what I have seen it looks good. Still, only longer distance tests really finds the things that need to be worked on.
Version 1.3.1a I have changed the audio library for one written by Volker Fischer. It doesn't use Directsound but is seems more robust and doesn't miss an audio sample. Saves 500k on memory too. Couple of other minor changes as well.
Version 1.3.2a Changed the acquisition routine to a different type, more systematic. More immune to burst errors. Uses slightly lower CPU. Interesting modification and is more standard for QAM, the equalizer no longer needs to track the symbol timing this is done by a modified Gardner algorithm. The receiver only initially adjusts it's frequency to the transmitter after witch time it has a accuracy of about 1/1000th of a Hertz, directed decision phase tracking adjusts the rest during normal operation. I can easily get 80Kb/s wma stereo audio from one end of the house to the other using this one.
Version 2 has total blind recovery of an arbitrary signal produced by version 2 of my program. lots of other bits and pieces also done on it. The first builds of this version had a couple of little mistakes so hence only third build is available.
this is a large program so do not be surprised if it still has bugs in it. Please feel free to correct them, I've included the source code which is written in C++ builder V6. I hope it inspires some people to do things. With computers getting faster one thing that could be possible is a new age of pirate TV stations. Little FM transmitters are very easy to make to cover little towns, using the QAM idea you could create your own TV station. if you do do this please tell me as I would be most thrilled.
Unfortunately it has come to light that the current version has some bugs when running on some computers, it drops soundcard buffers causing loss of synchronization and threads can stomp on each other. It would be real nice if someone could fix these bugs for me, but if not I may get around to fixing them one day.
I was writing an OFDM soundcard modem which would have probably been up and running in a month or two (from November 2008) but I'm putting that on the back burner for the moment.
Lastly this has been a huge amount of effort on my part,
creating such a program has taken 17months so far. The google ads so
far have brought in $17.21 over 9 months (57clicks for about 5000 downloads!!!), so lets get
clicking and click an add, see if we can get the figure into tripple
digits. (google doesn't payout anything till $100 is reached)
Please
do
your bit and click on one of my advertising links and/or donate ,
thank you.
| For donations just click the donate button below |
Downloads:
Jonti Olds
1 January 2009