- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone!
We are equipping PSoC 6 with an external power amplifier/low noise amplifier (PA/LNA) . As PSoC 6 documents say, there are three specific dedicated pins to control an external PA/LNA : P7.4 and P7.5 (RX_EN and TX_EN). However, in top design we digitally connected them to P0.0 and P0.1 . (we are not using an external 32768Hz crystal and BLE is run by ILO.)
I am wondering whether this approach is acceptable or it might affect the quality of real-time audio data transfer over BLE.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The BLE data transfer is OK with your design. The design just connect another PIN to the dedicated PIN by hardware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's better to use the dedicated pins for the external PA. If you use other pins, you can't use the internal API and need to control it with GPIO.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for you reply. We connected the dedicated pins to other pins in top design:
The internal API is usable though. We are worries if this approach is affecting the quality of real-time audio data transfer over BLE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is OK as your design. I am just curious about it. Why you need to use P0.0 and P0.1 for PA control. For a easy layout? You need use four pins as your design.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, yes, it is the matter of layout. Yes, it took two more pins though. However, the only worry is whether this could make a problem for real-time audio data transfer over BLE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The BLE data transfer is OK with your design. The design just connect another PIN to the dedicated PIN by hardware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As another but related question: do you think using ILO instead of PILO with a 32.768KHz crystal would make a problem for real-time audio data transfer over BLE?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not clear about your question. There are three sources for the low frequency clock: ILO, PILO, WCO. We recommend the WCO. You may also use PILO. ILO is not recommended because of the low precision.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, we have a two-way audio data transfer via BLE. one way (master to slave) works fine but another way doesn't.
Can we infer that because one of two ways are working properly, it is not the matter of precision of ILO?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I think the ILO is not the problem per your description.
You may need to capture some OTA log with a sniffer to analyse the root cause.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. That's a good idea. But, in general, what would we miss in BLE communication by using ILO instead of PILO with an actual 32.768KHz crystal?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The CLK_LF is used in sleep mode during connection interval. If you use the ILO as CLK_LF, there may be some problem with connection stablity. But in your case, there are data loss in one way transfer. It doesn't look like clock problem, need more information to analyse it.
You can change it to PILO or test your project in the kit board with WCO to see if the problem still exists.