Scientific Computing

A popular IDE for Julia (syntax highlighting, linting) is via the Julia plugin for Visual Studio code.

Radio Mobile Deluxe is free but not open source radio propagation Windows software that runs on Linux well via WINE. Installing Radio Mobile Deluxe is straightforward:

Download rmwcore.zip and extract to ~/rmw. Download English (or other) language code e.g. rmw1166eng.zip and extract to ~/rmw Install Visual Basic 6 runtime:

winetricks vb6run

Make a script ~/rmw.sh containing

#!/bin/sh

wine ~/rmw/rmweng.exe

Then:

chmod +x ~/rmw.sh

Create a new app icon by creating a file ~/.local/share/applications/rmw.desktop with contents:

#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Exec=wine ~/rmw/rmweng.exe
Name=Radio Mobile Deluxe

Use the Radio Mobile Deluxe menu shortcut or in Terminal

~/rmw.sh

Antenna Patterns

Radio Mobile Deluxe .ant antenna pattern files require Windows/DOS \r\n CRLF line endings even when run under WINE. Convert Unix LF line ending files with

unix2dos myfile.txt

When using Python to write text files in Linux, by default the line endings will be \n LF line endings. Force Python to write Windows/DOS CRLF from Linux when using functions with options such as:

numpy.savetxt(newline='\r\n')

That works across operating systems.

Radio Mobile Deluxe through version 11.6 does not reload modified .ant files. You must close/reopen the entire RMD program to reload a modified antenna pattern file.

err:module:import_dll Library MSVBVM60.DLL (which is needed by L"Z:\rmw\rmweng.exe") not found

Fix:

winetricks vb6run

Alternative open source wireless propagation software:

• Splat RF is also great for radio coverage prediction outdoors.
• PyLayers is for indoor site-specific radio coverage prediction, also suitable for UWB.

Many fonts support Unicode characters. To use a UTF8 character as text input to a program, find a language-appropriate font that works in a word processor such as LibreOffice. Enter the Unicode characters by any of:

• copy / paste
• Compose key
• enter hex code

At gasoline pumps in 5°F / -15°C weather, everyone was complaining that the pumps were unusably slow, just a few hundredths of a gallon per second. After everyone stopped pumping for 30 seconds, the system escaped vapor lock and pumping resumed as normal. Vapor lock implies high volatility gasoline has flashed to vapor somewhere in the suction pumping gas station system. Stopping pumping entirely allowed that portion of the system to cool, so the gasoline went back to liquid.

About 45 seconds into the video, we all stopped pumping, and when the video resumes, everyone is pumping normally. If at a fueling station and all the pumps are extremely slow, suggest that everyone stop for 30 seconds and then try again.

EPA regulations on summer fuel vapor pressure

Worthwhile mesh networked Wifi APs (a.k.a. “tri-band”) use a separate simultaneous channel for the backhaul.

Mesh networked Wifi AP should:

• use two simultaneous 5 GHz channels (one for backhaul/mesh, one for users)
• even better, use 60 GHz backhaul
• have a graphical screen/web interface that encourages users to reduce number of hops by tweaking AP location

In general Wifi APs should:

• be placed in inner rooms or the inner side of rooms away from windows.
• use wired, MoCA or powerline Ethernet connections to each AP.

Wifi APs should be placed (from most preferable to least preferable)

• in each high usage room (den, kitchen, bedroom), and place a Wifi AP at least every other room for large homes
• in smaller homes, one Wifi AP per home level, near the center of each level

5 GHz on all APs, enable 2.4 GHz only on ONE most central AP to account for IoT devices without 5 GHz.

Wifi AP Performance Notes

• We should always strive for wired Ethernet connections or MoCA to each AP as today’s best HomePlug and G.hn MIMO powerline Ethernet are much closer to 100 Mbps throughput instead of the 1000 Mbps displayed prominently on the package.
• Keep in mind the latency introduced by mesh networking and its impact on live streaming video.
• Wifi repeaters are even worse w.r.t. latency.

Related: WiFi channel, SSID, power best practices

FFmpeg can losslessly (without reencoding) concatenate videos, even in different container formats, as long as the codec is the same. If the codec is different between files (H.264 vs. FFV1) then you would instead need to reencode.

This method can be used for YouTube video uploads, where you want to join small video files into one big file without bothering with a video editor.

Concatenate same codec videos

This example assumes you have MP4 videos to concatenate. If you’re on Windows, you will need Windows Subsytem for Linux.

Create a specially formatted file listing files to convert.

for f in ./*.mp4; do echo "file '$f'" >> flist.txt; done

Concatenate:

ffmpeg -f concat -safe 0 -i flist.txt -c copy out.mp4

This produces out.mp4, which will be close to the sum of the file sizes. It’s not precisely the same number of bytes as the sum of the files, perhaps due to timestamping and metadata differences.

Notes

• -pattern_type glob -i '*.mp4' does NOT work because that’s for the input filter image2 ONLY!
• FFmpeg concatenate

Losslessly convert animated GIF to AVI for high-quality YouTube upload:

ffmpeg -i my.gif -c:v huffyuv my.avi

Working

Currently, lossless HuffYUV works for YouTube uploads. HuffYUV is a primitive lossless compression algorithm, but you don’t want YouTube to doubly-lossy encode a lossy input video.

NOT working

• ProRes: Video codec isn’t recognized by YouTube
• FFV1: Video is often heavily clipped horizontally, half the video panel is missing

Build FFmpeg from source:

git clone https://github.com/FFmpeg/FFmpeg

# Ubuntu
apt install autoconf automake build-essential libass-dev libfreetype6-dev libsdl2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo zlib1g-dev libfdk-aac-dev libx264-dev yasm libmp3lame-dev libopus-dev libvpx-dev libx265-dev

# example options
./configure --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-libpulse

make -j

make install

Related: install FFmpeg

This article is about improvised/first check methods to help make “sanity checks” when there is a question if something will work or why it’s not working. Live streaming with little ability to buffer needs more WiFi signal strength than general Web browsing or little logging sensors. Normally for good WiFi performance, a starting point is to have at least:

• 20 dB SNR
• -70 dBm RSSI (signal strength)

The signal levels mentioned here are relative and conceptual. Don’t design according to this highly simplified discussion alone!

A simple SNR estimate can be made by simply looking at desired WiFi signal strength and subtract the next strongest signal on your channel. For example, your WiFi is -68 dBm and there is another WiFi AP on or overlapping with your channel at -75 dBm, the SNR is no better than -68 - (-75) = 7 dB. This over-simplified calculation has significant error for RF congested environments, because it does not account for

• non-WiFi interference (microwave overs, baby monitors, Bluetooth, etc.) (makes SNR worse)
• channel occupancy time (is the unwanted co-channel WiFi unused, or are they streaming HD video (heavy utilization) (light usage of unwanted WiFi makes effective SNR better)

Here we assume a worst-case near-far problem, where CSMA/CA isn’t stopping conflicting transmissions because the unit is in the middle between the desired and undesired transmitters that can’t hear each other.

Real-life tests

A good 5 GHz AP was tested in an urban environment, with minimal traffic (late at night). The system configuration was a 40 MHz 5 GHz channel with a few other APs on channel, using Ubiquiti hardware with 20 dBm AP transmit power. The AP heard phone about 3 dB weaker than phone heard AP.

A cheap 2.4 GHz AP was tested with minimized environmental variation from outside or inside due to random human activity such as network loading, Bluetooth, microwave ovens, etc. AP was in adjacent office of commercial building, using a clear channel (no overlap/co-channel in test area), on a holiday (no microwave ovens/bluetooth etc. from employees).

Important factors not considered in this test include: latency, error rate, and increased loading due to transmission repeats. In many non-interference-free scenarios, streaming video dropouts may occur at these low signal levels. This is due to people moving about, trees waving, etc. causing signal variability. Log packet errors, transmission drops and signal levels. Rather than try to get big antennas for one AP, use multiple APs and allow beamforming to work. Whenever possible, 5 GHz is much better than 2.4 GHz for most use cases. Even if you’re at an isolated campground, visitors use WiFi-cellular gateways, baby monitors, microwave ovens and other 2.4 GHz devices, wiping out your 2.4 GHz premises monitoring system.

It’s important for wireless workers at all levels to remember principles of significant digits, especially when instrument and antenna calibrations have finite accuracies and the need to build in link budget margins to ensure sufficient reliability. Finer than 0.5 dB precision for field measurements, raises the question of measurement limits. Even 1-2 dB resolution is hard to achieve in real-world environments. The table above is generally indicative of trends, but each device has a couple dB ± accuracy between units of the same model, vs. temperature, etc. Keep in mind always that the environmental variability far dominates the instrument variability. It’s possible in urban environments on 2.4 GHz to have a -70 dBm signal and 5.5 Mbps raw connection speed. This is due to high activity on the channel.

WiFi noise floor

A fundamental factor for any radio receiver is the Johnson-Nyquist thermal noise floor. Assuming the system is designed so that the first receiver amplifier (typically called the low noise amplifier or LNA) dominates system performance, we can start with a simple system noise model that assumes a 20 MHz receiver bandwidth at 30 degrees Celsius.

P_noise = kTB

k is Boltzmann Constant, approximated as 1.38 x 10^-23. T is temperature in Kelvin, here taken as 300K ~ 27°C ~ 80°F. B is the equivalent receiver bandwidth [Hz].

The decibel expression is much more handy for computing ratios of power, which for convenience is expressed as power relative to one milliwatt “dBm”. Many times, just to help show that everyone is using the same reference point and units (dBm vs. dBW, say), kTB will be expressed as a constant in dBm with B=1 Hz. That is, noise power in dBm/Hz.

P_noise,B=1 = 1.38e-23 * 300 = 4.14 zW/Hz

Let’s go from zeptowatts to dBm:

P_noise,B=1 = 10*log10(4.14e-21) + 30 = -173.8 dBm/Hz

where the +30 factor converts from dBW to dBm. For a 802.11n 20 MHz channel, we can estimate the receiver thermal noise floor power as:

P_noise = -173.8 + 10*log10(20e6) = -100.8 dBm

This means an ideal WiFi 802.11n receiver will have a noise floor of about -101 dBm. Typical consumer WiFi gear will have a noise figure degrading (raising) this thermal noise floor by several dB.

Minimum WiFi SNR

A fundamental lower limit on minimum SNR for WiFi is set by the modulation type used. Assuming BPSK or QPSK is being used (MCS0, 1, 2) then 1% BER corresponds to about 4 dB E_b/N₀. Assuming a 3 dB noise figure for the receiver of the AP and unit, and assuming the transmitter powers are equal, it seems that about

-101 + 3 + 4 = -94 dBm

should be a rough lower limit for establishing a WiFi connection. The throughput as anyone has experienced at that signal level will be nil, but a WiFi connection can be established in the -94 dBm range. This analysis is oversimplified, because WiFi uses OFDM with numerous subcarriers operating in parallel.

Making a minimally useful WiFi connection requires a few dB more signal strength. If we believe the receive power indicator, -84 dBm seems to an approximate lower limit for actually being able to slowly download a website or buffer video.

Factors affecting the minimum viable WiFi signal include:

• ambient RF noise: microwave oven, Bluetooth, other WiFi traffic, baby monitors
• amount of other WiFi traffic: after-hours business vs. streaming HD video or torrents
• environmental variability: signal strengths are never constant. Desired and undesired signal strengths are always changing due to reflections from countless objects.
• equipment variability: performance of equipment varies from how it’s held, its temperature, etc.
• interference at one or both ends: If either end is in an interference area, the link is broken as both ends have to hear each other. This and the asymmetric data transfer are some reasons why we set AP transmit power a bit higher than the mobile devices.

With professional WiFi gear in greenfield (no interference) WiFi environments, I’ve seen 360p video streaming work acceptably, but with intermittent interruptions at -87 dBm. Would I ever design a system like that? No! I was merely surprised to see it actually usually working like that, but giving occasional signal loss alarms. The real question to ask when wanting to know if a system application will be viable is what is the minimum viable signal for the required data throughput and reliability factor.

To stream live video with occasional glitches at 360p in a clean RF environment, -77 dBm may be just enough signal allowing 10 dB for environmental variation. I can’t say it would not work, but I would be doubtful about how reliable it would be for clean uninterrupted no-glitch streaming for an hour.

To cover a warehouse on the edge of a rural town for bar code readers or temperature sensors and the budget was tight, it’s possible that -77 dBm is just enough, assuming temporary outages don’t impact the business or safety, and that outages are logged. Merely going in and designing a system for -65 dBm everywhere can be too expensive, and your competitor might get the bid instead. Know the characteristics of the system elements you design/support/sell/maintain. When you want to maximize performance vs. cost, you have to measure, experiment and log to verify your designs work in a wide variety of scenarios and to insure performance is met over time.

YouTube Live bandwidth requirements

Related: Manual WiFi AP config for better performance

In Windows Subsystem for Linux, printing via cups and scanning via xsane works fine for network-connected printer/scanner. For example, WSL works with networked Brother MFC devices. In general, Brother Linux printer/scanner support is very good. Generally it’s easier to setup a printer/scanner in Linux than Windows. A scanner that didn’t work on Windows might work from Windows Subsystem for Linux–on the same PC and Windows install.

We did not use DBUS. If you’re having trouble, it might help to try the printer with a computer running Ubuntu natively to see what’s up. I.e. it could be a faulty driver or a configuration step missing from the documents.

Install CUPS:

apt install cups

Then install the Linux printer driver.

For the scanner:

apt install xsane

Then install the Linux scanner driver.