Date
1 - 8 of 8
psk characters speed
|
David Westbrook
I have extended my "rtty length" calculator to do PSK31, too:
http://dwestbrook.net/projects/ham/rtty-length/?mode=PSK31 It will show the BPSK31 transmission time needed for any given string. for example, "CQ CQ PSKFEST DE KJ4IZW KJ4IZW CQ" is 9.44s, but all lowercase is 8.00s This is due to the difference in the varicode encoding -- the utility above displays the encoding for both for a visual comparison. Interesting to see some of the differences .... here's a chart of the encoding per character: http://en.wikipedia.org/wiki/Varicode#Printable_characters ===> I'm looking for someone more knowledgeable than me about the inner workings of the BPSK31 mode to verify the calculations... I based it one the varicode length (from Wikipedia) plus '00' between characters, and 32ms per bit. 73 --david kj4izw |
|
|
|
Steve W3HF
===> I'm looking for someone more knowledgeable than me about the innerI didn't check your lookup table, but the 00 delimiter and 32 ms per bit parameters are correct. And FWIW, it's the same for QPSK31. Although QPSK encodes two bits per modulation symbol, the rate-1/2 convolutional code exactly compensates, making the character rate identical. Steve W3HF |
|
|
|
David Westbrook
thanks steve!
toggle quoted message
Show quoted text
If the rate is the same, and QPSK provides FEC (forward error correctrion) for robust decodes, why isn't it used more? Is is because of the latency? (from wiki) "To successfully decode an input bit requires a large number of phase shift sequences to be received, causing a 20 bit, 640 millisecond latency (delay) in the output of the decoder" Or because we just d_n't r_a_ly n__d 10_% cp_ to un_ers__d th_ m___age? Or other (historical/etc) reasons? --david kj4izw On Mon, Jan 7, 2013 at 10:00 AM, melachri <w3hf@...> wrote:
**===> I'm looking for someone more knowledgeable than me about the innerI didn't check your lookup table, but the 00 delimiter and 32 ms per bit |
|
|
|
Craig AC4M
Some of it is due to no education about QPSK other reason could be due to hams resist change in general, it hard to know the difference by the sound and look (which I can hear the difference and see the difference), BPSK31 is usually the default mode, Not a huge difference in actually performance due to phase noise, QPSK is side band dependent some people on BPSK might be in LSB or USB.
toggle quoted message
Show quoted text
Another side note I think QPSK modulation technique is a little more behaved compared to BPSK (meaning not as wide banded like BPSK can be maybe that is due to the energy being spread out more in the phases instead of just two phases which there is slight penalty compared to BPSK, but the soft decision brings it back up near BPSK levels for sensitivity) --- In 070@..., David Westbrook wrote:
|
|
|
|
Steve W3HF
Craig has already mentioned some of what I would have said:
toggle quoted message
Show quoted text
- Fewer people know the details of QPSK31, and the "default" is BPSK31. - QPSK31 is inversion-dependent, like RTTY, so you have to match the USB/LSB convention of the sender or select INV (or equivalent) in your software. To that I'd add that QPSK31 was originally reported as harder to tune in than BPSK31, but that point may be moot now as most software has a built-in AFC that works well. Some other comments: - If there were an uncoded version of QPSK31, its bit error rate (BER) performance (as a function of SNR) would be exactly the same as BPSK31's when the SNR is normalized to data rate. Since QPSK sends two bits per phase symbol but BPSK only sends one, and the symbol rate stays the same (31.25 symbols per second), you'd need twice as much power to transmit a QPSK31 signal as a BPSK31. But if you could speed up the symbol rate for the BPSK31 to match that of uncoded QPSK31, they'd perform exactly the same (as a function of power and noise). Some of you already realize that the "speeded-up" version of BPSK is BPSK63. Since it runs at twice the symbol/data rate as BPSK31, it requires twice the power, and that WOULD be the performance of QPSK31 if it didn't have the coding. - Due to the convolutional coding, though, QPSK should be about 5 dB better than BPSK, but technically that parameter is defined for an Additive White Gaussian Noise (AWGN) channel. That would be true if the only noise contributors were receiver front end noise, or classic "background static." But HF channels often exhibit other characteristics, like fading (QSB), impulse noise, etc. - QPSK may also be more susceptible to phase distortions than BPSK. These might occur in some propagation conditions, such as polar paths and aurora. But the magnitude of those is enough to distort both signals enough to be unusable, and so the difference may be negligible. - If your PSK software has a phase scope display, it's easy to tell the difference between BPSK and QPSK. A clean strong BPSK signal will be a vertical line (or close to it). A clean QPSK signal with add a horizontal line. - In theory, both BPSK and QPSK should display the same band-spreading characteristics in the presence of large distortions (like overdriven transmitters). I'd speculate that if you perceive that there are proportionally fewer distorted QPSK signals, it's because the operators who know about QPSK are more experienced, and thus less likely to have distorted transmitters. Steve W3HF --- In 070@..., "my_call_is_ac4m" wrote:
|
|
|
|
Robert Johnstone
If you transmit each into a dummy load and time the time your tx stays lit or needle deflects for each on a long string such as you show below, cant you verify the relative times with a simple stopwatch, Since they are about a second and a half different, 10 strings of each per tx should give about 14 seconds difference and average out the key up down/time of your initial relay. Also, you would want your RSID off. Just a thought. KD0FIP #1396 73 If you think this a valid test perhaps we can get 10 members to try it and see what they get so we will know the effect/affect of different cpus.
R.A. Johnstone ________________________________[Non-text portions of this message have been removed] |
|
|
|
Steve W3HF
Or just disconnect your computer from your radio, and let the computer free-wheel. Or just turn off the radio. No danger of transmitting then.
toggle quoted message
Show quoted text
I've done both in the past to verify these things. Steve W3HF --- In 070@..., Robert Johnstone wrote:
|
|
|
|
Steve W3HF
Just re-read this and missed a comment.
If you think this a valid test perhaps we can get 10 members to tryPSK is not dependent on the speed of the CPU, as long as it is fast enough to run the software. The bit rate (for PSK31) is fixed at 31.25 bps regardless of processor. Steve W3HF |
|
|