Scientific Computing

Best practices WiFi AP channel, power

Some starting points for WiFi networks

  • 5 GHz AP transmit power: 18 dBm
  • 2.4 GHz: only 1/4 of APs 2.4 GHz enabled.
  • 2.4 GHz AP transmit power: 13 dBm
  • manually pick channels for least overlap
  • consider DFS channels for interior locations where best performance (clearest channels) are desired
  • 40 MHz channel (VHT40) on 5 GHz, 20 MHz channel (HT20) on 2.4 GHz

Commercial Wifi systems have automatic power adjustment routines that estimate the optimum power levels for best handoff while avoiding co-channel interference. You might choose to set your Wifi AP transmit power manually to get better control of your network. This can really help mobile users where devices try to hang on to the more distant Wifi AP instead of roaming.

The exact Wifi AP transmit power level depends on the devices you prioritize. For mobile phones, Wifi AP transmit power in the 18-20 dBm range is a good starting point. Increasing power increases download data bandwidth, but if it causes your phone to hang on too long, upload errors increase dramatically and you will experience bad two-way video connections. As network density increases to commercial level (hotels, schools), it’s even more important to use 5 GHz only and lower Wifi AP transmit power.

In the extreme case of several hundred person lecture hall, you may need:

  • two to four 5 GHz Wifi AP (as traffic demands). Note that excessive AP density causes problems from too much channel reuse.

  • 40 MHz channels

  • transmit power: 10-13 dBm

  • APs high on wall or tripod, facing down on crowd, in farthest corners of room for least overlap.

  • Business hotels: Wifi AP in each room (or one per pair of adjoining rooms), 5 GHz, 6-10 dBm transmit power.

  • Casual hotels: might serve 4-8 rooms with a 10-15 dBm transmit power 5 GHz Wifi AP.

Wifi network planning

Do NOT pick different SSIDs for each AP, floor, room, etc. This limits the ability of the device to pick the best AP. Put all the guests/customers on one Hotspot 2.0 SSID, and using VLAN put internal stuff (sensors, control, admin) on another SSID. Two or three SSIDs (public/private) should be adequate. Complicated networks like hospitals may need to partition users into 3 VLANs/SSIDs. Do not use more than 4 SSIDs to avoid wasting data bandwidth on SSID broadcasts.

Channel selection:

  • Maximize physical distance between co-channel APs.
  • Only 1 of every 4 or 8 Wifi APs might have 2.4 GHz enabled with 20 MHz bandwidth on channel 1, 6 or 11 ONLY.
  • Auto-channel Wifi APs will act based on what they can hear, which may be very different than what your clients can hear. High end professional systems from Cisco and Meraki do a better job than the average AP at guessing the right channel since they use more sophisticated measurement and analysis.
  • Site survey: Consider InSSIDer or AirSpy.
  • Set the APs on lower floors and middle of the building to channels that are more in use in adjacent (not controlled by you) Wifi APs. Set the APs in busier traffic areas to the clearest channels.
  • You can play tricks like reusing channels from low-traffic APs (say a loading dock–manual bar code scanners don’t take that much bandwidth) more closely physically spaced than usual.

Channel width:

  • Use only 20 or 40 MHz channels on 5 GHz. Increased interference on 80 MHz or 160 MHz in urban areas leads to ineffectiveness.
  • Because of the difference between raw channel rate and throughput, even if you have a 100 Mbps throughput connection to the AP (such as via MoCA 2.0/2.5 or Powerline Ethernet AV2/G.hn) 40 MHz channels can still more than double your Wifi throughput vs. 20 MHz channels on 5 GHz
  • 20 MHz ONLY on 2.4 GHz

The only time I could think of using 40 MHz on 2.4 GHz is on a farm in a barn or shed, away from other buildings and with one AP serving the whole building.

The only place I would consider 80 MHz for 5 GHz is for single-room service in a rural home office or personal “cave”, isolated from neighbors and the rest of the home, with lowest power 10 dBm for just that room.

For home entertainment or gaming systems the ultimate networking performance comes from either:

  • having a 5 GHz AP in the same room
  • having a wired Ethernet connection (or MoCA or Powerline Ethernet)

Related: Using WiFi at very low signal strength

Get email upon changed IP address

Setup a cron script to check for changed IP address at reboot and each hour. Uses mailutils to setup an email server on your PC.

Note: intended for devices with IPv6/IPv4 public internet addresses.

Install email dæmon

apt install mailutils

Test email dæmon. Port 25 is blocked by many home ISPs.

echo "testing" | mail -s "test" my@email.address

Check /var/log/mail.log for Connection timed out errors that may indicate port 25 is blocked by your ISP. You might config for port 587 in that case.

Create executable ~/checkIP.sh

#!/usr/bin/env bash

set -o nounset
emailaddr=$1

CurIP=$(hostname -I | tr -d [:space:])

OldIP=$(tr ' ' '\n' < ~/.current_ip) #space to \n for consistency

if [[ ${CurIP} != ${OldIP} ]]; then
    echo -e "IP change detected\n $CurIP \n $OldIP"
    echo "New IP address: ${CurIP} (old address: ${OldIP} )" | mail -s "IP address change: $(hostname)" "$emailaddr"
    echo -e "${CurIP}" > ~/.current_ip
fi

be sure it’s executable

chmod +x ~/checkIP.sh

Edit your cron schedule

crontab -e

add at the top:

SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin

add at the bottom:

@reboot ~/checkIP.sh my@email.address
@hourly ~/checkIP.sh my@email.address

Red Pitaya radar firmware discussion

Since the August 2017 eclipse, Pavel has made numerous improvements to the FPGA firmware and associated C code. The particularly interesting changes are those enabling easy GPS 1PPS input. An interesting question is does the clock synchronize to 1PPS or instead tag the data at the pulse? It seems the latter is more likely at first guess.

Radar firmware/software: start with Pavel’s radar project.

The basic idea is to:

  1. setup a virtual machine
  2. install Vivado
  3. compile & create an SD card image like the LED blinker example

Pavel’s commit adds the trigger logic to the radar projects. However, we experienced problems with radar.c

The server outputs Bus error when it reaches these lines. It stems from the sts (status) AXI, communication pathway.

Pavel said:

The error that you observe is expected. The radar.c code should be modified to adapt it to the radar FPGA configuration. In its current state, radar.c is mostly a copy of a code from an SDR project that I never tested with the radar FPGA configuration.

Verify hard drive write speed using dd

This quick benchmark verifies a remote USB HDD is performing as USB 3. A malfunctioning drive may show as USB 3 in USBview, yet write at USB 2 speeds. This technique works on Unix-like OS.

Typical USB HDD write speed:

  • USB 2 hard limit: 60 MB/s by the 480 Mb/s raw USB 2 speed.
  • real-world USB 2 HDD speed: 30-40 MB/s sequential write

In contrast, USB 3 HDD are limited by the magnetic hard drive speed with today’s hard drives, provided your chipset drivers aren’t messed up. If Windows fails to load the USB 3 drivers for an HDD the drive operates at USB 2 speeds, which is easily detected with this test. Because of numerous caches from the CPU to the drive itself, using a simple method like this will not give precise results.

Write speed for big files is a test of sequential write speed. Sequential write speed is important for many remote sensing problems, which are by definition often a time series of data.

dd if=/dev/zero of=${TMPDIR}/junk bs=1G count=4 oflag=dsync

That command writes 4 GB sequentially.

  • USB 3 HDD: > 80-100 MB/s
  • USB 2 HDD: < 60 MB/s

We have not yet determined a way to get a usable estimate of read speed with dd. The fdatasync, dsync, etc. options don’t seem to work on read.

Programs that formally benchmark drive speed include:

Get computer info from Terminal

Linux has several tools to get computer information from Terminal, including over SSH.

USB device lists are available to detect newly plugged or existing devices.

General computer info is obtained by:

dmidecode

dmidecode gives useful computer information from the Linux terminal, including over SSH. dmidecode can help in remote asset tracking and verification of Linux computers.

-t
selects type of dmidecode info. See man dmidecode for more categories 0-255.
  • Motherboard model # and serial #: dmidecode -t 2
  • BIOS version: dmidecode -t 0
  • CPU capabilities: dmidecode -t 4
  • CPU cache memory: dmidecode -t 7
  • RAM capability (maximum RAM): dmidecode -t 16
  • RAM installed: dmidecode -t 17

To determine CPU speed on Linux use powertop and tab over to frequency stats to see percent of time overall CPU and each core is in a particular speed and state. Getting point measurements isn’t as useful to me as modern CPUs are constantly switching state.

For BSD, get reports of CPU temperature and current speed with

systemctl dev.cpu

Storage info is revealed by

lsblk

lsblk gives a tree view of connected storage, including: hard drives, SD cards, DVD/CD, USB drives, etc. This includes drives that are not mounted. Use lsblk when writing an SD card to setup a Raspberry Pi for example.

On BSD,

camcontrol devlist

gives hard drive device names like lsblk on Linux. /dev/ada0 is a common BSD HDD name.

To control HDD spindown time,

ataidle -I 30 /dev/ada0

-I 30 sets spindown time (after HDD unused this many minutes, spindown, here 30 minutes)

Shows basic status for WiFi:

iwconfig

iw dev wlan0 station dump

gives more advanced information. wlan0 is the Wifi card interface name Typically, wireless cards including WiFi are on the PCI bus. Unless of course you have a USB WiFi adapter. The wireless/WiFi chipsets can typically be identified by

lspci | grep -i wireless

Rename Ethernet interfaces to eth0

systemd in Debian & Ubuntu generates robust Ethernet interface names like p1p1 or enp48a instead of the traditional eth0 to avoid race conditions.

Robust systemd eth0 | wlan0: Create a file /etc/systemd/network/10-eth0.link with the content, using Raspberry Pi MAC address from ip a:

[Match]
MACAddress=00:11:22:33:44:55

[Link]
Name=eth0

Ensure the file /etc/systemd/network/99-default.link exists with the content

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent

This may be more intuitive than using udev rules, which is another alternative method.


Alternative GRUB: This method is simpler, but does not work on non-GRUB hardware (e.g. ARM systems like Raspberry Pi).

Edit /etc/default/grub:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

In Terminal,

update-grub

Reboot and type

ip a

to confirm network adapter is at eth0


When is eth0 name needed? Some old software (e.g. old Matlab versions) will only accept eth0 for licensing using the MAC address (low security!) Also sometimes for convenience in embedded/IoT systems where you know you’ll only have one Ethernet interface, you’d like to simply use eth0.

FMeXtra/VuCAST vs. HD Radio

FMeXtra can use 20% or 30% of the FM modulation, making up to 110% or 82.5 kHz deviation.

Main channel SCA modulation
mono 30 %
stereo 20 %

From Radio World reporting, the one-time cost of FMeXtra was ~ $10K, with no periodic licensing fees. The FMeXtra receivers were to be of comparable cost to HD Radio receivers; in fact the proposed FMeXtra receivers could also decode HD Radio, DRM, DAB, etc.

That seems like a great deal, and the Radio World testing showed that for 20% modulation depth, FMeXtra coverage was roughly comparable to -20 dBc HD Radio. So why did FMeXtra/VuCast fail to be adopted?

FMeXtra ROI

In effect we’re discussing energy/bit, which translates into energy/revenue for broadcasters. The most typical mode FMeXtra would be used in would be the mode preserving FM analog stereo and RDS, while precluding analog SCA. Thus, 62.5-98.5 kHz baseband in the lu;rds mode yielding 48 kbps, which could be split into 4 audio streams of low mono fidelity or 2 streams of medium fidelity or 1 stream of good fidelity (not quite high fidelity).

In comparison, HD Radio offers 96-120 kbps in hybrid and extended hybrid modes respectively. WCSP in Washington, D.C. with 4 digital subchannels has good audio quality. Music stations with 2 digital subchannels generally have good music audio quality, particularly as compared to the high artifacts of the old codecs used by Sirius XM SDARS satellite radio.

To make a digital transition worthwhile for the broadcaster and the listeners, there must be additional digital audio streams of at least FM stereo quality. That is, the sales staff must be able to sell advertisers on additional audio streams. Generally listeners are OK with analog FM on modern receivers that employ DSP stereo blending and diversity receive antennas, but prefer the clarity of 48-64 kbps AAC audio. HD Radio is an improvement in audio quality over analog FM, particularly in multipath prone urban environments, but what drives listeners to buy a new digital FM radio is extra subchannels.

RF bandwidth for FMeXtra vs. HD Radio: FMeXtra adds one additional music channel at 48 kbps. For talk subchannels, at least 16-24 kbps is preferred. HD Radio gives a high quality digital copy of the analog channel and adds a second high quality digital channel, or gives two additional digital-only music channels. HD Radio transmitter basic install is ~ $50K. So for about 4 times the capital cost for HD Radio over FMeXtra, the broadcaster gets 2.5 times the digital bitrate.

The appeal of RDS is the ability to build station affinity by showing callsign, current song playing, station phone #, etc. at least than $400 broadcaster hardware cost, while nearly every modern automotive receiver will display RDS as well as cell phones, the main means of FM listening. To invest $10K in FMeXtra, with no current receiver availability, is a non-starter, perpetuating the chicken and egg program of FMeXtra.

Back to the energy/bit argument, with HD Radio’s extended hybrid 120 kbps available for audio, the sales staff has 4 medium fidelity subchannels + 1 analog subchannel. Or, 1 analog + 2 high fidelity subchannels. What happens in urban areas is that a station will sell 1 or 2 medium fidelity subchannels to foreign language programming or talk radio that would normally be on an AM station + one medium-high fidelity copy of their analog channel. Or, one high fidelity copy of analog channel + one high fidelity second music channel.

FMeXtra in the same scenario adds two foreign language or talk radio or one music without helping the existing analog. FMeXtra has in effect one less music subchannel to sell vs. HD Radio–and that lost relative revenue keeps accumulating. Stations also get the benefit of more reliable modern equipment when upgrading, more amenable to remote operations and maintenance. The affluent customers reached first by HD Radio could demand higher CPM (advertising rates).

Successful ROI has been achieved by FM HD Radio stations able to:

  • lease HD subchannels to serve particular markets (instead of/in addition to AM broadcast)
  • HD-on-translator, where a large subset of main coverage is narrowcasted to college, minority, etc.
  • onboard advertisers of modest means on subchannel, revenue not reachable at main channel cost structure

These techniques implicitly on having lots of receivers in the field. With over a third of new automobiles having HD Radio–primarily affluent and high tech models, audiences appealing to advertisers, FMeXtra is nudged out by having no available receivers. 1/2 the digital subchannels for 1/4 one-time capital is offset in the ROI game.

When it comes to full digital HD Radio, FMeXtra is left in the dust as it’s currently a hybrid-only system. As with HDTV, broadcasters will be able to cut their transmitter power (and electricity bills) significantly, while offering better coverage, quality and more channels.

If FMeXtra were free to the broadcaster, they still may choose HD Radio for the ability to have twice as many subchannels and the entrenched market of receivers. DAB has tried and failed in North America (Canada) due to the dispersed population.


Related: FM SCA analysis with GNU Radio

View tree of USB devices on Windows/Linux

Microsoft USBView allows viewing connected USB devices on Windows in a tree view. This allows viewing which ports devices are plugged in to. USBView shows the name of chipsets and devices, even their serial numbers. An example use is computers in remote locations: verify that equipment is plugged in via USBView.

USBview

Linux USB View is available on GitHub. Follow the “INSTALL” file directions.

Send email via Gmail from Python

Note: This test should only be used with a new throwaway Gmail account as it risks security of the Gmail account in use. Instead consider Oauth with Gmail.


This is a complete example of SMTP sending email via Gmail from Python. To use with two-factor authentication account requires a Gmail App Password.

You need to use Oauth instead of this method for real-world systems, this is just a simple didactic example.

"""
send text string (e.g. status) via Gmail SMTP
"""
import smtplib
from email.mime.text import MIMEText
from getpass import getpass

def sender(user:str, passw:str, to:list, textmsg:str, server:str):
    """
    this is not a good way to do things.
    Should use Oauth.
    """
    with smtplib.SMTP_SSL('smtp.gmail.com') as s:
        s.login(user, passw)

        msg = MIMEText(textmsg)

        msg['Subject']= 'System status update'
        msg['From']= user
        msg['To'] = ', '.join(to)

        s.sendmail(user,to, msg.as_string())
        s.quit()

if __name__ == '__main__':
    from argparse import ArgumentParser
    p = ArgumentParser()
    p.add_argument('user',help='Gmail username')
    p.add_argument('to',help='email address(es) to send to', nargs='+')
    p.add_argument('-s','--server',help='SMTP server',default='smtp.gmail.com')
    p = p.parse_args()

    testmsg="just testing email from Python setup"

    sender(p.user+'@gmail.com',
           getpass('gmail password: '),
           p.to,
           testmsg,
           p.server)