Dear Rick; I am trying to go into LINUX. I very well understand your idea of using a cross platform interoperability. For the past weeks I have been following all LINUX-related subjects on this site. I have discovered that there are so many LINUX versions. Now a question arises here. Is any application written for one LINUX version capable of operating with another LINUX version? 15 years ago, I used to be a UNIX man. I never liked or used WINDOWS until I was forced to do so by the availabilty of applications. Since then I have discovered that I was right about not liking WINDOWS. It is not stable and it has so many flaws.
UNIX was quite different. But a twist by manufacturers made UNIX not exactly a cross platform interoperable system. Every comany had its own UNIX. And one had to work a lot to make a certain applicaion written under one version of UNIX, operate under another version by another manufacturer. So I go back to my main question. Is any application written for one LINUX version capable of operating with another LINUX version? Best 73 Omar YK1AO ----- Original Message ----- From: KV9U To: digitalradio@yahoogroups.com Sent: Thursday, January 11, 2007 5:43 PM Subject: [digitalradio] Movement toward open digital software? I am a big proponent of cross platform interoperability and I am tending to continue moving away from anything that tends to not be cross platform. My Firefox web browser, Open Office suite, XnView photo viewing (and others), the free version of the excellent AVG Virus protection which is also available for Linux, etc. The one area that suffers the most is ironically amateur radio programs, particularly digital amateur radio programs since there do not seem to be many cross platform at this time. Any time you have cross platform programs, there is much more chance that the product has increased viability. And with digital modes, it is even more significant. A good example would be the use of an ARQ PSK63 mode as used in PSKmail if it had cross platform capability. But if you have no one to talk to, you are not going to be using such a mode as it needs a certain number of users to reach a critical mass. There is no reason that we can not have a memory ARQ mode for keyboarding or even faster purposes. The main limitation will be a noticeable latency, but that would depend upon how much time you want to leave for the behind the scenes pipelining. This has already been invented and tried and it works well but the inventor has not released anything to the open source community at this time. What would need to be done is to have this kind of ARQ mode, not only work at high speeds (which it already did), but also work like the proprietary hardware/software modes and have a fall back position as signals weaken or are affected by interference. Thus far, the hams that write digital software are just not interested in doing this. The non response to Jose's comments also shows that almost no digital hams are interested in this either. After all these years, and with all the work that so many have done voluntarily to produce some non-ARQ but excellent keyboard digital modes, it has not yet lead to anything open source that can compete with the closed proprietary equipment/software for high speed digital. I consider that unfortunate. The one exception may be the digital SSTV folks who have developed modes that can get quite a bit of data through in a short time. You have to in order to send pictures with no errors. They even have a crude form of "after the fact" ARQ to provide fills to receiving stations that may have missed certain blocks of data. This permits a one to many transmission. Last night I was receiving digital SSTV pictures on the 75 meter frequency but the band was fairly quiet with good S/N ratio. Several years ago, a protocol being used by digital SSTV operators was adapted as a connected mode with the SCAMP program. Phenomenal success at high text data rates, but requiring good conditions of around 10 db S/N ratio or better. It just did not have a fall back position when the S/N ratio was too low, )which is much of the time on HF). Although SCAMP used the RDFT protocol, the digital SSTV operators seem to have better performance with QAM types of OFDM and have moved in that direction. I often wonder if there is even one ham working on adapting the existing ham DRM type protocol to a pipelined ARQ connected mode that has adaptability to conditions. This way, you don't have to reinvent the wheel since most of the spokes are already in place. You couple Rick, KN6KB's pipelined ARQ and busy channel detect, with ham DRM, and make it adaptable and I think this would be quite an impressive achievement, especially if it was open source and moved to cross platform use for real world interoperability. Even though Q15X25 looked like a good protocol, it did not seem to work for those who tried it. Does it actually have a 2300 baud speed? Or is this a typo? I don't see any patent infringement issues at all providing you are not trying to duplicate an existing proprietary mode. The reason that Kantronics and AEA/Timewave did not progress is because they would have had to develop new ARQ protocols to compete with Clover II and Pactor modes. Even with Pactor 1, they could not match the proprietary product from SCS and SCS and HAL would not cross license their products, insuring small niche markets. The world is moving toward FOSS whether some like to admit it or not. If Microsoft really is able to make it impractical for theft of their new Vista OS, many users who are now using illegal copies will be moving toward Linux OS in rather large numbers. Some areas in recent days are doing that right now and I think we can see that this will increase the movement toward FOSS. 73, Rick, KV9U Jose A. Amador wrote: >The efforts I am seeing might indicate that we are attempting to bite a >bit too large.... > >On one side, the reports that Q15X25 works better at 2300 baud, and that >the 100 baud packet mode incorporated into MultiPSK works when 300 baud >does not looks like a hint to go at lower speeds and bandwidths, and at >least match the expected thruput of 300 baud packet, reliably. It is a >pity that only some AEA TNC's could go below 300 baud, and that it did >not become popular. Greed or carelessness? Cannot tell, but the results >are there for all to see. > >I have been a witness that Pactor II and III are better alternatives >than 300 (and HF 1200 baud) packet, with some 10 times the thruput. > >SCS has achieved to better protect the data in transit, starting with >their old "memory ARQ", and using adaptative techniques, like switching >in more complex constellations (Pactor II with 2 carriers) or more >carriers with no more complex constellations than DQPSK, starting with >as few as 2 carriers, and going up to as many as 16, depending on the >channel quality. It is complex and has a price, but works quite well. > >Should a faithful copy be made? Guess not, including the avoidance of >patent infringements, but there are salient points in display for all to >see. Adaptativity and data protection seem to be the key. > >The behavior with Q15X25 seem to follow this pattern, using slower >speeds if it is more reliable, and avoiding the filters passband edges. > >In a multicarrier environment, it is wise to confine them in the >flattest propagation delay portion of the passband. The edges do not >have this desirable property. > >It is important to go as fast as POSSIBLE to catch band openings and >move traffic, but with an eye in EFFICIENCY, neither that fast that the >water spills out of the bucket, neither that slow that it takes an >eternity to fill it up. With 300 baud packet, most of the water was >spilled outside (endless retries....remember?).... > >It is better (for moving BBS traffic) to have one drop falling INTO the >bucket for a day than a large hose with large pressure bouncing the >water on the bottom of the bucket spilling it all over the place for a >short while (wasting bandwidth). The good choice seems to be an average >of those extreme conditions. Transmitting data, and not live voice, you >are not forced to some minimum transmission speed. Just use the one that >DELIVERS the most. > >The HF channel is a variable one. In good years we can move to higher >frequencies, as close to the MUF multipath diminishes or dissapears, but >regional nets with the required path geometries do not enjoy these >benefits. > >And yes, the trend in the times we are living is using PC's and sound >cards, as it is versatile and somehow, affordable. Making it open >software may allow some worthwhile contributions and a shorter >development time. > >I have seen one similar solution: Using smaller motherboards with less >power hungry processors (VIA, etc) allows the development to be done in >the PC and ported to a smaller and less power hungry box, powered from a >DC-DC converter. It seems to be the fashion nowadays. There are non ham >networks in South America (and possibly Africa) being built that way. > >The AEA hardware solution saw the light in 1988....almost 20 years ago. >And at the pace the development goes nowadays, and the attitudes we are >seeing (life is hard and short, I am not criticizing anyone), it looks >that those boxes are history. > >Once again, pactor channel access solutions seem to show the way. You >can go with a single speed for all links in a shared channel, like in >wire (X.25 was born in that environment) on VHF/UHF, but on HF all paths >in a network won't show the same quality, so you cannot use the single >speed shared channel efficiently for all, neither a mix of speeds on a >shared channel seems to be a viable solution so far. So peer to peer >links at the highest EFFICIENT speed (maximizing ALLOWABLE thruput, not >HOPING the highest theoretical one to be AVAILABLE always) seem to be >the solution. It is the way the HF, ham side of the link works in >Winlink 2000. > >Could a viable mimic of that be achieved? > > >Jose, CO2JA > > >PS: Daydreaming....perhaps...even a mixture of those ideas with ALE and >an SDR.... > >Second...could we be able to live with variable bandwidth, adaptive >digital transmissions in our ham bamds without quarreling among us? > >Sorry for the crossposting, but to me, it seems interesting for both groups. > >Ken wrote: > > >>Well some bad news today after so long a effort of trying to get this >> damn mode into current technology like the Kam XL. >> >>A response from Tomi to my request to have the mode properly >>documented so developers like Kantronics could include it in their >>TNC range. >> >>--- >> >> >>>Do you have a more up to date Q15X25 technical description >>>available >>> >>> >>please? (Last release received 2005-07-20). >> >>Sorry to say but no. I have mosty forgotten the whole modem as I >>haven't used it and I don't think anyone else does either... At least >>I haven't heard from anyone. >> >>Unless I get a sudden inspiration to document stuff, I probably won't >>update it any more. --- >> >>So it seems we are at a dead end again. :( Most disapointing. I have >>been chasing this since 2005! :( >> >>OK So whats next? We still need a newer faster mode for HF that is >>ax25 / packet compatable for our existing networks. >> >>Any idea's? The big issue I see is having something that we can get >>the TNC manufacturers to include. A mode that is within the >>capability of some of the latest hardware like the Kam XL's etc. >> >>My only other idea is to abandon triditional TNC technology and go >>down the path of using Embedded PC boards with USB sound card dongles >> and linux. While this would offer more mode flexability and access >>to a better supported software base it's main limitations are these >>devices are generally power hungry which is bad news for field apps >>like solar sites and digi's etc. >> >>Any idea's anyone? >> >>~Ken - VK4AKP .-.-. >> >>--- In [EMAIL PROTECTED] <mailto:Q15X25%40yahoogroups.com>, kd4e >> <[EMAIL PROTECTED]> wrote: >> >> >>>>Jose A. Amador wrote: Could I suggest that PAX/PAX2 be considered >>>>as candidate modems formats? >>>> >>>> >>>There is no point to either -- they are costly proprietary formats >>>-- contrary to good sense and Ham tradition. >>> >>>Many manufacturers have tried the proprietary mode idea and all >>>have failed. Kantronics among them, more recently joined by Alinco, >>>Kenwood, and Icom's competing VHF/UHF digital and linking schemes. >>> >>>Ham radio needs a non-proprietary foundation same as in the >>>Internet realm, e.g. IEEE 802.11 and others. >>> >>>We need a robust format that is 100% non-proprietary: >>> >>>1. All of the code is published and anyone is allowed to base apps >>>on it. >>> >>>2. No exclusive source hardware requirement. >>> >>>3. Cross-OS platform compatible -- Apple, Linux, and MS. >>> >>>Only then will we have something likely to earn the support of the >>>majority of digital mode Ham ops and only then can we move into the >>>digital mode future working together vs divided and making >>>inefficient use of fragmented development resources. >>>-- >>> >>>Thanks! & 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot) >>>com >>> >>> > > > > > >
