• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.

NXDN iDas frame sync data needed

Status
Not open for further replies.

ElroyJetson

I AM NOT YOUR TECH SUPPPORT.
Premium Subscriber
Joined
Sep 8, 2002
Messages
3,687
Location
DO NOT ASK ME FOR HELP PROGRAMMING YOUR RADIO. NO.
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
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Send me a continuous recording of discriminator audio - 30 to 60 seconds. The frame sync should be easy to find.
 

ElroyJetson

I AM NOT YOUR TECH SUPPPORT.
Premium Subscriber
Joined
Sep 8, 2002
Messages
3,687
Location
DO NOT ASK ME FOR HELP PROGRAMMING YOUR RADIO. NO.
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.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
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
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
I HAVE FOUND IT.
You might want to take the champagne off the ice...


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.


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.
 

ElroyJetson

I AM NOT YOUR TECH SUPPPORT.
Premium Subscriber
Joined
Sep 8, 2002
Messages
3,687
Location
DO NOT ASK ME FOR HELP PROGRAMMING YOUR RADIO. NO.
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.
 

N2DLX

Member
Premium Subscriber
Joined
Jun 21, 2008
Messages
240
Location
Hamilton, NJ
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
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
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"
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
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.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
That's actually a horrible choice for sync patterns.
There is only one sync pattern (the FSW). The LICH is not a sync pattern.

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.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
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.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
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?


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.


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.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
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

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?
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
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.


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.


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.
 

phillmobile

Member
Joined
Oct 12, 2009
Messages
253
Location
bridlington, uk
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

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.
 
Status
Not open for further replies.
Top