Good news Matt! I presume that you are referring to Rijndael, the current standard for coded communications in P25. I expect that will result in a Nobel prize for some brilliant researcher shortly. Do you happen to know what algorithm is replacing FIPS-197? The journals are remarkably silent on this topic. Also, I am not familiar with the paper that you allege, but are unwilling to share. Is it perhaps a “square root of negative 1” type of paper? Ha!
I saw a paper on DES-OFB related to P25 back in Sept 2011. This paper was completely uninteresting owing to the fact that FIPS46-3 was withdrawn by NIST on May 19, 2005, more than SIX YEARS PRIOR. Not making this up yo: [
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf]. So unless your county’s public safety dept. is still using DES-OFB Matt, and trust me they aren’t for the very reasons you cited, my assertion stands. Besides, would you even know how determine whether that was the case by recovering the voice frames and analyzing them yourself? Apparently not, or you wouldn’t be beaking off like that. In case you ever decide to establish facts first, and type second, the answer is in Section 5.4 on page 14 of TIA-102 BAAA-A 2003 and also on pages 31 and 41 of TIA-102 AAAD-A (ANNEX A and ANNEX C respectively). Let me know what you discover off-the-air in your locale, I am curious to see if you are right (or not.)
One more thing Matt. COPACOBANA is out of production. So is FORMICA, its "low cost" successor. I happen to know this because in 2013 I wrote bitcoin mining software that runs on FORMICA, including designing XILINX FPGA targeted intellectual property to implement two rounds of SHA-256 fully pipelined in a single core and at a respectable clock speed to boot. I was able to earn BTC for several months by leasing time on a FORMICA and running my code before BTC difficulty went through the roof. I also wrote a plugin for the controller in Python (specifically, I adapted the MPBM to work with FORMICA API V 1.91 by porting the FORMICA API libraries to Python and writing a FORMICA driver for MPBM in Python). I also developed and sold distributed processing software that runs on the RIVYERA SPARTAN6-LX150 Machine Family. I can easily prove the FORMICA claim, just PM me with your verifiable identity Matt, and I will deliver. Also, not planning on just handing over my intellectual property to the first person who asks, sorry dude.
KA1RBI: The half rate CODEC is not really that hard. Especially if you have already written the full rate one, which is also available in DSD. What is hard is the changes to the packet format that go with it, and I have put that down at the moment, to work on other projects. At present, you and I can get Phase-II by purchasing a BCD536HP/BCD436HP if we need it, or perhaps the GNU/RADIO solution. One will just have to live with crappy symbol recovery for now (Sorry Paul). I also wrote a full rate IBME CODEC well before DSD was published. The largest pain in the behind was typing in and checking all those tables, then debugging the psycho summing algorithms, oh and the cosine transforms- they were finicky. By the way, that is how I first discovered that BCD996XT was doing IMBE in firmware. All the IMBE tables are in the ROM, and can be easily searched for, as they are unique fractional FP numbers. Example “-2.55826” from page 70 of TIA-102.BABA2003(R2009) is located at ROM Location 0x0CC244 in V1.07.03 of BCD996XT Firmware. The FP number “-2.55826” is represented at that location as the byte string 0xC023BA88. The numbers -2.3828499, and -2.2210419 follow in the memory locations immediately after. Of course…you have to decrypt the firmware first.
That all being said, what is much more interesting is the application of Stochastic Gradient Symbol Recovery to the channel, such that you can learn from, and adapt to changes in channel phase and group delay. This functionality I have fully developed, and have working swimmingly well. I also have a repeatable method to directly measure the performance of my symbol recovery vs. Uniden’s. My symbol recovery rate is significantly superior for the identical signal at the BCD996XT discriminator. I can prove this. I have also written a full P25 ECC suite for DSD to pick-up where the symbol recovery leaves off. If you are the owner of a BCD996XT, send me a PM and I will substantiate this claim.
Regarding more clues on Stochastic Gradient Symbol Recovery. Lets consider what Brad Hiben says in. TIA-102 BAAA-A 2003
“The stochastic gradient clock recovery device provides clock recovery for the waveform at the output of the Integrate and Dump Filter. Several techniques are available for this process. The details of the clock recovery are not specified by this document. “
This is Motorola speak for “It is our intellectual property, so why don't you make like the birds and flock off?”
That is exactly the place to start of course. Motorola being a rather litigious bunch, they patent the snot out of everything. Did you know they once tied my employer up in court claiming a patent on the Darlington Transistor connection? Completely unenforceable of course, but effectively shut our production down for 5 years.
Where to look:
US Patent Full-Text Database Manual Search
Search terms:
SPEC/C4FM and AN/Motorola
SPEC/cqpsk and AN/Motorola
SPEC/APCO and AN/Motorola
in/hiben and AN/Motorola
in/cudak AND AN/Motorola
This is a good place to build a foundation, but the final leap has to come from your own toil I am afraid. (Our you can wait until I release my firmware, which will be priced reasonably.)
Note: I will only be releasing firmware for BCD996XT.