RedPitaya / HPSDR Metis support

satfan52 commented 5 years ago

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 commented 5 years ago

Sorry I do not have a Red Pitaya to test. If it were the case I would have made a native plugin.

pavel-demin commented 5 years ago

I see that no callback is called for InterpolatorFloat in SoapySDROutputThread::run and in SoapySDROutputThread::callbackMO:

https://github.com/f4exb/sdrangel/blob/master/plugins/samplesink/soapysdroutput/soapysdroutputthread.cpp#L170-L173

https://github.com/f4exb/sdrangel/blob/master/plugins/samplesink/soapysdroutput/soapysdroutputthread.cpp#L254-L257

Doesn't it mean that the buffer is never filled?

f4exb commented 5 years ago

Yep well spotted. I am opening a specific issue for this (not RedPitaya specific). Issue #345 opened.

pavel-demin commented 5 years ago

Regarding the IP address problem.

Would it be possible to add a QLineEdit field to the soapysdroutput and soapysdrinput UIs and to append the value of this field to the kwargs variable in DeviceSoapySDR::openopenSoapySDRFromSequence?

It would allow to configure the IP address and other parameters via the UIs.

f4exb commented 5 years ago

Not sure... this is a device specific thing and should be handled in the SoapySDR interface. I mean SoapySDR should know the address during enumeration there is no input from the user here. Similarly SoapyRemote does not ask for an address it finds it using avahi (I think).

pavel-demin commented 5 years ago

SoapySDR is also used in other projects like Pothos, CubicSDR and QSpectrumAnalyzer. These projects provide a field to input the arguments for the SoapySDR modules. I think that these examples are enough to show that it's technically possible to implement.

The arguments are a part of the SoapySDR API and they are used by several SoapySDR modules (SoapyBladeRF, SoapyRedPitaya, SoapyUHD, etc.).

f4exb commented 5 years ago

This is probably where the "universalism" of SoapySDR falls short and why I was reluctant to implement it finally doing it under popular pressure. This is also why this issue is now directed at native support of RedPitaya.

Anyway if you mean a line edit to type in a freeflow argument string that is just passed on to Soapy then this is fine (and also to be covered in another issue). I know this is technically feasible but my concern is more functional: if this line edit is just to type in an address then this is an issue if these are generic keyword (or any kind btw) arguments to Soapy this is fine.

Edit: issue #346 opened

pavel-demin commented 5 years ago

Thanks!

satfan52 commented 5 years ago

Hello Edward,

In reception mode, it would also be useful, for the end user to be able to control (one way of the other) the GAIN of the redpitaya. The reason I am pointing this out specifically is because I noticed an obvious an very annoying problem with the reception of SSB signals with the redpitaya in the Sdrangel and sopaysdr ecosystem. The audio is saturating and clipping on most of the ssb signals, sometimes it is not too bothering and at other times it's just impossible to listen to the signal. Everything happens as if the redpitaya was "saturating" sdrangel or as if the audio system of my PC was getting saturated, leading to these noisy very anoying clipping effects. I noticed that the gain slider in the Sdrangel GUI is currently greyed when the redpitaya is defined as a soapysdr source, so I can't reduce it to attempt to get rid of that problem. In all the other soapysdr applications cited above there is this possibility in the UI , not just the IP address and the port number but the gain too. Of course, I am naively hoping reducing the gain will solve that problem, but in fact there might be other issues as well, and if that is the case, I am happy to make some tests.

Thanks Regards Peter

pavel-demin commented 5 years ago

In reception mode, it would also be useful, for the end user to be able to control (one way of the other) the GAIN of the redpitaya.

Red Pitaya doesn't have gain control.

satfan52 commented 5 years ago

OK fine. I guess this audio quality issue (saturation and clipping on SSB signal with redpitaya defined as source ) should to be addressed in an other more appropriate and relevant way, but I think it should be addressed that is my point.I will try to upload an audio sample here

On Fri, 17 May 2019, 19:35 Pavel Demin, notifications@github.com wrote:

In reception mode, it would also be useful, for the end user to be able to control (one way of the other) the GAIN of the redpitaya.

Red Pitaya doesn't have control.

— 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=ADR72WI2WGMV6XUX6MLKS5DPV3UFDA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVMKII#issuecomment-493536545, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WP4SGOD2DCAZDWUAYLPV3UFDANCNFSM4HNLZADA .

satfan52 commented 5 years ago

Here is an audio sample recorded in the 40m band. Weak or modest SSB signals are Ok, but strong ones get clipped somehow. The stronger the signal the more clipped it is.

captured_audio_redpitaya_sdr_txcv_soapysdr_sdrangel.zip

pavel-demin commented 5 years ago

Since I'm not an SDRangle expert, the following could be completely meaningless. If it's so, then please ignore it.

Looking at the demodssb documentation, I've found the 'Volume and AGC' section showing several volume and AGC controls.

I'd naively suggest that changing some of the volume and automatic gain settings could help to solve the saturation and clipping problem.

satfan52 commented 5 years ago

Well I played with the different SSB demodulator settings and yes I was able to eliminate clippings effects. It's actually so basic that I didn't think about it at first. The trick that worked for me is to lower the volume knob of the ssb demodulator to 2.0 (it is set by default to 3.0) and to compensate by increasing the general volume of the PC.

f4exb commented 5 years ago

The defaults have been set for weak signal work without AGC. It might not be practical in other use cases.

f4exb commented 5 years ago

While the final idea is to get native support in the SoapySDR plugin the support of passing IP address via GUI cannot work. This is because this is a parameter that should be discovered at device scan time to be used by the opening method that precedes the GUI instantiation. Actually the scanning process for Soapy looks for different possible exposed key value pairs during enumeration and the "addr" key comes last so it can be the case that another one ("serial" or "device_id") is also present and takes precedence. More on that when I can experiment with the RedPitaya.

pavel-demin commented 5 years ago

While the final idea is to get native support in the SoapySDR plugin the support of passing IP address via GUI cannot work.

Strange. It works in Pothos and QSpectrumAnalyzer. Here is a link to an issue comment with a screenshot showing how the addr parameter can be set in Pothos GUI and here is a link to an issue comment with a screenshot showing how the addr parameter can be set in QSpectrumAnalyzer.

I think that it could be useful to have two options:

scanning with automatic discovery
manual configuration

While automatic discovery works well for USB devices, it doesn't for network devices. The discovery protocols like Bonjour/DNS-SD can't cross subnet boundaries. So, it could be useful to have a manual configuration option if one wants to connect to a network device from a different subnet.

f4exb commented 5 years ago

SoapyRemote can do self discovery on IP addresses so it could be worth having a look.

If self discovery cannot be done for SoapySDR/RedPitaya then it is certainly not an option to use the plugin UI because this UI is tied to a particular device so this device should already be discovered. This is why I have ruled out this option completely. The self discovery is at the heart of the process when SDRangel starts so it is pretty difficult to implement a "manual" discovery later and at the moment I cannot see an elegant way to do it. So for the moment you have to take it as a limitation.

Edit: I know SoapyRemote is based on avahi and avahi uses DNS-SD therefore it may not be an option for you.

satfan52 commented 5 years ago

But why am I able to receive with the redpitaya (after hardcoding the address in the soapysdrredpitaya module and not transmit? This is so counter intuitive! Looks like the module code is using addr to receive and addr to transmit? addr is hard-coded but addr is supposed to be returned and it does not happen for the reasons you explained above? Can the module not use __addr for both TX and RX?

On Thu, 23 May 2019, 10:24 f4exb, notifications@github.com wrote:

SoapyRemote can do self discovery on IP addresses so it could be worth having a look.

If self discovery cannot be done for SoapySDR/RedPitaya then it is certainly not an option to use the plugin UI because this UI is tied to a particular device so this device should already be discovered. This is why I have ruled out this option completely. The self discovery is at the heart of the process when SDRangel starts so it is pretty difficult to implement a "manual" discovery later and at the moment I cannot see an elegant way to do it. So for the moment you have to take it as a limitation.

— 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=ADR72WPDGZZIJBEDXS6VTYDPWZIFTA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWBORQA#issuecomment-495118528, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WO73O7S3PMSL52T72LPWZIFTANCNFSM4HNLZADA .

satfan52 commented 5 years ago

and if sdrangel discovers the soapysdrredpiraya module (even when no redpitaya hardware is present) and is able to use the redpitaya in reception when the device is present, why can't sdrangel also use the same ip in transmission?

Apologies, I am not a programmer, just a common sense guy

On Fri, 17 May 2019, 20:59 Peter Ide-Kostic, pik138065@gmail.com wrote:

OK fine. I guess this audio quality issue (saturation and clipping on SSB signal with redpitaya defined as source ) should to be addressed in an other more appropriate and relevant way, but I think it should be addressed that is my point.I will try to upload an audio sample here

On Fri, 17 May 2019, 19:35 Pavel Demin, notifications@github.com wrote:

In reception mode, it would also be useful, for the end user to be able to control (one way of the other) the GAIN of the redpitaya.

Red Pitaya doesn't have control.

— 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=ADR72WI2WGMV6XUX6MLKS5DPV3UFDA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVVMKII#issuecomment-493536545, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WP4SGOD2DCAZDWUAYLPV3UFDANCNFSM4HNLZADA .

f4exb commented 5 years ago

soapysdrredpitaya module is nothing known in SDRangel so I suppose you are referring to the SoapySDR support module for RedPitaya and I cannot speak for it. Anyway I really need hands on experience with it to understand what happens. In any case this does not change the fact that the details on how to access the device (i.e. the address) should be known prior to opening it hence at enumeration time. If this is not possible and has to be given by the user then one needs to find a nice way (or not too ugly) to do it. I have some ideas but I need to mature them a bit.

pavel-demin commented 5 years ago

why can't sdrangel also use the same ip in transmission?

This question is already answered in these two comments and in this issue.

In the current version, the transmission doesn't work with the SoapyRedPitaya module because SoapySDROutputThread doesn't fill its output data buffer when the data format is CF32.

f4exb commented 5 years ago

Soapy for Red Pitaya does not work and therefore is not an option:

SoapySDRUtil --args="driver=redpitaya,addr=192.168.1.40" --rate=1250000 --channels=0 --direction=RX
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Stream format: CF32
Num channels: 1
Element size: 8 bytes
Begin RX rate test at 1.25 Msps
Starting stream loop, press Ctrl+C to exit...
Error in rate test: sendCommand failed: 0

I get the same error trying to start the device in SDRangel (adding addr in kwargs):

2019-06-10 16:35:42.561 (D) DSPDeviceSourceEngine::gotoRunning:input message queue pending:  0
terminate called after throwing an instance of 'std::runtime_error'
2019-06-10 16:35:42.563 (D) SoapySDRInputGui::handleInputMessages: message: DSPSignalNotification
  what():  sendCommand failed: 0
2019-06-10 16:35:42.563 (D) SoapySDRInputGui::handleInputMessages: DSPSignalNotification: SampleRate:100000, CenterFrequency:20000000
Aborted (core dumped)
...
(gdb) bt
#0  0x00007faa7f2fae97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007faa7f2fc801 in __GI_abort () at abort.c:79
#2  0x00007faa7f951957 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007faa7f957ab6 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007faa7f957af1 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007faa7f957d24 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007faa184be85d in SoapyRedPitaya::activateStream(SoapySDR::Stream*, int, long long, unsigned long) () at /opt/install/SoapySDR/lib/SoapySDR/modules0.7/libRedPitaya.so
#7  0x00007faa2ff1d63c in SoapySDRInputThread::run() (this=0x7fa9f4005120) at /opt/build/sdrangel/plugins/samplesource/soapysdrinput/soapysdrinputthread.cpp:130
#8  0x00007faa7fcfa16d in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007faa7d2b66db in start_thread (arg=0x7faa09526700) at pthread_create.c:463
#10 0x00007faa7f3dd88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Exception thrown here: https://github.com/pothosware/SoapyRedPitaya/blob/3d576f83b3bde52104b2a88150516ca8c9a78c7a/SoapyRedPitaya.cpp#L522

satfan52 commented 5 years ago

Hey Edward, it will not work without installing first the SoapySDR RedPitaya module. After installing the module it should be OK. I was able to use the "redpitaya SDR transceiver" with Sdrangel in reception mode. It is also found without by SoapySDR Until after install the module

On Mon, 10 Jun 2019, 16:53 f4exb, notifications@github.com wrote:

Soapy for Red Pitaya does not work and therefore is not an option:

SoapySDRUtil --args="driver=redpitaya" --rate=1250000 --channels=0 --direction=RX ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

[ERROR] SoapySDR::loadModule(/opt/install/SoapySDR/lib/SoapySDR/modules0.7/libHackRFSupport.so) dlopen() failed: libhackrf.so.0: cannot open shared object file: No such file or directory [ERROR] SoapySDR::loadModule(/opt/install/SoapySDR/lib/SoapySDR/modules0.7/librtlsdrSupport.so) dlopen() failed: librtlsdr.so.0: cannot open shared object file: No such file or directory [ERROR] SoapySDR::loadModule(/opt/install/SoapySDR/lib/SoapySDR/modules0.7/libsdrPlaySupport.so) dlopen() failed: libmirsdrapi-rsp.so.2.13: cannot open shared object file: No such file or directory [ERROR] SoapySDR::loadModule(/opt/install/SoapySDR/lib/SoapySDR/modules0.7/libuhdSupport.so) dlopen() failed: libuhd.so.3.15.0: cannot open shared object file: No such file or directory Stream format: CF32 Num channels: 1 Element size: 8 bytes Begin RX rate test at 1.25 Msps Starting stream loop, press Ctrl+C to exit... Error in rate test: sendCommand failed: 0

I get the same error trying to start the device in SDRangel.

— 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=ADR72WKJF2O5RMU5SWERK4DPZZTGBA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKDJLA#issuecomment-500446380, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WKNQMPE3BVILJETTQ3PZZTGBANCNFSM4HNLZADA .

pavel-demin commented 5 years ago

Soapy for Red Pitaya does not work and therefore is not an option

I've recently tested the SoapyRedPitaya module with the latest PothosSDR version (2019.03.24). It works for both RX and TX without any problem.

Exception thrown here: https://github.com/pothosware/SoapyRedPitaya/blob/3d576f83b3bde52104b2a88150516ca8c9a78c7a/SoapyRedPitaya.cpp#L522

I'd suggest that you check that 192.168.1.40 is the correct address of your Red Pitaya board and that SDR transceiver application is running on your Red Pitaya board.

pavel-demin commented 5 years ago

BTW. I see that #345 is now closed and the fix is in 4.8.1. So, I suppose that SDRangel can now transmit using the SoapyRedPitaya module.

f4exb commented 5 years ago

...and that SDR transceiver application is running

Yes this is probably the issue. But I have no idea on how to run it moreover I cannot ssh to the RedPitaya which makes this "RedPity" adventure a total disaster. I think I will hide it somewhere deep in one of my drawers and forget about it.

pavel-demin commented 5 years ago

But I have no idea on how to run it moreover I cannot ssh to the RedPitaya which makes this "RedPity" adventure a total disaster.

Since the Red Pitaya board is designed as a universal tool with a network interface, it's slightly more difficult to use than a single function USB device. It requires a working network connection and it has a set of applications that should be started via its web interface.

The network configuration and the web interface are described at

https://redpitaya.readthedocs.io/en/latest/quickStart/connect/connect.html

If the network problems persist, I'd suggest to check the boot process and the IP address of the Red Pitaya board using the USB/serial console as explained at

https://redpitaya.readthedocs.io/en/latest/developerGuide/os/console/console.html

If the USB/serial console shows error messages during the boot, then most probably the problem is with the SD card and replacing the SD card often helps to solve this kind of problems.

Once you have access to the board's web interface, the SDR transceiver application can be installed via the application market place.

Otherwise, I'd suggest to try my SD card image that has all my applications already preinstalled:

http://pavel-demin.github.io/red-pitaya-notes/alpine/

pavel-demin commented 5 years ago

BTW. What model of Red Pitaya board are you using? 10-bit, 14-bit or 16-bit?

f4exb commented 5 years ago

I have the 16 bit model. I have seen the SD card image but the .zip does not look like an image that you flash to the SD using the dd command. It is the very collection of files and this does not make a bootable SD.

Regarding the SSH problem I found the solution but that's was bit tricky. It turns out that in the image I used which is the "official" one I suppose: https://redpitaya.readthedocs.io/en/latest/quickStart/SDcard/SDcard.html (there is only a beta available for the 16 bit version the stable link is broken) the keys in /etc/ssh are empty. It was obvious and I tried change the permissions before realizing that the file size was simply 0! All I needed to do is generate the keys logging via the USB console:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key

pavel-demin commented 5 years ago

I have the 16 bit model.

The SoapyRedPitaya module only works with the 10-bit and 14-bit models.

The right SD card image for the 16-bit board can be downloaded from

https://pavel-demin.github.io/stemlab-sdr-notes/alpine/

Currently, it's the only way to run my SDR applications on the 16-bit board.

It is the very collection of files and this does not make a bootable SD.

Just copy all the files and directories from the .zip file to a FAT formatted SD card. No dd command is needed.

pavel-demin commented 5 years ago

If you could add the HPSDR protocol to SDRAngel, then it'll allow to use SDRAngel with all the models of the Red Pitaya boards and other radios compatible with the HPSDR protocol such as Hermes, Hermes-Lite, etc.

BTW. The HPSDR protocol has a built-in auto discovery.

pavel-demin commented 5 years ago

Here is an implementation of the HPSDR protocol:

https://github.com/g0orx/linhpsdr/blob/master/protocol1.c https://github.com/g0orx/linhpsdr/blob/master/protocol1_discovery.c

f4exb commented 5 years ago

Just copy all the files and directories from the .zip file to a FAT formatted SD card. No dd command is needed.

It does not work and I still do not see how it would because you need some sort of special formatting in the MBR.

Else... I'll have a look at HPSDR as this could be an interesting addition.

pavel-demin commented 5 years ago

It does not work and I still do not see how it would because you need some sort of special formatting in the MBR.

The boot loader that comes with the ZYNQ chips is intelligent enough to read the FAT file system and find the required boot.bin file. You can find the commands that Xilinx recommends to run when preparing a micro SD card at the following link:

http://www.wiki.xilinx.com/Prepare+Boot+Medium

The following commands from these instructions create a FAT formatted partition and just copy boot.bin to this partition:

mkfs.vfat -F 32 -n boot /dev/sdX1

mkdir -p /mnt/boot
mount /dev/sdX1 /mnt/boot

cp boot.bin /mnt/boot/

So, copying boot.bin from a .zip file to a FAT formatted micro SD card is enough to make it bootable with the ZYNQ chips.

pavel-demin commented 5 years ago

I'll have a look at HPSDR as this could be an interesting addition.

For information. The HPSDR/Metis communication protocol is described in the following documents:

f4exb commented 5 years ago

I eventually got your software working on the RP preparing the SD card as mentioned in the Xilinx link (with a single FAT32 partition) and the right SD archive (I had a different one). I also verified the Hermes emulation was working with openHPSDRJ so I should be able to move on thanks!

satfan52 commented 5 years ago

Hey Edward 😊😂

Life is beatifull!

You do not need to ssh to the rp to start the sdr transceiver, things are not as complicated! The RP has a web interface, all you have to do is type the IP address of the RP in browser and from there you just click on the "SDR transceiver". Instead of the IP address can also use the identifier provided on the label attached to the ethernet port.

rp://something see your label

You need to be on the same subnet though otherwise it will not work (90 percent confidence)

If you really wanna ssh, just ssh the IP address of the RP and from there you can navigate in the apps folder, there are start and stop script you can launch. If you take the start script of the sdr transceiver and put it at the root of the SD card then the sdr transceiver will automatically start as soon as the rp is booted, turned on, so no need for all the webstuff to launch the SDR transceiver! You just boot the RP and the SDR transceiver is automatically launched!!!

On Mon, 10 Jun 2019, 20:46 f4exb, notifications@github.com wrote:

...and that SDR transceiver application is running Yes this is probably the issue. But I have no idea on how to run it moreover I cannot ssh to the RedPitaya which makes this "RedPity" adventure a total disaster. I think I will hide it somewhere deep in one of my drawers and forget about it.

— 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=ADR72WKN37NP5LNLX3OJXFDPZ2OOXA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK24EY#issuecomment-500542995, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WIMWFQX5JG3JYTWN7DPZ2OOXANCNFSM4HNLZADA .

satfan52 commented 5 years ago

The ssh password is "changeme"

On Tue, 11 Jun 2019, 09:28 Peter Ide-Kostic, pik138065@gmail.com wrote:

Hey Edward 😊😂

Life is beatifull!

You do not need to ssh to the rp to start the sdr transceiver, things are not as complicated! The RP has a web interface, all you have to do is type the IP address of the RP in browser and from there you just click on the "SDR transceiver". Instead of the IP address can also use the identifier provided on the label attached to the ethernet port.

rp://something see your label

You need to be on the same subnet though otherwise it will not work (90 percent confidence)

If you really wanna ssh, just ssh the IP address of the RP and from there you can navigate in the apps folder, there are start and stop script you can launch. If you take the start script of the sdr transceiver and put it at the root of the SD card then the sdr transceiver will automatically start as soon as the rp is booted, turned on, so no need for all the webstuff to launch the SDR transceiver! You just boot the RP and the SDR transceiver is automatically launched!!!

On Mon, 10 Jun 2019, 20:46 f4exb, notifications@github.com wrote:

...and that SDR transceiver application is running Yes this is probably the issue. But I have no idea on how to run it moreover I cannot ssh to the RedPitaya which makes this "RedPity" adventure a total disaster. I think I will hide it somewhere deep in one of my drawers and forget about it.

— 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=ADR72WKN37NP5LNLX3OJXFDPZ2OOXA5CNFSM4HNLZADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK24EY#issuecomment-500542995, or mute the thread https://github.com/notifications/unsubscribe-auth/ADR72WIMWFQX5JG3JYTWN7DPZ2OOXANCNFSM4HNLZADA .

pavel-demin commented 5 years ago

from there you just click on the "SDR transceiver"

The problem is that the Edouard's board is the latest 122.88-16 model. There is no "SDR transceiver" for this model.

satfan52 commented 5 years ago

that is really sad! :-(

Edward, I can borrow you my second 125-14 model so you can work on it! we can meet in Fredrieschaffen in two weeks if you want

satfan52 commented 5 years ago

of if you are in a hurry, i can ship it to you today.

satfan52 commented 5 years ago

I meant you can borrow me

f4exb commented 5 years ago

For the native solution I'd rather go for trying to work with the HPSDR protocol that can work not only for the RP.

For the Soapy thing I am going to open another ticket because in fact this is the more generic issue of giving the possibility to the user to specify "kwargs" at open time and this would cover RP and other possible cases. The audio parameters work a bit like that saving the audio parameters in the global presets so there are already some ideas. I do not necessarily need the hardware for such a simple thing (in theory). In fact the RP is listed by Soapy but without keyword parameters and this seems to be the issue since you would like to have addr=xxx.xxx.xxx.xxx. At open time it just says "I want to open the first device with redpitaya driver" and it does not appear to be enough.

f4exb commented 5 years ago

Considering how the Metis frame is structured and even if not all FPGA images are truly MIMO I think it will be supported as a MIMO device and therefore in the future v.5

f4exb commented 4 years ago

MIMO support (v5) is abandoned

satfan52 commented 4 years ago

Hello Edouart,

1) So no more native support for the 125-16 red-pitaya board then ? 2) No enhancements either to work around the famous detection issue with the redpitaya 122-14 board in the soapysdr environment ?

Thanks Regards Peter Regards Peter

satfan52 commented 4 years ago

Ok I just saw the soapysdr "qwark" enhancement went through (point 2 in my previous comment) went through. Many thanks, I will test very soon.

Regarding point 1, does that mean the new 122-16 board will only be supported via soapysdr (no native support like for the PlutoSDR for instance)

Many Thanks

f4exb commented 4 years ago

OK, I was in a storm last night because BladeRF2 support as a MIMO device still does not work. The handling of FIFOs has to be redesigned from the ground up. I will reopen this issue without the "v5" label but do not expect anything soon

satfan52 commented 4 years ago

Dear Edouart, It is a very good news for all redpitaya users that you are still open on the long run to attempt to provide native support for the 122-16 board (not to mention the other hermes/metis boards).

On the long run I would like to use SdrAngel for interfacing to both my plutosdr and my redpitaya and to use it as well in combination with wsjtx and other similar programs. Unless I am mistaken I don't think any SDR interface can do that yet under Linux (maybe Windows but switching from Linux to Windows is not an option for me)

Thank you again Regards Peter

f4exb / sdrangel

RedPitaya / HPSDR Metis support #344

Soapy SDR -- the SDR abstraction library