Complex Digital Demodulation Hardware Discussion

[DaveNF2G]

Discriminator tap vs. baseband?

Back in the early days of taps and slicers, the stated purpose (at least in some of the documentation) of tapping the discriminator was to recover baseband audio.

Now I see comments indicating the baseband is something different. Clarification?

 

[KA1RBI]

Now I see comments indicating the baseband is something different. Clarification?

Yeah, in this context baseband refers to the RF signal as it exists at a "zero IF" frequency.

The concept of Zero IF does not exist in real hardware based receivers because they can't deal with any spectral components below 0 Hz. Complex arithmetic (I/Q sampling) allows us conceptually to software-shift the incoming RF signal (consisting of a band of spectral components) to "0 IF" such that the frequency-translated signal has a center frequency of 0 Hz. One half of the signal spectrum lies above zero and the other half below.

In a digital TX the baseband I/Q signal is at centered precisely zero Hz. However in a digital RX the translated IF signal is not initially exactly at zero until after frequency-lock is achieved...

73

KA1RBI

 

[SCPD]

Quisk

Here's another link - software that supports the RFSpace SDR-IQ and the Soft Rock.

Quisk

It's written in Python so the USRP crowd ought to feel at home.

 

[Mike_G_D]

Man this is great! I love this information and feel I'm learning stuff constantly - great! That's the main thing I wanted to do was stimulate discussion about the hardware aspect of decoding digital two-way radio voice signals. There has been a lot of discussion and development on the software side and that's great - fantastic! - I'm blown away by how far it's progressed and how well said software works using just a disc-tap and PC soundcards! But I wanted to see more discussion on improving the hardware aspects of this - maybe I'm completely off base here but I personally believe that there is room for improvement in terms of the hardware used and IF said improvements can be made and doing so becomes "cookbooky" enough to be universally employed then I believe the software efforts could really shine - pretty much handle anything (not encrypted, of course).

Ronenp, KA1RB, MattSR, and Unitrunker - outstanding info!

KA1RBI, thanks! I forgot all about the USRP - dang, I knew I was overlooking something! I need to research that - ummm,,,I don't mean to be lazy but could someone (KA1RBI) provide a link to the internal design documents of that device? I could search these forums (I think KA1RBI posted it awhile back and I meant to look then but didn't for whatever reason) but I figured I'd ask to maybe save me the trouble. I'm curious what components are used and why the cost is as high as you infer.

Ronenp and MattSR - absolutely great info concerning the XTS5000 design!!!! I was really wondering if designing a circuit that would dynamically switch types of demodulators on the fly according to BER would be practical. Obviously the answer is YES as Moto does that! As you say, clever folks! I originally wanted my vaporware idea to include multiple demodulator implementations and be switchable in software for experimental purposes. I wasn't really thinking of making it on-the-fly switchable according to BER but, providing the hardware is good enough, that would certainly be doable with software control (or maybe, ideally, using a dedicated hardware implementation)! I do think this may severely impact the cost, however, as making the hardware robust enough to handle fast switching in the IF path without severely impacting noise performance and tying that to a good BER decoder (software maybe?) might be problematic from a practical "low-cost" standpoint.

Ronenp - I am a little confused by your last post. This vaporware I'm suggesting doesn't focus on the RF so much as it is primarily an IF-to-bits solution using a user provided front end. It should have multiple switchable IF filters (to accommodate and optimize for different modes) which all have good group delay characteristics for good digital mode signal handling, however, and have a good AGC with loop parameters controlled by software, plus have in-line amp(s) with software controllable gain(s) and with decent dynamic range. I realize that the RF front end used will then be the limiting factor - possible too much so - but I'm trying, perhaps naively, to reduce the cost and complexity a tad by focusing primarily on the demodulator. And, yes, I am a "Ham" though not very active in the last several years or so (heck, I need to check on my license status - I think it expires next year!).

In looking over my previous post, I have to say that that $300 cost for the manufacturers to sell it for might be a bit overambitious (I think I was still buzzing from too much caffeine). Now, especially if you add that neat Moto trick of dynamically switching demodulators according to BER, I feel it's probably going to be at or above the cost of current consumer level digital scanners. I still think it would be viable even at a cost of $1000 or more. I think many hobbyists and experimenters would still buy it. Even if the cost is close to the currently available RF Space and Winradio products, I think that having it focused on LMR usage alone and for use on signals wherein all of the voice data fits within an RF channel of 50KHz or less would allow the design to transfer the cost from making features to support a do-everything analysis receiver to making features focused on LMR narrowband signal support (like switchable filters and switchable demodulator architectures). Anyway, I'm probably just dreaming - ok, I am dreaming! But it's all very interesting and I'm still hoping something nice and solid and "cookbooky" comes out of this somehow;-)!

Thanks for all the great info and discussion guys!! That's one thing I was really hoping for!

-Mike

 

[Mike_G_D]

KA1RBI,

Forget what I asked you - I found the Ettus site and am downloading (verrrrrrry slooooooowly) info now. I even found that I had already downloaded a bunch of stuff including some limited schematics (though they don't cover the parts I am interested in) over a year ago and never got around to fully researching them! Oh well...anyway, I think the Ettus stuff is the way to go for now based on cursory examination. I don't need the TX stuff but it appears as though you can run it in receive only and pick the daughterboards you want (correct?). It sounds as though you have much experience with this system so I may be attempting to pick your brain on this a lot! For me, I need to hunker down and finally get Linux literate - tough stuff for a command line challenged idiot like me, though. Oh well (lots of those "oh well's" lately, huh!).

I 'd still like to see a dedicated LMR narrowband self contained box like my vaporware outline...well, uh...outlines. But, as of now, I think this is the closest real product available (albeit, still somewhat of an overkill for what I want and I still feel more comfortable with selectable hardware IF filters). I need to go back and look over the latest stuff from RF Space and Winradio too.

-Mike

 

[Mike_G_D]

Weeeellll...shoulda gone to bed a while ago but have been looking at the Ettus stuff and pretty glued to it. So far, I am thinking this is the best thing to do what we (or at least I) want. It's a real product and isn't really as bad cost-wise as I was expecting. In fact I think the USRP1 is fine for this purpose since we are dealing with narrowband signals. Maybe a custom daughterboard might be nice at some point but I think what's currently available might be fine for the first go-round. Just the basic RX daughterboard and our own mixers and front end.

I have to study it a lot more, myself, but I have to say that I think the DSD author should seriously look into working with this platform for future development.

Plus I really like the open source aspect of it; I can examine the schematics myself and "thunk it through".

Lots more to look at but I think we should start discussing how best to utilize this beast to mate with the DSD software from now on. I'm shelving my vaporware idea for now until I can at least get a better handle on what this beast can do.

So...let's talk Ettus USRP!

-Mike

 

[ronenp]

Hi
I have looked at the ettus
it is quiet expensive (700$)
while pro SDR radios cost 1000$

I have got answeres from the Softrock radios about a test made for the SI570 (the oscilator)
and the results say it a very good oscilator i can bring the link if neccessary
beside most of the softwares wrtten now start to support I-Q inputs

and if the SDR is good to decode the voyager signals far from the universe (i can bring the link to the experiment if needed) ....

and if its capable to decode Pulsars from the far space i think it is good inough for us also .... it may be the softrock as low cost solution and a pro SDR as a high end pro expensive solution .....

At least thats what i think
Best regards
Ronen - 4Z4ZQ
Ronen Pinchooks (4Z4ZQ) WebSite

 

[RadioDSPjunkie]

Hi ALL,

First of all, I am really impressed of ALL of your enthusiasm and dedication!

As an RF-ASIC-FPGA-DSP engineer for many years design radio trunking controllers, scanners, and other complex monitoring devices including interceptors. I think we should build a repository of all the specs that we are interested in (if we can even get it).

For example, while EDACS, DSTAR, INMARSAT, LTR and SmartNet are reasonable attempts, iDEN is not since it is a totally different Layer 1hysical (L1) and Layer 2: Data (L2) architectures than main stream radio trunking systems. Although, it is still possible with enough resources (i.e. known specs) and engineering expertise, of course!

I have done many complex reverse engineering projects in the past, I know for certain you need to research what you're getting into thoroughly before you can even determine what hardware, software or other tools you will need to complete the project right.

Sincerely,

Jose Miguel

 

[systron]

Hi ALL,

I have done many complex reverse engineering projects in the past, I know for certain you need to research what you're getting into thoroughly before you can even determine what hardware, software or other tools you will need to complete the project right.

i guess DSDAuthor needs copyright protected vocoders as linux software code... just for the disc taps modulations..

AMBE, AMBE+, ACELP, RP-CELP...

 

[Mike_G_D]

i guess DSDAuthor needs copyright protected vocoders as linux software code... just for the disc taps modulations..

AMBE, AMBE+, ACELP, RP-CELP...

I'm on thin ice here in terms of knowledge but if the DSD dude or his ilk can make their OWN vocoders that do the job and make them open source and not try to sell them for profit wouldn't that circumvent the legalities (kinda, in a very rough sense, what was done when the EDACS trunking protocol was reverse engineered to allow production of the first EDACS capable scanner)?

But I agree that getting ahold of the real hardware IC from DVSI (they now have chips - real hardware and not just the software solutions - the AMBE+2 is an example, I think) would be spasmodically wonderful for someone building this stuff! Money, money, money, though!!!!

Ronenp - I wouldn't actually consider $700 that bad, actually. Though, yes, a good deal more than $45! What do you consider "pro SDR"? Are you talking about the RF Space stuff since you mentioned the Voyager data reception? Yes I have read through that.

In both cases, the RF Space and the Ettus products, I still consider both to be a tad overkill for what we (I, at any rate) want but, especially the Ettus because of its open source hardware and software approach, they are the closest real hardware products to do what we (or rather I, at any rate) want. The SoftRock just still sounds not quite right to me - I gotta understand it better, I admit. We can probably add the Winradio do-everything stuff to that list also but that is probably the largest case of "overkill"!

At this point, I'm still gonna lean towards the Ettus camp but am more than willing to be swayed another way if I can be convinced to do so! If that SoftRock can do it I want to see it spit out nice bits for PC processing given drunken, brawling, barfightin', nasty, Harley-riden, "Rules?-we-don't-need-no-stinkin-rules!", surly, nose thumbing, seriously messed up RF or IF at the goesinna port! And I want this done for a real world messed up randomly fading phase distorted PI/4DQPSK or equivalent complexity modulated signal with high level adjacent channel interferers present. I'm all for it if it can be done, believe me!!

RadioDSPjunkie - agreed in full (mostly), especially the last paragraph - I've worked in that environment though I don't think I've done near as much reverse engineering as you sound like you have done. And I am not even close to being DSP-literate though I have dealt with a lot of brilliant DSP gurus. One question, though, why would iDEN be any harder to handle from a hardware pre-vocoder preprocessing point of view? I mean, wouldn't its modulation be just as yielding to a quadrature demodulator and/or discriminator-slicer as anything else? I don't know alot about it (iDEN) but we are concentrating, in this thread, on just getting the RF to as clean as possible baseband I and Q or the digitized equivalent as cheaply as possible. Everything after that is back in the software geniuses (including any DSP gurus') ballpark, as far as I am concerned.

Good discussion, let's keep it flowing!

-Mike

 

[Raccon]

Ronenp - I completely agree on the need to examine real radios! I was thinking today about wishing we could look at a TETRA portable radio's internal receiver design because IF TETRA really uses PI/4DQPSK as someone on here said earlier, then its demodulator should give us a good indication of a design which could handle some pretty nasty complex digital signals. That is, unless it's all wrapped up in some proprietary system-on-a-chip large scale IC which we can neither look at the innards of nor use in a flexible multi-mode analog and digital high performance sense - it might be great at TETRA and pretty much useless on anything else.

TETRA does use π/4 DQPSK modulation.

The most used System in Europe are Tetrapol.

Based on what - number of systems installed, number of base stations, number of users ... ?

 

[grosminet]

European market

TETRA does use π/4 DQPSK modulation.


Based on what - number of systems installed, number of base stations, number of users ... ?

France, Spain are using Tetrapol for police, firemen forces (nationwide network) 15000 devices . We have also (France) many Tetra networks (french main motorways )

 

[systron]

Based on what - number of systems installed, number of base stations, number of users ... ?

TETRAPOL currently has 80 networks deployed in 34 countries and claims 70% of the European Digital public mobile radio (PMR) market.

With 91 networks in 35 countries, more than 1,850,000 users are already covered by TETRAPOL.

Tetrapol GMSK can be decoded with a soundcard and a disc tap.

We should aks the DSDAuthor if he could include some "European" systems.

 

[RadioDSPjunkie]

The real reason is that I have worked on RF monitoring system that was adapted to small iDEN network awhile back here in South America. The Layers L1 thru L3 is Motorola proprietary cellular specifications modded from the GSM standard and therefore discriminator taps and data-slicers will not work unfortunately, but a custom I/Q demod RF/SDR front-end would. However, in my experience, I noticed the prominent VSELP vocoders are close related to GSM-HR and IS-54 combined. By examining the handsets, there are actually four(4) vocoder modes for iDEN, AMBE4400, AMBE2200, VSELP4200, and VSELP8000. I believe the VSELP8000 LPC vocoder is similar to Astro's as well (if someone has discriminator tap let me know, we'll see if it works with DSD+VSELP). From this experience, there's a very high probability of decoding Astro VSELP networks using DSD, however not likely for the iDEN dispatch radio without using SDR. Also, since the iDEN radio network based on packet data, the packet data contents can also be possibly decoded once the L2 transport mechanisms are figured out.

 

[RadioDSPjunkie]

Hi all again,

I forgot to mention that this thread gave me a low-cost idea that I can bounce off of you guys:

How about a small low-cost DSP-capable microcontroller (like a microchip's dsPIC) with an RF front-end and USB/Ethernet connection under $100 of Bill of Materials (BOM)?


Antenna --> BPF --> ADC --> DDC --> dsPIC --> USB and/or Ethernet

I think there are SWL/HF projects out there that uses this method with 48KHz bandwidth processing.
For trunking we can just probably daisychain them!

The hardware and software will be open-source!

Any thoughts?

 

[tripleplay905]

I believe the VSELP8000 LPC vocoder is similar to Astro's as well (if someone has discriminator tap let me know, we'll see if it works with DSD+VSELP)..

What exactly do you mean by this? I am within range (mostly) of a major trunked system using VSELP voice. If you need a tester for DSD+VSELP I am available.

 

[RadioDSPjunkie]

Astro VSELP decoding parameters

Hi tripleplay905,

That's interesting that you have access to ASTRO networks.

Do you know what radios they are using on those networks? XTS3000 on VSELP mode? That could give us a hint (or just confirm) what vocoders are in use.

Vocoder specs look like this?

VSELP 4.8kbps
ECC 2.1kbps
Signaling 2.7kbps

Total
bitstream 9.6kbps

Modulation C4FM/QPSK-C

Must be 30ms compressed speech samples?

If this is the case, then the LPC vocoder maybe closer to GSM-HR/FR, IS-54, and iDEN VSELP4200 with similar Gaussian-based codebooks.

Let's see if we can capture some discriminator taps and I will try to identify patterns.

JM

 

[tripleplay905]

Cleveland Trunking System, Cleveland, Ohio - Scanner Frequencies

Above is the system I was referring too. Honestly I don't know any technical specs about it unfortunately.
I know that they have had this system in place for a extremely long time (~15 years?), and are reluctant to upgrade.

How clear of a recording do you need from a discriminator tap? I think I am too far away to get a perfect recording, but the signal is still there.

 

[Mike_G_D]

The real reason is that I have worked on RF monitoring system that was adapted to small iDEN network awhile back here in South America. The Layers L1 thru L3 is Motorola proprietary cellular specifications modded from the GSM standard and therefore discriminator taps and data-slicers will not work unfortunately, but a custom I/Q demod RF/SDR front-end would. However, in my experience, I noticed the prominent VSELP vocoders are close related to GSM-HR and IS-54 combined. By examining the handsets, there are actually four(4) vocoder modes for iDEN, AMBE4400, AMBE2200, VSELP4200, and VSELP8000. I believe the VSELP8000 LPC vocoder is similar to Astro's as well (if someone has discriminator tap let me know, we'll see if it works with DSD+VSELP). From this experience, there's a very high probability of decoding Astro VSELP networks using DSD, however not likely for the iDEN dispatch radio without using SDR. Also, since the iDEN radio network based on packet data, the packet data contents can also be possibly decoded once the L2 transport mechanisms are figured out.

I am still a little confused by your questions. In my experience the vocoders do not accomplish any signal demodulation - they are for handling the decoding of the digital voice frame data purely in the "digital domain" (1's and 0's). In this thread, I am only concerned with the proper and consistent demodulation of the RF information down to digital bit level BEFORE any processing by further hardware (i.e. a dedicated DSP vocoder IC) or software (like the DSD stuff).

In your follow-up post you propose a simple design - in theory - and it is pretty much the "holy grail" of SDR pundits (well, to be honest, they would like to see a pure super wideband super high dynamic range RF amp to super wideband with super high dynamic range handling ADC+DSP to DAC to audio amp design with no external hardware filtering and no up/down conversion). Unfortunately, due to constraints and cost of current hardware and the nasty RF environment of the urban real world this type of design without at least many switchable front end bandpass filters and adjustable gain RF amps will suffer severely from front end overload and IM issues and adjacent channel selectivity issues. For limited bandwidth applications wherein you look at only a small RF input bandwidth and with a good high linearity RF font end amplifier this can work but is much harder to do in real life for very wideband RF inputs in the VHF and higher ranges.

But hey, if you can do that (25MHz to 950MHz RF input frequency range, very high dynamic range, very high IMD immunity and at least 60dB adjacent channel selectivity for selectable common narrowband LMR signal bandwidths) and get it to clean bits out consistently and while tested in multiple urban heavy RF congested environments with hardware costing less than $500 USD then, believe me, I'm all for it!!

-Mike

 

[KA1RBI]

Well I may have to take back some of the bad things I said about the 455 KHz IF.

With a new, improved version of the demodulator software (USRP SDR) connected to an old PRO-2006 which has been tapped for a 455 KC output, and tuned to a really nasty LSM CQPSK station on 800 MHz (located in another county), got the symbol plot shown here... The result decodes nicely with some occasional Trellis errors. So it can be done!

One noticeable thing: the avg. distance between the +1's and -1's is less than between them and the +/-3's, a very strange form of distortion that's worse here than I've seen anywhere. It is apparently caused by the use of differential decoding which in turn is forced by the very bad results of direct decoding of the constellation, and THAT is most likely caused by the aforementioned maladies in the scanner circuitry ...

Max