Frost-Keysor Genealogy

I had to write this all out to email it to the keepers of the Genealogy of the Abial Frost Family website, so I might as well post it here in case someone finds it from another angle and has information.

I’m looking for a connection to the Frost family and hoping someone might be able to give me some guidance on my wife’s side of the family.

Looking over the newsletters and this site, I don’t think she is a descendant of Abial Frost, but there are references to the Hadley, NY area that I think are intriguing.

My wife is descended from an Elizabeth Frost, who married Clark Keysor Sr., father of Civil War Union Captain Clark Keysor of Mankato, MN. We don’t have direct familial knowledge of the line this far back, but Capt. Keysor’s early life is documented in both “Mankato: It’s First Fifty Years..” (1903) and “History of Blue Earth County…” (Hughes, 1901). I’ve copied some text below:

Captain Keysor was born in Luzerne, Warren county, New York, May 24, 1826, and was among the five children of Clark and Elizabeth (Frost) Keysor. The father followed the lumbering business until his death, which occurred in New York state in 1830. Survived by the widow, she eventually came to Mankato [MN] and died here in 1877 at an advanced age. Their son, Clark, Jr., received a common-school education in New York state and grew to manhood upon a farm, early gaining a thorough knowledge of agricultural pursuits. (Hughes, 1901)

KEYSOR, Capt. Clark–Born in Luzerne, Warren County, New York, May 24th, 1826, a son of Clark and Elizabeth (Frost) Keysor. His grandparents on his father’s side were natives of Germany, who landed in New York City about the end of the 18th century, were the grandmother died, leaving the Captain’s father an infant, who, being adopted by a family named Wells, was brought up in New York State, where he died in 1830. After his father’s death, Capt. Keysor made his home with his grandfather Frost, in the town of Hadley, New York, working on a farm and attending the country school until he was sixteen years of age. He then started out for himself, finding employment first in a saw mill at Luzerne, and the following winter in a lumber camp. (Mankato, 1903)

Elizabeth Frost Keysor did move to Mankato and died there. She may have remarried to a Noyes after Clark Sr’s death, but I am having a hard time finding documentation. There are two markers that bear her name in Glenwood Cemetery in Mankato.

Looking through the newsletters, I see mention of Uncle Elijah, who lived in Hadley around that time and had a daughter named Lizzie. This is noted in the Frost Genealogy (1912); Elijah is individual #8.

I’d appreciate any sources documenting the Frost-Keysor connection if there is one. Thanks for any ideas.

Matt

P.S. My wife’s tree is online, the direct link to Elizabeth Frost is here: https://mattbk.com/webtrees/index.php?route=%2Fwebtrees%2Ftree%2FFinstad%2Findividual%2FI782%2FElizabeth-Frost

Uploading big files to Castopod on YuNoHost

Find PHP version being used:

> matt@example:/etc/php$ tail ynh_app_version
> castopod:8.0

Update `memory_limit` in `sudo nano /etc/php/8.0/fpm/php.ini`

Restarted PHP 8 service, getting `504 Gateway Time-out nginx` now. Progress?

Then set `client_max_body_size` in here to 700 rather than 600:
`matt@example:/etc/nginx/conf.d/castopod.example.net.d$ sudo nano castopod.conf`

Then set `max_execution_time` to 90 at `sudo nano /etc/php/8.0/fpm/php.ini`

Restart nginx and PHP services (I used https://example.net/yunohost/admin/#/services).

APRS over LoRa, iGating and digipeating

I haven’t touched this in a while, but I may forget if I don’t keep working on it. An advantage of running APRS (on whatever protocol, even if on a license-free band) is the existing infrastructure (APRS-IS) and ability to use existing software for interface (e.g., APRSDroid). Additional advantages of using ESP32 devices are 1) low cost, 2) easy to get, and 3) no need for license, but you can’t use nearly as much power and still be legal.

Of course, there is still the caveat that LoRa itself is a proprietary protocol, so if you need everything to be open, you’ll have to look elsewhere. My interest is working networks. If you want encryption, Meshtastic might work for you.

Copying what I wrote at https://github.com/SQ9MDD/TTGO-T-Beam-LoRa-APRS/issues/29#issuecomment-926018368:

I can confirm that the https://github.com/lora-aprs/LoRa_APRS_iGate project can act as an iGate for a device running this code, if the baud rate is set at 300, not 1200. SQ9MDD’s code can both send and receive packets sent by the lora-aprs code, and vice versa.

This doesn’t solve the ticket, but does make it possible to deploy an iGate/digipeater if you are OK using different code for it. I’m pretty excited for that, at least.

Some notes I took while learning are below.
—–

SQ9MDD:
image
image
These codes mean:
– 300 baud: `Bw125Cr45Sf4096`
– bandwidth 125 kHz
– coding rate 4/5
– spreading factor 4096 chips/symbol (SF 12)
– 1200 baud: `Bw125Cr47Sf512`
– bandwidth 125 kHz
– coding rate 4/7
– spreading factor 512 chips/symbol (SF 9)

lora-aprs:
(values are default except for frequency, which I changed for my device)
image

Spreading factor is here given in different units? A number between 7 and 12.

2^{??} ?ℎ??? =1 ?????? (source).

So a spreading factor of 12 is 4096 chips/symbol and a spreading factor of 9 is 512 chips/symbol.

WSJT-X Setup on macOS

I may add to these notes, but a key one was to make sure to give WSJT-X access to the microphone, even when using a USB cable to control the rig. Thanks to K3DCW for the tip.

I presume that you have a checkmark in the box labeled “PortAudio” next to the USB Audio CODEC device selectors. If so, then the only other thing that I can think of is that you haven’t given macOS permission to access your “microphone.” Many of these programs see/treat that USB Audio CODEC as a microphone input and failing to give it access to your “microphone” will cause it to not hear a thing. Go to the Security & Privacy pane and make sure that Fldigi has access to the microphone.

I also have iShowU Audio Capture installed (for OBS screen recording), which I thought might have been the problem. Here are my current working audio settings (Audio Midi Setup).

The rest of the settings described here work out well for connecting the IC-7300 and my MacBook Pro.

To get the gain right in the software, I used the RF Gain knob on the IC-7300. There is a way to adjust this in the settings but I can’t find it at the moment. It’s the ACC/USB AF Output Level setting under MENU>SET>Connectors (make sure you scroll up and down the menu items as needed). All suggestions are to get the bar in WSJT or JTDX to about 30 dB.

Labeling minimum and maximum values on a fill color guide in #rstats #ggplot2

This took me a while to understand, and even though I think this should be built in somewhere, I ended up with the following function:

# Function to show min and max values on fill color bars.
# Inspiration from https://stackoverflow.com/a/60732101/2152245
# original_func should be something like "scales::breaks_pretty(3)"
breaks_min_max <- function(original_func) {
    function(x) {
        original_result <- original_func(x)
        breaks <- c(min(x), 
                  original_result, 
                  max(x))
breaks_sort <- sort(breaks)
# If values are too close, drop one of them
close <- diff(breaks_sort) < 1
breaks_sort <- breaks_sort[!close]
breaks_sort
    }
}

Note the very rough method of determining when labels will be too close together. This would need to be modified if working with negative numbers or values that are all decimals.

In use:

ggplot(mtcars,
aes(x = mpg,
y = disp,
color = qsec)) +
geom_point(size = 5) +
scale_color_continuous(breaks = breaks_min_max(scales::breaks_pretty(4)))

Result:

Update 2021-09-28:

If you have a log scale, this will also work if you use breaks_log(). Example below. This seems to be sensitive to the number of breaks you set; for the example below, 4 doesn’t work (the top and bottom values aren’t labeled), but 6 does.

ggplot(mtcars, aes(x = mpg, y = disp, color = qsec)) + 
geom_point(size = 5) + 
scale_color_continuous(trans = "log10",
breaks = breaks_min_max(scales::breaks_log(6)))

List of #APRS Projects (and interesting alternatives)

I’ve expanded my search beyond what I introduced in APRS tracker/viewer build concept. Here I will attempt to organize projects some other folks have put together.

This has been sitting in draft mode for several weeks, but I’m pushing it out now and hoping to add more as I learn.

Bulk Convert your Dire Wolf logs to GPX

Dire Wolf won’t let you save both a daily and single log file of packets received, but if you log daily with LOGDIR, you can write a script that bundles up all the log files and then produces a GPX file of the output. This is useful if you want an idea of the area your digipeater or iGate is covering without trusting to aprs.fi or aprsdirect.com, which only provide the actual path taken and drop duplicate iGated packets.

Simple script for Linux:

#!/bin/bash
# merge log files
sed 1d *.log > log_merged.csv
# convert to gpx
log2gpx log_merged.csv > log_merged.gpx

(sed tip from Linux.com means you don’t need Python or similar)

Make it executable:

chmod +x merge_and_gpx.sh

Run or schedule in cron:

./merge_and_gpx.sh

APRS tracker/viewer build concept

Writing this on the fly and hope to add links later.

I’ve been into APRS lately, which tends to yield project ideas. There are small trackers put there that aren’t cheap, cheaper trackers that aren’t small, and none of them do all of what you might want.

At an event (e.g., an endurance race in a remote location), you want everyone to know as much as possible. We’ve tried satellite tracking on racers to various success, but when the race course has little mobile data and barely SMS (if anything), satellites don’t help race directors very much.

Having enough amateur radio volunteers to set up a real net is the dream, but in absence, what else can we do? Enter APRS.

Build idea here is for an easy-to-install vehicle (staff and volunteer) tracker that lets everyone see other where other people are. A limited number of hams would enter data and send messages or bulletins, and the rest would be passive; not pushing buttons on the radio, but having access to received data.

Quick concept and then I’m done:

  • Raspberry Pi Zero running Dire Wolf as a TNC.
    • Will need USB port, maybe not the Zero?
  • Cheap 2m radio, ideally mobile rather than HT so powering is easy. Doesn’t need any features!
  • Custom cable to run the radio and sound in/out.
  • USB sound card.
  • APRSdroid pr APRSfi phone app.

See where im going? Need to run numbers on cost, because it’s adding up in my head.

Exploring genealogy with R: readgedcom and tidygraph

My code is an absolute mess right now, but here’s a fun plot showing everyone in my family GEDCOM. With so many people, it’s hard to visualize all of them at once, and most software provides one or the other of a descendant tree or an ancestor tree.

Colors on this plot show whether a person is a terminal ancestor (no parents) or terminal descendant (no children). You can also tell that I don’t have the graph (connections between people) set up properly, because I don’t have that many unrelated individuals in this GEDCOM (at least, I shouldn’t). Overall I think this is a good start and eventually I can end up with a poster.

network plot with lots of circles and arrows
Red = terminal ancestor, green = terminal descendant, blue = neither.