Option to get integer I/Q stream about airspyhf HOT 17 CLOSED

Again, this is not personal. You can move on.

from airspyhf.

I had a closer look. My idea is to

• expose airspyhf_complex_int16_t
• make samples in airspyhf_transfer_t a void *
• define an enum for the formats like airspyhf_sampleformat_t
• have a field with this enum in struct airspyhf_device
• have a setter for the format in the interface like airspyhf_set_sampleformat(airspyhf_device_t* device, airspyhf_sampleformat_t format);
• in allocate_transfers the output buffer needs to be allocated with the proper size depending on the format
• in consumer_threadproc the conversion is done or not done depending on the format. I suppose a copy of the original samples to the output buffer still needs to be done in the case of the integer format.

from airspyhf.

You will also have to implement the IQ balancer to use integers instead of floats.

from airspyhf.

Yes it looks like it and there is a complex multiplication with a fixed value dpending on frequency correction. I am wondering if angle shouldn't be a varying phasor that should be incremented with the sample index thus a NCO in fact. Now if frequency shift is 0 it will have the effect of inverting I and Q which seems to be necessary also.

from airspyhf.

Guys, it costs CPU cycles to get these floats out. Why would anyone convert them back to int16? The post processing of the raw samples involves complex math and part of that math runs on doubles, not even single precision floats, so the cost of using floats/doubles will be there anyway.
Another aspect most people overlook is the quantization to 16bit (or any integer) from floats. Doing it right involves even more processing with integration, noise shaping and proper handling of the DC point. Ignoring that will basically render the last LSB practically useless. Using int16 for minimizing the CPU cost is a false economy.

Use floats. Floats are cheaper than you may think - if implemented properly.

from airspyhf.

I don't know why anyone wants int samples, perhaps to reduce the transfer rate on a sub-standard USB connection?

from airspyhf.

I do want int16 and why would it cost something? They are already there and converted to floats. All my software works with integers. It seems necessary for you to convert to floats to further apply frequency, DC and IQ corrections and then of course it would have a cost to get back to integers. In my opinion these corrections should be left to the application code but that's your choice... I am not keen to support the cost of this choice in my application code though. Maybe I should reformulate the request: what I actually want is the raw integer samples without any correction and that costs nothing. Actually this is not entirely true because for some reason the I and Q need to be swapped but I can live with this.

Moreover I am talking about an option. Usually interface libraries offer a choice of format for the samples. Why wouldn't your library support this?

from airspyhf.

Fair enough. The code is released under the most permissive license. You can embed a light version without the IQ correction to accommodate your requirements. You can even remove the DSP thread and the output queue.

from airspyhf.

Does this mean you would accept a PR or shall I proceed with this on my own fork only?

from airspyhf.

The idea is to not break the existing API, which is already referenced by many applications. All the other applications use floats to represent IQ signals internally. Any suggestions?

from airspyhf.

I see only this as an issue: "make samples in airspyhf_transfer_t a void *". I suppose adding another pointer for the raw int samples wouldn't hurt though. One should access the airspyhf_transfer_t using its fields. Of course the float option should be the default.

Note1 on "All the other applications use floats to represent IQ signals internally": maybe but that might not be such a great idea. Integer arithmetics will go faster.

Note2: Ironically the original Airspy library offers a vast choice of sample formats using more or less the interface initially suggested.

from airspyhf.

I think this is going nowhere. I'm still not convinced applications should use raw samples or any internal stuff that is specific to any given hardware. The role of the library is to abstract these details.

If you need usable 16bit samples, the first thing to do is to port the IQ correction algo to fractional math and make sure it works properly with 120 dBc of rejection, and only then hack the output buffers.

Hacking is easy. Doing it right is not.

from airspyhf.

I have working LO, DC and IQ correction in my software, The role of a low level library is to provide the applications with what they need.

You are right this is going nowhere because of your stubborness and lack of knowledge and experience in real computing and collaboration. I will use my own copy.

from airspyhf.

This is not personal. Your solution doesn't fit our quality standards (or any reasonable quality standards that is). Nothing to do with "collaboration". Many useful contributions were accepted because they solve real problems with elegant solutions.

from airspyhf.

Sorry to be a bit bold maybe. I don't find your solution very elegant and I have 25+ years of experience with a software company that raised its revenue from millions to billions. At least you have made the right choice to go for Open Source but you should be more open to change. What you mean by quality standards? If my changes do not meet it then you need to rewrite libairspy because I just applied the same standards. And real problems come from real use cases of your customers.

from airspyhf.

Software dev standards have changed since 25 years. This lib is open source because it has to be open source - not because we like software patchwork.

from airspyhf.

Real problems come from real use cases of your customers and you don't want to listen to my needs that are perfectly legitimate. You think everyone should use floats? I think this is a bad choice in a high performance SDR application. And even if I'm wrong you should provide me with the option. You think your low level library should do everything and even brew the coffee? Some applications do it better so this should only be an option. Your library libairspy was much better in that sense. If you were in real business you wouldn't go very far.

You re thinking I am just an old git telling old stories of old rubbish. Listen more carefully young boy. In those 25+ years I have followed history from mainframes in assembly code to cloud computing client/server applications with nosql DB, Angular io... So I know a little bit what I am talking about.

from airspyhf.