Twin City FM Club

Thanks for the response! I will look at the forums at eham.net and QRZ. I think I had looked at them to see if there were any links to examples but didn't pose the question.

One of the reasons I asked the question in the first place is that I have the MFJ 418 and have looked at a couple QSO generators on the Internet, and they all seem to differ in the format of the QSO. I assumed that the difference resulted from changes in the format of the "real" QSO's given for an exam. I found someone who had many QSO's in some zip files (I think there was a total of 900), I parsed these QSO's and determined that there were 3 different "base" QSO formats in the 900 QSO's. I took all the variables out. Our program picks a random "base" format, insert all the variable information at random and generates an .mp3 file that can be listened to over the Internet. I added a couple things from the MFJ 418 QSO's also. One thing in particular was to randomly include the current temperature from the transmitting stations location. I attempted to make the program as smart as possible, ie it won't ask what the temperature was if the temperature wasn't given, the number in the senders call sign is the actual number for the QTH that is sent in the QSO, if the temperature is given it will match other details included in the weather information, so it won't be reported that it is "sunny and warm", but the temperature is 40, etc. The temperature will match the climate of the QTH of the sender in the QSO, etc.

Yes, the call signs seem to be the place to make up the characters that don't appear in the rest of the QSO. Our program generates call signs using the rarer letters and each QSO is checked for all required characters before the audio file is generated and presented to the visitor, it sometimes has to generate 3000 or more QSO's before it gets one that has all required characters (it generally takes less than 1 second to generate an acceptable QSO, even if it has to generate 3000 of them, creating the audio takes quite a bit longer...)

I was hoping a VE would see my question and take the time to visit the web site and see if the format is roughly similar to the QSO's that are given in the current exams. If there is someone who is willing to take the time you can visit :

http://www.mindformation.com/cgi-bin/qso_generator.pl

That page will ONLY display the text of a QSO, once there, you can just hit reload and you will get a different QSO, it happens very quickly so it shouldn't take long to look at several QSO's.

For anyone else who is interested in taking a practice morse code test on the web, or if you want to take a practice Technician, General or Extra test, you can visit :

http://www.mindformation.com/hamradio/index.html

then just choose which test you want.

Hopefully there is no problem with giving these addresses here, this is one of our (KC0UQY and mine) personal websites, there are no advertisements and we have no pecuniary interest in any visits to the web page. The programs that generate the tests were written to assist us in getting and advancing our licenses, but were made available for anyones use.

--
Tom Green - W1SDM
http://www.mindformation.com/

I agree that having a VE go over the output is a good idea. Though from what little I know, it sounds like you have a good tool already. It also sounds like you went through a lot of work to get things right that I wouldd possibly not have done were I in your place.

With the number of snowbirds I know of, as well as the people I know who regularly travel, I suppose it would be a good idea to review the location dependent code and use mobile location information to throw off some of the results. So for example someone form tens area working out of their winter home in FL (3?) might have a call like KG0VVK/3, potentially reporting extreamly cold days of 60 degrees in February, and not be wrong.

I don't know how multiple '/' suffixes are handled, is an AG out of their home area for example with the same call, KG0VVK/AG3, or KG0VVK/3AG?

At the same time from what I understand the moblie area suffix is not really a requirement, just often included as a courtesy.

If the random generator is kicking out as many as 3000 samples ge get a usable QSO, it sounds like there might be some room for improvement on the generation and testing code. Though it sounds like it isn't too bad at the moment. One possible idea would be to use the current system to build a table of a couple thousand or a million qso's then use a random number generator to kick out any one of that collection to the person looking for the QSU. Then you can use the processor time to kick out the resulting MP3.

If storage space is the issue, save the 'seed' for the random number generator that generates a usable QSO, Presuming that the seed is a 16 digit number, and you store a million or so of those, you could probably store the .au clips of each character, along with appropriate length blank .au files for pauses betwen characters, words and transmition blocks, in three or four different frequencies. A quick script pastes that collection together from the text generated from the seed, and the output fo that goes through Lame to convert it into the .mp3 file.

One thing to do with the text of the QSO would be to toss it in as the lyrics of the mP3 file rather than having a second file that the user downloads for each sample qso. Unfortunately I don't know enough about setting up enhanced ID3 tags to advise how to insert the lyrics. It may only be availabe for AAC files for all I know. Which might be usefull for iPod owners, though I don't know who else can take advantage of the file type.

Good luck, and if you get good feedback from eHam.ne or qrz, I would love to use some of the results for a couple of projects I am playing around with at the moment.

73,

-Rusty - kc0vcu

Rusty,

I read your comments earlier this morning on digg, now I see more from you here! I seem to be following you around the Internet!

You wrote:
"I agree that having a VE go over the output is a good idea. Though from what little I know, it sounds like you have a good tool already. It also sounds like you went through a lot of work to get things right that I wouldd possibly not have done were I in your place.

With the number of snowbirds I know of, as well as the people I know who regularly travel, I suppose it would be a good idea to review the location dependent code and use mobile location information to throw off some of the results. So for example someone form tens area working out of their winter home in FL (3?) might have a call like KG0VVK/3, potentially reporting extreamly cold days of 60 degrees in February, and not be wrong.

I don't know how multiple '/' suffixes are handled, is an AG out of their home area for example with the same call, KG0VVK/AG3, or KG0VVK/3AG?"

That's a good question. I am not sure of the answer.

"At the same time from what I understand the moblie area suffix is not really a requirement, just often included as a courtesy."

Exactly, so if it were me I would use /AG3, putting the AG first, since that is required and the 3 is, as you say, a courtesy. How about /AG/3 ? :) From what I have read they use it in the tests in order to get the / in there...

"If the random generator is kicking out as many as 3000 samples ge get a usable QSO, it sounds like there might be some room for improvement on the generation and testing code. Though it sounds like it isn't too bad at the moment. One possible idea would be to use the current system to build a table of a couple thousand or a million qso's then use a random number generator to kick out any one of that collection to the person looking for the QSU. Then you can use the processor time to kick out the resulting MP3."

Very good suggestion! Although, it occasionally will take around 3000 loops, it generally is much less. Even when it is 3000 it takes less than one second to generate them, so the speed of the generation isn't really an issue.

"If storage space is the issue, save the 'seed' for the random number generator that generates a usable QSO, Presuming that the seed is a 16 digit number, and you store a million or so of those, you could probably store the .au clips of each character, along with appropriate length blank .au files for pauses betwen characters, words and transmition blocks, in three or four different frequencies. A quick script pastes that collection together from the text generated from the seed, and the output fo that goes through Lame to convert it into the .mp3 file."

That is something I hadn't looked at. I don't have a whole lot of experience with generating or dealing with audio files. Would joining the .au files together just be a matter of reading them as data files, and put them in a new .au file one after the other? I assume that lame will convert .au to .mp3? I am using some perl code that will generate the morse code files as a .wav and then I use lame to convert it to .mp3. The .au method, if it is as easy as just adding the single string, would be much simpler and probably much less time consuming. The program spends most of it's time generating the .wav file. I think it takes about 1 second to generate the QSO with all the required characters, about 50 seconds to generate the .wav file and around 5 seconds for lame to convert it to an mp3. I will look into the .au file format...

"One thing to do with the text of the QSO would be to toss it in as the lyrics of the mP3 file rather than having a second file that the user downloads for each sample qso. Unfortunately I don't know enough about setting up enhanced ID3 tags to advise how to insert the lyrics. It may only be availabe for AAC files for all I know. Which might be usefull for iPod owners, though I don't know who else can take advantage of the file type."

Yeah, I am not sure how to get the "lyrics" into an mp3 either. If there is a Perl module to do it then I probably could handle it.

"Good luck, and if you get good feedback from eHam.ne or qrz, I would love to use some of the results for a couple of projects I am playing around with at the moment."

There was a bit of discussion on QRZ, mostly things that have been discussed here. One person felt that I was reinventing the wheel, which of course I am. At least in a way, the other web sites that I have seen will generate the morse code file, but they then just send you the file, no actual test is generated. Not that big of deal since just practicing copying the code is the most important aspect, but I thought the way I was doing it was a little more interactive.

And now that they are going to eliminate the code requirement, the usefulness of the program probably has decreased. Now I have to bust my butt to get good enough in time to actually be able to pass the morse code test. I don't like the code being dropped, for various reasons, hopefully I still have time before they stop giving tests!

Thanks for your input, it is very much appreciated!

--
Tom Green - W1SDM
http://www.mindformation.com/

.au files are pcm coded files, similar to .wav files, but without the formatting header at the begining of the file. Essentially they are raw pcm for the audio. The big advantage to .au files is that you can simply concatinate them together to make a longer .au file, or pcm stream.

The gotcha is that they don't have the .wav header at the begining of them, which includes such information as the sample rate, sample size, and number of channels. However if you are already keeping track of that you can pass those paramaters into Lame as paramaters, or possibly create an appropriate header that the raw pcm gets appended to, creating the .wav format.

If you create a collection of files, one for each character in the set, a fairly simple script would concattenate them all together. Obviously you will need a file for the space character as well, but that ends up being almost noise when compared to inserting the spacing for farnsworth for the file. In fact you can pretty safely get away with just using to farnsworth intervals in place of a space for farnsworth spacing of 5-15. It will probably be a little bit more noticiable at a farnsworth of 13-15.

Oh, as to how I am familiar with speeding up processes which use a random number generator, I once had a small internet radio station, and part of what it was doing was using a random number generator to select the next audio file to put in the stream. The program in question would pick a file at random, then check to see if that file would be appropriate. (genra, was it just played, or played within the past x songs, whatever.) I had a fairly small collection of files to work from, a couple thousand was all, and I was seeing playlist generation taking litterally hours to run for a day's worth of playlist. I understand the developers were working on an improvement or two, but I decided that all the work wasn't worth it for something primarily intended for my own enjoyment, when I realized that the licencing fees to ascap, bmg, and some other group, was going to run me an additional $1000 a year. So I moved on.

However a quick way to randomize a set you intend to go through most of without repeating any of the elements is to treat that set as one side of a tupple. The other side gets a random number, then you sort the list on the randomized number side of the tupple. So if you have a set 'A, B, C, D' to which you build the tupples '[A 53] [B 14] [C 98] [D 2]' you end up with the 'sorted randomly' list 'D B A C' as the output. Handy for things like decks of cards you want to 'shuffle' for dealing out. Useful as well for handing out random numbers that you know will work, but that you don't want to be able to predict in what order they are sent to begins with.

With that, I should probably head off to bed. Have a good night, and 73 for now.

-Rusty - kc0vcu