The Madrigal distributed database allows access to much of the high level AMISR (incoherent scatter radar) data and DMSP data.
For lower level data (e.g. I/Q digitized samples) you need to approach the PI of the relevant instrument for data.
Updated syntax
of the original Fortran code slightly to fit with the FORTRAN 77 standard (not changing algorithm behavior, only syntactical correctness).
Plotting code uses f2py to make the LCPFCT run from Python with 50x speedup overall since you don’t have to write output to disk and then read it back in via a custom parsing algorithm.
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.
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.
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.
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.