Re: [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
Em 16-04-2013 15:17, Antti Palosaari escreveu: On 04/16/2013 08:26 PM, Mauro Carvalho Chehab wrote: Em 16-04-2013 11:36, Antti Palosaari escreveu: On 04/16/2013 11:09 AM, Mauro Carvalho Chehab wrote: Hi Antti, See my comments below. As I already commented, IMO, we should add SDR as an extension to V4L2 API. We have enough headaches by having two different APIs that already overlaps on some places, to add yet another one. So, I'll add a few comments below with regards to that. I tried to study and list all requirements, without a even knowing very well what is possible using V4L2 API, as you has gone now totally to the implementation side. Surely most those implementations you mentioned are best to implement as you said. I tried to both comment the requirements and discuss about implementation. Could you study and list requirements from the issues you mentioned? IMO, in order to study, we need to implement it first and start testing. Maybe keeping the experimental driver for one or two kernel cycles on a separate topic branch, before merging upstream. Anyway, the better is to get feedback from Amateur Radio people, as they have a way more experience with that than us outside the TV band. The better would be to get input from the ones that are authorized to operate at the full HAM radio range, as they have experienced the usage of the several types of modulation and operate at the long distance ranges. I know a few ones. I'll try to contact them, in order to get their feedback. Here is the one =) I have had license maybe ~15 years, first ~5 years technician class and after CW was removed from requirements license upgrades to unlimited. By a change I just returned to home from our uni. HAM club! I have to say I am not very experienced working with radio bands as I rarely do it nowadays. It is more radio technology which inspires, like modding old Nokia/Mobira mobile phones to HAM band. The one I know more have dozens of different radio types and several antennas with different lengths. He installed himself (sometimes with his son - also HAM), several HAM repeaters at the montains around Rio de Janeiro and nearby cities. Em Thu, 11 Apr 2013 17:56:58 +0300 Antti Palosaari escreveu: I added some new parameters as described. Comments are welcome - I haven't got almost any up to date. I will keep latest version of that document same old address: http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt regards Antti LINUX KERNEL SDR API REQUIREMENT SPECIFICATION = Ideal SDR specific requirements (basics SDR settings) * operation mode * values: ADC (Rx) or DAC (Tx) * operations GET, inquire what HW supports GET, get current value SET, set desired value Instead, IMO the better is to have separate devnodes, one for RX and another one for TX. For devices where TX and RX can't be used at the same time, it should return -EBUSY if the device is already streaming. My suggestion here is to use V4L2 querycap to distinguish between TX and RX. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html At VIDIOC_QUERYCAP, TX devices devices have capabilities set to: for TX devices: V4L2_CAP_MODULATOR for RX devices: V4L2_CAP_RADIO. It makes sense a new capability to identify that the device is SDR: V4L2_CAP_SDR sampling resolution * values: 1 - 32 (unit: bit) 16 bit could be enough, but better to leave some room for future * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling rate * values: 1 - infinity (unit: Hz, symbols per second) currently 500 MHz is more than enough * operations GET, inquire what HW supports GET, get current value SET, set desired value TODO: * inversion? At least GET inversion makes sense. I am not sure about that, study please? Well, userspace may be able to detect bandwidth inversion, for some types of modulation, but I'm not sure if it is always possible to detect it. As it doesn't hurt to inform userspace, IMHO, the better is to just report it there, in order to simplify userspace processing. There's no V4L2 ioctl to set it. My suggestion is to create a new ioctl pair for them VIDIOC_S_SDR- sets SDR specific parameters VIDIOC_G_SDR- gets SDR specific parameters Those will set/get the SDR specific stuff: - sampling rate; - ADC/DAC resolution; - band inversion; -... On VIDIOC_S_SDR, if one parameter is out of range, instead of failing, the device should return the closest allowed value. Btw, all ADC/DAC are linear, or some of them uses A-Law/u-Law? If they could use non-linear bit stepping, then we may need an extra field there for it. I am not sure about that too, but I have feeling that could be correct. Needs conf
Re: [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
On 04/16/2013 08:26 PM, Mauro Carvalho Chehab wrote: Em 16-04-2013 11:36, Antti Palosaari escreveu: On 04/16/2013 11:09 AM, Mauro Carvalho Chehab wrote: Hi Antti, See my comments below. As I already commented, IMO, we should add SDR as an extension to V4L2 API. We have enough headaches by having two different APIs that already overlaps on some places, to add yet another one. So, I'll add a few comments below with regards to that. I tried to study and list all requirements, without a even knowing very well what is possible using V4L2 API, as you has gone now totally to the implementation side. Surely most those implementations you mentioned are best to implement as you said. I tried to both comment the requirements and discuss about implementation. Could you study and list requirements from the issues you mentioned? IMO, in order to study, we need to implement it first and start testing. Maybe keeping the experimental driver for one or two kernel cycles on a separate topic branch, before merging upstream. Anyway, the better is to get feedback from Amateur Radio people, as they have a way more experience with that than us outside the TV band. The better would be to get input from the ones that are authorized to operate at the full HAM radio range, as they have experienced the usage of the several types of modulation and operate at the long distance ranges. I know a few ones. I'll try to contact them, in order to get their feedback. Here is the one =) I have had license maybe ~15 years, first ~5 years technician class and after CW was removed from requirements license upgrades to unlimited. By a change I just returned to home from our uni. HAM club! I have to say I am not very experienced working with radio bands as I rarely do it nowadays. It is more radio technology which inspires, like modding old Nokia/Mobira mobile phones to HAM band. Em Thu, 11 Apr 2013 17:56:58 +0300 Antti Palosaari escreveu: I added some new parameters as described. Comments are welcome - I haven't got almost any up to date. I will keep latest version of that document same old address: http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt regards Antti LINUX KERNEL SDR API REQUIREMENT SPECIFICATION = Ideal SDR specific requirements (basics SDR settings) * operation mode * values: ADC (Rx) or DAC (Tx) * operations GET, inquire what HW supports GET, get current value SET, set desired value Instead, IMO the better is to have separate devnodes, one for RX and another one for TX. For devices where TX and RX can't be used at the same time, it should return -EBUSY if the device is already streaming. My suggestion here is to use V4L2 querycap to distinguish between TX and RX. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html At VIDIOC_QUERYCAP, TX devices devices have capabilities set to: for TX devices: V4L2_CAP_MODULATOR for RX devices: V4L2_CAP_RADIO. It makes sense a new capability to identify that the device is SDR: V4L2_CAP_SDR sampling resolution * values: 1 - 32 (unit: bit) 16 bit could be enough, but better to leave some room for future * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling rate * values: 1 - infinity (unit: Hz, symbols per second) currently 500 MHz is more than enough * operations GET, inquire what HW supports GET, get current value SET, set desired value TODO: * inversion? At least GET inversion makes sense. I am not sure about that, study please? Well, userspace may be able to detect bandwidth inversion, for some types of modulation, but I'm not sure if it is always possible to detect it. As it doesn't hurt to inform userspace, IMHO, the better is to just report it there, in order to simplify userspace processing. There's no V4L2 ioctl to set it. My suggestion is to create a new ioctl pair for them VIDIOC_S_SDR- sets SDR specific parameters VIDIOC_G_SDR- gets SDR specific parameters Those will set/get the SDR specific stuff: - sampling rate; - ADC/DAC resolution; - band inversion; -... On VIDIOC_S_SDR, if one parameter is out of range, instead of failing, the device should return the closest allowed value. Btw, all ADC/DAC are linear, or some of them uses A-Law/u-Law? If they could use non-linear bit stepping, then we may need an extra field there for it. I am not sure about that too, but I have feeling that could be correct. Needs confirming (not algorithm, but use in SDR ADC/DAC). Practical SDR specific requirements (SDR settings for RF tuner) * RF frequency * values: 1 - infinity (unit: Hz) currently 100 GHz is more than enough * opera
Re: [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
Em 16-04-2013 11:36, Antti Palosaari escreveu: On 04/16/2013 11:09 AM, Mauro Carvalho Chehab wrote: Hi Antti, See my comments below. As I already commented, IMO, we should add SDR as an extension to V4L2 API. We have enough headaches by having two different APIs that already overlaps on some places, to add yet another one. So, I'll add a few comments below with regards to that. I tried to study and list all requirements, without a even knowing very well what is possible using V4L2 API, as you has gone now totally to the implementation side. Surely most those implementations you mentioned are best to implement as you said. I tried to both comment the requirements and discuss about implementation. Could you study and list requirements from the issues you mentioned? IMO, in order to study, we need to implement it first and start testing. Maybe keeping the experimental driver for one or two kernel cycles on a separate topic branch, before merging upstream. Anyway, the better is to get feedback from Amateur Radio people, as they have a way more experience with that than us outside the TV band. The better would be to get input from the ones that are authorized to operate at the full HAM radio range, as they have experienced the usage of the several types of modulation and operate at the long distance ranges. I know a few ones. I'll try to contact them, in order to get their feedback. Em Thu, 11 Apr 2013 17:56:58 +0300 Antti Palosaari escreveu: I added some new parameters as described. Comments are welcome - I haven't got almost any up to date. I will keep latest version of that document same old address: http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt regards Antti LINUX KERNEL SDR API REQUIREMENT SPECIFICATION = Ideal SDR specific requirements (basics SDR settings) * operation mode * values: ADC (Rx) or DAC (Tx) * operations GET, inquire what HW supports GET, get current value SET, set desired value Instead, IMO the better is to have separate devnodes, one for RX and another one for TX. For devices where TX and RX can't be used at the same time, it should return -EBUSY if the device is already streaming. My suggestion here is to use V4L2 querycap to distinguish between TX and RX. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html At VIDIOC_QUERYCAP, TX devices devices have capabilities set to: for TX devices: V4L2_CAP_MODULATOR for RX devices: V4L2_CAP_RADIO. It makes sense a new capability to identify that the device is SDR: V4L2_CAP_SDR sampling resolution * values: 1 - 32 (unit: bit) 16 bit could be enough, but better to leave some room for future * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling rate * values: 1 - infinity (unit: Hz, symbols per second) currently 500 MHz is more than enough * operations GET, inquire what HW supports GET, get current value SET, set desired value TODO: * inversion? At least GET inversion makes sense. I am not sure about that, study please? Well, userspace may be able to detect bandwidth inversion, for some types of modulation, but I'm not sure if it is always possible to detect it. As it doesn't hurt to inform userspace, IMHO, the better is to just report it there, in order to simplify userspace processing. There's no V4L2 ioctl to set it. My suggestion is to create a new ioctl pair for them VIDIOC_S_SDR- sets SDR specific parameters VIDIOC_G_SDR- gets SDR specific parameters Those will set/get the SDR specific stuff: - sampling rate; - ADC/DAC resolution; - band inversion; -... On VIDIOC_S_SDR, if one parameter is out of range, instead of failing, the device should return the closest allowed value. Btw, all ADC/DAC are linear, or some of them uses A-Law/u-Law? If they could use non-linear bit stepping, then we may need an extra field there for it. I am not sure about that too, but I have feeling that could be correct. Needs confirming (not algorithm, but use in SDR ADC/DAC). Practical SDR specific requirements (SDR settings for RF tuner) * RF frequency * values: 1 - infinity (unit: Hz) currently 100 GHz is more than enough * operations GET, inquire what HW supports there could be unsupported ranges between lower and upper freq GET, get current value SET, set desired value For GET, IMO dealing with the frequency drift from the programmed frequency is better. It is implementation decision, but let me still ask why it is better? The GET value is the SET value, if everything is OK (except, of course, for tuner step rounding). If there are some difference, this di
Re: [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
On 04/16/2013 11:09 AM, Mauro Carvalho Chehab wrote: Hi Antti, See my comments below. As I already commented, IMO, we should add SDR as an extension to V4L2 API. We have enough headaches by having two different APIs that already overlaps on some places, to add yet another one. So, I'll add a few comments below with regards to that. I tried to study and list all requirements, without a even knowing very well what is possible using V4L2 API, as you has gone now totally to the implementation side. Surely most those implementations you mentioned are best to implement as you said. Could you study and list requirements from the issues you mentioned? Em Thu, 11 Apr 2013 17:56:58 +0300 Antti Palosaari escreveu: I added some new parameters as described. Comments are welcome - I haven't got almost any up to date. I will keep latest version of that document same old address: http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt regards Antti LINUX KERNEL SDR API REQUIREMENT SPECIFICATION = Ideal SDR specific requirements (basics SDR settings) * operation mode * values: ADC (Rx) or DAC (Tx) * operations GET, inquire what HW supports GET, get current value SET, set desired value Instead, IMO the better is to have separate devnodes, one for RX and another one for TX. For devices where TX and RX can't be used at the same time, it should return -EBUSY if the device is already streaming. My suggestion here is to use V4L2 querycap to distinguish between TX and RX. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html At VIDIOC_QUERYCAP, TX devices devices have capabilities set to: for TX devices: V4L2_CAP_MODULATOR for RX devices: V4L2_CAP_RADIO. It makes sense a new capability to identify that the device is SDR: V4L2_CAP_SDR sampling resolution * values: 1 - 32 (unit: bit) 16 bit could be enough, but better to leave some room for future * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling rate * values: 1 - infinity (unit: Hz, symbols per second) currently 500 MHz is more than enough * operations GET, inquire what HW supports GET, get current value SET, set desired value TODO: * inversion? At least GET inversion makes sense. I am not sure about that, study please? There's no V4L2 ioctl to set it. My suggestion is to create a new ioctl pair for them VIDIOC_S_SDR- sets SDR specific parameters VIDIOC_G_SDR- gets SDR specific parameters Those will set/get the SDR specific stuff: - sampling rate; - ADC/DAC resolution; - band inversion; -... On VIDIOC_S_SDR, if one parameter is out of range, instead of failing, the device should return the closest allowed value. Btw, all ADC/DAC are linear, or some of them uses A-Law/u-Law? If they could use non-linear bit stepping, then we may need an extra field there for it. I am not sure about that too, but I have feeling that could be correct. Needs confirming (not algorithm, but use in SDR ADC/DAC). Practical SDR specific requirements (SDR settings for RF tuner) * RF frequency * values: 1 - infinity (unit: Hz) currently 100 GHz is more than enough * operations GET, inquire what HW supports there could be unsupported ranges between lower and upper freq GET, get current value SET, set desired value For GET, IMO dealing with the frequency drift from the programmed frequency is better. It is implementation decision, but let me still ask why it is better? Smaller numbers transferred? Is there is some very common user scenario application likes to see drift rather than actual frequency? Returning drift extends possible numbers to negative too. Also app needs to do some trivial calculation in order to get real value. Basically HAM radio style application will read that value very often when it updates freq seen in UI. Also, returning it as a drift means app needs to know what is frequency set, which it surely usually knows, but not always (makes dependency to value set & permission to set value first). How about remote radio you has no permission to tune? V4L provides this via this ioctl: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-frequency.html What VIDIOC_G_FREQUENCY returns is the programmed frequency, with can actually be different than what userspace requested due to the tuner's scale. Currently, V4L2 unit is either 62.5 Hz or 62.5 kHz, and it uses 32 bits for frequency. All radio devices currently uses the 62.5 Hz scale. With the 62.5 Hz step, the max frequency is about 268 GHz (268,435,455,937.5) with seems good enough. A
Re: [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
Hi Antti, See my comments below. As I already commented, IMO, we should add SDR as an extension to V4L2 API. We have enough headaches by having two different APIs that already overlaps on some places, to add yet another one. So, I'll add a few comments below with regards to that. Em Thu, 11 Apr 2013 17:56:58 +0300 Antti Palosaari escreveu: > I added some new parameters as described. > Comments are welcome - I haven't got almost any up to date. > > I will keep latest version of that document same old address: > http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt > > regards > Antti > > > LINUX KERNEL SDR API REQUIREMENT SPECIFICATION > = > > > Ideal SDR specific requirements (basics SDR settings) > * > > operation mode > * values: ADC (Rx) or DAC (Tx) > * operations > GET, inquire what HW supports > GET, get current value > SET, set desired value Instead, IMO the better is to have separate devnodes, one for RX and another one for TX. For devices where TX and RX can't be used at the same time, it should return -EBUSY if the device is already streaming. My suggestion here is to use V4L2 querycap to distinguish between TX and RX. http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html At VIDIOC_QUERYCAP, TX devices devices have capabilities set to: for TX devices: V4L2_CAP_MODULATOR for RX devices: V4L2_CAP_RADIO. It makes sense a new capability to identify that the device is SDR: V4L2_CAP_SDR > > sampling resolution > * values: 1 - 32 (unit: bit) > 16 bit could be enough, but better to leave some room for future > * operations > GET, inquire what HW supports > GET, get current value > SET, set desired value > > sampling rate > * values: 1 - infinity (unit: Hz, symbols per second) > currently 500 MHz is more than enough > * operations > GET, inquire what HW supports > GET, get current value > SET, set desired value > > TODO: > * inversion? At least GET inversion makes sense. There's no V4L2 ioctl to set it. My suggestion is to create a new ioctl pair for them VIDIOC_S_SDR- sets SDR specific parameters VIDIOC_G_SDR- gets SDR specific parameters Those will set/get the SDR specific stuff: - sampling rate; - ADC/DAC resolution; - band inversion; -... On VIDIOC_S_SDR, if one parameter is out of range, instead of failing, the device should return the closest allowed value. Btw, all ADC/DAC are linear, or some of them uses A-Law/u-Law? If they could use non-linear bit stepping, then we may need an extra field there for it. > > Practical SDR specific requirements (SDR settings for RF tuner) > * > > RF frequency > * values: 1 - infinity (unit: Hz) > currently 100 GHz is more than enough > * operations > GET, inquire what HW supports > there could be unsupported ranges between lower and upper freq > GET, get current value > SET, set desired value For GET, IMO dealing with the frequency drift from the programmed frequency is better. V4L provides this via this ioctl: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-frequency.html What VIDIOC_G_FREQUENCY returns is the programmed frequency, with can actually be different than what userspace requested due to the tuner's scale. Currently, V4L2 unit is either 62.5 Hz or 62.5 kHz, and it uses 32 bits for frequency. All radio devices currently uses the 62.5 Hz scale. With the 62.5 Hz step, the max frequency is about 268 GHz (268,435,455,937.5) with seems good enough. As this ioctl has 8 reserved fields, it would be possible to change frequency to 64 bits and add an extra CAP to VIDIOC_G_TUNER to indicate a different scale, like Hz. Not sure if it this is needed through. I would just start with what we have, adding something else only if needed. > IF frequency (intermediate frequency) > * values: 0 - infinity (unit: Hz) > currently 500 MHz is more than enough > * operations > GET, get current value While IF could be provided by a V4L2 control, IMO, adding it at VIDIOC_G_TUNER using one of the reserved fields makes more sense. At least on r820t, IF depends on the standard and bandwidth. > > tuner lock (frequency synthesizer / PLL) > * values: yes/no > * operations > GET, get current value I would add it to: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-tuner.html#tuner-rxsubchans > > tuner gains > * gain and attenuation > * there could be multiple places to adjust gain on tuner signal path > * is single overall gain enough or do we want more manual fine tuning? * enable/disable auto gain IMO, tuner gain should be provided by a V4L2 control: http://linuxtv.org/dow
[RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION
I added some new parameters as described. Comments are welcome - I haven't got almost any up to date. I will keep latest version of that document same old address: http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt regards Antti LINUX KERNEL SDR API REQUIREMENT SPECIFICATION = Ideal SDR specific requirements (basics SDR settings) * operation mode * values: ADC (Rx) or DAC (Tx) * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling resolution * values: 1 - 32 (unit: bit) 16 bit could be enough, but better to leave some room for future * operations GET, inquire what HW supports GET, get current value SET, set desired value sampling rate * values: 1 - infinity (unit: Hz, symbols per second) currently 500 MHz is more than enough * operations GET, inquire what HW supports GET, get current value SET, set desired value TODO: * inversion? Practical SDR specific requirements (SDR settings for RF tuner) * RF frequency * values: 1 - infinity (unit: Hz) currently 100 GHz is more than enough * operations GET, inquire what HW supports there could be unsupported ranges between lower and upper freq GET, get current value SET, set desired value IF frequency (intermediate frequency) * values: 0 - infinity (unit: Hz) currently 500 MHz is more than enough * operations GET, get current value tuner lock (frequency synthesizer / PLL) * values: yes/no * operations GET, get current value tuner gains * gain and attenuation * there could be multiple places to adjust gain on tuner signal path * is single overall gain enough or do we want more manual fine tuning? tuner filters * there could be multiple filters on tuner signal path (RF/IF) * do we need to control filters at all? * calculate from sampling rate? TODO: * pass RF standard to tuner? Passing standard is clearly against idea, but some RF tuners does "black magic" according to standard. That magic is usually setting filters and and gains, but it could be more... * inversion? Hardware specific requirements (board settings) * antenna switch * values: 0 - 32 (unit: piece) * operations GET, inquire what HW supports GET, get current value SET, set desired value external LNA * values: -20 - 20 (unit: dB/1000) * operations GET, inquire what HW supports GET, get current value SET, set desired value * range from -200dB to 200dB should be enough multiple ADCs / DACs on single device * there could be multiple ADCs and DACs on single device * resources could be shared which limits concurrent usage * eg. device has 2 ADC + 2 DAC = 4 total, but only 2 could be used at the time Kernel specific requirements * device locking between multiple APIs * same device could support multiple APIs which could not be used at same time * for example DVB API and V4L2 API * locking needed DOCUMENT VERSION HISTORY = 2012-10-15 Antti Palosaari * Initial version 2013-04-11 Antti Palosaari * add version history * order requirements per sections * add IF frequency (intermediate frequency) * add tuner lock (frequency synthesizer / PLL) * add external LNA * add TODOs -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
