Re: [digitalradio] Logging for MultiPSK and DM780
Maybe use DXKeeper from Dave AA6YQ? I know there are interfaces in DM780, sure-ish that they exist in MultiPSK. One idea I have thought about is for programs such as DXKeeper, DM780 etc. to run UDP servers which allow other programs to send new QSO's for logging. Simon Brown, HB9DRV - Original Message - From: Dave Flack, W6DLF [EMAIL PROTECTED] I go between MultiPSK and DM780. What is the best/easiest way to create a combined/common log?
[digitalradio] Re: Logging for MultiPSK and DM780
Re UDP servers, we established the Amateur Radio Software Development group a year ago to work out the details of this and other shared mechanisms, but it died from lack of interest. http://groups.yahoo.com/group/arswd/ Remember? I'll stick with DDE interfaces for now; they aren't elegant, but they work well enough to support an ecosystem of ~20 interoperating applications. If a serious effort to define a common protocol for interoperation arises, I will certainly participate. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Simon Brown [EMAIL PROTECTED] wrote: Maybe use DXKeeper from Dave AA6YQ? I know there are interfaces in DM780, sure-ish that they exist in MultiPSK. One idea I have thought about is for programs such as DXKeeper, DM780 etc. to run UDP servers which allow other programs to send new QSO's for logging. Simon Brown, HB9DRV - Original Message - From: Dave Flack, W6DLF [EMAIL PROTECTED] I go between MultiPSK and DM780. What is the best/easiest way to create a combined/common log?
[digitalradio] UI Design
UI Design is something I am not very good at but am very interested in. Here's an excellent article I came across this morning, well worth reading, it will take you just one minute. http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-web-design/ Simon Brown, HB9DRV
[digitalradio] JT65A Crawl contest deadline
The deadline for receiving logs from the 1/1/08 JT65A Crawl has now passed. I will publish the results within the next few days. -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] 1/1/08 Olivia contest deadline
The deadline for receiving logs from the 1/1/08 Olivia contest has now passed. I will publish the results within the next few days. -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] Re: Logging for MultiPSK and DM780
I go between MultiPSK and DM780. What is the best/easiest way to create a combined/common log? Multipsk seemlessly logs to DX Keeper . DM780 easily exports to DX Keeper.
[digitalradio] Mexico RTTY International Contest: 1800Z, Feb 2 to 1759Z, Feb 3
Courtesy WA7BNB ( http://www.hornucopia.com/contestcal/weeklycont.php ) Mexico RTTY International Contest: 1800Z, Feb 2 to 1759Z, Feb 3 Mode: RTTY Only Bands: 80, 40, 20, 15, 10m Classes:Single Op Single Radio Single Op Two Radio Max operating hours:24 hours Exchange: XE: RST + State non-XE: RST + Serial No. Work stations: Once per band QSO Points: 2 points per QSO with same country 3 points per QSO with different country 4 points per QSO with XE Multipliers:Mexican states and Federal District once per band DXCC countries once per band Score Calculation: Total score = total QSO points x total mults Submit logs by: March 4, 2008 E-mail logs to: xe1j[at]ucol[dot]mx Mail logs to: Jose Levy, XE1J Dirección de Concursos FMRE Clavel 333 Colima, Col. 28030 Mexico Find rules at: http://www.fmre.org.mx/concursos/2008/rtty/rules-rtty-2008-english.doc -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Re: Logging for MultiPSK and DM780
BTW - I have a fine NTPClient class in C++ in case anyone is interested, I use this when calibrating soundcards and also to keep my computer clock updated every 15 minutes. You would have to modify it yourself as it uses a few DM780 calls but the intelligence you need is in place. Simon Brown, HB9DRV - Original Message - From: Simon Brown [EMAIL PROTECTED] Also I would say that UDP is easy in all languages, DDE is a tad complex in C++.
Re: [digitalradio] Re: Logging for MultiPSK and DM780
An advantage of UDP is that the logger could be on another platform / computer. Although there's network DDE I have never tried it and don't want to try it to be honest. Also I would say that UDP is easy in all languages, DDE is a tad complex in C++. Simon Brown, HB9DRV - Original Message - From: kh6ty [EMAIL PROTECTED] Dave, over five years ago now, I pushed for using a standard DDE interface for all PSK31 programs so anybody could use his favorite logging probgram with his favorite PSK31 program, and developers did not have to keep reinventing the wheel. It also found little interest. :-( I'd still like to see that happen. The need never goes away!
[digitalradio] Re: New release (4.7) of MULTIPSK
Paul, I believe message #26409 answered your question? http://groups.yahoo.com/group/digitalradio/message/26409 Pardon me if I'm wrong, as it was just a quick glance. Frank, K2NCC Thank you Frank. I did miss that. It tells me the configuration file will not be overwritten which implies there is an installer action going on instead of SelectAll Copy/Paste. It was suggested to ask in the MultiPSK news group and I had long ago. When I saw all the MPSK users here I thought I'd try the quick question again. I'll download 4.7 and go though the install/update process again. 73, Paul
Re: [digitalradio] Re: RFSM 8000
Thank you for that information, Dimitry, When I read over the MIL-STD/FED-STD/STANAG standards, I could not understand how these slower modes would work all that well by the multi-repeating approach. They repeat multiple times, even if you do not need the repeat (sort of a non automatic ARQ) which seemed very wasteful in terms of throughput. Especially because this was happening at the slower speeds which made them even slower than they might otherwise need to be. When I saw the charts that compare the throughputs with the S/N ratios, there was some improvement in terms of weak signal capability over the non repeating speeds, but none of the modes seemed to be able to compete with Pactor2 speeds at the low S/N levels. When I have asked those who work daily with STANAG type modems how successful they are, they tell me that they often have difficulty with certain paths. Also, because they use inefficient document types (MS Word .doc files) just to send the shortest possible message can take a very long time. They even have some technologies that have duplex voice and that does not always work either. The reason that they use these technologies is because they have to use them due to the need for interoperability. In fact, this is now mandated more and more with regulations. I often wonder if they may eventually rethink some of the modulation schemes or have a switch over to something that can tolerate severe ISI/doppler/ under weak signal conditions that are common with amateur signals? The STANAG modem standards do allow for OFDM modems as well, but I don't think that anyone switches over to OFDM for part of the time when they are normally using a single tone modem. But perhaps the standard allows it? After seeing which modes seem to work the best under the most difficult conditions, (well below zero dB S/N) which are the conditions we often have with amateur communications, it does seem like a few (two under worst conditions) spaced a moderate distance apart, may have the best compromise on throughput vs. robustness. That is why Pactor 2 (and Pactor 3 when operating in the Level 1 speed) work so well. At this time, it does not appear that there is any other mode that can compete with that modulation technique based on all the comparisons that I have been able to find. Again, thanks for your help on this. 73, Rick, KV9U dmitry_d2d wrote: Hello Rick. As regards the speed that is slower 600 in MIL-STD 188-110A/B. There are 300, 150, 75. In my opinion speed reduction has been made nonoptimal, using dumb repetition of data in 300 and 150 is not needed. The theory of coding says that repetition is the worst way to improve noise immunity. Speed 75 based on the method of spectrum spread by orthogonal consecution by Walsh. It's rater good but this speed uses repetition as well. We consider that the speed 300, 150, 75 allows reaching better characteristics of noise immunity that the standard MIL-STD 188- 110A/B allows. Frankly speaking the standard MIL-STD 188-110A/B has been used our product to be noticed by customers. But true to say it contains nonoptimal solutions. Turning to the point of RFSM we should admit that we have mistaken making the minimal speed - 600. I hope we improve it in the near future. Dmitry.
Re: [digitalradio] Re: Logging for MultiPSK and DM780
Dave, over five years ago now, I pushed for using a standard DDE interface for all PSK31 programs so anybody could use his favorite logging probgram with his favorite PSK31 program, and developers did not have to keep reinventing the wheel. It also found little interest. :-( I'd still like to see that happen. The need never goes away! Skip KH6TY - Original Message - From: Dave Bernstein [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Friday, February 01, 2008 3:39 AM Subject: [digitalradio] Re: Logging for MultiPSK and DM780 Re UDP servers, we established the Amateur Radio Software Development group a year ago to work out the details of this and other shared mechanisms, but it died from lack of interest. http://groups.yahoo.com/group/arswd/ Remember? I'll stick with DDE interfaces for now; they aren't elegant, but they work well enough to support an ecosystem of ~20 interoperating applications. If a serious effort to define a common protocol for interoperation arises, I will certainly participate. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Simon Brown [EMAIL PROTECTED] wrote: Maybe use DXKeeper from Dave AA6YQ? I know there are interfaces in DM780, sure-ish that they exist in MultiPSK. One idea I have thought about is for programs such as DXKeeper, DM780 etc. to run UDP servers which allow other programs to send new QSO's for logging. Simon Brown, HB9DRV - Original Message - From: Dave Flack, W6DLF [EMAIL PROTECTED] I go between MultiPSK and DM780. What is the best/easiest way to create a combined/common log? No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.17/1253 - Release Date: 1/31/2008 9:09 AM
Re: [digitalradio] Comaparison Table of Major Digital Mode and Logging Apps
Hi Phil, My take is that there is more similarity than difference. Most of the multimode digital programs will support the most commonly used modes. All other modes are very rarely used and can quickly fall into disfavor. Consider the primarily used sound card modes, PSK31, MFSK16, and some Olivia modes that are used for keyboarding. Other modes that may be available include faster PSK speeds up to PSK250, ALE, particularly the FAE forms of the 8FSK ALE waveform, Hell, etc. But these modes are not that commonly used. If you like to experiment with the latest technology, then you would want Multipsk over all the other multimode programs because only Multipsk has these modes available. If you are mostly interested in an ultra high quality, polished interface, you would likely consider Ham Radio Deluxe/Digital Master 780. As has been pointed out, both of these programs can interface with DX Lab and that will give you one of the best suites available, particularly for logging data and handling electronic logging. Standardizing on one program may be best for most hams because they can get better at using a given software program and make the logging easier than having logs scattered around on many different programs. I do find it difficult to switch back and forth between what I consider to be the two main choices. But then I also am interested in the newer NBEMS concept for emergency communications and I tend to favor anything that uses ARQ. Since VBDigi (part of NBEMS suite) does RTTY/MFSK/PSK, it actually works FB for much of what I do. But then a new mode comes along, and it is often found only on Multipsk so you still must use that program anyway for those purposes. At this time Multipsk does not support NBEMS so you have to use the NBEMS suite on either Windows or Linux if you want to use that system. Actually, it is a rather nice problem to have considering that a few years ago we only had hardware solutions, and at great cost for modest performance. 73, Rick, KV9U Phil Wells wrote: Hi All, Am fairly new to ham radio and I read a lot about the different apps for different modes and particularly the multi-function apps like HRD and MixW (for which I have a license) and it's all pretty daunting. I'm wondering if anyone has done a comparison of features of the different offerings, perhaps a spreadsheet, either for their personal benefit or posted somewhere. I didn't find anything after a brief Google search and a search of this forum. The purpose of such a document would not be to say which is best, like a Consumer Reports rating, but simply to show which have what features so that a newcomer could decide which one(s) might best satisfy *their* needs. Certainly, such a doc would be out of date within a few weeks of release since most programs are always being upgraded, but it would be a start. I might attempt this on my own at some point but don't want to reinvent the wheel so thought I'd check here, first. 73 to all Phil AF6AV San Diego
[digitalradio] Re: New release (4.7) of MULTIPSK
I would certainly agree to that. I am not a new user of digital or logging software, having used several over the past decade, but every time I attempt to go to Multipsk, I am put off by just too much on the screen at one time. A tabbing system would certainly be one better way. I particularly like the way the the DXLab suite handles the different programs and you can pick and choose exactly what you do want on the screen. Its only drawback is it just doesnt have the capbility of running all the modes that MultiPsk or evn MixW has. When I wish to use a differnt mode, like those, I use MixW in conjunciton with DXLabs DXKeeper logging program. You can also use MultiPsk with DXKeeper (they say) but I simply dont have the time and do not want to put in the effort to use MultiPsk with its very confusing screen. Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB All 2 years or more (except Novice) Pls QSL direct, buro, or LOTW preferred, I Do not use, but as a courtesy do upload to eQSL for those who do.
Re: [digitalradio] Software Development [was] Logging for MultiPSK and DM780
--- John Becker, WØJAB [EMAIL PROTECTED] wrote: Speaking of, I (and others) sure wish when writing RTTY software you developers would add or force a CR/LF after 70 charters. I really don't think the glass operators would notice or mind. And us using paper would notice the most since we would not get the pile up at the end of a line. ARRL bulletins are transmitted that way still today. It should not be that hard to do. I wrote a rtty program for an old 8080 processor about 20 years ago that would do that. After about 65 characters it would look for a space and would send two carriage returns, a line feed, and a leters function to be compatiable with the mechanical machines. If it did not get a space, it would force the end of line sequence after 72 charcters. I mostly use the computer sound card interface for most digital work, but do have an old mechanical machine hooked up and it is irriatating to have to watch it to make sure it gets the cr/lf instead of just printing a big black block at the end. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
[digitalradio] Software Development [was] Logging for MultiPSK and DM780
Speaking of, I (and others) sure wish when writing RTTY software you developers would add or force a CR/LF after 70 charters. I really don't think the glass operators would notice or mind. And us using paper would notice the most since we would not get the pile up at the end of a line. ARRL bulletins are transmitted that way still today. At 02:39 AM 2/1/2008, you wrote: Re UDP servers, we established the Amateur Radio Software Development group a year ago to work out the details of this and other shared mechanisms, but it died from lack of interest. http://groups.yahoo.com/group/arswd/ Remember? I'll stick with DDE interfaces for now; they aren't elegant, but they work well enough to support an ecosystem of ~20 interoperating applications. If a serious effort to define a common protocol for interoperation arises, I will certainly participate. 73, Dave, AA6YQ
RE: [digitalradio] UI Design
One possibility is for modem developers to no provide a UI. Instead provide a HTTP or other network interface that can be accessed using web protocols. The UI is then developed by someone else and hosted in a web browser. Before I retired my work was with such a system used to monitor corporate server farms, i.e. 100 or more PC servers in racks. This management system used a web browser UI to allow access from any desktop. The system monitored a plethora of information, e.g. temperature, disk capacity and failure status. One caution about the UI article: There is a difference between a web site and an application interface. A web site needs to grab attention immediately others the user will try a different site. The user of an application will expend more effort toward understanding the application. The motivation is higher since a process of download, install, and setup already consumed effort by the user. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net http://thehamnetwork.net/ -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Simon Brown Sent: Friday, February 01, 2008 3:35 AM To: Digitalradio@yahoogroups.com Subject: [digitalradio] UI Design UI Design is something I am not very good at but am very interested in. Here's an excellent article I came across this morning, well worth reading, it will take you just one minute. http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-web-de sign/ Simon Brown, HB9DRV
[digitalradio] Re: UI Design
Simon, I disagree that you are not very good at GUI design. One of the reasons I prefer HRD and DM780 to other software is the beautiful and intuitive GUI. Keep up the good work! KCÃPTOLes --- In digitalradio@yahoogroups.com, Simon Brown [EMAIL PROTECTED] wrote: UI Design is something I am not very good at but am very interested in. Here's an excellent article I came across this morning, well worth reading, it will take you just one minute. http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-we\ b-design/ Simon Brown, HB9DRV
Re: [digitalradio] Re: MT63 Hardware Question
Hi Well it did happen - the Motorola 56002 EVM could be programmed to work as MANY different modems --- please try this link http://det.bi.ehu.es/~jtpjatae/ham.html also if you Google mt63+evm 56002 you should get plenty of reading I used one - and still have it - from late 1998 There was plenty of software available for many different applications Regards Les VK2DSG From: David McGinnis Sent: Friday, February 01, 2008 1:00 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: MT63 Hardware Question - To answer that in one word, no. Ain't going to happen. The reason so so many use the sound card modes right now is because they don't have to *buy* some black box to do it. John, W0JAB Thanks John, That answer is no help. I understand the economics of it, but black boxes are more reliable than PCs. For most hobby applications it probably doesn't matter, and your point is valid. You gain nothing for nothing paid. Dave K7UXO
[digitalradio] Old RTTY machine - force the end of line sequence after 72 charcters
Hello John and Ralph, If it did not get a space, it would force the end of line sequence after 72 charcters. In Multipsk (and perhaps in other soft) this option exists (button 1 CR/LF/72 char.). It permits to communicate with old RTTY mechanical machine. But this option is OFF by default (you must select it). I remember that this question yet came about one year ago (perhaps two?). 73 Patrick - Original Message - From: Ralph Mowery To: digitalradio@yahoogroups.com Sent: Friday, February 01, 2008 4:54 PM Subject: Re: [digitalradio] Software Development [was] Logging for MultiPSK and DM780 --- John Becker, WØJAB [EMAIL PROTECTED] wrote: Speaking of, I (and others) sure wish when writing RTTY software you developers would add or force a CR/LF after 70 charters. I really don't think the glass operators would notice or mind. And us using paper would notice the most since we would not get the pile up at the end of a line. ARRL bulletins are transmitted that way still today. It should not be that hard to do. I wrote a rtty program for an old 8080 processor about 20 years ago that would do that. After about 65 characters it would look for a space and would send two carriage returns, a line feed, and a leters function to be compatiable with the mechanical machines. If it did not get a space, it would force the end of line sequence after 72 charcters. I mostly use the computer sound card interface for most digital work, but do have an old mechanical machine hooked up and it is irriatating to have to watch it to make sure it gets the cr/lf instead of just printing a big black block at the end. __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [digitalradio] Old RTTY machine - force the end of line sequence after 72 charcters
--- Patrick Lindecker [EMAIL PROTECTED] wrote: Hello John and Ralph, If it did not get a space, it would force the end of line sequence after 72 charcters. In Multipsk (and perhaps in other soft) this option exists (button 1 CR/LF/72 char.). It permits to communicate with old RTTY mechanical machine. But this option is OFF by default (you must select it). I remember that this question yet came about one year ago (perhaps two?). 73 Patrick It is good that you can turn the end of line function off and on. I had it that way on my system so I could edit the pix that were sent on the air about 20 years ago. I have not been too active on rtty for the last 5 years. I moved and am just now getting the station back together. Mostly just receiving now and not doing any transmitting lately. I will have to look at the software to see what options are for transmitting. It might just be that the glass rtty users need to be educated as to what is really needed for those of us that have the old mechanical machines. I have the Modle 19 and a home built ST-6 that I use. We use to have a group of about 15 hams on the 220 mhz band and a repeater just for rtty about 20 years ago. 73 de KU4PT Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [digitalradio] Re: RFSM 8000
dmitry_d2d wrote: 1. A few words about OFDM and serial tone modem. Let's find out how the fight between ISI and Doppler shift takes place in these systems. OFDM uses the great number of low speed channels so the symbol duration increases. While the duration of ISI is much smaller than symbol duration everything goes well. Consequently there is an aim to increase the number of channels ad infinitum BUT at the same time natural limitation takes place. It's just a Doppler shift effect. Hence there is always a compromise between ISI and Doppler shift. Moreover we should take into consideration a big peak factor which results in non-effective usage of power of transceiver. There are methods directed at improvement of peak-factor, but the most part of them makes the system characteristics worse. In case of serial tone modulation the fight ISI with Doppler is provided with adaptive algorithms. The more effective and faster they are the larger number of Doppler and ISI the modem can manage. As for RFSM it should be mentioned that now it includes rather efficient adaptive algorithms that work properly at a speed of 600(500) up to 4800(4000) bps (wide/narrow mode). To work at a speed 6400(5333) - 8000() much more compound algorithms are needed. In particular using turbo-equalization will improve noise proof feature at all rates. Therefore OFDM and serial tone modem can be more efficient in dependence on channel statement. In my opinion serial tone modem with effective adaptive algorithms is the most effective. We'd like to mention that under certain circumstances either serial tone or OFDM modem can fail to provide connection, for example, when the Doppler shift is extremely high (polar communications). In that case one should use the methods of spectrum spread that extending the symbol in time and frequency. Unfortunately the speed would not be high in this case. So the best way out is to measure the channel characteristics and choose the speed of transmission and modulation method according to them. The full adaptation of the all characteristics is required. 2. About our users. The project RFSM-2400/8000 was initially aimed at organizations (not for HAMs)! (First version had no 0,3-2,7 band, which is adapted for HAMs). Its prime value is that high-performance algorithm is used in it. Consequently only technical specialists of organizations where data (files, mail etc.) transmission through HF is needed can estimate the program at its true worth. They need the following: high speed of connection and data transmission. They are the FIRS GROUP OF OUR USERS. For example there are organizations (our users at the moment) who even haven't looked upon HAM -modems (little speed, instability, absence of files transmission in spite of excellent chat-exchange). If you are interested in RFSM as in a program for chat- exchange (or even for file transmitting but you do not need a high speed) and runner is not important for you:. You are the SECOND GROUP OF OUR USERS. $60 may be a pretty penny for this product for you. There is also not numerous GROUP OF USERS - THE THIRD ONE The representatives of this group are specialists in HF- radiocommunications and radioamateurs at the same time who is interested in algorithms of a high efficiency - the runner of the program. May be $60 is rather expensive for them but they can trial versions for free. They communicate with us suggesting interesting and moreover useful ideas. We really appreciate their advices and suggestions. Due to the THIRD GROUP the first version of RFSM has transformed in the product adopted for HAM. 3 . There are several remarks on the open source codes. a) RFSM-2400 (and all the more RFSM-8000) is not just a dumb modem though such a rate is also possible (it was used in PSKMail). Our product is an accomplished system of communication that provides different types of services including receiving/transmitting e-mail on Internet. b) Speaking about OFDM it should be pointed out that we have got experience in such a kind of modulation and can remark that to construct this modem is incommensurably easier than Serial Tone Modem. But the modem of this kind doesn't compare with RFSM characteristics. If we were not be able to realize Mil-STD correctly and use OFDM in RFSM, we would not be sorry to distribute source codes. c) Philosophy. Professional free software is possible because qualified developer has been grown up by certain company. The buyers have already paid for software and progressive developer as well. Then at the same time free software appears (like RFSM-2400) - like an ad, to create an image or ease consumers' tasks. The fact that software is free is a result of successful sales of developer. However free software is not possible in fact. The bigger the quantity of it the poorer it's quality. So said Write on C++ for food ;) There is also rather INTERESTING free
Re: [digitalradio] UI Design
On Friday 01 February 2008 04:34:57 am Simon Brown wrote: UI Design is something I am not very good at That must have hurt. I mean poking your tongue into your cheek that hard must have hurt. You have masterful UI design skills. -- Sometimes I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it. - Mark Twain
[digitalradio] Fwd: [UDXF] 5366.5 KHz
-- Forwarded message -- From: Facility 406 DM09 [EMAIL PROTECTED] Date: Feb 1, 2008 10:55 PM Subject: [UDXF] 5366.5 KHz To: [EMAIL PROTECTED] What is the digital station on 5366.5 KHz? It appears to cycle through several different modes. Kurt
Re: [digitalradio] RFSM8000 Mail Server
Hi Howard The RFSM mail server can send email - originated by any outstation which can connect to the Mail Server by radio - onto any internet mail address Any mail coming from an internet mail address and addressed to the servers email address in the To line and then addressed to the callsign (in the Subject line) of any remote which can connect to the server - will be placed in its Mailbox on the server for collection by that station as required [Delivery to multiple (callsigns) or email addresses is handled bothways Attachments can be included Just the action of connecting to the Server by a remote station will create a mailbox in the name of the connecting station on the server When a remote station sends an email to the server a folder called OUT_EML is created as a subfolder of that callsign and the outgoing mail is picked up from there at the time determined in the server Setup - every X minutes See using e-mail.txt in the README folder in RFSM8000 Hope that explains it enough for you Regards Les VK2DSG From: Howard Brown Sent: Saturday, February 02, 2008 3:50 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] RFSM8000 Mail Server Can anyone comment about the RFSM8000 mail server? Would this work in an emergency as an adhoc email gateway server? Does it need routing tables to determine how to deliver email (especially local email)?? It would be great to find a description of this. Howard K5HB
[digitalradio] Bands improving
US ssb stations now readable on 7183 lsb at 0600 utc W5RG BOB s8/9 A lift in conditions maybe heralds things to come SF=71 A=19 K=5 and SSN is 19 Les VK2DSG
