Any chance we will see iDen decoding in DSD?

[kb1ipd]

It may be surprising to some to learn that iDen is normally transmitted without encryption, but that is, in fact, the case. As a result, iDen traffic can be received, in the clear and without need for encryption authorization, using Motorola test and monitoring equipment.

Iden is a pretty simple format. It uses a VSELP vocoder and is a pretty straightforward 6x tdma transmission with 25khz channel bandwidth. It seems it should not be terribly hard to decode, although it would require a VSELP decoder to be added.

One problem with including iDen decoding is that the largest user of iDen has been Nextel, which uses it for voice traffic on the phone service. This would represent a problem since listening to mobile phones is generally illegal and presents real privacy concerns. The authors of DSD seem to want to avoid making trouble and thus have not added an encryption option. So adding iDen might be a difficult problem, simply because it opens the door to phone monitoring.

However, Sprint, which purchased Nextel a few years ago, has announced they are shutting down the nationwide iDen service and transitioning their customers to their CDMA service. With this shutdown, most of the phone traffic on iDen will vanish and the remaining users will primarily be dispatch radio and other professional radio users.

Given this, I am wondering it this could mean that it will be less problematic to include iDen decoding in DSD and if this makes it a realistic possibility in the near future.

 

[SCPD]

The trade literature claims iDEN (formerly MIRS) is 16QAM. I do not know if an FM discriminator will faithfully pass a useable waveform for decoding. This may require IQ sampled data - something DSD does not support.

 

[rbrtklamp2]

It may not be possible with a discriminator tap but with all of these SDR dongles/USRP's coming along you can pretty much monitor any signals you want as long as you can decode the audio. If its on the air sooner or later some one will figure out how to monitor it, its just a matter of time and knowledge.

Bob

 

[inigo88]

It may not be possible with a discriminator tap but with all of these SDR dongles/USRP's coming along you can pretty much monitor any signals you want as long as you can decode the audio. If its on the air sooner or later some one will figure out how to monitor it, its just a matter of time and knowledge.

Bob

Hi Bob, my thoughts exactly. I recently purchased the Realtek RTL2832u RT820 USB dongle (very cheap at around $20) and am so far extremely satisfied with the results. It's honestly kind of amazing how many NEXTEL iDEN channels are in the 848-869 MHz range, because the VSELP-based vocoder sounds so much like static it's very easy to dismiss as noise or birdies. Running SDR# with the Realtek and looking at the spectrum waterfall chart, all of the 25 KHz wide iDEN channels really stand out from everything else. (I'll try and post a screenshot later.)

Even without FM discriminator audio, I think it's definitely worth pursuing a USB-tuner based SDR solution. The USB tuners have gotten so cheap (thanks to the Realtek exploit that was discovered), I think it's really revolutionized the hobby and made SDR affordable for everyone.

 

[inigo88]

For what it's worth, here are a couple iDEN screenshots using the SDR# program and the Realtek RTL2832u RT820 USB stick.

Here's a snapshot of the upper 850 MHz band. The difference between the 12.5 KHz wide analog channels and 25 KHz iDEN channels is dramatic. You can see an iDEN channel right around 857.70 MHz and another at 858.25 MHz. The rest is NFM analog voice, with the exception of 857.20 MHz which is P25 voice (you can see it's slightly wider than analog). The thin red center peak is an artifact of the USB dongle and can be ignored:

A closeup of what I assume is the iDEN control channel on 859.30 MHz. Notice how the channel is only 20 KHz wide, but given a 2.5 KHz buffer on each end to fit 25 KHz spacing. The VSELP-based TDMA voice channels all sound like static (kind of like analog Motorola encryption), but this control channel was more periodic and mechanical sounding (and you can see the difference in the spacing of the pulsed horizontal lines). The control channel sound briefly changed to static, and you can see it visible in the waterfall chart as the darker red block near the top. Most TDMA-based trunking systems support voice over control (newer MotoTRBO Connect Plus for example), so I suspect that one of the other 5 timeslots on the control channel was being used for a voice call during that time:

Here's what I believe to be an iDEN voice channel on 858.25 MHz. To the left is an analog (narrower) and P25 voice transmission. To the right at 858.375 MHz is a 3rd type of iDEN channel I'm not quite sure about. It's a rapid "click click click" data format that seems to use vacant voice channels when they aren't in use. I'm not sure whether this is just an idle status marker common to all iDEN systems, or whether it's some sort of cellular packet data format like CDPD/GPRS that's just using vacant voice channels. It almost sounds like a sped up version of Mobitex:

That's all I've got. Anybody want to try and make heads or tails of it?

 

[SCPD]

It should be very easy to decode iDEN but there is no software out in the wild for decoding VSELP.

 

[AZScanner]

It should be very easy to decode iDEN but there is no software out in the wild for decoding VSELP.

Maybe this page has the answer? There's a tarball of C code on there for encoding and decoding VSELP that looks promising, perhaps DSDAuthor could make use of it? That and being able to take I/Q samples directly from a USB dongle without having to pass them through the soundcard first would be great updates for DSD.

-AZ

 

[exkalibur]

I suspect the ECPA regulations would kick in, given that iDEN is a PSTN technology.

 

[inigo88]

I suspect the ECPA regulations would kick in, given that iDEN is a PSTN technology.

No. iDEN is a digital two-way radio system, just like any other digital two-way radio system. The PSTN access is a telephone interconnect "add-on," just like the phone patch feature on many other trunking systems. The difference is that NEXTEL chose to buy iDEN systems and market it as a cellular system (which it is not), making the PTSN patch the primary option. As the OP said, Sprint does not share this philosophy and is migrating their aquired NEXTEL customers over to their true cellular CDMA network. Read here for more: http://community.sprint.com/baw/message/136883

Many business two-way radio customers use iDEN, including all ops at Disneyland, and many airlines via ARINC's network (off the top of my head).

As previously mentioned, ECPA probably applies to decoding NEXTEL's iDEN systems (given that they are being marketed as cell phones) but it should not apply to decoding iDEN in general.

Way to blur the lines eh?

 

[kb1ipd]

Maybe this page has the answer? There's a tarball of C code on there for encoding and decoding VSELP that looks promising, perhaps DSDAuthor could make use of it? That and being able to take I/Q samples directly from a USB dongle without having to pass them through the soundcard first would be great updates for DSD.

-AZ

It doesn't seem like it should be that hard to find suitable decoders for VSELP. It's a common speech coding method that has been around for a while. The GSM codec set includes a VSELP-based codec as a half-rate option. I do not know if it's the same thing as used in iDen or some kind of variation of the VSELP method.

Here is the GSM version in an open source decoder: GSM half rate of the source code (VSELP) GSM half rate of the source code (VSELP... - Free Open Source Codes - CodeForge.com

The version of VSELP as used in IS-54. Also, the early Real Audio formats used VSELP.


Libavcodec is a codec library from FFMPEG. It supports damn near every codec used for multimedia files. It includes VSELP implimentations

 

[WayneH]

Many business two-way radio customers use iDEN, including all ops at Disneyland...

Disneyland is using an extension of the S/N network. As S/N migrates off iDEN DLR will go to the CDMA PTT format.

Besides dealing with decoding VSELP you've got the TDMA to contend with. Not exactly the coding simplicity like dealing with TRBO's two slots (for a format that's standardized). Also, you've got traffic channels TDMA'd on the control channel too.

Harmony is the lesser sized network product iDEN is used for so there's still that. But still, is it worth the effort with S/N shutting their network down? They're tanking it as fast as they can; I see it first-hand.

Maybe of interest for the folks in Mexico to listen to the Cartels? :lol:

 

[kb1ipd]

After doing more research, it seems to me like adding iDen capability would make it easy to also add Moto Astro VSELP, since it is the same codec, same basic encoding and slightly different format without TDMA, but otherwise a complimentary and technically similar product.

I would LOVE to see such a vast expansion to DSD as adding both Astro and iDen.

Sadly, while I have some coding experience, it is not in this area.

But I would be willing to pay.

How does 500 dollars for iDen and Astro sound to anyone?

If not enough perhaps I could find others to chip in.

And if security and anonymity of payments is paramount, I am sure something can be figured out... Some kind of anonymous wire transfer or prepaid card or bitcoins or something

 

[krokus]

What services, excluding any remaining Nextel, utilizes iDen? It would seem like a lot of effort for an almost nil return.

 

[kayn1n32008]

What services, excluding any remaining Nextel, utilizes iDen? It would seem like a lot of effort for an almost nil return.

While Nextel is going away, Telus MiKE is not for a few more years. There are some of us north of the border that could find a use for being able to decode iDEN transmissions!!!


Sent from an unknown place...

 

[kb1ipd]

What services, excluding any remaining Nextel, utilizes iDen? It would seem like a lot of effort for an almost nil return.

There are a number of regional network operators in the US, I believe the largest is SouthernLINC wireless. They provide a regional service for the Southern US that operates much like Nextel did. There are also more specialized network operators. For example, Airpeak which runs some networks for government and local business sector use. There are companies which market iDen networks for smaller facilities - they setup iDen systems for college campuses, airports, industrial facilities etc.

The units can also be used as standalone 2-way radios.

There are even more networks outside the US, including Asia, Canada and Latin America.

Motorola still produces and markets iDen products.


And personally, I would LOVE to have it added to the formats that can be decoded with software like DSD

 

[kb1ipd]

My "dream" is that some day DSD could become a kind of swissarmyknife of decoders for voice and audio, In other words, any format, provided it is not encrypted or an absolute one-of-a-kind would be recognized and decoded.

Take as an example the FFMPEG library of audio/video decoders. They decode damn near everything. There are a few exceptions or super proprietary examples, but in general, throw a video file into FFMPEG and it will decode. Whether it is mpeg4 avc, asp, mpeg-2, theora, VP6, sorenson, huffvid even the most obsolete and unsuccessful codecs, like Indio, h.261, Real VIdeo 1 etc.

If it won't play it, either the codec is completely closed and nobody bothered to try to backengineer it, or the codec has built in strong encryption, or it is just so obscure its all but unknown.

Thus, the *Ideal* voice decoder would be equipped with every major codec known and capable of demodulating any major modulation and then seek format it and seek a decoded.

Perhaps this could be done with a "block diagram" method, to allow even never before seen speech and audio to be decoded.

Oh, someone is using an obscure Japanese-produced walkie talkie that encodes a 9.6 kbps audio stream using vslep and then adds some overhead bits and uses 4fsk to put it onto a 12.5 khz channel? No problem!


I do not know if this will ever happen. To get it started I tried to add a VSLEP capability to it using some open source code. I'm not very experienced in this kind of programing, but I was learning and making progress...

Then last month I fell off a bicycle and shattered my right shoulder (yes I am right handed). Typing one handed is frustrating. But programming? Forget about it.

Perhaps I will start again when I am out of the sling. Sadly, that will likely be 2 more months at least