Unitrunker: P25 raw signal MUST be filtered

Status
Not open for further replies.

js_scan888

Member
Joined
Jul 1, 2008
Messages
56
I would like to make a strong recommendation that the Unitrunker program apply a RC "rasied cosine" filter to the incoming raw signal. From looking at old posts it looks like this is not being done or that there's a problem somewhere in the implementation.

I think a lot of the problems with decoding weak or noisy P25 signals can be eliminated. I've included a graph of a weak P25 signal. The signal does not look very good, but with an RC filter applied in real time the signal can easily be decoded.

Frame sync: +3+3+3+3+3-3+3+3-3-3+3+3-3-3-3-3+3-3+3-3-3-3-3-3

1st plot: Frame sync square wave before RC filter.
2nd plot: Frame sync after RC filter. Ready for transmission.
3rd plot: Raw incoming signal from "line input" of soundcard. Can you spot the frame sync ?
4th plot: Raw signal after RC filter. Frame sync can easily be seen now and signal decoded.

Example Code with RC filter:
sample rate: 96000 hz
cutoff freq: 2400 hz
roll off: 0.2

I think this filter would be a good thing to add to the Unitrunker program.
I've also attached some sample C code on using the RC filter.
 

Attachments

  • sigplot.jpg
    sigplot.jpg
    38.4 KB · Views: 1,746
Last edited:

mancow

Member
Database Admin
Joined
Feb 19, 2003
Messages
6,879
Location
N.E. Kansas
Any suggestions as to how to do something like that with hardware? I have a project that I'm working on that needs a clean signal.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
JS - your point is very well made (although I don't know what all those consecutive "+3" 's mean). I experimented with doing exactly as you are suggesting here a few years ago. I found that the waveform *looked* smoother but saw no measurable improvement in decoding.

If you run the Uniscope program on a P25 waveform - you can check the "Filtered" option to see the effects of a raised cosine filter applied to the waveform.

For anyone wondering ... the coefficients in the OP's sample C code come from York University's Tony Fisher. You can find details here.

I can certainly revisit the filtering issue but based on past experience I'm not optimistic. I'm also concerned about the increase in CPU load. Again, check the "filtered" option on Uniscope to see the impact.
 

EricCottrell

Member
Premium Subscriber
Joined
Nov 8, 2002
Messages
2,413
Location
Boston, Ma
Hello,

I did some research on this and the Raised Cosine filter is meant to be on the TX side only. The RX side consists of a FM Detector and a Moving-Average Filter of one symbol time. There is an additional pre-emphasis filter on the TX side to counter the effects of the Moving-Average Filter and this pre-emphasis filter may be the cause of the "noise" on the signal.

The Moving-Average Filter is the "magic" that allows decoding of both C4FM as shown in the first message and CQPSK which looks like occasional up or down pulses in the signal. The output consists of the average of the last symbol's worth of samples. So at the 4800 symbol per second data rate and 48000 sound card sampling rate this is 10 samples.

The real fun part is the stochastic gradient bit recovery. Only certain zero crossings should be used for symbol synchronization.

73 Eric
 

js_scan888

Member
Joined
Jul 1, 2008
Messages
56
Howdy - just out of interest what program did you use to create those graphs?

That was just me using some MoveToEx and LineTo functions inside the WM_PAINT message.
Otherwise I use the free Gnuplot program for MS Windows.
 

js_scan888

Member
Joined
Jul 1, 2008
Messages
56
JS - your point is very well made (although I don't know what all those consecutive "+3" 's mean).

I can certainly revisit the filtering issue but based on past experience I'm not optimistic. I'm also concerned about the increase in CPU load. Again, check the "filtered" option on Uniscope to see the impact.

Oh the +3's and -3's was just showing the frame sync pattern with +3=01 and -3=11 dibits.
When using Uniscope I do see a difference when using the filtered option. From the message I just saw from Eric, it looks like there is a better method than using an RC filter. Maybe this other method doesn't require so much computations.
 

js_scan888

Member
Joined
Jul 1, 2008
Messages
56
Hello,

I did some research on this and the Raised Cosine filter is meant to be on the TX side only. The RX side consists of a FM Detector and a Moving-Average Filter of one symbol time.
73 Eric

Thanks Eric, I'll look into that more.
 

Nessus

Member
Joined
Oct 5, 2011
Messages
28
Hello,

I did some research on this and the Raised Cosine filter is meant to be on the TX side only. The RX side consists of a FM Detector and a Moving-Average Filter of one symbol time. There is an additional pre-emphasis filter on the TX side to counter the effects of the Moving-Average Filter and this pre-emphasis filter may be the cause of the "noise" on the signal.

The Moving-Average Filter is the "magic" that allows decoding of both C4FM as shown in the first message and CQPSK which looks like occasional up or down pulses in the signal. The output consists of the average of the last symbol's worth of samples. So at the 4800 symbol per second data rate and 48000 sound card sampling rate this is 10 samples.

The real fun part is the stochastic gradient bit recovery. Only certain zero crossings should be used for symbol synchronization.

73 Eric

Just reading through this old post. Eric is correct about this. In the time domain, the magnitude response of a moving average filter is "1" for period T = 1/4800. This is known as a boxcar averager and is effectively a "Unit Pulse". http://sunnytek.net/admin/xiazaifiles/2010114103920522.pdf In the frequency domain, the corresponding magnitude function is the sinc function (sin(x)/x) since the Laplace pair for a boxcar is a sinc. TIA-102 puts it like this:

|D(f)| = magnitude response of the Integrate and Dump Filter
|D(f)| = sin(π f/4800) / (π f/4800)

I played with this definition a bit and came up with a smoothed boxcar here:

http://forums.radioreference.com/di...1-4-mbelib-1-2-3-released-13.html#post1684791

Regarding stochastic gradient bit recovery, I have a working solution that learns from the frame-sync then self-heals giving a very clean symbol histogram even in highly degraded signal conditions.
 

MattSR

Member
Joined
Jul 26, 2002
Messages
407
Location
Sydney, Australia
Information on this seems to be a bit thin - can you share your solution or point us to a source?


Regarding stochastic gradient bit recovery, I have a working solution that learns from the frame-sync then self-heals giving a very clean symbol histogram even in highly degraded signal conditions.
 

Nessus

Member
Joined
Oct 5, 2011
Messages
28
Hi Matt,

Before venturing into the solution domain, I always like to get a firm handle on the problem at hand. Nothing more frustrating than investing your most precious resource into a venture that yields the solution to the wrong problem, would you agree?

Would you mind clearly articulating the problem that you are trying to solve?

For example:

1) I wish to decode P25 digital communications that are already in the clear, but may be significantly degraded due to phase delay in the channel.

2) I am working on a hobby project to port a P25 Symbol decoder into the BCD996T scanner firmware and I would like to ensure that I have symbol decoder that is <SIGNIFICANTLY> superior to Uniden's current solution (yes even the solution in the BCD536HP/BCD436HP!), because I intend to release firmware onto that platform that folks would be willing to pay a small fee for.

3) Having discovered that the entire P25 "DEC" part of the IMBE CODEC is in fact embedded in the BCD996XT firmware, and NOT in an external H/W module I am rewriting the DEC to also handle P25-Phase II thus breathing new life into all BCD996XT Scanners and I would like to make sure that I have a truly skookum P25 symbol decoder to go with it when I release this new firmware.

You know, that sort of thing.

Perhaps we could join forces if you have something interesting to bring to the table. In that regard, at present I would like to recommend that we recognize our collective indebtedness to John Doe for sharing his pioneering work in the area of Uniden Archaeology on the Twittersphere...if that is a word.

Who is John Doe? I am sure I don't know, but he is a rather clever fellow, and as luck would have it he is also a member of this distinguished forum:

http://forums.radioreference.com/members/n3617400.html

Here then Matt is some stuff to whet your appetite and assist in formulating your problem statement:

Timing Recovery - Springer

http://forums.radioreference.com/vo...-unitrunker-p25-raw-signal-must-filtered.html

http://web.stanford.edu/group/cioffi/doc/book/chap6.pdf

P.S. Don't waste your time on encryption if that was where you were headed. I promise you, it is unbreakable, even by you-know-who. You will just annoy/attract murky folk who are better left to their own devices. I will not exchange communications or ideas on this subject.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
2) I am working on a hobby project to port a P25 Symbol decoder into the BCD996T scanner firmware and I would like to ensure that I have symbol decoder that is <SIGNIFICANTLY> superior to Uniden's current solution (yes even the solution in the BCD536HP/BCD436HP!), because I intend to release firmware onto that platform that folks would be willing to pay a small fee for.

It's not exactly clear whether this was just a rhetorical flourish or if it represents an actual project, but very interesting (if true). However it will ultimately depend on whether the hardware implements IF DSP. If it doesn't (i.e., if the implementation is a standard AF DSP architecture, tapped at the output of the discriminator), the results are guaranteed to be substandard compared to a proper decoding of the complex QPSK constellation (when attempting LSM demodulation).

Would you mind clearly articulating the problem that you are trying to solve?

I don't think Matt was unclear in his question. I too would be interested in more detailed technical info - a paragraph or two on your work and experiences with the stochastic gradient algo, as it sounds pretty neat. Anyone can search online, so extraneous links to academic papers aren't necessary.

A lot of time has gone by and a lot of things have changed since this thread was started... For example P25 Phase 2 drops all pretense of C4FM compatibility - the downlink modulation format is officially now spec'ed as "H-DQPSK". The official demodulator defined in the spec for P25 phase 2 (differential PI/4) was implemented long ago in OP25. The P25 P2 specification also outlines a method for using LLR (Log Likelihood Ratios) to generate the most likely bit sequence, which is also currently implemented (in simplified form) in OP25.

Max
 

MattSR

Member
Joined
Jul 26, 2002
Messages
407
Location
Sydney, Australia
P.S. Don't waste your time on encryption if that was where you were headed. I promise you, it is unbreakable, even by you-know-who. You will just annoy/attract murky folk who are better left to their own devices. I will not exchange communications or ideas on this subject.

I'll ignore the rest of the post as Max has addressed it perfectly. As for crypto - well, I suspect what you have written is clear case of trolling. The OP25 project published a paper of the crypto flaws 5 years ago now and it was accepted verified and presented at Securecomm.

Seeing as you are mistakenly convinced it can't be done, and that you are implying that you somehow have "ideas" on it that are so incredibly special they can't be shared lest the men in black come after you, I shan't bother posting the paper or source code that shows exactly how it works, even thought they are all freely available online and have been published elsewhere.

Cryptography is a public-domain endeavour, there's no secrets to be had, and every discovery that has been made is based on concepts that have already been proven and built up over time. As Isaac Newton wrote in 1676 - "If I have seen further, it is by standing on the shoulders of giants." In the case of OP25's cryptographic breaks with P25, we built upon the famous work done by EFF and distributed.net back in 1997/1998, as well as other proofs that have been implemented such as the COPACOBANA project.

Regards,
Matt
 
Last edited:

Nessus

Member
Joined
Oct 5, 2011
Messages
28
Good news Matt! I presume that you are referring to Rijndael, the current standard for coded communications in P25. I expect that will result in a Nobel prize for some brilliant researcher shortly. Do you happen to know what algorithm is replacing FIPS-197? The journals are remarkably silent on this topic. Also, I am not familiar with the paper that you allege, but are unwilling to share. Is it perhaps a “square root of negative 1” type of paper? Ha!

I saw a paper on DES-OFB related to P25 back in Sept 2011. This paper was completely uninteresting owing to the fact that FIPS46-3 was withdrawn by NIST on May 19, 2005, more than SIX YEARS PRIOR. Not making this up yo: [http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf]. So unless your county’s public safety dept. is still using DES-OFB Matt, and trust me they aren’t for the very reasons you cited, my assertion stands. Besides, would you even know how determine whether that was the case by recovering the voice frames and analyzing them yourself? Apparently not, or you wouldn’t be beaking off like that. In case you ever decide to establish facts first, and type second, the answer is in Section 5.4 on page 14 of TIA-102 BAAA-A 2003 and also on pages 31 and 41 of TIA-102 AAAD-A (ANNEX A and ANNEX C respectively). Let me know what you discover off-the-air in your locale, I am curious to see if you are right (or not.)

One more thing Matt. COPACOBANA is out of production. So is FORMICA, its "low cost" successor. I happen to know this because in 2013 I wrote bitcoin mining software that runs on FORMICA, including designing XILINX FPGA targeted intellectual property to implement two rounds of SHA-256 fully pipelined in a single core and at a respectable clock speed to boot. I was able to earn BTC for several months by leasing time on a FORMICA and running my code before BTC difficulty went through the roof. I also wrote a plugin for the controller in Python (specifically, I adapted the MPBM to work with FORMICA API V 1.91 by porting the FORMICA API libraries to Python and writing a FORMICA driver for MPBM in Python). I also developed and sold distributed processing software that runs on the RIVYERA SPARTAN6-LX150 Machine Family. I can easily prove the FORMICA claim, just PM me with your verifiable identity Matt, and I will deliver. Also, not planning on just handing over my intellectual property to the first person who asks, sorry dude.

KA1RBI: The half rate CODEC is not really that hard. Especially if you have already written the full rate one, which is also available in DSD. What is hard is the changes to the packet format that go with it, and I have put that down at the moment, to work on other projects. At present, you and I can get Phase-II by purchasing a BCD536HP/BCD436HP if we need it, or perhaps the GNU/RADIO solution. One will just have to live with crappy symbol recovery for now (Sorry Paul). I also wrote a full rate IBME CODEC well before DSD was published. The largest pain in the behind was typing in and checking all those tables, then debugging the psycho summing algorithms, oh and the cosine transforms- they were finicky. By the way, that is how I first discovered that BCD996XT was doing IMBE in firmware. All the IMBE tables are in the ROM, and can be easily searched for, as they are unique fractional FP numbers. Example “-2.55826” from page 70 of TIA-102.BABA2003(R2009) is located at ROM Location 0x0CC244 in V1.07.03 of BCD996XT Firmware. The FP number “-2.55826” is represented at that location as the byte string 0xC023BA88. The numbers -2.3828499, and -2.2210419 follow in the memory locations immediately after. Of course…you have to decrypt the firmware first.

That all being said, what is much more interesting is the application of Stochastic Gradient Symbol Recovery to the channel, such that you can learn from, and adapt to changes in channel phase and group delay. This functionality I have fully developed, and have working swimmingly well. I also have a repeatable method to directly measure the performance of my symbol recovery vs. Uniden’s. My symbol recovery rate is significantly superior for the identical signal at the BCD996XT discriminator. I can prove this. I have also written a full P25 ECC suite for DSD to pick-up where the symbol recovery leaves off. If you are the owner of a BCD996XT, send me a PM and I will substantiate this claim.

Regarding more clues on Stochastic Gradient Symbol Recovery. Lets consider what Brad Hiben says in. TIA-102 BAAA-A 2003

“The stochastic gradient clock recovery device provides clock recovery for the waveform at the output of the Integrate and Dump Filter. Several techniques are available for this process. The details of the clock recovery are not specified by this document. “

This is Motorola speak for “It is our intellectual property, so why don't you make like the birds and flock off?”

That is exactly the place to start of course. Motorola being a rather litigious bunch, they patent the snot out of everything. Did you know they once tied my employer up in court claiming a patent on the Darlington Transistor connection? Completely unenforceable of course, but effectively shut our production down for 5 years.

Where to look: US Patent Full-Text Database Manual Search

Search terms:

SPEC/C4FM and AN/Motorola
SPEC/cqpsk and AN/Motorola
SPEC/APCO and AN/Motorola
in/hiben and AN/Motorola
in/cudak AND AN/Motorola

This is a good place to build a foundation, but the final leap has to come from your own toil I am afraid. (Our you can wait until I release my firmware, which will be priced reasonably.)

Note: I will only be releasing firmware for BCD996XT.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
I can easily prove the FORMICA claim

[see below]

My symbol recovery rate is significantly superior for the identical signal at the BCD996XT discriminator.
As previously discussed, any approach that utilizes the output of the discriminator is guaranteed to produce substandard results when demodulating LSM. This is a hardware issue and can't be cleaned up after the fact in software (or "firmware"), no matter how clever.

I can prove this .... I will substantiate this claim.

There you go again... You sound insecure

“The stochastic gradient clock recovery device provides clock recovery for the waveform at the output of the Integrate and Dump Filter. Several techniques are available for this process. The details of the clock recovery are not specified by this document. “

All well and good, but it's important to note that document refers to C4FM only, not to "LSM" or to H-DQPSK. As previously mentioned, for example, it's completely inapplicable to P25 Phase 2. It's hard not to regard C4FM as legacy tech at this point, but that's what the I+D filter and all the rest are oriented to.

In fact, any radio claiming P25 Phase 2 support and that uses only the disc-tap method is skating on very thin ice indeed, arguably verging on false advertising...

(Our you can wait until I release my firmware, which will be priced reasonably.)

Note: I will only be releasing firmware for BCD996XT.

The existing bar is very low indeed....

Max
 

Nessus

Member
Joined
Oct 5, 2011
Messages
28
Hi Max,

My previous remarks on symbol recovery above pertain to C4FM signals, I do not have access to CQPSK Traffic, so I will have to rely on the kindness of strangers when I finally proceed with the port of my demodulator to Phase-II. My thinking originally was this is possibly where you and I, or Matt and I could collaborate.

Regarding your information, very interesting, thanks for sharing, you sound quite well informed on the subject, and certainly have more direct experience with Phase-II than I do.

The interesting thing about negative hypothesis is they are asymmetrical. They cannot be proven, only disproven. (Hence my challenge to Matt.) Please give me your opinion: Would you consider the discriminator signal in the attached scope-shot pure enough to reliably convert into symbols? This was taken from Unitrunker

It looks pretty good to me, but as I say, you appear to be the expert.

If either you or Matt want to capture some off-air Phase-II signals right at your discriminator tap and save them in a .WAV file I would be glad to analyze them as I described in the previous post. I will be happy to post the results here for the benefit of all. I will need a set of data that includes at least two complete transmissions between two (and preferably three) different stations, all in one contiguous .WAV file and it MUST be from the discriminator. Even though the the transmission is encrypted, you can still use the UID feature on your BCD996XT receiver to determine how many stations are involved in the exchange as well as their trunk system call signs.

So basically I'm offering to disprove my negative hypothesis (that Matt's County Public Saftey org is NOT using DES-OFB) and I fully expect to disprove your negative hypothesis that CQPSK symbol recovery cannot be reliably performed at the discriminator...Just as soon as one of you sends me the requested .WAV file.

One more recommendation for both you and Matt, let's dispense with name-calling shall we? It is wasted energy, and degrades the quality of information exchange in the forum.

Nessus

P.S. Alan Wilson also disagrees with you Max. See US Patent 5377229, attached for your convenience.
 

Attachments

  • Uniden-CQPSK1.png
    Uniden-CQPSK1.png
    16.7 KB · Views: 944
  • US5377229A.pdf
    686.1 KB · Views: 262

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
As a disclaimer, I admit I have poor DSP knowledge and poor software knowledge. SDR is not my forte.

Having said that, I come from a hardware background in dealing with pi/4DQPSK modulation and demodulation. I was active in that at about the time that the patent paper Nessus attached and referenced was published. The work I did was for 3 slot TDMA cellular systems.

We designed dual mode FM and TDMA digital radios for use on the then still mostly analog cellular systems.

When I started looking hard at the P25 phase I and phase II digital demodulation in consumer scanner radio equipment in the US I was actually surprised at the continued use of a basic FM discriminator circuit to work with both digital and analog demodulation.

I had become familiar professionally with the use of a I/Q demodulator for the reception of both modes.

A true I/Q quadrature demodulator can demodulate pretty much anything. It will work fine for demodulation of analog constant envelope and linear modes as well as both forms of digital (constant and "non-constant" or linear [with some changing amplitude information] modulations). Unlike a FM discriminator circuit it will "look at" and deduce info from both amplitude and phase information in the modulated signal.

A pure FM discriminator will not yield info on varying amplitude information (well, you get some below the limiter threshold on weak signals but we will disregard that for the sake of this discussion) due to the inclusion of a limiter circuit.

In most, if not all, consumer scanner radio designs currently extant (to my knowledge - I do NOT claim to know the intricacies of all the internals of all models) use of highly integrated radio IC's that are cheap and readily available for use in wide frequency coverage receivers is the norm. Such IC's usually yield basic AM and FM receiver demodulation designs that are, while in some cases co-located on the same IC die, are essentially completely separate circuits using very old tried and true AM and FM demodulator designs - a basic rectifier approach for AM and a common discriminator approach for FM.

Using an FM discriminator output as your source to work with you will not get amplitude information (again, above the limiter threshold). So, to attempt demodulation of complex digital signals which contain information in both varying amplitude and phase you are starting with a handicap. You have already discarded "half" of your information about the quality of the modulated signal. You cannot recover that information - it is simply gone. For pure analog FM that is a good thing as you throw out unneeded amplitude information which is just noise. For constant envelope (no amplitude variation sourced information outside of noise) digital modes such as C4FM this is also fine. Unfortunately for complex schemes which contain desired info in changing amplitude and phase this is a problem.

I believe what both KA1RBI and MattSR are saying is essentially that: when you limit yourself (no pun intended) to the use of a basic discriminator circuit output and are interested in complex demodulation modes you have already started with a severe handicap that no amount of post processing can truly and accurately overcome.

Now, to be sure, nowadays it is quite feasible to implement nicely behaved software I/Q demodulators and you can start with simply a downconverted RF signal and run it into a powerful DSP (dedicated hardware or implemented on suitably powerful general purpose CPU's) and you're off and running.

BUT - if you are using just a FM discriminator output as available on common consumer class scanners, well, you get the picture.

If I understand the patent alluded to correctly, it does not state that the receiver design at the finish uses a simple FM discriminator output to recover info from for both constant and linear complex modulation modes. It simply states that the receiver uses a design wherein the Nyquist filter is no longer needed (as opposed to the older methods whereby the channel system Nyquist filtering was spread between receiver and transmitter). The receiver also uses a specially optimized "loose" IF filter. The demodulation includes a "phase demodulator" and a "differential decoder" which are higher level descriptions of what an I/Q demodulator will do.

You can certainly have one receiver demodulator work well for both constant envelope and complex modulation forms but it must use a form of I/Q demodulator to work reliably and accurately, either in hardware or software form - as far as my admittedly limited understanding allows, at any rate.

To the best of my knowledge, although you can use a basic FM discriminator output to demodulate complex modulation forms to some degree, you cannot expect to do so reliably and accurately (assuming you are looking ONLY at the discriminator output).

I do not claim to be right, I well may be missing something here. I am trying to clarify some points brought up here and maybe I can be enlightened and corrected at the same time!

Sorry if I got a bit long worded here!

-Mike
 

Nessus

Member
Joined
Oct 5, 2011
Messages
28
Hi Mike,

That was well done. You quite likely saved a lot of wasted effort on my part. The literature is very misleading.

For example, in Figure 9.3 of TIA-102.BAAA-A-2003 a “Frequency Demodulator” replaces the Phase Demodulator in Figure 3C of US Patent 5377229. From the text of TIA-102.BAAA-A-2003: “The frequency modulation detector can be a standard discriminator output provided by an FM receiver.”

So, the [Frequency Demodulator] in figure 9.3 is a simple FM discriminator while the [Phase Demodulator + Differentiator] in Figure 3C of US Patent 5377229 is obviously a modern day DSP based IF stage I-Q demodulator. Furthermore, the title of figure 9.3 is "QPSK Demodulator", and section 9.6 of this document, (also titled “QPSK Demodulator”) states: “The QPSK demodulator is capable of receiving a signal from either the C4FM modulator or the CQPSK modulator."

Since TIA-102.BAAA-A-2003 was published almost ten years after US Patent 5377229 (1994) I was convinced that a discriminator plus SDR was all that was required to optimally recover DQPSK symbols, as this was clearly the intent of the P25 FDMA CAI working committee

I see now that the point that Max was trying to drive home was that TIA gave up on using the discriminator, as it could NOT accurately convey both phase AND amplitude information. I thought that the central point of US5377229 was that if you put both halves of the RRC Filter in the C4FM transmitter that you could handle either modulation scheme in the same receiver with appropriate post processing, and that once powerful enough post processor was available, one could simply substitute that in, and leave the front-end of the receiver untouched. In fact that is pretty much what lines 12-51 of column 1 in US Patent 5377229 state. I considered that that the choice of demodulator was simply revised (and cost reduced) to a simple FM discriminator in 2003, as TIA proceeded from research to implementation.

Thanks to your persuasive explanation Mike, I did some more digging and discovered that in July 2009 TIA published TIA-102.BBAB which includes “Figure 8 Demodulator for H-DQPSK” on page 14 of TIA-102.BBAB (see attached). This is what Max was referring to. Clearly TIA-102.BBAB contradicts TIA-102.BAAA-A-2003 regarding the suitability of a simple FM discriminator for CQPSK symbol recovery.

Had you not posted today Mike, I would not have discovered this for some time to come. Clearly an optimized CQPSK symbol recovery engine CANNOT be based on BCD996XT Hardware, unless the IF is tapped, and an I-Q demodulator is inserted.

This explains why Uniden went to new hardware for Phase-II.

Thanks Mike.

P.S. If anyone out there is up for it, I am still interested to receive off-air C4FM .WAV audio samples of traffic as described in the previous post above.

Specs:
-Two, preferably three stations interacting with each other. "Normal" radio comms-just unintelligible
-Minimum two complete transmissions per station, and
-I am looking for the kind of traffic that has the MI frame populated with other than all zeros.
-Samples from a discriminator tap only please.
-All this in a single time contiguous .WAV file. (OK if it contains periods of unmodulated base band noise.)

Just PM me and let me know if you do not want me to publish the results on this thread, and I will simply send the results back to you by PM.
 

Attachments

  • H-DQPSK Demod.jpg
    H-DQPSK Demod.jpg
    67.3 KB · Views: 855

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
A pure FM discriminator will not yield info on varying amplitude information (well, you get some below the limiter threshold on weak signals but we will disregard that for the sake of this discussion) due to the inclusion of a limiter circuit.

The LSM signal's "AM component" causes the signal virtually to altogether disappear 4,800 times per second. That is, the signal stregth (magnitude) varies from full strength to almost zero strength at the symbol rate.

Quiz: why would we expect the discriminator circuit to output a meaningful voltage during the instant(s) in time when there is no signal going in to it? If the signal line coming out of the discriminator (or FM PLL demodulator etc). goes a little (or a lot) random on us during these time intervals, what right do we have to get upset?

Quiz: If a limiter (typically, an amplifier driven to the point of clipping) is in use before the discriminator, the limiter output will be nothing but noise during the periods when the input signal strength goes below threshold. What are the effects of this noise on the discriminator output when there is a blast of it every symbol period?

Quiz: as frequency is the first derivative of phase, our FM demodulator essentially takes the derivative of its input (with attendant loss of information). The spec then suggests we take that output and feed it into an "integrate and dump". Now we're back where we started again, except with less information than when we started. Why would we expect this to lead to superior results?

The literature is very misleading.

It is.

This explains why Uniden went to new hardware for Phase-II.

It's not at all clear that they did. For example, is the BCD996P2 a hardware update, or just new firmware?
 
Status
Not open for further replies.
Top