RedPitaya / HPSDR Metis support

[satfan52]

Hello,

I tried using the redpitaya "SDR transceiver" that is compatible with SoapySDR with "Sdrangel " and using the "SoapySDRredpitaya" module. I was only able to receive, impossible to transmit and Sdrangel does not seems to report any errors in the console when I try to transmit.

I am using the latest version of Sdrangel (recently compiled in the Linux Ubuntu 18.04 environment). As I was able to use Sdrangel sucessfuly with my plutosdr (both with iio and soapysdr drivers) so I think that my Sdrangel and Soapysdr set-ups are probably OK.

As there is no discovery mechanism implemented yet in the SoapSDRredpitaya module, I had to hardcode the the static IP address of my redpitaya in the .cpp file. This trick works well in reception so it should logically also work in transmission too according to the developer...., but it is unfortunately not the case....so...

I initially opened a ticket on the SoapySDRredpitaya github respository but I concluded after some discussion with the developer that the Sdrangel repository is better suited to tackle this issue considering that everything works fine in reception mode and only TX mode is the issue. I understand the developer has tested the module with the PothosGUI and everything works as designed including the transmission part.

More information (including Sdrangel console info) in the initial ticket opened in the SoapySDRredpitaya github respository

https://github.com/pothosware/SoapyRedPitaya/issues/5

Thanks Regards Peter

[f4exb]

I don't know exactly what you want to do. It is already possible to run more than one device in the same SDRangel instance. It is also possible to use WSJTX by piping the audio output of a SSB modulator into the audio input of WSJTX using a pulseaudio virtual audio device. The purpose of this ticket is to create a plugin that gets its I/Q samples from a hermes/metis connection (thus supporting Red Pitaya in the Metis mode and the like) and to do it respecting the synchronization between streams (what I called MIMO mode).

[satfan52]

Yes, yesterday I managed to use SdraAngel with two different devices; my RP 125-14 board ("SDR transceiver" via "SoapySDR") and with my PlutoSDR (native support not SoapySDR middleware). That worked well, but the only trouble is that I was only able to use one of two receivers of the RP SDR transceiver app; in other words I could monitor only one HF band at the time. Two receivers and two transmitters would be available according to the doc of the "SDR tranceiver" app :-(

What I am hoping is simply that this ticket will allow me to use the "hpsdr transceiver" instead of the "SDR one" and of course, I am also logically consequently hoping to be able to monitor several HF bands concurrently (as many as the hpsdr transceiver app allows it) instead of 1 nowadays (with the "SDR transceiver/SoapySDR/SoapySDRredpitaya" trio).

Le sam. 28 sept. 2019 à 10:11, f4exb notifications@github.com a écrit :

I don't know exactly what you want to do. It is already possible to run more than one device in the same SDRangel instance. It is also possible to use WSJTX by piping the audio output of a SSB modulator into the audio input of WSJTX using a pulseaudio virtual audio device. The purpose of this ticket is to create a plugin that gets its I/Q samples from a hermes/metis connection (thus supporting Red Pitaya in the Metis mode and the like) and to do it respecting the synchronization between streams (what I called MIMO mode).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel/issues/344?email_source=notifications&email_token=ADR72WJF7FFG3T2E4PXEZXTQL4GUDA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72TTOI#issuecomment-536164793, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WONJ5XZG3CNTTVZ2MDQL4GUDANCNFSM4HNLZADA .

[satfan52]

Well, thanks for the clarification. I am sorry if I don't use the right terminology to discuss about this. Indeed, I naievely thought that if the redpitaya supports N receivers and 1 transmitter, then N different source devices would appear in the dropdown source menu and one sink device would appear in the dropdown sink menu.

On Wed, 2 Oct 2019, 02:03 f4exb, notifications@github.com wrote:

MIMO POC is definitely a fail. It is not possible to handle simultaneous threads in SDRangel. If Red Pitaya is to be supported natively it has to be with classical Rx and Tx streams (device sets).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel/issues/344?email_source=notifications&email_token=ADR72WO5ILYBY76BN32MJ23QMPQL7A5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADD23Q#issuecomment-537279854, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WPAZHHFLRACRVY65YLQMPQL7ANCNFSM4HNLZADA .

[devil1468h]

@satfan52 Hi, I am new to Sdrangel. I can't see the redpitaya in the sampling device. I am using sudo snap install sdrangel (ubuntu 16.04). I install the Soapysdr redpitaya as well. I also hardcode the the static IP address of my redpitaya in the .cpp file. Could you tell me how I can find redpitaya in the sampling device list.

[satfan52]

Hello, Well, Edouart is really the expert not me, hower are my two cents (1) The method you describe is outdated and actually has never worked correctly. It only worked in reception but not in transmission. (2) If you have installed SoapySDR and the SoapySDRredpitaya module the redpitaya should appear in your device list. If it does not appear it is because your installation is not correct. Just run "SoapySdrUtil -find" from the console and if your redpitaya is not detected it means there is an issue with your SoapySdr/RedpitayaSoapySDR installation. (3) When I did those tests a while ago I used the latest version of sdrangel (compiled from source not the one available in the Unbuntu repository) that includes a "menu" to enter the IP address and the Port Number (1001) of the redpitaya (so there is no need to modify the RedPitayaSoapySDR .cpp file to manually encode the IP address). Please refer to ticket 362 (https://github.com/f4exb/sdrangel/issues/362 ) that is closed (4) Kindly note that I do NOT routinely use sdrangel with my redpitaya using soapysdr. I occasionaly use this set-up for experimental purpose, for making some tests of the soapysdr environment or if I want to compare the performance of my redpitaya in VHF with the one of my PlutoSDR (since sdrangel supports both). Prior to switching to a more operational use of the redpitaya with sdrangel, I am patiently waiting for this ticket (some kind of HPSDR compatibility supporting multiple receivers - up to 8) to be implemented (so sdrangel supports the redpitaya WITHOUT the need to recourse to soapysdr)

I hope this helps

[devil1468h]

Hi,

I really appreciate your reply. I just need redpitaya as the receiver for my DATV test and I will consider your suggestion on HPSDR too. I failed to build SDRangel from source and I will upgrade my Ubuntu to 18.04 to make the new try.

Thanks again for your helps.

On Sat, Jun 13, 2020 at 3:48 AM satfan52 notifications@github.com wrote:

Hello, Well, Edouart is really the expert not me, hower are my two cents (1) The method you describe is outdated and actually has never worked correctly. It only worked in reception and but not in transmission. (2) If you have installed SoapySDR and the SoapySDRredpitaya module the redpitaya should appear in your device list. if it does appear it is because your installation is not correct. Just run "SoapySdrUtil --find" from the console and if your redpitaya is not detected it means there is an issue with your SoapySdr/RedpitayaSoapySDR installation. (3) When I did those tests a while ago I used the latest version of sdrangel (compiled from source not the one available in the Unbuntu repository) that includes a "menu" to enter the IP address and the Port Number (1001) of the redpitaya (so there is no need to modify the RedPitayaSoapySDR .cpp file to manually encode the IP address). Please refer to ticket 362 (#362 https://github.com/f4exb/sdrangel/issues/362 ) that is closed (4) Kindly not that I do NOT routinely use sdrangel with my redpitaya using soapysdr, it used for experimental purpose only for making some tests in the soapysdr environment . I am patiently waiting for this ticket (some kind of HPSDR compatibility supporting multiple receivers - up to 8) to be implemented so sdrangel supports the redpitaya WITHOUT the need to recourse to soapysdr.

I hope this helps

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/f4exb/sdrangel/issues/344#issuecomment-643593084, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG52EABBTIJM7GLLETIUM5TRWM4NHANCNFSM4HNLZADA .

[f4exb]

Thanks @satfan52 for the clarifications. Indeed the version you refer to in (3) is 4.10.1 and is ~9 months old. I don't think there has been a regression so the latest should also work. I strongly advise you to upgrade to 18.04 there is hardly any chance that you will be to compile with older releases. Note that on the other hand it should compile in 20.04 although this is not yet "official".

You mention DATV. Please note that the DATV plugin is not fully operational and needs ~15 dB S/N or more to decode images. This makes it impractical for QO-100 for example.

Although this ticket is pretty old it is definitely on my list for this year. Being able to process Metis stream is key to open the way to more MIMO devices support. I am mainly thinking of a separate driver (TBD also) to support Kerberos SDR and possibly any generic array of clock synchronized sources and possibly sinks seen as Metis sources/sinks.

[devil1468h]

@f4exb When I open the sdrangel, soapysdr input and output show up in the log info. However, they dont show up in the sampling device list of sdrangel. Any possible reason? I fix this problem by deleting the "git reset --hard "soapy-sdr-0.7.1" the version is too old.

2020-06-14 21:02:06.552 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.fileinput 2020-06-14 21:02:06.552 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.fcdpro 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.fcdproplus 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.kiwisdrsource 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.localinput 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.remoteinput 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.soapysdrinput 2020-06-14 21:02:06.554 (D) DeviceSoapySDRScan::scan: Lib Version: v0.7.1-g5838bc91 2020-06-14 21:02:06.554 (D) DeviceSoapySDRScan::scan: API Version: v0.7.1 2020-06-14 21:02:06.554 (D) DeviceSoapySDRScan::scan: ABI Version: v0.7 2020-06-14 21:02:06.554 (D) DeviceSoapySDRScan::scan: Install root: /opt/install/SoapySDR 2020-06-14 21:02:06.554 (D) SoapySDROutputPlugin::enumOriginDevices: 0 SoapySDR devices 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateRxDevices: sdrangel.samplesource.testsource 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateTxDevices: sdrangel.samplesink.filesink 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateTxDevices: sdrangel.samplesink.localoutput 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateTxDevices: sdrangel.samplesink.remoteoutput 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateTxDevices: sdrangel.samplesink.soapysdroutput 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateTxDevices: sdrangel.samplesink.testsink 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateMIMODevices: sdrangel.samplemimo.testmi 2020-06-14 21:02:06.554 (D) DeviceEnumerator::enumerateMIMODevices: sdrangel.samplemimo.testmosync 2020-06-14 21:02:06.554 (D) DeviceEnumerator::addNonDiscoverableDevices: start

[f4exb]

Metis discovery example in Qt: https://github.com/alexlee188/ghpsdr3-alex/blob/master/trunk/src/HPSDRServer/discovery.cpp

[f4exb]

Eventually I do not think this feasible due to weak documentation. It is not possible to guess how the stream is composed.

[pavel-demin]

Here are the links to the detailed description of the protocol: https://github.com/TAPR/OpenHPSDR-SVN/raw/master/Metis/Documentation/Metis-%20How%20it%20works_V1.33.pdf https://github.com/TAPR/OpenHPSDR-SVN/raw/master/Documentation/USB_protocol_V1.58.doc

[f4exb]

It seems the specification is not respected. i.e. for 3 receivers as in the example we would have: <I1,2><I1,1><I1,0><Q1,2><Q1,1><Q1,0><M1><M0><I2,2><I2,1><I2,0><Q2,2><Q2,1><Q2,0><M1><M0><I3,2><I3,1><I3,0><Q3,2><Q3,1><Q3,0><M1><M0> instead of: <I1,2><I1,1><I1,0><Q1,2><Q1,1><Q1,0><I2,2><I2,1><I2,0><Q2,2><Q2,1><Q2,0><I3,2><I3,1><I3,0><I3,2><Q3,1><Q3,0><M1><M0> as in the documentation

[f4exb]

Moreover it appears to be a single Rx (not 2, 3 or 4) and I and Q samples are inverted. This way it may work but there is no point making it as multiple input.

[f4exb]

OK I think I've got it you have to activate the receivers with the number of receivers setting in the "C4" byte. And the format is indeed what is documented. In the case of a single receiver both formats are the same.

[f4exb]

The "SDR receiver compatible with HPSDR" has 8 receivers but the protocol in the original paper is for 7 receivers. However the "Hermes 2 lite" (https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol) has room for 12 receivers and the frequency of the 8th one is addressed with command index 0x12 in bits [6:1] which is 36 in decimal ignoring the mox bit. I suppose then that this command index should be used to address the 8th receiver. This is for the SDR receiver only which is not multiple coherent input but could be used with the MIMO scheme.

[satfan52]

Good to read that this is moving on! I will just comment that I learned the hard way, trying to make my redpitaya work with software initially designed for the Hermes-Lite protocol (such as QUISK) , that HPSDR/metis and Hermes-Lite are not always systematically compatible for all the functionalities offered by one or the other. So I am not surprised at all by such a difference. If we could already get 8 receivers, it would be a major breakthrough ;-) Though to be on the leading edge, probably 12 receivers would be more relevant. Some of the hermes-lite 2 hardware offer more than 8 receivers today already....I don't own one myself but I have read that the firmware of the hermes-lite 2 hardware that is commercialized by Marcofab already supports 9 or 10 receivers.

[f4exb]

This is eventually released with tag v5.10.0 on the v5 branch. It uses the MIMO scheme so it will be present on the v5 branch only. It means you have to check out this branch and compile the code.

It has not all the bells and whistles to make the Red Pitaya control peripherals with its GPIO but it is functional to receive and transmit with both Pavel's HPSDR emulations. Any possible follow-up can be tracked with new issues.

For now this one can be closed.

[satfan52]

Many thanks. I will test it soon

[satfan52]

Tested ok in reception mode with two receivers using the app "Transceiver compatible with HPSDR" . Also tested ok with 8 receivers using the app "Receiver compatible with HPSDR". Noticed that performance is degrading significantly when the number of receivers in increasing. Practically, with 8 receivers open, I could only operate with 48 KSA per receiver. Probably with a more powerful hardware it should work better at higher sampling rate.

Still need to tests the transmission mode

[f4exb]

The I/Q data stream is de-muxed in a single thread because of its inherent MI (multiple input) nature even if practically true MI exists only with the transceiver where the first two streams come from the first and second Rx respectively. De-muxing the 8 streams probably requires quite a bit of processing.

[f4exb]

To be retrofitted to master as v6

[f4exb]

Deployed in v6.0.0