[digitalradio] MFTTY 3.0.143 is out
MFTT 3.0.143 # Pilot Tone will be inserted automatically after a transmission pause of equivalent 4 words time # Thin grey line added to spectrum display, indicating the center frequency of Rx-Band-Pass-Filter # Double click on "Rx . Hz" will copy the Tx freq. # Double click on "Tx . Hz" will copy the Rx freq. # Tool Tip Text added to UI elements Download it from : http://www.polar-electric.com/MFTT/index.html 73 de LA5VNA Steinar
[digitalradio] OH, so close and yet............
VOILA! Before I knew what was happening, I found myself suddenly printing a CQ on MFTTY from WB4MWD on 3591 around 0200Z. He had an S4 or so signal here in Richmond, IN. Only problem was that he was competing with an RTTY signal who suddenly appeared on frequency AND...AND...there was this PACTOR MBO that was a little off frequency giving him competition as well. Surprising thing...TO ME...was that I was printing his CQ while being pretty well covered by the RTTY station. That surprised me. I didn't answer 'cause I was fumbling trying to reply and then the XYL had a problem, then...then... Well, suffice it to say I at least did break the ice for receiving. Now for the transmit. Howard W6IDS Richmond, IN EM79
Re: [digitalradio] MFTTY 3.0.143 is out
Hey, Steiner I have it installed. Before I did anything else, I modified the Pilot CQ to add my callsign and Grid Locator (EM79). When I selected the Pilot CQ (I'm using the "SEND" button now) I found four tone "beeps" transmissions being transmitted. When I pressed the "SEND" button, I transmitted the CQ sequence but with no PILOT Tones. My Pilot CQ is: CQ CQ CQ DE W6IDS W6IDS EM79 CQ CQ ..etc etc etc HmmmI'm not totally clear on what's happening or if I accidentally did something wrong in modifying the Pilot CQ. Can you clarify your sentence abut the Pilot Tone below also? Howard W6IDS Richmond, IN - Original Message - From: "Steinar Aanesland" To: Sent: Monday, January 12, 2009 5:08 PM Subject: [digitalradio] MFTTY 3.0.143 is out > MFTT 3.0.143 > # Pilot Tone will be inserted automatically after a transmission pause > of equivalent 4 words time > # Thin grey line added to spectrum display, indicating the center > frequency of Rx-Band-Pass-Filter > # Double click on "Rx . Hz" will copy the Tx freq. > # Double click on "Tx . Hz" will copy the Rx freq. > # Tool Tip Text added to UI elements
Re: [digitalradio] MFTTY 3.0.143 is out
Hi Richmond I have not tested this last version yet. I will give it a try when I am back from work. 73 W6IDS wrote: > Hey, Steiner > > I have it installed. Before I did anything else, I modified the Pilot CQ to > add my callsign > and Grid Locator (EM79). When I selected the Pilot CQ (I'm using the "SEND" > button > now) I found four tone "beeps" transmissions being transmitted. When I > pressed the > "SEND" button, I transmitted the CQ sequence but with no PILOT Tones. > > My Pilot CQ is: > > CQ CQ CQ DE W6IDS W6IDS EM79 > CQ CQ ..etc etc etc > > HmmmI'm not totally clear on what's happening or if I accidentally > did something wrong in modifying the Pilot CQ. Can you clarify your > sentence abut the Pilot Tone below also? > > Howard W6IDS > Richmond, IN > > >
Re: [digitalradio] Re: Digital Modes Presentation (Need Help)
ab8it wrote: > I have a presentation that I have used at several ham clubs you could > borrow from or use. It is a powerpoint and I could e-mail it to you > if you like. Tom- AB8IT > Tom, I'd like to have it too. If you don't mind I would give you a credit when I discuss about ham radio at scientific conferences. Misko YT7MPB PS: Is there available a short audiovisual sequence of an AX.25 packet signals for download? I'd like to present to the conference audience something like packet audio burst being received and have it decoded on the computer screen (or a short keyboard-to-keyboard conversation between tho ham packet users, or so), but in my area there are no reliable correspondents anymore to make a recording of that.
Re: [digitalradio] AX.25 modem as an infrastructure?
Charles Brabham wrote: > What you describe can be done but it would be a step back, not forward from > Packet networking as we know it. - This assumes that you are talking about a > network that covers a significant area and has a good number of users in it. > Your idea would be most advantageous with a small number of users within a > small area. For something like that, you would be best off utilizing old WIFI > equipment, off of the ham bands. - And we all know how far the development > and utilization of ham radio WIFI went... When it was finally realized that > PART97 was not going to be repealed, allowing internet content to be > irresponsibly transported over the ham bands, all of the interest in ham > radio WIFI suddenly dried up and blew away. - R.I.P. hinternet. > Ok, let's make it this way: 1. I did not mean of transporting any Internet-originated content by using the ham packet infrastructure. I meant of only ham packet traffic. 2. I know of many types of "official" node systems (incl. Flexnet, BPQ etc) but did not think about them because they ask for either better or separate dedicated computers (besides their end-users' packet operations). I thought about some implementation/modification of 'silent nodes' within the existing AX.25 protocol or, if you like it that way, existing modems/TNCs. I also said to allow some, say up to 10% of the usual TNC utilization to be used for node traffic. For example, if there are some 4-5 packeteers in a city area, whose technical conditions are different (antenna hight, output power, better listening to the other stations etc), why shouldn't be possible for a low-end station to use such a better "node" from the neighborhood - instead of a remote distant node? The steps would be the following: 1st: My 'low-end' station fires up and becomes active, including its own "node", 2nd: My 'low-end' "node" listens immediately what it can hear around (before me, as its operator, even think to transmit something), 3rd: My 'low-end' "node" recognizes the availability of the nearest "hardware node" on the hill, but also hears some other ham's 'high-end' station's "node" somewhere in the city, 4th: My 'low-end' "node" put both nodes in its node list, compares the quality of them and, as a result, decides to use my buddy's "node" rather than the hill's node - maybe just because my 'low-end' antenna better communicate with the buddy's station than to the hill's one 20 km far, 5th: When I am about to transmit something to the packet network, my station is already prepared for sending my packets through the buddy's "node" (*and from there* to the the hill's hardware node). In the same time, I suppose my 'low-end' station would avoid sending to many retries, which might happen if I forced it to use the hill's node only. 6th: My buddy's home "node" forwards information being received from me without problems because it communicate the hill's node better than my system (and his/her "node" spends up to 10% of it capacity for that, as mentioned earlier), 7th: During the conversation, if it happens that my buddy switches his/her system off (and goes to bed), my 'low-end' "node" recognizes that the buddy's "node" disappeared and immediately recomputes its node-quality list, 8th: My 'low-end' "node" recognizes that the only available node is the hardware one (on the hill top) and automatically switches to that one (maybe without giving any particular attention alert to me -related to that take-over being taking place). 9th: My 'low-end' "node" uses the hill's node with more or less retries (because, as mentioned, it hears the hill's node with different, probably lower quality compared with the buddy's "node" that had disappeared). 10th: Suddenly, the other ham in the city wakes up and activate his/her 'high-end' station which, in turn, hears the mountain node better than my station does. My 'low-end' "node" recognizes the change soon, recalculate its best route(s) and a network "take-over" takes place again, etc etc ... So, I wanted all of that to see within a TNC to work automatically - without installing/activating external node programs (BPQ, Flexnet or whatever). I mean, just to become a part of the protocol, or like. (I wouldn't mind if it could be manually switched on/off.) I don't see why such a system would not be viable for more than 1-2 station per area. In fact, what is a probability that, say, my 'low-end' "node" uses more than one buddy's "node" as a relay for reaching the 'real' hardware node on the hill or so. I suppose that my approach would work for a minority of 'low-end' packeteers who do not have something stronger than a handy talkie with a rubber ducky. I also suppose that the actual packet node networking, where a node serves its end-users equally (but where some of the low-end users can hardly reach the node), is more vulnerable to endless retries and waiting for answers, than the system I suggest. Maybe I am wrong, maybe not. Misko
Re: [digitalradio] MFTTY 3.0.143 is out
No problem, Steinar. I'm just working my way along my learning curve here. I just noticed that I get the Pilot tones when I have the "Send Immediately" box checked. Then, when I select the Pilot CQ, the tones are sent at the beginning of each line as typed in the box. If i select "Send By Enter Key" or if I UNCHECK BOTH selections, the "SEND" button appears and in any case, NO Pilot tones are sent. They're sent ONLY when the "Send Immediately" box is checked. I should think that the tones should be sent anytime the CQ is sent or perhaps when text otherwise is being sent and I insert somewhere inside any typed text. However, that isn't the case. The only time the tone is sent is at the beginning of a line where I place . It cannot be inserted anywhere else, so that seems to make it difficult to increase the number of Pilot tones as recommended in the information I read. Unless, of course, the Pilot tones are only used during a CQ sequence, then all of this is moot. The only issue then is being able to transmit tones in instances involving using "SEND" button or "Send By Enter Key" which doesn't happen now. Howard W6IDS Richmond, IN - Original Message - From: "Steinar Aanesland" To: Sent: Tuesday, January 13, 2009 1:24 AM Subject: Re: [digitalradio] MFTTY 3.0.143 is out > > Hi Richmond > > I have not tested this last version yet. > I will give it a try when I am back from work.
Re: [digitalradio] Re: MFTTY Tuning information
It seems to be an interesting piece of software, Norbert. I was susrprised at how I was able to copy my first CQ from WB4MWD while that station was basically "covered" by a PACTOR MBO. I don't know if that was a "fluke" or not but will be curious to see if it can be replicated in the future. Howard W6IDS Richmond, IN - Original Message - From: "Norbert Pieper" To: Sent: Sunday, January 11, 2009 6:54 AM Subject: [digitalradio] Re: MFTTY Tuning information > Hi Steinar, > > no problem just click options and enter new Tx Center Frequency > ( in the upper right corner ) click apply. > > MFTT can handle any Tx Frequency from near zero up to near half of > TX sample rate of soundcard. > > BR > Norbert
