Add GPIO control in PTT feature

[srcejon]

I was thinking it would be useful to add to the PTT feature, the ability to write user-defined values to device GPIOs, in order to support external TRX switch control.

Currently the Lime device has gpioPins and gpioDir exposed via its API. Similar could be added for USRP, RTL SDR, BladeRF (and perhaps other SDRs that have GPIOs), so there's a consistent API for the PTT feature to use.

[f4exb]

In my opinion due to the vast variety of TRX switch controls including custom ones this should be handled via a call to an external command.

[srcejon]

Having the ability to call an external command would be useful as well, but will an external command be able to write the GPIO registers of an SDR that SDRangel has open? I would have thought not, but haven't tried.

[f4exb]

Sure but what's the point to turn on the GPIO of an SDR that in turn will turn on a TX/RX switch. It should be possible to control this TX/RX switch outside the SDR.

[f4exb]

Moreover since the GPIO control comes with the device support (in its interface library) it is more a device thing than a PTT feature thing so I'd rather see this functionality implemented in the device controller (i.e. plugin) connected to the start/stop action of the device. For things that cannot be controlled with the device the external command still makes sense.

[srcejon]

Moreover since the GPIO control comes with the device support (in its interface library) it is more a device thing than a PTT feature thing so I'd rather see this functionality implemented in the device controller (i.e. plugin) connected to the start/stop action of the device.

Yes, that makes sense if you want it to work when starting the TX device without using PTT feature as well.

[srcejon]

Sure but what's the point to turn on the GPIO of an SDR that in turn will turn on a TX/RX switch. It should be possible to control this TX/RX switch outside the SDR.

Currently I have no other way to do it. I could buy a USB relay controller, but why not use something that already exists? It's what they are for.

[f4exb]

Moreover since the GPIO control comes with the device support (in its interface library) it is more a device thing than a PTT feature thing ...

Well changing my mind eventually since I have (re)discovered the ChannelWebAPIUtils class which is a collection of static methods that can interface with the various components using the web interface. Although called "Channel" something since the methods are static it does not need to be tied to a particular channel instance. There is a pair of getDeviceSetting and patchDeviceSetting methods that can retrieve or update any key of the settings interface. This is used in the Radioastronomy plugin with the GPIO settings precisely.

Using this interface it is possible to abstract the device type and hence the best place to deal with GPIO and Rx/Tx is indeed the PTT feature. If the device has no GPIO it simply does nothing.

[Radiomix2000]

Hello, dear developers,
is it possible and how to use some of FT232 family chips (FT232H, FT232RL) for PTT in SDRangel using python? Which starting point do you recommend?
I found that even FT232RL without GPIO with standard RS232 signal lines is good for PTT and used it in Gnuradio project to switch TX ON/OFF.

    def __init__(self, Port_Number='COM9'):  # only default arguments here
        """arguments to this function show up as parameters in GRC"""
        gr.sync_block.__init__(
            self,
            name='Mute on UART CTS',   # will show up in GRC
            in_sig=[np.complex64],
            out_sig=[np.complex64]
        )
        ms = serial.Serial(port=Port_Number, baudrate=9600, rtscts=True)
        self.ms = ms
        self.Port_Number = Port_Number


    def work(self, input_items, output_items):
        """example: multiply with constant"""
        if self.ms.getCTS():
            output_items[0][:] = input_items[0] * 1#self.example_param
        else:
            output_items[0][:] = input_items[0] * 0
        return len(output_items[0])

I would be thankful, if you point me to point to start from.

[srcejon]

Well changing my mind eventually since I have (re)discovered the ChannelWebAPIUtils class which is a collection of static methods that can interface with the various components using the web interface. Although called "Channel" something since the methods are static it does not need to be tied to a particular channel instance.

I think I called it ChannelWebAPIUtils, because it was originally used from within a channel. But have often thought most of the code that doesn't use a channel number, should probably be moved to DeviceWebAPIUtils, or something like that.

[f4exb]

Re @Radiomix2000 If Python is the dominant technology for your case you may as well control SDRangel from a Python script using its Web API interface. You have plenty of examples in the scriptsapi folder

[f4exb]

I think I called it ChannelWebAPIUtils, because it was originally used from within a channel...

I undestand WebAPIUtils was already used and can remain as the place for lower level methods but it doesn't hurt if the higher level methods are all stuck in the same class. One could call it ComponentWebAPIUtils to be more generic but using the current name is a minor issue.

[srcejon]

I notice some GUI elements have been added to the PTT for RX/TX commands - but they don't appear to be connected. Was that an accidental/partial commit? Someone was asking about it on the forum: http://sdrangel.org/forum/viewtopic.php?t=80

[f4exb]

Yes this is a partial commit not to loose track too much from master. I have swapped priorities a bit...