DSD DMR Decoding

[mryamac]

Hello All,

Basically, I want to develop DSD+ over DSD. Therefore I checkout DSD from git and I started from DMR Data. I have also a testbed including Mobile stations, repeaters,etc..

My question is about color code. In dmr_data.c file we have

char cc[5];

cc[0] = (1 & (dibit >> 1)) + 48; // bit 1
cc[1] = (1 & dibit) + 48; // bit 0
cc[2] = (1 & (dibit >> 1)) + 48; // bit 1
cc[3] = (1 & dibit) + 48; // bit 0

variable.This variable seems to be color code. When I print this variable. It doesn't give me color code. DSD+ works perfect; but DSD doesn't.

Question 1:
Am I right about cc is color code?
If yes question 2:
What might be problem with DSD ? Is there any major changes in DSD+ while decoding DMR?

Thanks all.

Not:
If someone wants to join me to implement DSD+, you are welcome.

 

[mryamac]

The other thing which I found Color Code is just before the Burst Type and cc is exactly Color Code. Also I compared latest version of the DSD and DSD+. Burst type of both software is different although same data sent by SDRSharp.

 

[DaveNF2G]

Do you have the permission of the DSD+ author to "develop" something that includes his code?

 

[mancow]

Develop it to do what?

 

[mryamac]

Do you have the permission of the DSD+ author to "develop" something that includes his code?

I don't need any permission to develop sth. over DSD. DSD is open source project. Do you know what does open source mean? I'm not working for reverse engineering. Why DSD+ is not open source is another topic in this forum. I will develop a software which is similar to DSD+ may be better than DSD+. There is not any restriction about that.
Look at the copyright info in source of DSD (I also copy at below). So please, do not send such posts. You are misleading my question.

Sincerely
http://wiki.radioreference.com/index.php/Digital_Speech_Decoder_(software_package)

Copyright License

DSD and mbelib are both released under a BSD style copyright license. This means that as far as copyrights are concerned it can be freely copied and used, including for commercial products as long as the original copyright notice is included. (However, see important patent issues section below.)

/*
* Copyright (C) 2010 DSD Author
* GPG Key ID: 0x3F1D7FD0 (74EF 430D F7F2 0A48 FCE6 F630 FAA2 635D 3F1D 7FD0)
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
* REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
* LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
* OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/

 

[EricCottrell]

Hello,

The cc array is a bit array using ascii numbers '0' and '1' instead of binary values. You need to process it further to get the value. It is designed for bitwise printable output and not an actual number.

I did some work with dsd decoding the DMR data a few years ago. One problem with dsd is that there is no error checking.
The color code is part of the slottype, so I gather up all the bits, do the error correction using Golay 208, then divide it up into the color code and the bursttype. The bursttype remains ascii numbers as a string compare is done.

// slot type
  for (i = 0; i < 10; i += 2)
    {
      dibit = *dibit_p;
      dibit_p++;
      if (opts->inverted_dmr == 1)
        {
          dibit = (dibit ^ 2);
        }
      slottype[i] = (1 & (dibit >> 1)) + 48; // bit 1
      slottype[i+1] = (1 & dibit) + 48;        // bit 0
    }

...

// current frame - second half
  for (i = 10; i < 20; i += 2)
    {
      dibit = getDibit (opts, state);
      slottype[i] = (1 & (dibit >> 1)) + 48; // bit 1
      slottype[i+1] = (1 & dibit) + 48;        // bit 0
    }

...

sprintf (state->fsubtype, "              ");
  if((errorflag = doGolay208(slottype)) == 0)
    {
      cc = 0;
      for(i = 0; i < 4; i++)
	{
	  cc <<= 1;
	  cc |= (slottype[i] - 48);
	  bursttype[i] = slottype[i+4];
	}

73 Eric

 

[slicerwizard]

My question is about color code. In dmr_data.c file we have

char cc[5];

cc[0] = (1 & (dibit >> 1)) + 48; // bit 1
cc[1] = (1 & dibit) + 48; // bit 0
cc[2] = (1 & (dibit >> 1)) + 48; // bit 1
cc[3] = (1 & dibit) + 48; // bit 0

variable.This variable seems to be color code. When I print this variable. It doesn't give me color code. DSD+ works perfect; but DSD doesn't.

Question 1:
Am I right about cc is color code?
If yes question 2:
What might be problem with DSD ? Is there any major changes in DSD+ while decoding DMR?

That code builds a four character binary string, which is a strange thing to do, but the DSD authors were not programmers, which led to many strange things in the DSD code.

A DCC of 7 will create the string "0111", which then has to be run through a conversion function (strtol) to actually get the numeric value of 7.

IIRC, the symbol extraction code in DSD is marginal and the DCC value bounces around quite a bit during DMR trannsmissions.

 

[mryamac]

Thank you for responses.
I realize that if I print cc it shows as binary. I will summurize what I observe.
I set mobile stations color code to 5. Then I got 0101 as cc. It is ok. Then I decide to set MS's color code to 10 in decimal. I got 1111 as cc in DSD. Then I surprised. Next, I open DSD+ and check what is color code. Result was 10 in decimal. Finally I decide to compare burst types captured by DSD and DSD+. Unexpectedly they were different although same data piped to the DSD and DSD+.
For example:
DSD+ shows CSBK and for same data DSD shows Rate 1/2.
I conclude that DSD dmr_data is not working well. These are my experiences. Now I will check for error correction. If I get correct result, I will share with you. Thanks

 

[mryamac]

Update:
I received raw data and checked synchronization. Then data seems like this:
24 bit cach- 98 bit info- 10 bit slot type - 48 bit sync- 10 bit slot type - 98 bit info
So 48 bit sync exactly matches.
then 10 + 10 bits are concatenated then I have 20 bit slot type.
20 bit slot type 4 bit CC 4 bit burst type 12 bit Golay parity.
Then parity check is ok; but configured CC is wrong.
This is the my problem. What may cause this? Do I need a further step?