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
