For the Aug 2017 eclipse measurements in South Carolina, despite the fans installed on each Red Pitaya, it was important to keep track of CPU temperature and voltage as each PiRadar node was unattended.
#!/bin/sh
## based on www.kkn.net/~n6tv/xadc.sh## works in Ash (Red Pitaya ecosystem 0.95) and Bash (ecosystem 0.97)# path to IIO deviceXADC_PATH=/sys/bus/iio/devices/iio:device0
# Note: used "cat" to work in Ash instead of the typically recommended Bash "<".OFF=$(cat $XADC_PATH/in_temp0_offset)RAW=$(cat $XADC_PATH/in_temp0_raw)SCL=$(cat $XADC_PATH/in_temp0_scale)FORMULA="(($OFF+$RAW)*$SCL)/1000.0"VAL=$(echo"scale=2;${FORMULA}" | bc)echo"in_temp0 = ${VAL} °C"
#!/bin/sh
# based on www.kkn.net/~n6tv/xadc.sh## works in Ash (Red Pitaya ecosystem 0.95) and Bash (ecosystem 0.97)# power supply voltages (predefined scaling)# note that Ash doesn't have "array" so we use "set --"# path to IIO deviceXADC_PATH=/sys/bus/iio/devices/iio:device0
set -- "in_voltage0_vccint"\
"in_voltage1_vccaux"\
"in_voltage2_vccbram"\
"in_voltage3_vccpint"\
"in_voltage4_vccpaux"\
"in_voltage5_vccoddr"\
"in_voltage6_vrefp"\
"in_voltage7_vrefn"for voltage doRAW=$(cat ${XADC_PATH}/${voltage}_raw)SCL=$(cat ${XADC_PATH}/${voltage}_scale)FORMULA="(${RAW}*${SCL})/1000.0"VAL=$(echo"scale=2;${FORMULA}" | bc)echo"${voltage} = ${VAL} V"done
Using serial ports from Linux is easy and robust.
Serial ports also work in
WINE.
PuTTY
has GUI configuration for serial port.
Minicom
or
screen
give command line access to serial port links.
On Linux, add the user to the “dialout” group for non-root access to serial ports (one-time)
adduser $(whoami) dialout
Then logout and login.
List hardware serial ports (motherboard or PCI card):
Find a random available local port with this Python snippet.
#!/usr/bin/env pythonfromsocketimport socket
with socket() as s:
s.bind(('',0))
print(s.getsockname()[1])
From shell, this returns on STDOUT a free port number.
There is a slight race condition where between end of this program and start of your shell program, another program could grab this port.
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.
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)
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.
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.
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.
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
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.