Apache Labs Community Forum

Hello Everyone,

I did some basic testing with pure signal2 (Thetis v2.9.0.6 x64 (4/23/22) (Protocol 2 v11.7) ) and an Anan 100D (Grey) connected to a dummy load.

As a newbie – I was trying to see the specific effects (and performance on the 100D) of PS2 and the associated “load” on the network and at the same time to see if there is a variance in PS2 performance in relation to output drive (given that the band frequency is constant).

My rationale was to determine if “network” load varies when PS2 is active and more importantly – what are the limitations and load of the network in ensuring an optimal (100%) operation.

As a first dive – when experimenting – I just realized that my PC was on a wireless network connection – albeit capable of 100MB – nevertheless – it was wireless.

I also notice some “glitches” in the PS2 operation.

At first, I could not determine why the glitches were happening and for the moment thought it was attributed to my configuration which I was creating.

After a while, I started to think about what I am exactly doing and how I am doing things, immediately realizing that I should make sure that BOTH the PC and Anan 100D are on the Gigabit switch – which they were not!

As soon as I put them on the same switch – no wireless – the performance improved – no glitches!

I then decided to do the PS2 “on” and PS2 “off” tests – and measure the network load.

I had the impression that most of the “processing” for the Adaptive Pre-Distortion (ADP) was taking place in the FPGA – however the increased network load (at least 50% more – jumped from 21.1Mbps to over 40.2Mbps) indicates that there is high level of “communication” taking place between the PC and the Anan – also with an associated increase in CPU utilization – in my case specifically CORE 1 of my 4 core (real) cpu.

What’s going one may ask?

I would guess that the PC is doing all the “heavy lifting” in running the PS2 code for the adaptation process. The “DATA” is obviously being generated (via the FPGA presumably) and sent to PC, then back to the FPGA) on the Anan and PC is processing – sending back to the Anan, etc. ,etc.
Sounds good – its working!

The warning here is that you MUST make sure your have a “rock solid” network connection and adequate bandwidth (in my case >> 40Mbps) for the PS2 to function without glitches.

Having discovered this “first hand” thanks to having an Anan 100D to experiment with, I just realized – from hearing various QSO’s from Anan owners having problems with their PS2 operation (all sort of sync and dropping problems) – and how they were struggling and obviously attributing blame to “flakey” PS2 software.

Well to the contrary – their problem stemmed from poor network performance – running Thetis on a capable Laptop – but via a poor wireless network.

So, I hope the above comments are useful to those of you still having some glitches with PS2 – CHECK YOUR NETWORK – make sure its good to go for at least 50Mbps – otherwise you will have problems!

The other interesting observation is the actual PS2 performance with the 2-tone test with respect to output power.

Here is a table of results – frequency used was 40M band 7.178Mhz – Observation was using 3rd Harmonic in relation to 1st Harmonic – RF Power used was 1W, 20W and 100W – to get a trend.

RF Power: 1W, 20W, 100W
Suppression: 31.8 dbm , 12.8 dbm, 23 dbm
Network Load increase when PS2 ON: 19.1Mbps, 19Mbps, 19.6Mbps

We can conclude the following; -

When PS2 is active there will be at least a 20Mbps increase (this was consistent within measurement errors) in network bandwidth – make sure your system(s) can handle this with sufficient headroom.

There is a “sweet spot” with PS2 – this is expected (and the limited sample results confirm this) – as each radio is different – in particular with the RF amplifier semiconductor nonlinearities (within the Anan finals as was in my case as no external Amp was used).

In my case there is a much better PS2 “efficiency result” with very low power – and again more efficient with higher power than in the 20W range (again my specific radio and limited results).


Below is a screen grab of one of the tests (1W – low power) with PS2 “on”
Hope someone finds this information useful

I certainly learned a lot by just doing these basic tests with a dummy load - most notable aspect being the "heavy traffic" on the network between the PC running Thetis and the Anan - when PS2 is active - confirming that all the heavy lifting with PS2 is done on the PC running Thetis.

You can now clearly see why the current Anan setup is not suitable for Remote operation via internet.

It will fail - because you will need a "solid" conection with at least 25Mbps continous no loss in packets AND at least 50Mbps when PS2 is running.

Unless you have extream internet speeds and can guarantee low latency (ping times) without packet loss - its highly unlikely that you will have trouble free operation whilst attempting to use the Anan remotely via an internet connection.

I hate to break it to you, but you are merely discovering what everyone already knows. And doing a good job of telling us all of your own journey of personal discovery

Except under very limited and tenuous circumstances you can't run Thetis (or PowerSDR) over Wi-Fi with anything approaching good performance.

Contrary to popular belief, the box you bought from Apache is not a radio, but merely the RF front end of a radio. Most of the radio is in Thetis. And the FPGA does very little other than housekeeping and the first IF conversions. Even the audio coming into or going out of the ANAN chassis goes to/comes from Thetis, and is not processed in the FPGA other than for routing to/from Thetis.

Since all processing other than the first (and only) IF conversions is done with Thetis on the PC, this is known as a "thick client" architecture. Such architectures require relatively high network bandwidth to move all that IF data. This is to be contrasted with, for example, the "thin client" architecture of the Flex radios. In the Flex there are both FPGA and GPP (general purpose processing) resources located in the radio that do all of the DSP processing and the SmartSDR software client is merely receiving/transmitting audio, control, and FFT data. This requires substantially less network bandwidth and is far more tolerant to any dropped or missing packets.

just to make things even more difficult, the openHPSDR communications protocol uses UDP for moving all audio, control and 1st IF data. UDP is a lossy protocol. Unlike TCP/IP, lost UDP packets are lost forever. Since each UDP data packet contains many samples of either audio or IF data, losing just one, especially an IF data packet, can create a noticeable glitch on receive or transmit. Hence a high quality, low latency, low contention network link is required. Those are not qualities found with Wi-Fi.

As for network bandwidth requirements, each receiver you instantiate requires its own IF stream to be sent from the FPGA. RX1 and RX2 are each a stream. More streams, more bandwidth. Add PureSignal to that and it is another stream that is a split off of the transmit IF data stream that is going to the DAC and sent back to Thetis. And before you ask "Why not just grab that data internal to Thetis, it's the same data, right?", the answer is that for PureSignal to work each ADC sample from the RX1 input (from the coupler) must be matched precisely to the corresponding outgoing DAC sample and delay compensation over the Ethernet link proved impossible to accomplish. There were too many variables and too many different network topologies that people might use (including Wi-Fi).

Hi Scott,

Just a stupid joke :

Fat (eg thick) clients against lean (eg thin) clients is still an open discussion. But remember flavour and taste is in the fat
(any good cook would say so).

73s

Phil FM5GB

<Huge groan at bad joke>

If the Thetis console was not such spaghetti we'd already have a client-server setup for openHPSDR. But nobody wants to tackle unraveling the knots and splitting Thetis into both a client and server piece. And I don't blame them, starting over would be easier!

However, it could be band-aided with a half-step. Only a client app needs to be developed and some audio and video transmit facilities added to Thetis. Thetis would remain as the server side app.

Consider that there is more than sufficient CAT control of Thetis for most operations so the new client could exploit that. Then add VBAN support to the client and Thetis for two-way, multi-channel audio. Finally add some means to transmit spectral display information from Thetis for the client to render.

w-u-2-o wrote:... Finally add some means to transmit spectral display information from Thetis for the client to render.

It's already there !

Sort of true, Walter. That would put the onus on the client to do the FFTs and format the displays. I'm suggesting to only send the resulting video info over to the client.

Video streaming is a little bit of problematic. An uncompressed screen of 1280x1024 pixel at 60 frames per second would take a bandwith of 1.887 Gbit/s.
.
The 192ks/s IQ stream need only 6.144 Mbit/s, no problem in the age of FTTH-Internet. It contains all infomation needed for Panadapter and Waterfall in full resolution and speed (a single FFT does both of them) as well as multiple subreceivers to demodulate any modes, even different ones simultaneously.

A compressed videostream would give you a high latency and likely artifacs (if you want a bandwith lower than IQ-Stream).

The FFT data would be something like 30*1024*2 bytes/sec or around 61,440 bytes/sec. Easily done over a loopback UDP socket.

Waterfall would be the same.

DL2XY wrote:Video streaming is a little bit of problematic. An uncompressed screen of 1280x1024 pixel at 60 frames per second would take a bandwith of 1.887 Gbit/s....A compressed videostream would give you a high latency and likely artifacs (if you want a bandwith lower than IQ-Stream).

Not at all. 8Mbit/s, low latency h.264 nets you a very nice, 30Hz, 720p image with <10ms latency (typical videoconferencing spec's).

Once you jump up above a 192KHz sampling rate going with a video CODEC approach becomes quite competitive. At 768KHz sampling it's a requirement. Even a 12 or 16Mbit/s bit rate for h.264 (higher resolutions) becomes competitive.

How does Flex do it?

Against better knowlage i had a try on video codec.
This is not what i want to look at!
Even at 25mbit/s (4 times the IQ-stream) the quality is not acceptable.

(Please explore the screenshots at 100% resolution)



Correction
That was a scaling problem. The capture app had scaled 1280x1024 to 720p and the decoder had scaled back to 1280x1024.

So it is possible to code and decode pixel exact, but at 60fps there is a massive CPU load on the source computer (hardware accelerated codec used) that leads to slow down thetis degrading framerate and provoking audio stutter.