Underwater Networks Handbook

Agents offering the baseband service are most commonly modem drivers (and simulators). They support a set of messages and parameters that are explained below. Baseband service providers may also provide optional capabilities to send or record signals at a specified time, or based on premable detection.

Communication systems usually represent signals in a complex baseband representation, as this allows them to be sampled at a lower sampling rate than real passband signals. Passband signals have to be sampled at more than twice the highest frequency (Nyquist criterion). Baseband signals need to be sampled at more than twice the bandwidth. Since the bandwidth is typically much lesser than the carrier frequency, the baseband representation is usually more economical than the passband representation.

While the baseband service is aimed at signals represented in the complex baseband representation, it also supports signals represented as real passband samples. Such signals are identified by setting the fc (carrier frequency) field of the TxBasebandSignalReq or RxBasebandSignalNtf to 0. Modems offering the baseband service may optionally support passband signal transmission and recording.

Since Java and Groovy do not support complex numbers natively, the complex baseband signals are represented by an array of floats with alternate samples from the in-phase (real part) and quadrature (imaginary part) channels. In languages that support complex numbers (e.g. Python and Julia), the signals are represented as arrays (or lists) of complex numbers.

If all this seems to be confusing, don’t worry, it’ll become clear as we go through examples shortly.

In Section 2.7 , you already saw how to transmit and record arbitrary signals. We then used the convenience functions bbtx and bbrec for simplicity. In this chapter, we will do the same thing by sending the TxBasebandSignalReq and RecordBasebandSignalReq messages instead. As you’ll see, these messages provide you greater control, and can also be sent via the UnetSocket API or a fjåge gateway from external applications.

Fire up Unet audio to try out the examples here:

On the shell for the Unet audio SDOAM, check which agents provide the baseband service:

We can now direct all our requests to the phy agent. Let’s check the baseband parameters of the phy agent (we omit other parameters here for brevity):

We see that the Unet audio SDOAM operates at a carrier frequency of 12 kHz and a bandband sampling rate of 12 kSa/s. Let’s create a DC signal of length 12000 complex baseband samples (24000 floats) and transmit it. A DC signal of length 12000 complex samples with a carrier frequency of 12 kHz is a sinusoidal 12 kHz signal for 1 second.

You should hear the sound from your computer speaker.

Unet audio supports transmission of passband signals as well. Let us create a half second 2000 kHz passband signal and transmit it:

Next, let’s request a recording of 12000 samples (1 second duration):

You can also ask for recordings to begin at a specified time:

You’d have noticed the 6 second delay (5 seconds to begin recording, 1 more second to finish the recording) before the recording notification.

Interestingly, you can also request recordings in the past! Many modems have a short buffer, allowing recording in the recent past. Go too far in the past and the modem will refuse your request!

Specifying a negative recTime is understood by the baseband service provider as a relative time. So we can simpify our request to record 5 seconds in the past:

Each logical channel (CONTROL, DATA, etc.) is associated with a detection preamble. Detectors in a modem monitor incoming signals, and trigger when the preamble is detected.

We can transmit a preamble easily:

Here, we did not specify a signal to transmit, so only the preamble was transmitted. You should have heard the preamble as a short chirp from your computer speaker. If we had specified a signal, the preamble would have been followed by the signal.

If you had another Unet audio SDOAM running nearby, it would have heard the preamble and detected a CONTROL frame. It would have tried to decode the frame, but failed, as we didn’t actually transmit anything after the preamble. So you’d have seen a RxFrameStartNtf followed by a BadFrameNtf if you had subscribed to phy topic on that modem.

If you don’t have access to another computer to run Unet audio on, we can easily demonstrate the above behavior with a single Unet audio SDOAM by simply enabling the full-duplex mode (and hence using the same computer for transmission and reception simultaneously), as we did in Chapter 15 :

Preambles 1 and 2 are used by the CONTROL and DATA channel respectively. It’s better not to mess with these, but instead use preamble 3, which is left for the user to configure in Unet audio. By default, detection of preamble 3 is disabled. You can enable it by setting the detection threshold phy[3].threshold parameter. Let’s try it:

We see the RxFrameStartNtf of type #3 indicating that preamble 3 was detected. Since phy[3] is not associated with any modulation scheme (we set the modulation parameter to none ), the modem did not generate a BadFrameNtf as it did with preamble 1.

In applications such as sonar or ranging, we may only be interested in the detecting the timing of a known signal. In that case, the RxFrameStartNtf is sufficient for us. But in some applications, we may wish to capture the signal once detected. That can be easily achieved in Unet audio by setting the basebandRx parameter.

If you enable basebandRx , a recording will be triggered every time the preamble is detected:

The RxBasebandSignalNtf notified us of the recorded signal (containing just the detected preamble). If we wanted a longer recording after the preamble, we can ask for that using the basebandExtra parameter, specifying the length of the recording (in samples) beyond the preamble:

You can see that the recording is much longer now.

During the development of signal processing algorithms, one often wants to simply record received signals in the modem for postprocessing. For this, you could write a script to listen for RxBasebandSignalNtf messages from phy agent’s topic, and store them in a file. Since this requirement is common, UnetStack already provides an agent which does exactly this. The agent is called BasebandSignalMonitor or bbmon for short.

The bbmon agent is already loaded when you run Unet audio. However, by default, it is disabled. It’s easy to enable it:

Now, every RxBasebandSignalNtf that is sent to phy agent’s topic will be recorded in a signal-0.txt file in the logs folder.

As you record more signals, they are appended to the same file (with delineating metadata for each signal). If you restart Unet audio, this file will be renumbered to signals-1.txt , as the logs are rotated.

The signals file stores the signals in a base64 encoded format. The Python package arlpy.unet allows you to read this file and work with the signals in it:

In the previous section, we showed you how to record signals for postprocessing. This is great if you postprocessing is what you desire, but sometimes it is important to access the functionality in real time from Python. This is very useful while debugging new signal processing algorithms, since tools such as Jupyter notebooks and libraries such as numpy , scipy , pandas , arlpy , and many others have made Python the preferred platform for a lot of scientific computation.

Let’s try it!

You had already installed the Python package unetpy in Section 2.5 . We’ll be using it now, so in case you don’t have it installed, now is a good time to install it. Start a Jupyter new notebook with Python 3 and connect to your Unet audio instance:

Of course you could do the same thing with Julia or other languages, if you wish, with obvious minor changes to the syntax!