This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
university:tools:pluto:hacking:power_amp [09 Jul 2019 03:36] – created Robin Getz | university:tools:pluto:hacking:power_amp [16 Jul 2019 20:15] (current) – [Test Results] Robin Getz | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Controlling External Devices on the ADALM-PLUTO ====== | ====== Controlling External Devices on the ADALM-PLUTO ====== | ||
- | While this was requested to better understand how to control external power amplifiers for various software to implement push to talk, and ensure the PA was off during the Rx portion, this is good practice for any application which is just doing Rx or just doing Tx for best performance. Even you you are not concerned about controlling external devices, this may be a good read for some (just skip the GPO discussions). | + | While this was requested to better understand how to control external power amplifiers for various software to implement |
+ | |||
+ | There are two ways to implement General Purpose Output (GPO), Automatically (the easy way), or Software Controlled (which is handled later). | ||
===== Background ===== | ===== Background ===== | ||
- | The [[adi> | + | The [[adi> |
* Wait — power save, synthesizers disabled | * Wait — power save, synthesizers disabled | ||
* Sleep — wait with all clocks and the BB PLL disabled | * Sleep — wait with all clocks and the BB PLL disabled | ||
- | * Tx — Tx signal chain enabled (Rx signal chain powered down) | + | * Time Division Duplex (TDD) Tx — Tx signal chain enabled (Rx signal chain powered down) |
- | * Rx — Rx signal chain enabled (Tx signal chain powered down) | + | * Time Division Duplex (TDD) Rx — Rx signal chain enabled (Tx signal chain powered down) |
- | * FDD — Tx and Rx signal chains enabled | + | * Frequency Division Duplex (FDD) — Tx and Rx signal chains enabled, where both Tx and Rx can be used simultaneously at different frequencies. |
* Alert — synthesizers enabled | * Alert — synthesizers enabled | ||
+ | |||
+ | In this document, we will mainly focus on the Frequency Division Duplex (FDD) mode and the Time Division Duplex (TDD) Tx & Rx modes. | ||
While the default settings are FDD mode (where Tx and Rx signal chains are always enabled), there are many use cases where TDD (Time Division Duplex) mode is beneficial. The ENSM has two control modes (1) SPI control and (2) pin control. If the TDD is a slotted system, where μsecond timing requirements must be met, pin control from a FPGA based state machine is normally used. When the TDD system is random, or push to talk, SPI control is possible. In SPI control mode, the ENSM is controlled asynchronously by writing to SPI registers to advance the current state to the next state. SPI control is considered asynchronous to the device or sample clock because the SPI clock can be derived from a different clock reference and can still function properly. The SPI control ENSM mode is recommended when real-time control of the synthesizers is not necessary. | While the default settings are FDD mode (where Tx and Rx signal chains are always enabled), there are many use cases where TDD (Time Division Duplex) mode is beneficial. The ENSM has two control modes (1) SPI control and (2) pin control. If the TDD is a slotted system, where μsecond timing requirements must be met, pin control from a FPGA based state machine is normally used. When the TDD system is random, or push to talk, SPI control is possible. In SPI control mode, the ENSM is controlled asynchronously by writing to SPI registers to advance the current state to the next state. SPI control is considered asynchronous to the device or sample clock because the SPI clock can be derived from a different clock reference and can still function properly. The SPI control ENSM mode is recommended when real-time control of the synthesizers is not necessary. | ||
- | The AD9363 also include 4 '' | + | The AD9363 also include 4 '' |
More information about the [[adi> | More information about the [[adi> | ||
- | ===== ADLM-PLUTO implementation ===== | + | ===== ADALM-PLUTO implementation ===== |
==== VDD_GPO ==== | ==== VDD_GPO ==== | ||
- | The power connected to the '' | + | The power connected to the '' |
- | With the 1.3 V '' | + | With the 1.3 V '' |
==== Pinout ==== | ==== Pinout ==== | ||
Line 31: | Line 35: | ||
The [[./ | The [[./ | ||
- | {{: | + | {{ : |
+ | |||
+ | Just connect these '' | ||
==== Software ==== | ==== Software ==== | ||
- | There is a setup portion (if you are unsure of what these attributes do, check out the [[/ | + | There is a setup portion (if you are unsure of what these attributes do, check out the [[/ |
- set up the part in TDD mode ('' | - set up the part in TDD mode ('' | ||
- | - set up '' | + | - set up '' |
- write the new configuration to the part < | - write the new configuration to the part < | ||
- | Verify | + | Verify the setup is in TDD mode, by checking the '' |
dev ' | dev ' | ||
Then there is a run time configuration that is needed. | Then there is a run time configuration that is needed. | ||
- | - To set the part into Receive only mode:< | + | - To set the part into Receive only mode:< |
- | - To set the part into Tx only mode:< | + | - To set the part into Tx only mode:< |
+ | |||
+ | When you change from Rx mode to Tx mode, any of the four pins will assert/ | ||
<WRAP important> | <WRAP important> | ||
+ | |||
+ | There is a short bash script that shows how to use pin control from userspace: [[github> | ||
+ | |||
+ | ==== Test Results ==== | ||
+ | |||
+ | A small script on the Pluto SDR (or host) will demonstrate: | ||
+ | |||
+ | < | ||
+ | #!/bin/sh | ||
+ | |||
+ | # Setup : Put into TDD mode, and setup GPO0 and GPO1 | ||
+ | iio_attr -q -a -D ad9361-phy adi, | ||
+ | iio_attr -q -a -D ad9361-phy adi, | ||
+ | iio_attr -q -a -D ad9361-phy adi, | ||
+ | iio_attr -q -a -D ad9361-phy | ||
+ | |||
+ | while [ 1 ] ; do | ||
+ | iio_attr -q -a -d ad9361-phy ensm_mode rx | ||
+ | # capture buffer | ||
+ | iio_attr -q -a -d ad9361-phy ensm_mode tx | ||
+ | # transmit buffer | ||
+ | done | ||
+ | </ | ||
+ | |||
+ | by placing a scope on the GPO0 and GPO1 pins, you can see the levels switch, as the Pluto transitions between Receive and Transmit. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | <WRAP round help> | ||
+ | </ | ||
+ | |||
+ | OK, someone asked for the C code - it's pretty trivial, just longer. You will need to change the uri, and put in proper error checking. | ||
+ | |||
+ | < | ||
+ | #include < | ||
+ | #include < | ||
+ | #include < | ||
+ | #include < | ||
+ | #include < | ||
+ | |||
+ | |||
+ | volatile sig_atomic_t stop = 0; | ||
+ | |||
+ | void inthand(int signum) { | ||
+ | stop = 1; | ||
+ | } | ||
+ | |||
+ | int main(int argc, char **argv) | ||
+ | { | ||
+ | struct iio_context *ctx; | ||
+ | struct iio_device *dev; | ||
+ | struct iio_channel *ch; | ||
+ | const char* val_str; | ||
+ | ssize_t ret = 0; | ||
+ | char buf[256]; | ||
+ | |||
+ | signal(SIGINT, | ||
+ | |||
+ | /* Create IIO Context */ | ||
+ | ctx = iio_create_context_from_uri(" | ||
+ | |||
+ | /* Find IIO device in current context */ | ||
+ | dev = iio_context_find_device(ctx, | ||
+ | |||
+ | /* Write into the IIO debug attributes */ | ||
+ | iio_device_debug_attr_write_bool(dev, | ||
+ | iio_device_debug_attr_write_bool(dev, | ||
+ | iio_device_debug_attr_write_bool(dev, | ||
+ | iio_device_debug_attr_write_bool(dev, | ||
+ | | ||
+ | while (!stop) { | ||
+ | ret++; | ||
+ | iio_device_attr_write(dev, | ||
+ | iio_device_attr_write(dev, | ||
+ | } | ||
+ | iio_context_destroy(ctx); | ||
+ | printf(" | ||
+ | return EXIT_SUCCESS; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Over USB, you get:< | ||
+ | time ./foo | ||
+ | ^Citteration = 2693 | ||
+ | |||
+ | real 0m5.283s | ||
+ | </ | ||
+ | |||
+ | or about 0.980876346 ms per Rx/Tx slot. | ||
+ | |||
+ | ^ Platform | ||
+ | | host | USB | shell | 80ms | | ||
+ | | host | USB | C code | 0.6 to 1.3 ms | | ||
+ | | pluto | local | shell | 30-35ms | | ||
+ | | pluto | local | C Code | 0.2 to 0.6 ms | | ||
+ | |||
+ | Again, these are representative numbers for software control, faster is possible with pin control. | ||
+ | ===== Testing in IIO Oscilloscope ===== | ||
+ | |||
+ | The [[/ | ||
+ | |||
+ | |||
+ |