I have two (or maybe two-and-a-half or three) questions that may or may not have been answered already, but I haven't seen a definitive answer in my trawl thru this and the pre-release thread (and I think I've even asked both questions once or twice). So I am asking again for a clear, straight answer.
1. It's my understanding that the PSR-800 has a "discriminator tap" built in. I presume this is the "PC/IF Data" function. Do recordings saved using the record function involve discriminator audio? In other words, can I have the scanner record a MotoTRBO signal, then play it back into DSD at a later date in order to decode it? Or are the recordings "normal" audio and not suitable for use in an application where "tapped audio" is required?
1a. May be irrelevant depending on the answer to the above question, but I have tried playing back audio on the scanner and had no luck getting it to pipe thru the earphone jack to the program requiring tapped audio. I have had marginal success by copying the recordings to my computer, then playing those recordings from the computer into DSD. Am I doing something wrong with the scanner or does it just not pipe out tapped audio on playback? (Furthermore, when I tell the scanner to output PC/IF to both headphone and speaker, I don't hear anything other than the usual audio. Is this expected?)
2. Another recording question - I did a ton of recording today and found when I got home that many of the recordings were garbled, as if they were sped up/missing about 25% of every half-second or so. After looking at the settings, I discovered I have (a) recording set on all my channels/talkgroups and (b) CCDump enabled to write to a file on the SD card. Are these incompatible with one another - i.e., is the CCDump function messing with the ability to write clear, coherent audio files?
1. The PC/IF output and the true discriminator output are two entirely separate and different animals.
The PC/IF control channel data output is the same as what is on the 500 series units. It uses the internal processing of the scanner to demodulate and strip out the essential "bits" from a compatible control channel signal (EDACS wide and narrow, Motorola 3600 baud, P25 9600 baud). This is strictly for control channel decoding and will not work for spitting bits for anything else such as non-compatible control channel systems and voice data of any kind. Think of this as a subset of Unitrunker built in to the radio - only the part that listens to the discriminator output and then demodulates and pre-decodes the digital bits before sending them out the PC/IF jack. Then, programs like Unitrunker can just do the final post processing of the bits without having to deal with actual discriminator audio. It offloads some amount of work from the external program by doing the rest internally within the radio. So, again, what gets spit out of the PC/IF jack for control channel data is really just actual digital 1's and 0's (like you would see on USB ports and serial ports notwithstanding the voltage characteristics and NRZ or RZ stuff and such) and NOT discriminator audio output; what you would see here using a scope would be actual square wave type transitions between high and low states - not analog audio signals. People seem to get this confused constantly based on what I read in these forums. One simple analogy to understand this better is to think of an old analog dial-up modem. The telephone audio coming INTO that modem is analog audio with audio frequencies and phases modulated to correspond to digital data. This is analogous to the discriminator audio output in a radio when tuned to a control channel (or any digital modulated signal). The OUTPUT of this modem, however, is actual binary data bits demodulated from the analog audio coming over the phone line. This is analogous to the PC/IF data that the 500, 600, and 800 can spit out when tuned to a compatible control channel signal. Now, if that modem does not have FAX capability then, if confronted with a FAX signal coming over that phone line it would not know what to do with it and would output either garbage or nothing at the computer data output just as the PC/IF port would not output anything when the radio is listening to a non-compatible control channel or to any digital voice channel.
The discriminator output is BEFORE ANY processing (or should be) with the possible exception of some amplification. Looking at this output with a scope you would see varying analog audio frequency (AF) waves and not the binary digital high and low states you would see on the PC/IF output. Prior to the 800 if you wanted to use raw discriminator audio on consumer scanners in this price range you had to internally modify them to tap that point in the demodulator chain within the radio. The 800, however, already does this for you so no internal modification is necessary. Instead of using a separate pre-amp and jack for the output, however, the designers decided to utilize the headphone jack with a switch inside which could then send raw discriminator audio out of that jack rather than the post processed and demodulated audio. I do not know if the 800 has a "stereo" jack which can allow simultaneous demodulated and processed audio as well as the raw discriminator audio by using one side for the raw discriminator output and the other for the normal post processed audio - it is feasible to do this, technically, but I have no idea whether the 800 can do this; as far as I can tell from what I have read in these forums I THINK it is either one or the other and not both simultaneously but I do not know for sure. In any case, you want this unprocessed (or very lightly processed) raw discriminator audio to be available so that you can use any computer program and hardware you want to then process and demodulate the signal in any way that you wish. This is necessary to allow for demodulating digital signals that are not part of the group of signals that the radio can demodulate and process internally on its own such as MOTOTRBO, NXDN, and other voice modes and non-compatible control channel modes (such as some forms of LTR other than the common standard LTR). It can also, of course, be used to use external hardware and software to demodulate and process signals that the scanner can handle internally in case one just wants to use external means which might do better than what the scanner can or just for experimentation. You want "raw" discriminator output here because you want to be in full control of the post processing (filtering, limiting, etc.) and demodulation so as to give you maximum flexibility. The difference between this point and the actual audio output from the speaker or headphones (normally) is that the raw discriminator has NO processing applied apart from the discriminator action itself (look up FM discriminator in Google if you want to understand it better - don't currently have a simple explanation written up yet, myself; essentially it converts the phase or frequency changes in FM signals to amplitude changes to allow further processing and application to a speaker output for human ear compatibility). When dealing with analog FM signals the output of this is processed, including standard voice audio filtering to exclude potential noise outside the standard human speech range (300Hz to 3KHz, roughly, give or take); of course a music centric radio would want to extend that range for music listening (typically 20Hz to 20KHz) and, likewise, a digital centric radio might not want any filtering at all or else completely different filtering. This is why you want raw discriminator audio - to AVOID that post processing that you otherwise want when listening normally with headphones or speakers.
1a. Understanding the above, the answer to your "1a" question is likely that the recorded audio is ONLY from the post processed and demodulated audio from at least a few stages following the discriminator (including filtering, limiting, etc.). So, even if you turn off the digital demodulation and force the unit to receive analog only, the audio frequency signal would only contain information within that voice frequency range of approximately 300Hz to 3KHz and would heavily filter anything outside that range. Since to properly demodulate digital information contained in FM radio signals in many cases requires the usage of frequencies and phases well outside that "speech range" and completely different processing altogether, trying to use the speech filtered standard audio to feed external post processing and demodulating computer+soundcard+program (DSD, etc.) would yield poor results. Technically, the scanner could have designed within the ability to record raw discriminator output but that may have either not been initially considered due to cost reasons or just not thought of at all. Since the vast majority of users simply wanted the ability to record human speech type audio that's what they would have designed for as a priority. Keep in mind that, because of the extra bandwidth required to accurately record raw discriminator signals they would, necessarily take up more space on the record medium. Also, the record circuit would have to have the ability to tap right after the discriminator (with, maybe a preamp in line and perhaps some form of filtering to prevent the analog to digital converter from aliasing severely and limit its bandwidth derived data output for record space conservation issues; up to a point, ideally you would want to have as pure a raw discriminator recording as possible but that could cause complexity issues in the A/D converter as well as capacity issues in the recording medium) and, obviously, if you understood my explanation above, NOT after the normal human speech filtered audio circuitry. Additionally, a switch to select which audio to record would have to be provided in software, in hardware or in both. Having it simply default to recording BOTH speech filtered audio AND raw discriminator audio simultaneously would likely add even more record medium capacity issues since you would have double files for all incoming signals - one speech filtered and one raw discriminator audio with its larger and more complex data requirements.
I can't answer, exactly, your question number 2 but I would guess that you are correct in guessing that having the CCDump record feature turned on while trying to record standard audio might be overtaxing the internal hardware too much. I have no information on this, myself.
Hope this helps your understanding.
-Mike
