|
"John Smith" wrote in message ... Mike: 300 baud is ridiculous, in Dee's first post mentioning 300 baud I tossed it out the window--that was fine up to about 1985, then only the mentally challenged continued to run 300 baud modems! Please show me and everyone else how we can run more than 300 baud on HF without exceeding reasonable band widths. There are a whole lot of things, not just video, that would be nice to do. How can we do it? Bandwidth is directly related to baud rate. Dee D. Flint, N8UZE |
"Dee Flint" wrote Hey I'm all for the "eureka" when it happens but the problem is that it is unpredictable. Not only is it unpredictable in time but in the nature of the breakthrough. That's what makes ham radio some damn much fun! In my profession role I can send a team of engineers off with some marketeers scribbling and know that within 12-18 months I'll be shipping product. Bnt ham radio is not so predicable --- we get these delightful surprises from unexpected places. Some like APRS and PSK-xx gain traction and thrive in a niche, others like AX.25 packet radio and 2-meter autopatches which blossom like an Independence Day firework, then fizzle to a few sparks on the ground after a short period of glory. Then there are a few genuine "revolutions" which fundamentally change the nature of amateur radio. We're about due for one of those. 73, de Hans, K0HB |
"Dee Flint" wrote Please show me and everyone else how we can run more than 300 baud on HF without exceeding reasonable band widths. Why is this conversation hung up on 300 baud? It's perfectly legal, for example to run digital voice (J2E) on HF under todays FCC rules, and it will fit nicely in the generally accepted 3KHz band width now used by traditional SSB. 97.307(f)(3) applies to rtty/data transmission, it does not apply to voice or image. 73, de Hans, K0HB |
Dee:
You don't understand binary compression techniques, ok... .... it all has to do with binary trees (well, mostly, kind of), in software, of the data stream, multiple bytes are converted into "data streams", i.e., a pixel "byte" at this level is NOT necessarily 8 bits long in a stream, and sometimes can be represented by a single bit (automatic compression to 1/8 size just because it is stored in a binary tree! (or, data stream) multiple occurring bytes can be sent in the form of (five of these) or ((67 - number of bytes) of (00100100 - binary data byte to create 67 of)), in other words you tell it how many of ONE type of data to create on the other end to fill in the "video hole" on the screen, I would think you can visualize how small a simple BW image can be transmitted--it grows bigger with grayscale data, and much bigger with color data (in quality pictures an extra few bits have to be sent just to describe the color/brightness of the pixel being sent...) .... there is also "variable bit rate compression" which I don't even want to begin to try to give a simplified explanation of here... I am sorry, my ability to describe these complex methods at work here is lacking, and I realize this... don't trust me on it, the web is loaded with papers on every aspect of it... The size of compressed data? That depends on the data types compressed, BW video can be 90%+ compressed (resulting in data 1/10 to 1/20 the size, or MORE, it all just depends on the complexity of the image.) For example, a completely white frame would be (for example) 1,024,000 bytes of color 00000000--this whole screen could be transmitted in TWO BYTES! and the same for an all black screen, at EXTREME RESOLUTION in this simplified case. Further "compression" can be had down at the hardware level where the transmission software can "scan" data and "table-ize" streams of duplicate bytes, or very similar bytes which can all be represented by a common value with little or no detectable loss in "realized visual quality." (can you really tell almost-almost black from "real" black? Or, almost-almost-blue from "real" blue?) In a very efficient compression scheme, it can be "mentally modeled" as a onion, where many "layers" of compression are occurring in a tight sequential loop creating very tightly compressed data packets, with crc sums to ensure no data corruption and packets sequentially numbered to provide a "sane" display stream (this can frequently be rather lax with low quality audio (speech) and less than absolute perfect video.) Digital cell phones use very similar techniques on audio. Some of the "trade secrets" there are closely protected... It is really beyond the resources we have here to go into a deep explanation on data compression techniques, and cheap tricks and short cuts--a good book on the subject should bring one up to speed quickly--perhaps amazon.com for those with a desire for a in-depth understanding... Now some "cheap tricks" examples: you can actually throw away every other pixel (immediately cut the size of a video frame in half!) by using a "normalized" colored pixel in those "dropped" pixels place (and normalizing this "fill in pixel color" as needed to fit the "general background" of the rest of the picture--with NOT as great a loss of video quality as you would expect (or a smaller percentage of "normalized" pixels if greater quality is really needed) and, a smaller than screen sized "picture" can be broadcast and "expanded" by "image size extrapolation" (computer makes a lot of guesses on how to represent it as a larger picture and "fill the screen"--and attempts to have those "guesses" maintain a reasonable quality of picture. and, I could go on and on, however, this is quickly becoming WAY beyond the scope of the arena we need to hold this "argument/discussion" within... and there are papers and books which can do a much finer job than I... I must say, Len was quite correct in the appraisal of your mental aptitude, I would venture to say this with confidence, as damn few women would have hung with this technical discussion as you have... .... are you single, just how old are you? leering-smile .... just kidding, well, mostly--I AM single yanno! grin Warmest regards, John "Dee Flint" wrote in message ... "KXHB" wrote in message ink.net... "Mike Coslo" wrote So here we are. Yup, and no one has persuaded me it can't be done. I've only been persuaded that we haven't figured out how yet. (Sorta reminds you, doesn't it, of how those old-tymey hams must have felt when they were told to take their party to "200 meters and below".) You, Jim, and Dee bemoaning how hard it will be, and John raising the tantalizing notion that we may only be a few "eureka!!!"s away from something workable. Outside my area of competence, but I'll watch the dialog with interest. 73, de Hans, K0HB From my understanding of John's comments, he is saying it can be done now with current technology. He does not however tell us how. He just chatters on about "compressing it enough" without stating the degree of compression, etc. Hey I'm all for the "eureka" when it happens but the problem is that it is unpredictable. Not only is it unpredictable in time but in the nature of the breakthrough. Dee D. Flint, N8UZE |
Dee:
This "show me", "show me" you are repeating causes a complete confusion on my part. Will you agree that a 56K phone modem, does indeed, transmit this data rate with an audio bandwidth of ~300Hz to ~5000K, and if you do so agree, how can you argue this cannot fit in a HF AM RF signal which only goes 2.5K each side of center frequency?????????? Are you NOT imposing an audio frequency of AT LEAST a 5K bandwidth on the rf carrier with normal speech? (actually, most quality transceivers have a wider audio bandwidth than this which can be set +/-) and if you agree you are indeed, how can you argue that 5K bandwidth can carry a 56K data rate over a phone line--and NOT a hf rf signal???? That looks insane to me? The modem is NOT using the whole 5K bandwidth--necessarily, there is compression into a narrower bandwidth which can and is generally software controlled--if necessary (the modems software is a LOT smarter than most give it credit for, especially in the case of the old "onboard processor" and "hardware logic" USRobotics external modems. You need to explain to me why it even begins to look difficult to you for me to be able to understand what you are asking? As, I have to be missing something here... You do realize that a picture good enough to run a "webcam" on the amateur HF bands and get an acceptable image from can be done in 28K (or less depending on the fps), and 36K is really fine at 5 fps and good at 10 fps--you will be able to see the wart on the guys nose you are video conferencing with at 36K!!! You know, I have not even looked to see on the web, but aren't tons of people doing this right now as we newsgroup? I suppose you could actually use the rf signal as data carrier itself and modulate it directly through on/off switching, as opposed to modulating the rf carrier with the audio data carrier... but that would take some heavy duty equip mods/revamps, if it didn't wipe out the neighbors cable tv! grin Think about this: at 100 mhz if you can precisely control the EXACT amplitude of each and every cycle of rf out the back end of the xmitter, you have a virtual 100mbs data carrier... most are working here... 450 MHz? 1Ghz? 12Ghz? .... and of course, the receiver has to be able to decipher the amplitudes of each cycle back to a data stream for the video card... .... this is the land where dreamers are... John "Dee Flint" wrote in message ... "John Smith" wrote in message ... Mike: 300 baud is ridiculous, in Dee's first post mentioning 300 baud I tossed it out the window--that was fine up to about 1985, then only the mentally challenged continued to run 300 baud modems! Please show me and everyone else how we can run more than 300 baud on HF without exceeding reasonable band widths. There are a whole lot of things, not just video, that would be nice to do. How can we do it? Bandwidth is directly related to baud rate. Dee D. Flint, N8UZE |
KØHB wrote:
"Mike Coslo" wrote So here we are. Yup, and no one has persuaded me it can't be done. I've only been persuaded that we haven't figured out how yet. (Sorta reminds you, doesn't it, of how those old-tymey hams must have felt when they were told to take their party to "200 meters and below".) You, Jim, and Dee bemoaning how hard it will be, and John raising the tantalizing notion that we may only be a few "eureka!!!"s away from something workable. He also give a lot of solid technical ways in which this can be done, eh? Outside my area of competence, but I'll watch the dialog with interest. Hey, Hans, ignorance is not a crime! Note that Jim brought up an *actual* method of trying to do a lot of BW using 256 or more phase angles that are decoded by the receiving station. That is not likely to work at HF, but a simplified version of this is used for some satellite comms. they (see my link in my post to Jim) note that QPSK is more reliable - or at least suffers less from link degradation - same thing, than 8PSK. But there is some theory there that can be discussed. And as for "bemoaning", I have been asking for something based in solid theory since early in this thread. Most of what I have gotten in return is that I am an olde tyme ham (untrue) stuck on CW with my Bug (paraphrased, but laughably untrue), and topic shifted to DRM voice (technically working, but beside the point). That ain't substance. |
John Smith wrote:
Mike: Oh no. Now someone is going to have to explain ccd cams and pixels to you, huh? Take a course! Challenge, "John Smith"! DO IT! Post the method in which you and I can send live Video to each other via whichever HF band will propagate between our QTH's, and I will build a duplicate. We can set up a sked. Once we have established live communications, I will most certainly apologize for my olde tyme hamminess. Let us keep everything in the group so that I may apologize publicly when proven wrong. Anxiously awaiting your system outline and diagrams.. - Mike KB3EIA - |
Dee Flint wrote:
Please show me and everyone else how we can run more than 300 baud on HF without exceeding reasonable band widths. There are a whole lot of things, not just video, that would be nice to do. How can we do it? Bandwidth is directly related to baud rate. Dee D. Flint, N8UZE John has been challenged. His system for real time video via HF will be posted soon, TTPUOSU! - Mike KB3EIA - |
Mike:
The clock in a ~4GHz computer and DDR memory makes modem data xfr look incredibly s-l-o-w.... with spaces miles long between marker bits... 100Mbs nic cards are not even close to a challenge to that clock speed... John "Mike Coslo" wrote in message ... wrote: Mike Coslo wrote: wrote: Mike Coslo wrote: Dave Heil wrote: LenAnderson@ieeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeee.org wrote: How we be gonna scale those pictures and live video to fit into 2.5 KHz? Two steps: 1) Convert the pictures and video into highly-compressed digital formats for transmission. Oooh, there could be a problem there! There are limits to the compression, and we have exceeded them in some forms already. Of course! But it all depends what you consider "acceptable quality"... I'm assuming it has to be better than a very high quality SSTV image in the case of stills, and present day OTA video signals.... Check to see how many vertical pans there are on video signals lately. The compression on the digital signals (note that even if you are getting your feed via analog cable, you are still almost certainly looking at a digital signal) already calls for some major aliasing. OTOH, if all you want is B&W ~CGA video.... Comes pre-aliased! ;^) There are limits, and there are limits. How much more are we going to throw away? Always a tradeoff. Hams routinely use 1.8 kHz wide SSB filters for "communications quality". Hardly hi-fi but it can make the difference between QSO and QRJ. 2) Use different modes/modulations/protocols Shannon's Theorem tells us that we can get very high data rates through very narrow bandwidths *if* we have adequate signal-to-noise ratio. Note that "noise" takes many forms, not just the thermal noise we're used to. What're we going to do when the data rate that we need is darn near(or above) frequency in use? Use modes designed for the purpose. See below. And a high enough frequency to handle the BW requirements. For example, PSK has an advantage over OOK when dealing with thermal noise. But when dealing with other types of noise, OOK can have an advantage. It all depends on the transmission medium. What works on a telephone line may not work on an HF path of the same apparent bandwidth. I thought that we were going to be able to send live video and digital images on HF? You can do that now - just need enough S/N. Always? No mode always gets through. But if you have enough S/N, all sorts of things are possible. Remember though that we are talking about our favorite playground - HF. A high S/N is not often the case here. Here's one way. I apologize if you are way beyond this simplified example: Consider how PSK31 works in BPSK mode. There are just two basic modulation states - 0 degrees and 180 degrees. One bit per unit time. But in QPSK mode, there are four basic modulation states - 0 degrees, 90 degrees, 180 degrees and 270 degrees. Two bits per unit time, but the bandwidth is no greater than with BPSK. Only problem is that you need a transmitter, receiver and transmission medium whose total distortion is low enough that you can accurately tell the four states apart. Now consider a theoretical "256PSK" mode, in which there are 256 states: 0 degrees, 360/256 degree, 720/256 degrees, etc., all the way to ~359 degrees. 8 bits in one unit time, in the same bandwidth! But you need a transmitter, receiver and transmission medium whose total distortion is low enough that you can accurately tell the 256 states apart. The error rate would be fantastic! You can see that if we just keep increasing the number of states, the number of bits per unit time in the same bandwidth keeps going up. But you need more and more accurate modulator/medium/demodulator - IOW, better and better signal-to-noise. Or to look at it another way, the mode carries huge amounts of data in a tiny bandwidth but has very little tolerance for noise that takes the form of phase distortion. Now for this system to be practical, there would have to be a way to correct for all that phase distortion Now imagine multiple spaced carriers in the 2.5 kHz bandwidth all carrying data - lotta bits, huh? Now yer cheatin! ;^) That is increased bandwidth Of course you may find that in practice it's not that easy to get a modulator/medium/demodulator setup that meets the requirements - particularly if the medium is HF RF with relatively low power. I have to imagine that there must be a lot of power, despite the sensitivity being to phase distortion. When I look at my phase display, there is a lot of noise showing up that can become bogus phase noise. Simply by hooking our computers to our rigs via the proper interfaces. And software. I really didn't think it was all that simple. Nobody said it was simple! Mr. Smith did! Why don't we get together and pop off a live video system for say the 160 meter band. The video would be real time, 30 fps, and otherwise like broadcast video. Better yet, Why don't we do it at computer resolution? Ask the PROFESSIONALS, Mike. Remember, ham radio is a HOBBY, according to them.... SNORT! Now it seems that the *idea* is that we are going to use DRM, and we're going to need to get more spectrum in which to use. There are all sorts of solutions. But there's a world of difference between people talking theory and actual application. I did hear that DRM was capable of doing imagery. I couldn't find any examples tho'. And they were very vague about it. Most of all, some folks confuse the journey and the destination. The journey beats all..... Exactly. Does complex and newer equal better? Sometimes. Not always. Is analog simpler than digital? Sometimes! Does having a computer that attaches to the Internet make a person a digital expert? Some folks think so! I don't. And besides - "digital expert" doesn't mean someone knows much about radio. Ain't that the truff? I ask for enlightenment, I get invective. Are you surprised? Nope. It doesn't make for a very good discussion tho'. Discussion is not what the invective-hurlers want, Mike. You're right. Your multi-angle psk is the closest thing to possibility that I have seen yet. For Satellites and other UHF applications, it starts to become possible/practical: http://www.tech-faq.com/qpsk.shtml They also write about 8psk. Note that link degradation is an issue. Here on HF, we just don't have the proper conditions. I can do quadrature mode, but almost no one does. I've done some QSO's using BPSK63, but of course that uses more BW. But imagine! Someone (you) writing about something with a real possibility, not just calling me stupid or ignorant, etc!!!! Sunnavagun (with apologies to Hans) BTW, 20 meters is going to town tonight! - Mike KB3EIA - |
| All times are GMT +1. The time now is 07:20 AM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
RadioBanter.com