Hi all,

I'm using SDR Console v3.0.23, PC with i7 CPU, 16GB Ram and the Pluto is connected to my local GBit network via USB-Ethernet adapter. While there is no issue when the Pluto is connected via USB, I'm experiencing dropouts of the TX signal when the Pluto is accessed via Ethernet.
Via Ethernet, RX is working without dropouts up to the maximum bandwitdth (resulting in some 200 MBit/s of network traffic), but TX signal is affected by dropouts, even at the lowest bandwidth. This is strange, as the total network load at lower bandwidth is noticebly lower with e.g. some 40 MBit/s on TX and RX at 1.2MHz bandwidth.

Apart from dropouts on the TX signal, there are some interruptions on RX also. The SRD Console logfile then records "Radio PlutoSDR> NOT Ready / Radio PlutoSDR> Ready".
The System Debug output shows overflow messages from "Pluto TX Send> CBackgroundThreadTX::SendOne". Playing around with transmit/receive buffer sizes, using different network adapters as well on the Pluto side as on the PC does not lead to a significant improvement - the smaller the buffer, the more dropouts.

Furthermore, the issue occurs when using the libiio.dll bundled with SDR Console v3.0.23 (which seems to be v0.17) as well as when using the current libiio.dll version 0.21.
Looking at the Wireshark recording may lead to the assumption that the issues occur when the PC starts sending its TCP stream to the Pluto. There are lots of errors and warnings in the Wireshark recording while there not a single error/warning when just using the RX path.

I've scanned the messages and found some entries dealing with TX dropouts which seemed to be related to Pluto being connected via USB, but I didn't find entries dealing with dropouts while working via Ethernet. Are there any experiences here in the group on using the Pluto for RX and TX via USB-Ethernet adapter?

Jean DJ0VL
        

Hello, Jean!

I'm currently trying it out using an Amazon FireTV ethernet adapter. I have an i7 and i5 both with Nvidia cards running Windows 10 64 bit. 24 and 8 GB of ram respectively. SDR Console v3.0.23. I have noticed some issues the first being a lower limit to the maximum bandwidth. Above 2.5 MHz things start to stutter. Not a big deal this is mostly the network adapter's limitation as It's only 100MB but it's plugged into a gigabit switch. USB only has no problem to 3MHz and beyond. Transmit works fine up to this point. If there are dropouts I haven't detected them. It might be good to ensure all the Ethernet hardware is ok. Crispy devices can be insidious. It sounds like your receive packet path is good or at least more tolerant of errors.

I do have major problems stopping and restarting the Pluto's connection or changing bandwidth without the receive stream breaking and sensitivity dropping. It seems to lose control of the receiver. This happens in firmware 30 or 31. Things get worse with PlutoWeb or F5OEO's custom firmware. I have to reboot a lot. Transmit seems to work still. This also happens with direct USB.

If I run tail /var/log/messages on the Pluto I get an interesting error message when connecting or disconnecting in firmware 31. Not sure if it's relevant:
user.err kernel: ad9361 spi0.0: ad9361_validate_enable_fir: Invalid: TAPS > 64 and Interpolation = 1

I thought I had a bad Pluto but the replacement had exactly the same problem so I'm thinking it's something else. Other programs like SDRAngel seem to work properly connected directly but it's hard to make comparisons this early. I'd be curious if you experience any of that as well.

Jayson
AA7NM

Also here's my SDR Console log. I do see a difference from Jean's in an error that pops up during tuning:

21:59:24.579: Radio PlutoSDR> Setting FIR filter = RX 3 GAIN 0 DEC 1 TX 3 GAIN 0 INT 1 0, 0 0, 0 1, 0 3, 0 5, 0...
21:59:24.579: Radio PlutoSDR> Error writing Channel attribute voltage_filter_fir_en = 1, error 22, Invalid argument

Hello Jayson,

Thank you for sharing your experience and for your hints. I understood
that transmitting is working for you at lower bandwidth despite using a
100 MBit/s network adapter. I concluded that there must be a network
issue in my setup causing the observed issues and network errors.
In order to eliminate most of the potential error causes, today I
started by connecting the Pluto directly to the PC and practically all
issues seemed to be gone. Even up to 3 MHz bandwidth, there were no
dropouts and no error entries in the SDR log and system debug log. This
is encouraging as it shows that the network operation is working in
principle.
The only issue that remains are some short audio interruptions directly
after switching TX on (e.g. by directly pressing the "tune" button), but
I remember having seen the same with the USB connection. These short
dropouts do not leave any trace in a log and I cannot see a network
issue in the Wireshark recording. Anyway, these are not very disturbing,
as they just occur immediately after turning on the TX.

With this in mind, I started searching for the culprit and identified
the switch as the bottleneck. My PC is directly attached to the router
while the Pluto is attached via a Netgear switch to the router.
Connecting both the Pluto and the PC via the Netgear switch leads to a
maximum of errors, connecting both directly to the router (using the
router switch) is slightly better, but still produces lots of dropouts
and overflow messages in the system debug log.
According to the specifications that Netgear switch has 128 Kb buffer,
this seems to be too little for this application. I assume there are
some issues with flowcontrol involved as well, as just receiving works
up to 200 Mbit/s with the same Netgear switch and the gigabit network
cannot be a limitation for the required bandwith of about 40 MBit/s in
each direction (working with 1.2 MHz SDR bandwidth).

I recently purchased a spare switch with 1.5 Mb buffer, connecting the
PC and the Pluto via that switch works without any issue. So my
conclusion is that Pluto can be operated via network, given the current
software configuration (probably libiio.dll in first place) there is a
need for switches with a large buffer as long as the Pluto is not
directly coupled to the PC. So I need to restructure my network
configuration, as I intend to move the Pluto to the tool shed in my garden.
I realize that remote operation (via public network) would not be an
easy task, as the operation on a local network isn't even straightforward.

With regards to your problems switching bandwidth I observed the same.
Changing the bandwidth leads to an interruption of some seconds,
however, I do not notice a sensitivity dropping. RX Gain is set to "slow
attack" and the input level remains unchanged when switching the
bandwidth (apart from the dropoff at the edges).
With F5OEO curstom firmware, the TX signal on GPO0 seems to get out of
sync under some conditions, e.g. when switching off the radio in SDR
Console while TX is on, the GPO0 remains set and gets only reset when
the radio is restarted again. Sometimes the TX switches on/off when the
radio is started.  

I do see the same entry "user.err kernel: ad9361 spi0.0:
ad9361_validate_enable_fir: Invalid: TAPS > 64 and Interpolation = 1" in
/var/log/messages, no idea if this is relevant.

Regarding the console log send in the other reply from you, I think I've
seen that error message sporadically as well. There is an error "Error
writing Channel attribute hardwaregain = 26, error 95, Unknown error"
that seems to be generated on every start of the radio.
Your log shows some entries like: "23:39:07.472: USB Notification:
Device Unknown, A device has been added to or removed from the system."
I've experienced the same when connecting the Pluto via an old USB2 hub
and operating on higher bandwidth. I believe this is an indication of a
USB communication issue. I didn't get these entries when the Pluto is
directly connected to a USB port of the PC.

Jean
DJ0VL

They do like fast network performance possibly a dedicated link. My setup is connected through a Dlink switch in the shack which has only 128kb cache. It works great in the shack but if I go to the other end of the house there's another switch or two plus a media converter with more traffic and maybe even wifi so then it does not work so well. Only low bandwidth. My testing is mostly limited to the shack so far as I don't have a satellite to aim at (I wish) but I have some ideas.

That windows system has multiple USB devices and there's chances of an intermittent RTLSDR, a weak USB port on the computer, and me physically bumping things loose while testing. Most things are plugged into powered hubs. It's not happening with the Pluto. There may also have been errors from times I was trying to connect while the Pluto was still booting up one way or another.

SDR Console will connect with the Pluto Web firmware after starting SoapyRemote but the tuner starts with the receive issue immediately so it isn't really usable. I have not tried transmit. OpenWebRX works as does dump 1090.  F5OEO's DATV bleeding edge firmware will work about the same as the stock firmware but the receive also breaks in SDRC with a large jump in tuning. Small steps or changing with direct frequency entry is ok. Transmit works including sending DATV streams from OBS or my phone. I haven't tested the stable build yet.

I also appreciate your experience Jean. I'm glad to know I'm not the only one seeing some of these issues. My biggest concern was defective hardware. I have some parts for the TCXO and PTT modifications but I don't want to void the warranty unless I'm sure they worked properly to begin with.

Jayson
AA7NM

Meanwhile, I got TX working with the Netgear switch as well. The assumption of a flowcontrol issue showed to be right, that old Netgear switch (GS105E) has IEEE 802.3x flowcontrol disabled by default. So far, I just operated some printer via this switch so that this never was an issue. After activiating the flowcontrol and connecting both PC and Pluto to the switch, the transmission dropouts are gone at all bandwidths, apart from some short bursts during the first seconds after switching on TX. These seem to come out of the Pluto itself, as there is no trace in a log and no irregularity in the Wireshark recording.

I also appreciate your experience Jayson, as it led me to search and find network issues. I did already void my Pluto warranty by desoldering the XO and adding a connection plug tor a small PCB with the PTT switching relay. I did not replace the XO by a TCXO, but I added a U.FL socket so that I can feed in an external reference. Stability and accuracy of a TCXO (even the 0.1 ppm variants) did not satisfy my requirements, so I feed in a 40MHz VCTCXO signal locked to a GPS synced 5 or 10 MHz OCXO. If you like, I can share related experience, you can also find some discussions about issues with TCXOs in the amsat-dl.org forum. The main (not so obvious) issues arise if the TCXO signal amplitude does not fulfil the AD9393 XTALN requirement, leading to spurs in the TX signal.  

Jean
DJ0VL

I'm going to replace the network adapter with gigabit USB to improve throughput. I have some LTV-354T optocouplers to connect directly across GPIO 0 and 1 for PTT. It should be enough to switch a relay or controller input.

The TCXO boards are recommended by others but I don't know about that potential issue. I have a 10MHz sine wave GPSDO I use with a hackRF that works though it should be a square wave. If there's an easy way to convert to an input I could use with the Pluto I'd definitely be interested.

Jayson
AA7NM

I've seen that some OMs directly connected an LVT-354T to the GPOs. Probably works, but I would not feed comfortable with connecting a diode directly to an logic output port without current limiting. I designed a small PCB with a transistor driving the relay. 

The main issue with the recommended TCXOs is the output amplitude (the other issue is phase noise). The stock XO delivers nearly 1.8Vpp square output while e.g. the often named Abracon TCXO delivers a 0.8Vpp clipped sinus output. The AD9363 input requirment is 1.3Vpp, the adaption is implemented in the Pluto by a capacitive voltage divider. As the XTLAN input seems to be a logic input, the switching level may just be reached on the crest of the clipped 0.8Vpp sinus. This may lead to timing jitter resulting in spurs, poor phase noise etc. due to the low slew rate at the switching level. The AD9364 reference manual clearly states that a high slew rate on the XTALN input is required for best performance. The 0.8Vpp clipped sinewave output level of typically used TCXOs seems to be borderline, as it works for some or most of the Plutos, but there are many reports about spurs that appear after TCXO modifications.

I'm not aware of an easy way to generate 40Mhz out of the 10Mhz GPSDO output, but this depends on what you call an easy way. For my usage, I designed a low noise PLL driving a 40MHz VCTCXO that is locked to a 5MHz or 10MHz GPSDO output. It includes a level shifter to provide a squarewave with 1.8Vpp to the Pluto. A more simple way is to use a PLL-synthesizer chip like the SI5351a with the drawback of a poorer output signal quality with regards to phase noise. With a 50 Ohm load, the Si5351a can be configured to deliver the required output level.

According to the data sheet, you can feed in a 10MHz signal to the AD9363 (with a modified Pluto configuration file). As I saw problems reports when using a 10MHz reference, I did not try it out. 
   
Jean
DJ0VL 

Good to know the details for the AD9363 input. I had thought I might use some sort of clock synthesizer like a Si5351a to get the required frequency and waveform. There's lot of boards for that. I could ultimately just invest in another GPSDO as the one I have is pretty basic. Leo Bodnar has some nice customizable outputs and is popular in a lot of stations.

I have noted a variety of ways of achieving PTT from a small circuit board to dead bug transistors. The LVT-354T direct connection is very simple but yes with that potential risk. Finding available boards is a limitation and I haven't had time to build one myself. But I'm not in a hurry. I'm going to leave it as is for now and try some other programs to see how it goes.
Thanks for the information!

Jayson
AA7NM

The Si5351a works quite well if you use integer divisors, but do not expect any miracles from a $1 chip. As soon as you use fractional-N divisors, spurs show up on the output signal. I did play around quite a while with the SI5351a as a first setup to generate the 25MHz reference signal for the qo-100 RX LNB, however the phase noise gots visible on strong signals due to the x390 multiplacation of the LNB PLL. As there is no information available on the internal PLL and phase comparator, I do not know the  amount of performance degradation when feeding in a 10MHz reference signal instead of using a 25-27MHz XTAL as specified by the datasheet.  

The Leo Bodnar GPSDO is quite popular among Pluto users and is a great device if you need programmable outputs. As is is build around a VCTCXO and a fractional-N synthesizer, I would personally prefer an OCXO based GPSDO if just a single 10MHz output is required.

Jean
DJ0VL 

If you have a bit of time, I'm working on a board containing all these features.

The first prototype will be finished in the next days. If you are interested in you can contact me.


--
Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.

you can get ready to use ptt board from batc

but you allso can make a similar circuit on an experimentors board within minutes

relay with protection diode, 2 transistors, 2 resistors ...

should be easy to find the parts in the junk box hi hi

greetz sigi dg9bfc

Likely it is power supply related. The micro-USB connector is a horror in my experience. Cables go defective just sitting there. Wiggling the connectors results in device reinitialization. And so forth.

{^_^}

Hi Nils,

As long as my LAN problems persisted, I experienced some waterfall freezes as well, but they were temporary and did not last more than a few seconds. They were always mapped to pairs of entries  "Radio PlutoSDR> NOT Ready / Radio PlutoSDR> Ready" in the logfile. Do you see those pairs of messages in your logfile as well? If the time difference between not ready and ready is just some milliseconds, the issue is not due to power interruptions, as rebooting and getting ready on the network takes some seconds.

To narrow down the problem, you can log your network traffic with Wireshark and look for evidence of network problems like errors/warning/repeating packets etc.

Did you enable System Debugger Diagnosis in the Audio options menu? Maybe you can get additional hints from some System Debug entries.

If you are using GPU support and run other programms in parallel that also make usage of the GPU, this may lead to some stuttering of the waterfall as well. While this slows down the response, it does not crash the program.

73 de Jean DJ0VL

Hello jdow and Jean,
thanks for your hints. 

jdow, I have not noticed any reboot activiies by the Pluto yet, but maybe missed it.

Jean, I have saved only one log file up to now. At the end of this log file I found "Radio PlutoSDR> NOT Ready" as third-last entry, but no "Radio PlutoSDR> Ready". At restart of SDR Console the Pluto answered as usual, but I do not know for sure, if the Pluto had or had not rebooted in the meantime. 
At least in the "case 1" freezes I assume no reboot of the Pluto, because the setup worked again very quickly.
I will do further investigations, following your hint to enable the System Debugger Diagnosis. I will report my results here.

Any further comments are welcome.
tnx es 73 de Nils DHØHAN

Do you have an external power supply on your Pluto? If not you might consider adding that second USB for additional power.
{^_^}

hello Nils

did you add the ground bridge over L7??

dg9bfc sigi