Scientific Computing

Cross-jurisdictional and intra-jurisdictional radio systems that are incompatible is a problem as old as public safety radio itself. It takes a major catastrophe to suddenly bring together diverse EMS and Police forces on a task needing common radio channels. Yes, preplanned events such as parades and national holiday celebrations also bring EMS and Police in large inter-jurisdictional efforts, but that can be solved with radio system patches or extra radios.

Firefighters mix and match other department resources frequently as big fires can happen anywhere, anytime. One typical solution is to have large numbers of adjoining Fire agencies on common radio technology, such as VHF analog, even when every other public safety resource might be on a P25 digital trunked network system. Another solution is for an incident response van to have a bank of radios that can be patched on-site. In major urban areas, city laws may require installation of distributed antenna systems for local public safety radio–a building-wide built in broadband repeater for public safety in effect.

VHF portable coverage is worse in general compared to higher frequency (shorter wavelength) radio bands due in large part to high on-body attenuation (up to factor of 100-1000 (20-30 dB)) and high noise levels on VHF, particularly in urban areas. Yet, vast swathes of American fire departments are stuck on VHF due to interoperability concerns and budget constraints. The high cost of the APX8000 won’t necessarily be a solution for rural fire departments, but the adjoining large tax base city might afford the APX8000, allowing the city fire department to upgrade to the regional P25 digital system. The APX8000 in that scenario purchased for the city fire department allows mutual aid from adjoining rural fire departments.

Motorola APX8000 cost/benefit breakdown

Of course the Motorola salesperson isn’t pitching the APX8000 to small budget fire departments. The APX8000 sale goes to the adjoining city fire department, who now doesn’t need a $5000 radio patch that might break down, making a single point of failure in the incident response van. Dispatch isn’t tying up repeaters with console patches.

A real value add of the APX8000 is the reduction of need for complex fireground or console patches that tie up channels and break down at the worst possible time. Will the whole city get APX8000? Maybe not, but it depends on the historical patterns. They might choose to only get enough APX8000 to cover say 95% of mutual aid needs, and let console patches handle the last 5%. Also, given noise on VHF and a large site to cover for fire, it’s well possible to get out of radio range of the incident response van with the patch (or the central repeater), leading to the constantly dreaded case where you can’t talk to the person next to you on the radio.

I had a micro SD card that would only mount read-only, in Gparted and everywhere else, even as root. I moved the SD adapter read-only switch to either position, tried it in different readers, different computers.

Then I tried a different SD adapter and read/write worked.  

I experienced an error upon any use of apt with a new Rev. C Beaglebone with the factory Debian install like:

insserv: Starting led_aging.sh depends on rc.local and therefore on system facility ‘$all’ which can not be true!

Fix apt failure by replacing /etc/init.d/led_aging.sh with:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides: led_aging.sh
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start LED aging
# Description: Starts LED aging (whatever that is)
### END INIT INFO

x=$(/bin/ps -ef | /bin/grep "[l]ed_acc")

if [ ! -n "$x" -a -x /usr/bin/led_acc ]; then
/usr/bin/led_acc &
fi

and then reboot.

Code demonstrating use of the Adafruit GPIO module for Python flashing LEDs on the Beaglebone Black

A large maximum dynamic disk size for a VirtualBox guest is problematic. Even if one uses a small portion of that maximum size, the guest OS (especially Windows) will spread itself out. A 10 GB Windows image will climb to the maximum size of the dynamic VDI file over time (say to 50 GB).

Here’s a fairly painless procedure to fix this, taking less than 1 hour on a modern PC. I assume your guest OS is Windows, and your host OS is Linux running VirtualBox.

BACKUP THE VDI FILE BEFORE DOING THIS PROCEDURE!

In guest Windows, run Disk Defragmenter. It’s also possible to zero free disk space with SDelete.

Shutdown guest Windows, and “insert” the Gparted ISO file by right-clicking the CD icon at the bottom of the guest OS VirtualBox window and selecting your ISO file.

Resize guest Windows partition so that you have only say 8 GB free (e.g. original partition 40 GB, only 10 GB used –> resize to 18 GB)

Reboot guest Windows, removing the Gparted ISO file from VirtualBox. You will see Windows automatically runs CheckDisk–this is normal. You will need to reboot guest Windows once more, then shutdown guest Windows

In host Linux Terminal:

vboxmanage modifyhd --compact MyFile.vdi

The VDI file size may shrink significantly.

Defragment in guest Windows can make host VDI file INCREASE in size by the amount of bytes that were moved to defragment. Repeat steps 1, 2, and 6 of the procedure above when VDI has again grown too large. Do not make excessively large maximum size Dynamic VDIs to start–this problem will only repeat itself over time.

Script to log module version: checkversions.py

AGU Data Position Statement

My comments to AGU were:

I like the new emphasis on documentation. I would strengthen this even further by emphasizing the provision of open-source code/API that allows at minimum recreation of all figures in published papers, and canonical registration cases. Publication of source code AND build instructions necessary to recreate all paper figures should be an essential requirement for publication.

At YouTube, from Worcester Polytech Inst.:

The 902 MHz band plan was adapted to reflect reality in much of the USA with regard to easily adaptable commercial equipment. FM next to weak signal situation might include:

Consider the relevant FCC specifications demand for “off-channel, in-band” emissions. Is this specified as say -60dB so many kHz from center channel, or with an emission mask? Is the specification sufficient to protect a weak signal operator within N km of a powerful FM transmitter? If the specification is not sufficient for weak signal protection from nearby (in range) FM transmitters, do the practical filter implementations used by the most frequently used equipment provide enough protection any way as a corollary to meeting the FCC specification?

Run AGI STK on a Linux PC by using a Windows guest virtual machine.

If STK crashes upon opening a scenario in VirtualBox, shut down the virtual machine. In the options for that virtual machine, disable 3D acceleration, enable 2D acceleration, and set video memory to at least 64 MB. Then startup the virtual machine and try STK again.