This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1312R: CC1312R problem

Part Number: CC1312R

Hi team 

Good day

my customer need some help:

I want to use the CC1312R as the core of a land mobile radio design - need to be able to send audio samples to the RF core for FM modulation, and received FM demodulated audio samples back - audio preferably in a g.711a/u companding (8-bit/8kHz). This will require a new "protocol" patch for the RF module as it is closed source. Separate power amplification stage, using one of the radio control GPIO pins to enable the power amplifier, and 5x other pins as a parallel bus to set the TX power level. The program core should have enough compute power to handle CTCSS and CDCSS generation and mixing with the audio data, the RF core has more than enough compute power to modulate analog audio if it is computing gaussian functions on 4-level digital states. Extra functions for the display and user control IO are low enough rate for a state machine in a light CPLD. This should be possible, and I want to get there first. CC1312R is interesting as it covers the two bands I'm targeting (MURS/GMRS).

Best regards
Aosker 

  • I believe this require some work just to see if it's possible. If this require a patch this should be requested through the sales channels and not a technical channel as this is and it would require a fairly large volume to be interesting. 

  • Grumbling to myself "thus the issue with closed source cores with limited documentation".

    TI's staffing and interest restricts how the part can be used by customers (not what it can actually do), but the dev kits I have show that there is a lot of capability and functionality left on the table due to limited TI internal development time.  Send me an NDA to sign, and the programming manual, and I'll do it myself (I'm not looking to manage a vendor).  Email me off forum so we can talk, probably not a million parts, but more likely a few thousand is within reach.

  • We have full open documentation of the Sensor Controller and on the CM4 side but we don't have documentation available that covers the modem. This is of two main reasons: High complexity and the need for knowing the full implementation of the modem which will reveal too much details, even with an NDA.

  • I'm not sure what you're trying to convince me of - SDR, DPLLs, mixers, and amps are too hard for people to understand?   Or you want to keep the output of my design effort proprietary so that you can sell it to others without compensating me for it?  Or that there is something wrong with the part's implementation you don't want the public to find out about, even if they are provided technical details under NDA?

    The first reply is along the lines of "we don't want to put the effort into your purchase due to low volume."

    That's fair, we all have to justify our costs.  My reply is I'm offering to "waste my own time" figuring out your part to make it work - I just need the documents (not even the tools) your own people would use to understand the available resources and registers while designing an algorithm to accomplish the ends I'm after.

    The second reply really has me scratching my head.  You say you don't have the documentation available - I'm going to go ahead and doubt that the radio modem design only lives in someone's head.  I'm guessing what you meant to say is that you don't have publicly available documentation available - "yes, I know," as I have been unable to find it, which is why I offered to enter into an NDA to obtain any documentation.  The last half of your last sentence however suggests that your "proprietary tools" may actually only be obscuring fairly simple and common components arranged in a non-novel implementation found in modern SDR which might invalidate a patent?  Is TI afraid I'm going to reverse engineer the ISA and release open source tools for its parts that TI doesn't control?  That's not my intention, but - what options are you leaving smaller motivated customers? Reverse Engineering? Analog Devices? NXP?  I'm having trouble understanding why there's no managed path forward...

    I'll think on this for a week, and again I'll suggest that this discussion be done in email.