PA6H provides 1 PPS (pin 13) after 3-D Fix at 2.8 V (p. 7, 13)
3.3V external antennas may draw up to 28 mA (p.15)
Power supply: 3.3 V, 25 mA
NMEA: GGA, GSA, GSV, RMC, VTG over 2.8 V TTL (p. 17)
The PA6H GPS module and Raspberry Pi can make an
NTP server.
Note that the Raspberry Pi has 3.3 V logic so level shifters may be necessary to/from the 2.8 V GPS IO.
NMEA over UART: the Raspberry Pi
UART
via PySerial can read NMEA with a program such as
NMEAutils.
The hardware UART connection is to GPIO pins 14 and 15 on the various Raspberry Pi versions.
Red Pitaya NMEA over UART: starting with the
Red Pitaya UART Example in C,
one could scoop up the NMEA and extract the current time using a 1PPS driven interrupt.
Perhaps use PySerial to access /dev/ttyPS1 to use the Red Pitaya UART from Python.
The Red Pitaya UART
pinout
is to pins 7 and 8 of connector E2.
This would not be for setting the clock accurately like NTP, but rather for determining which second the 1PPS tick occurred at.
This technique (with different hardware) was used for the
HiST auroral tomography system.
The obsolete Fortran 66 statement pause had various behaviors depending on the operating system and compiler.
Fortran pause was used for three different purposes in the Fortran 66 / 77 era:
(most common use) program waits forever, until the user pressed the Enter key, ignoring typed input.
wait for user to type text on ttystdin, assigning the typed text to a variable.
(very old programs) drop to a system shell, allowing any shell command to be used
These can be replaced with unambiguous modern Fortran code.
Wait till Enter: the program waits for the Enter key, ignoring any console input.
use,intrinsic::iso_fortran_env,only:input_unitprint*,'Waiting for Enter.'read(input_unit,*)
The examples below are for Ubuntu, but equivalents may be found for
DebianGentooArch Linux
and other distros.
File: “Search the content of Packages” in the Ubuntu Package
Search,
to find which packages provide a file for specific Ubuntu versions.
This is important for files that aren’t available in your Ubuntu version.
Example: search for core/dbus/dbus.h shows it’s in libdbus-cpp-dev.
Program: show which versions Fortran open-coarrays is available in.
Searchsource package namesopen-coarrays
Microsoft Miracast display adapter worked for me for a couple years.
Suddenly I couldn’t pair from an Android device.
The adapter is configured to use a PIN, and I had the correct PIN, but nothing would work.
I had firmware V.2.0.8372 on the Microsoft Miracast adapter.
Use a native Windows laptop, as typical virtual machine software such as VirtualBox doesn’t provide the necessary software links to allow Miracast to work from a Windows guest OS.
After a couple tries, I could connect.
Disable PIN and restart adapter
Enable PIN and restart adapter
Then the Miracast adapter again worked from an Android device as usual.
From a native Windows laptop:
Windows Store → Microsoft Wireless Display Adapter
Android devices can be used as Bluetooth Low Energy (BLE) beacon receivers, loggers and transmitters with the
nRF Connect app.
For initial experiments, instead of buying BLE-specific beacon hardware, consider using old Android tablets and phones to setup a beacon network.
Laptop computerss, BLE-enabled microcontrollers, and BLE-enabled single-board computers can also transmit and receive BLE beacons.
A typical application of such beacons is for indoor / outdoor position estimation and tracking.
BLE beaconing adjustments include:
transmit beacon contents (de facto standard formats)
BLE Advertisement period
BLE Transmit power
BLE logging uses the
nRF Logger app.
to write to a log file beacon RSSI vs. time.
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)