RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Commercial and Professional Radio > Digital Voice Formats

Digital Voice Formats Discussions regarding different digital radio voice formats, including AMBE, IMBE, VSELP, GSM, CELP, MELP, and others.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 01-21-2012, 8:55 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Posts: 1,544
Default NXDN iDas frame sync data needed

I'm investigating...something...involving the alignment of the digital systems of Icom iDas digital radios.


I have test equipment that is fully capable of answering every question I could possibly ask with regard to the digital transmisssion's characteristics, (Rohde & Schwarz FSEA 30 spectrum analyzer with FSE-07 vector analysis/flexible digital demodulation option) But there is some data that I need to find regarding the
iDas signal that I have not yet been able to locate.

I need to know the data pattern for any repetitive frame sync data in the iDas signal format. With that
data pattern, I can program my analyzer to sync up to the signal and allow me to analyze the signal parameters. Without that data, I can't sync up to the signal and thus it makes getting useful information
really hard.


If anyone here should know what the bit patterns are (hex or binary) that are repeated from frame to frame in the iDas signal, I'd sure like to get that information.

The signal format is 4800 symbols per seconds on a 4FSK carrier, very similar in many respects to APCO P25 C4FM, I'm not quite clear yet on the deviation from carrier of each of the 4 frequency shifts, but should be able to deduce that information if nobody happens to have it handy.

The hex values of each of the four 4FSK modulation states are 0, 5, 15, and 10, from low to high as demodulated on the analyzer. (I'm able to generate a simulated signal with my Agilent ESG signal generator, although I'm using a user-defined sync sequence as I don't have the "correct" one.)

Elroy
Reply With Quote
Sponsored links
  #2 (permalink)  
Old 01-22-2012, 12:44 AM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

Send me a continuous recording of discriminator audio - 30 to 60 seconds. The frame sync should be easy to find.
Reply With Quote
  #3 (permalink)  
Old 01-22-2012, 11:26 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Posts: 1,544
Default

I should be able to do that. Send me a PM, please.
Reply With Quote
  #4 (permalink)  
Old 03-28-2012, 12:57 PM
Member
   
Join Date: Aug 2005
Posts: 130
Default

Did you find the syncs, can you share them?

TIA
Reply With Quote
  #5 (permalink)  
Old 08-09-2012, 8:48 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Posts: 1,544
Default

I HAVE FOUND IT.

Here's the code, in binary:

Though I can't warrant that this is the actual frame sync sequence, it is a repeating sequence that I am able to trigger off of and thus be able to make consistent off-the-air measurements of NXDN signals, which has resulted in my NOT having to spend an additional 38,000 dollars to buy this capability in a suitably equipped service monitor!

So here it is:
00001111 11110011 10011001 10110000

The actual repeating sequence is longer than this, a LOT longer from what I've seen, but this
is quite enough to trigger off of reliably and once you have this and can lock onto it, you can see the rest of the repeating data quite easily enough.

That's the first step toward breaking the format.

Now it's up to YOU guys to do something with it. Post your progress in this topic, please.

My interest in this is all about being able to make accurate measurements of the transmitted signal to address possible alignment issues in the targeted radios. I can now precisely determine if a radio 's digital transmission is properly modulated.

FYI, the signal is 4FSK, 4800 baud, and the frequency shift values are +1050 Hz, +350 Hz, -350 Hz, and -1050 Hz. I'm not sure which of these values is 00, or 01, or 10, or 11.

Filter type is root raised cosine+1/sinc with a nominal alpha value of 0.350.

I'm using a Rohde & Schwarz FSEA 30 spectrum analyzer with vector analysis option to make the majority of the measurements. I use an Agilent E4406A transmitter tester (spectrum analyzer + specialized extras) to perform very high resolution analysis of the signal. (Bandwidth filter resolution goes down to 0.1 Hz!) I generate simulated signals using an Agilent E4431B vector signal generator with flexible digital modulation generation capability.
Reply With Quote
Sponsored links
  #6 (permalink)  
Old 08-09-2012, 9:48 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

Knowing which symbol dibit goes with which deviation is essential.

Elroy - did you ever send me a wave file recording?

I think the NXDN association has announced plans to publish the specifications.

The same packed data transmitted over and over makes it hard to distinguish sync from data.

Common symbol map is a grey code where adjacent symbols differ by only 1 bit. Here's my best guess.

00 = 350 Hz
01 = 1050
10 = -350
11 = -1050
Reply With Quote
  #7 (permalink)  
Old 08-10-2012, 3:30 AM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

Quote:
Originally Posted by ElroyJetson View Post
I HAVE FOUND IT.
You might want to take the champagne off the ice...


Quote:
Here's the code, in binary:

Though I can't warrant that this is the actual frame sync sequence, it is a repeating sequence that I am able to trigger off of and thus be able to make consistent off-the-air measurements of NXDN signals, which has resulted in my NOT having to spend an additional 38,000 dollars to buy this capability in a suitably equipped service monitor!

So here it is:
00001111 11110011 10011001 10110000
Sorry, but that looks wrong on multiple levels:

- NXDN sync patterns are 18 symbols / 36 bits, not 16 symbols / 32 bits

- that pattern looks nothing like the NXDN conventional channel sync patterns

- sync patterns only contain full deviation symbols (01/+3/+1050 Hz and 11/-3/-1050 Hz); you have partial deviation symbols (00/+1/+350 Hz and 10/-1/-350 Hz), which are full blown showstoppers. You're looking at payload data (probably control channel signaling)


You've found a pattern that repeats in your sample data, but may not appear in all streams. I'll check some local systems and see if it's present here.


Quote:
Originally Posted by Unitrunker View Post
Knowing which symbol dibit goes with which deviation is essential.

Common symbol map is a grey code where adjacent symbols differ by only 1 bit. Here's my best guess.

00 = 350 Hz
01 = 1050
10 = -350
11 = -1050
Looks correct to me.
Reply With Quote
  #8 (permalink)  
Old 08-10-2012, 6:18 PM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2002
Posts: 1,544
Default

Those data values are confirmed.

As for the pattern I found, it suits my needs in the simple regard that I can now lock to the signal and thus get a stable display and analyze modulation performance. And with this locked synchronized signal, I can see the rest of the data stream and see what information is static and what information is dynamic, for both a specfic radio transmitting on specific ID and talkgroup allocations, and to identify what changes in those static patterns when the ID or talkgroup allocation is changed.

Given time I should be able to map out whatever I want to map out. Simply finding this one signal I can sync to has given me that ability. The rest just requries some patience and effort.

I don't say I have the actual frame sync pattern. Not yet. I just have a pattern that I can use for my own specific analysis requirements.
Reply With Quote
  #9 (permalink)  
Old 10-06-2012, 10:36 PM
N2DLX's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Jun 2008
Location: East Windsor, NJ
Posts: 215
Default

I know you resolved your issue, but just wanted to update the thread with the correct info, since the NXDN spec has been made available to the public:

4.4.4 Frame Sync Word
Frame Sync Word shall be 10 symbols (20 bits) described in the following table.

Code:
           Transmission Order -->
Symbol     -3, +1, -3, +3, -3, -3, +3, +3, -1, +3
HEX        CDF59
Code:
Dibit    Symbol
01       +3
00       +1
10       -1
11       -3
So following the NXDN symbol mapping (above), you end up with the following binary sequence:

Code:
-3 +1 -3 +3 -3 -3 +3 +3 -1 +3
11 00 11 01 11 11 01 01 10 01
Reply With Quote
Sponsored links
  #10 (permalink)  
Old 10-06-2012, 10:59 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

The ten-symbol FSW pattern is already present in the DSD source code. However, attempting to use such a short sequence will lead to many false hits. The DSD authors wisely chose to combine the FSW with the 8-symbol link information channel (LICH) field to form more reasonable 18-symbol sync patterns. The option to use only the FSW has always been there, but it's a suboptimal solution. AAMOF, because even the 18-symbol FSW-LICH sync patterns are so prone to falsing, DSD contains extra code to ignore NXDN sync patterns unless they're seen back to back, e.g. as part of a valid transmission stream.

Code:
//                              |--FSW---||-LICH-|
#define NXDN_MS_DATA_SYNC      "313133113131111333"
#define NXDN_MS_VOICE_SYNC     "313133113131113133"
#define NXDN_BS_DATA_SYNC      "313133113131111313"
#define NXDN_BS_VOICE_SYNC     "313133113131113113"

#define INV_NXDN_MS_DATA_SYNC  "131311331313333111"
#define INV_NXDN_MS_VOICE_SYNC "131311331313331311"
#define INV_NXDN_BS_DATA_SYNC  "131311331313333131"
#define INV_NXDN_BS_VOICE_SYNC "131311331313331331"
Reply With Quote
  #11 (permalink)  
Old 10-07-2012, 12:54 AM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

That's actually a horrible choice for sync patterns. Each pattern has a hamming distance of 2 with at least one other pattern. A frame sync with only one bit error is completely ambiguous. Sheesh.
Reply With Quote
  #12 (permalink)  
Old 10-07-2012, 2:39 AM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

Quote:
Originally Posted by Unitrunker View Post
That's actually a horrible choice for sync patterns.
There is only one sync pattern (the FSW). The LICH is not a sync pattern.

Quote:
Each pattern has a hamming distance of 2 with at least one other pattern. A frame sync with only one bit error is completely ambiguous. Sheesh.
The only thing using the LICH as part of a sync pattern is DSD, and DSD doesn't tolerate any symbol errors in any sync pattern, so every protocol - P25, DMR, ProVoice, etc. is subject to data loss if a single sync symbol is flipped. A dropped NXDN voice frame loses only 80 ms of audio; a P25 voice frame, 180 ms - so which issue is more of a problem? And those both pale in comparison to DSD's handling of the 4 P25 DUID bits - when it gets any of them wrong, it's buhbye 9 or 18 voice frames - 360 ms of audio gone because of one flipped bit.
Reply With Quote
  #13 (permalink)  
Old 10-07-2012, 12:51 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

DSD's handling of DUID bits - you should fix that.

As you pointed out earlier, the LICH is in effect part of the sync pattern. They should have chosen four separate 18 symbol patterns with much greater hamming distance. There's no protection on the LICH bits which sucks. Since 3 of the symbols vary, you really have a 15 symbol sync pattern.
Reply With Quote
  #14 (permalink)  
Old 10-07-2012, 1:52 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

Quote:
Originally Posted by Unitrunker View Post
DSD's handling of DUID bits - you should fix that.
I see - because I point out that the "problem" you're highlighting is minor compared to a much more serious problem, I should fix the big problem?


Quote:
As you pointed out earlier, the LICH is in effect part of the sync pattern. They should have chosen four separate 18 symbol patterns with much greater hamming distance.
Only DSD uses the LICH as part of the sync pattern, and only because the short FSW pattern is too easy to false on while RXing other protocols (DMR, P25...). This is not an issue for NXDN base radios and subscriber gear.

As for choosing four patterns,

- inbound conventional voice frame
- inbound conventional data frame
- inbound trunked voice frame
- inbound trunked data frame
- inbound trunked control frame
- outbound conventional voice frame
- outbound conventional data frame
- outbound trunked voice frame
- outbound trunked data frame
- outbound trunked control frame

That would be ten sync patterns. No designer wants that and none of the protocols do that.


Quote:
There's no protection on the LICH bits which sucks. Since 3 of the symbols vary, you really have a 15 symbol sync pattern.
Actually, since the LICH bits are sent as full deviation symbols (effectively as 2 level data), they do have a measure of protection - noise levels high enough to get through a matched filter are going to trash the 4 level voice data anyway. By comparison, the four P25 DUID bits are jammed into two easily damaged symbols, which is why they are protected by a long BCH code.

NXDN4800 is an efficient low data rate protocol with half of the capacity of the 9600 bps schemes and is squeezed into narrow RF channels; this means that there aren't piles of excess bits lying around waiting for the designers to allocate to FEC. In real world use, with both NXDN subscriber gear and DSD, I have not seen any problems caused by the choices the NXDN designers made - if the 2 level FSW and LICH don't survive their trip, the voice data is shot to hell anyway.
Reply With Quote
  #15 (permalink)  
Old 10-07-2012, 2:54 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

Quote:
Originally Posted by slicerwizard View Post
I see - because I point out that the "problem" you're highlighting is minor compared to a much more serious problem, I should fix the big problem?
You're griping about something you can fix. I have no magical powers over the NXDN committee. :~p

Quote:
As for choosing four patterns,

- inbound conventional voice frame
- inbound conventional data frame
- inbound trunked voice frame
- inbound trunked data frame
- inbound trunked control frame
- outbound conventional voice frame
- outbound conventional data frame
- outbound trunked voice frame
- outbound trunked data frame
- outbound trunked control frame
I see. You had only listed the four conventional voice frames. Any reason for excluding trunked voice?
Reply With Quote
Sponsored links
  #16 (permalink)  
Old 10-07-2012, 3:07 PM
Member
   
Join Date: Sep 2002
Location: Toronto, Ontario
Posts: 2,319
Default

Quote:
Originally Posted by Unitrunker View Post
You're griping about something you can fix.
Cut the crap. I'm not griping, I'm pointing out that your "Sheesh" problem is nothing compared to the DUID problem. NXDN gear has no problem with the FSW and LICH design, nor does P25 gear have any issue with the DUID field. Rather, these are strictly DSD issues, and DSD is far more likely to lose a DUID than a FSW-LICH.


Quote:
I have no magical powers over the NXDN committee. :~p
Well, I don't see anything that they need to fix, so that shouldn't be an issue.


Quote:
I see. You had only listed the four conventional voice frames. Any reason for excluding trunked voice?
I listed what's in the DSD source code. I haven't seen a list of all of the FSW-LICH patterns and the NXDN documents aren't very clear on what the other patterns are.
Reply With Quote
  #17 (permalink)  
Old 10-07-2012, 3:13 PM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

Quote:
Originally Posted by slicerwizard View Post
Cut the crap. I'm not griping
My mistake. I thought you were.
Reply With Quote
  #18 (permalink)  
Old 10-17-2012, 10:04 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Oct 2009
Location: bridlington, uk
Posts: 117
Default

i may sound stupid but why do you need to break a format that has been released as a open standard

NXDN™ specification released | Southgate Amateur Radio News

Quote:
Originally Posted by ElroyJetson View Post
I HAVE FOUND IT.

Here's the code, in binary:

Though I can't warrant that this is the actual frame sync sequence, it is a repeating sequence that I am able to trigger off of and thus be able to make consistent off-the-air measurements of NXDN signals, which has resulted in my NOT having to spend an additional 38,000 dollars to buy this capability in a suitably equipped service monitor!

So here it is:
00001111 11110011 10011001 10110000

The actual repeating sequence is longer than this, a LOT longer from what I've seen, but this
is quite enough to trigger off of reliably and once you have this and can lock onto it, you can see the rest of the repeating data quite easily enough.

That's the first step toward breaking the format.

Now it's up to YOU guys to do something with it. Post your progress in this topic, please.

My interest in this is all about being able to make accurate measurements of the transmitted signal to address possible alignment issues in the targeted radios. I can now precisely determine if a radio 's digital transmission is properly modulated.

FYI, the signal is 4FSK, 4800 baud, and the frequency shift values are +1050 Hz, +350 Hz, -350 Hz, and -1050 Hz. I'm not sure which of these values is 00, or 01, or 10, or 11.

Filter type is root raised cosine+1/sinc with a nominal alpha value of 0.350.

I'm using a Rohde & Schwarz FSEA 30 spectrum analyzer with vector analysis option to make the majority of the measurements. I use an Agilent E4406A transmitter tester (spectrum analyzer + specialized extras) to perform very high resolution analysis of the signal. (Bandwidth filter resolution goes down to 0.1 Hz!) I generate simulated signals using an Agilent E4431B vector signal generator with flexible digital modulation generation capability.
Reply With Quote
  #19 (permalink)  
Old 10-17-2012, 10:06 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Oct 2009
Location: bridlington, uk
Posts: 117
Default

And
NXDN Forum Website
Reply With Quote
  #20 (permalink)  
Old 10-18-2012, 2:02 AM
Seņor Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Dec 2001
Location: Texas
Posts: 5,768
Default

Quote:
Originally Posted by phillmobile View Post
i may sound stupid but why do you need to break a format that has been released as a open standard
The origin of this thread predates the announcement and subsequent publication of the standard.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 12:41 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2011 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions