WIP: Provoice Conventional Framesync

I've recently received a batch of Provoice Conventional samples where no known software had the ability to sync on the sample. What I have found is that Provoice Conventional has two factors going on. First, it has a different framesync pattern, but otherwise, appears to operate exactly like the usual batch of Provoice. Second, in the different framesync pattern, we see a shorter framesync pattern of 16-bits that is always the same, and the next 16-bits of the Provoice Sync Pattern correlating to TX/RX address personalities that are programmed into the radio making up the second half of the framesync pattern. For comparison, the normal PV framesync pattern is 32-bit (PV is 2 level GFSK, so its not dibit based, but one symbol = one bit)

This of course, leaves me wondering, if the framesync pattern on all Provoice is 16-bit and the other 16-bit is another value entirely, its just that every repeater uses the same value, or if this is an intentional occurrence on the frame sync pattern. Here is a snippet from the radio personality manager used to program the radio to send me the samples.

Screenshot (125)

The TX address is 8-bit and the RX address is 8-bit, thus our 16-bits on the second part of the frame sync being different. According to this, both parties have to have the same addresses programmed or they will not unmute. So, looks like this is either accomplished by having the frame sync pattern change depending on the programmed TX/RX value, or, the sync pattern is only 16-bit, and those values are the very next values sent. Here is my findings across multiple samples with different TX/RX values.

In this pattern (inverted polarity, the norm for PV) 3 is bit 0, and 1 is bit 1 (2 level GFSK)

                 //same pattern  //TX     //RX
Sync Pattern = 3131311133313313 31331131 31331131 TX/RX 77  -- 31331131 symbol = 01001101 binary = 77 decimal
Sync Pattern = 3131311133313313 33333333 33333333 TX/RX 0   -- 33333333 symbol = 00000000 binary = 0 decimal
Sync Pattern = 3131311133313313 33333331 33333331 TX/RX 1   -- 33333331 symbol = 00000001 binary = 1 decimal
Sync Pattern = 3131311133313313 13131133 13131133 TX/RX 172 -- 13131133 symbol = 10101100 binary = 172 decimal
Sync Pattern = 3131311133313313 11333111 11333111 TX/RX 199 -- 11333111 symbol = 11000111 binary = 199 decimal
Sync Pattern = 3131311133313313 31313131 31313131 TX/RX 85  -- 31313131 symbol = 01010101 binary = 85 decimal

I have written some code that can framesync based off of the shortened framesync pattern and read the TX and RX values, and then forward to PV voice decoding, and it is working decently. There is an issue, due to the short framesync, with occassional false positives (not even nearly as bad as NXDN though), so I am going to make this a cmake option only kind of thing, where the user has to specify whether or not to turn on this framesync pattern when compiling. That being said, the image above shows the default value of TX/RX at 85, so I will allow that to be enabled always, so if users have their own radios programmed to conventional on 85, then it will framesync just fine since we have a hard 32-bit pattern that doesn't pop false positives.

cmake -DPVC=ON .. will disable the 85 default, but allow all PV conventional at the risk of occassional frame sync false positives. Using squelched source audio highly recommended for using this mode. -fp option will still be required to enable provoice decoding.

Leaving it off will allow only default personality PV Conventional TX/RX85.

Nether option disables the already established PV/EDACS sync patterns as that behaves extremely well due to their long sync patterns.

With PVC on in cmake, decoding PV Conventional will look like this:

03:55:30 Sync: -PV_C  TX: 0 RX: 0  VOICE
 N64: 6969696969696969
 LID: 0000 FF83DF1732094ED1
 IMBE 6C00000000000000000000 err = [0] [0] 
 IMBE 6C00000000000000000000 err = [0] [0] 
 BF: 2175 
 IMBE 6C20120090000012000024 err = [0] [1] 
 IMBE 0C1F49190F004012058029 err = [1] [0] 
03:55:30 Sync: -PV_C  TX: 0 RX: 0  VOICE
 N64: 6969696969696969
 LID: 0000 FF83DF1732094ED1
 IMBE 584384092820003874AE2C err = [1] [1] 
 IMBE 540D8C53D1E000CCEDC94C err = [1] [0] 
 BF: 2175 
 IMBE 0C0CEE465C60346C94651D err = [1] [1] 
 IMBE 0C149EB66360239D5B826D err = [1] [0]

This code will need a round of testing, along with the rest of the updates. Hopefully, it'll be ready to go sometime this weekend, barring any major issues.

lwvmobile / dsd-fme

WIP: Provoice Conventional Framesync #122