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.

Summits on the Air (SOTA) and highpointing

Did some quick looking for information on Summits on the Air (SOTA), a ham radio contest to make contacts while either you or your contact are standing on top of a summit (mountain peak, usually) and highpointing, which is a hiking contest to stand on all the high points in a given set of jurisdictions (continents, counties, US states, US counties, etc.). Links below.

  • https://www.sotamaps.org/ maps to help you find official SOTA summits, although determining which association you belong to is not especially clear. Minnesota is association K0M and North/South Dakota are association W0D.
  • https://sotawatch.sota.org.uk/en/ SOTAwatch is a good place to let people know what peak you’ll be on so they can try to contact you
  • SOTA summits in North Dakota and South Dakota: https://summits.sota.org.uk/region/W0D
  • SOTA summits in Minnesota: https://summits.sota.org.uk/association/K0M
  • Getting started with SOTA: http://www.pnwsota.org/content/getting-started-sota
  • SOTA Minnesota association reference manual: https://sotastore.blob.core.windows.net/arms/ARM-K0M.pdf
  • Joining in with SOTA: https://www.sota.org.uk/Joining-In
  • How to activate a SOTA peak: http://www.pnwsota.org/sites/pnwsota.org/files/How%20to%20Activate%20a%20SOTA%20Peak.pdf
  • Minnesota county high points: https://www.peakbagger.com/list.aspx?lid=13407