Can't set centerFrequency >2GHz for some devices via API

[srcejon]

For some devices it isn't possible to set the centerFrequency greater than 2GHz using the API.

For example, with the TestSource:

curl -X PATCH "http://127.0.0.1:8091/sdrangel/deviceset/0/device/settings" -H "accept: application/json" -H "Content-Type: application/json" -d "{ "deviceHwType": "TestSource", "direction": 0, "testSourceSettings": { "centerFrequency": 2435000000 }}"

Results in the center frequency being set to 0.

Looking in swagger/sdrangel/code/qt5/client, it seems most targets use qint64 for center frequency, but TestSource and some others are just using a 32-bit signed integer, so will overflow.

[srcejon]

Just looking at how to rebuild the swagger generated files. In the swagger/sdrangel/readme.md, it refers to using a patched version of swagger-codegen:

https://github.com/etherealjoy/swagger-codegen/tree/qt5cpp_rework_antis81_patch-1

This branch doesn't seem to exist anymore. It appears to have been merged now: swagger-api/swagger-codegen#7194

It seems the existing generated files were generated using a version around 2.4.0 (according to swagger/sdrangel/code/qt5/.swagger-codegen/VERSION), however, I can't recreate the existing files using prebuilt versions of swagger (I've tried 2.4.0 to 2.4.15 - wget https://repo1.maven.org/maven2/io/swagger/swagger-codegen-cli/2.4.15/swagger-codegen-cli-2.4.15.jar).

In the SDRangel git repo, several methods are virtual which aren't in the regenerated files, SWG_API and export.h are missing and some method signatures have changed. Any idea what I might be missing? Thanks.

[f4exb]

This is done using a Docker container: https://github.com/f4exb/sdrangel/tree/master/swagger/docker
Some information here as well: https://groups.io/g/sdrangel/topic/adding_a_new_samplesource/75170838?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,75170838

[f4exb]

In TestSource.yaml:

TestSourceSettings:
  description: TestSource
  properties:
    centerFrequency:
      type: integer
      format: uint64

I suppose uint64 is not interpreted by the generator as a 64 bit unsigned. To keep the large integer format one must use int64 instead.

Edit: it looks like it is indeed the case.