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 ------------------------------------ Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked Check our other Yahoo Groups.... http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/themixwgroup Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
