Previous page (Recording) <------- Back to index


Advanced

This section is a sort of appendix containing in-depth information on particular topics, some of them already mentioned in other sections, some not.


Test patterns

This is not a physical device but an internal functions generator. It has been created for development purposes, to generate pseudo-echoes to test the event detection, screenshots, dumps, reporting etc.

Depending of the acquisition mode selected in Output tab, this device generates different functions:

If Continuous mode is selected, this device generates a fixed frequency sinewave with frequency equal to a third of the sample rate and amplitude proportional RF gain (+127 with RF gain 100%). Being the resolution 8+8 bits (I+Q) this means the I component varies from -128 to +127 while the Q component is always zero.

test_patterns_continuous

If Periodic mode is selected, this device generates a sweeping wave with frequency starting from zero to the tuned frequency increasing quickly.

test_patterns_periodic

If Automatic mode is selected, this device generates pulses with a certain randomness in duration and size that should trigger the capturing mechanism and generate a screenshot in a way similar to the capture of a real echo.

echoes_running

By default the tuning is set half the sample rate and cannot be changed, while on waterfall window the Freq. zoom slider is set to 1.0X (the default) and Freq. offset is set to zero by default but both can be adjusted.


Dongle servers and clients

Besides physical dongles, in the Device list can now appear dongle servers too (UDP server...). This pseudo-device appears if in preferences tab a server address has been specified different from 0.0.0.0. It can be the IP address of another machine running Echoes or the localhost address (127.0.0.1) in case the same machine runs more Echoes instances.

The purpose of running more instances on the same machine is to run simultaneously more waterfalls with different timing, power, bandwidth parameters. When a Echoes instance connects a dongle server, that instance becomes a Dongle client. An example of the results is showed below. The first image is a screenshot taken in automatic mode with a 10ms scan speed, so with a waterfall coverage about 5s half of the echo has been cut out. The client instance instead, running at 50ms has been able to capture its full length.

server_ex

client_ex

Dongle clients inherit the settings in Device tab from the server (except the connected device name): sample rate, tune, gain and error compensation will be set on the client from the server. If one or more of these controls are changed on the server, the client gets the same modifications.

All the remaining settings in other main window's tabs can be freely changed.

client_server

A server won't send anything on the net until a client instance announces itself; this happens when the client starts the acquisition. After announcing, the client receives from the server the Device tab settings then the samples flux starts.

When the server stops the acquisition for any reason (manual stop or midnight swap) the client acquisition freezes waiting for samples without stopping. So when the server acquisition restarts, the client too resumes acquisition.

The midnight swap occurs on servers and clients. If the Echoes instances run on the same machine, it's advisable to define different working directories or different configuration files to avoid messing up the archive with file overlapping.

Finally, the following caveats should be considered when playing with multiple instances.

  1. The server should start first, because the client at startup checks if a server instance is up with acquisition running. If not, the UDP device won't appear in client's device list. If the sessions are started with a script or batch file, on the same machine, the clients should start cadenced, i.e. the client starts 10 seconds after the server.

  2. The server's firewall must be configured to accept incoming messages on port 12345/udp (or any other UDP port you set in preferences tab)
  3. The resolution set on clients cannot be higher than server's, so the resolution control on clients is disabled. In FFT tab, only the downsampling frequency and the window type can be selected.

  4. It's safer to perform device and FFT parameters change only when both server and client are stopped, to avoid raising exceptions. The protocol is very simple and cannot support changes 'on the fly' at server's side.

Note: being UDP-based, this way of sharing samples is simple and fast but is not suited for worldwide sharing. SoapyRemote that is TCP-based could be a better solution for that.

Automatic mode thresholds setup

A client and a server running on the same station can be very useful to set up the right thresholds to run a station in automatic mode.

First, let's prepare a dongle server configured in periodic acquisition then a dongle client connected to the server and configured in automatic acquisition and the same refresh interval set on the server.

The server will capture screenshots at regular cadence; the best is to set in Output tab, data dump coverage the same value displayed in waterfall as Waterfall coverage in order to get a long series of contiguous screenshots. The client should shot only on events. After some hours running, the periodic screenshots will show a certain number of echoes. The thresholds on the client should be adjusted until the echoes caught will match the ones seen on periodic screenshots.


Previous page (Recording) <------- Back to index