OK , It was simply a concept based on current systems , the original panoramic digipan system capturing all, now expanded to cover rtty and the Olivia recovery in drm780 , my experience with hf packet back in the 80's when you could digi all over the place on 10 Mtr's , the wspr auto beacon software decoding down in to the noise and the latest `cw' skimming software that is capturing the call signe , operating frequency and posting it to a web server...
As with the above I should think the calibration of a standard ham ssb set would be good enough to ensure net , as for the communication protocols .. well who knows a sort of lynux (compared to windows) communication system that sits in a small space and uses the advances in computing power and narrow modulation 'modern frequency usage' and allows everyone to join in, with the same dial setting I think the intelegent use of a band of frequencys would reprensent progress in 'ham' data transmission ? --- In digitalradio@yahoogroups.com, "Jose A. Amador" <[EMAIL PROTECTED]> wrote: > > > Graham wrote: > > > ****I really do not understand Graham's proposal: a narrow band spread > > spectrum system? I really need some more clarification about this.*** > > > > Ok may be a bit like calling a steam train a iron horse, dose the > > same thing but a little differently > > > > Spread spectrum : may not be quite the intended system, more like a > > frequency agile system within a constrained pass band, where data > > packet are transmitted, by say psk31 type modulation, on random > > channels within the pass band collision avoidance with multi > > users, and short data bursts > > Now I see. Frequency hopping spread spectrum. > > Those channels are not really random, but pseudo-random. I foresee two > problems: > > 1) Coordination. The necessary codes should be defined. Netting those > transmissions is not trivial, calibration issues are important and not > all radios are calibrated equally. A heavy task for CAT, indeed. I am > not sure it can be done well enough, or without special radios. > > 2) Administrative. It will be hard to convince communications > administrations to let run systems they cannot monitor easily or reliably. > > PSK31 is not suitable per se, it is not thought for reliable transfers > but for casual keyboarding. Emphasis is on quick responsiveness, because > features that increase reliability of transfers also increase latency, > which is felt as undesirable by many keyboarders. Count me in, I react > differently if I want to chat with few erroneous characters that do not > obliterate the meaning or if I want to transfer a file reliably. > > > AX25 : merely as comparison to existing mode's of operation, > > some kind of watered down system that would allow routing via other > > stations, mail boxes that sort of thing, ok the data rate wont be > > too high, but just a novel system using the pc as a intelligent > > modem. could transmit command/route packets and data packets to > > keep things short > > Actually, it is not only AX.25, but using the BBS Interface > Specification Working Draft 11/28/93 > > Is there any newer? I have not seen any other, newer or improved. > > FBB modified some aspects of it, specially regarding compressed > transfers, but this is the basic protocol as I understand. I also keep > the FBB protocol docs on a backup CD. The FBB and JNOS sources could be > a good guide for someone interested in the tiny details. FBB does it > better, with Z-modem style transfers that resume the file transfer where > the link is cut. That also reduces the spectral footprint. > > > If you views the system on a waterfall display, you would see, what > > looked like random vary length , short psk31 (type) signals > > appearing simulations'ly with in the system band with on say fixed > > channels with the odd collision and extended gaps . Depending on > > usage why not start to double up on the cannel usage to give a fec > > function under good conditions > > A waterfall would be a good thing. It was particularly hard to net in, > even with a well calibrated radio without being able to really watch the > spectrum using a TNC with no tuning indicator. > > Summarizing, I believe this is too complex and creates more problems > than solutions. That is my personal perception. > > What I feel is needed is something based on the established technology > (AX.25, BBS Spec) with a new modem more suitable for HF than the old > Bell 103 modem. > > I see divided opinions, many prefer the shared frequency concept. > > This is not without problems. Bad or uncoordinated parameters, hidden > stations, collisions, all reduce the transfer efficiency. I still > remember that 14095 could be quite messy at times. > > I participated on a net where one station was the hub and clearinghouse, > all had to be coordinated with the net manager, and it worked rather well. > > Something similar to frequency hopping but not exactly so were the > procedures used by the AMTOR/Pactor mailboxes, scanning several channels > per band, and using one for the entire connection period. > > What does this has to do with FPGA based data modes? At the end, we > still need a better HF modem than the Bell 103. One step at a time, I > would love to see a better, open source, low cost mousetrap implemented > for reliable transfers. > > I feel important to note and take adventage of what strategies are > proven to work, and not reinvent the wheel. Exact bit to bit > compatibility to say, pactor, is not as important as a good robust > modem, negotiable signaling speed and coding adapted to HF propagation, > among other aspects. Adaptive equalization might be used advantageously > in a modem. Maybe some good ideas could be taken from Q15X25, with care, > of course, because it also left a not satisfied wish list. > > It is not necessarily as simple as stating such a wish list, but there > should be some intellectual property modules that actually do some of > the above, in modules, to simplify the programming tasks ahead. > > 73, > > Jose, CO2JA >
