Assembling a Diamond X300N antenna

Recently, I noticed the 2m flower-pot antenna that has been my home base antenna for some 15 years now, had developed a high VSWR. Either that, or the feed-line had. I haven’t tried troubleshooting which.

I tried a mobile antenna on a mag-mount base sat atop the corrugated iron roof of the deck, plugged in where the flow pot connects, and got good results there, so I think the cabling going from the back deck into my room is fine, it’s just the section that connects to the bulk-head BNC to the outside world and/or the antenna itself.

That section includes a 3m-length of HDF-400 coax, purchased back in the days of the now defunct Brisbane Mesh. I figured if the coax is bad, okay, I’ll re-use the flower-pot for other requirements (it’d be great as a small antenna to use at Imbil), the base antenna could use an upgrade anyway.

I ordered a Diamond X300N, something that would have decent gain on 2m/70cm, not be too obnoxiously large, and still should allow me to get a signal out up high. I ordered it through Andrews Communications, and it arrived late last week… today I finally got around to putting it together.

The instructions seemed simple enough:

Okay, so insert this bit into that bit… sounds simple enough, except:

(1) the tip of the lower element has a tag on it saying “do not pull on this” (fair enough), and
(2) the coupling I’m supposed to insert it into is buried far down the end of the upper antenna section

Turns out, you can put the hack-saw away, the answer is simple enough. The top-section can slide back and forth, and in transit it may settle inside the tube. You grab the top-section by the upper outer-shell joint to stop it rattling, and bang the whole lot against a flat surface to encourage gravity to “pull” that upper conductor down. Eventually it reaches the bottom and you can pull it out with conventional needle-nose pliers.

The instructions are pretty straight-forward from here, although installation will have to wait until someone is here to guard the door or until “Jesus Cat” is sound asleep, as I’m not having a repeat of last week-end again.

Missing cat, “Sam”: Lower Eranga St, The Gap — FOUND

Current situation

He has returned this morning. Tracey sent me a message via SMS reporting some neighbours across the street from me had spotted him sleeping on their outdoor lounge. When they tried to catch him, he made a bolt for it and disappeared.

I had a quick shower and got dressed, then went outside to have a look around. Sure enough, he was across the street, and on seeing me, immediately came running. The bed bug is back. I think it’ll be supervised outdoor access only from now on.

Unconfirmed sightings

At around 6PM on Friday, whilst I was searching the back yard with a headlight, I did spot what appeared to be two green eyes like Sam’s reflecting back at me, the headlight however seemed to spook the cat and it disappeared, not seen since. This would have been in the back yard / fence between the properties 92 / 94 Settlement Road.

Later around 8PM, I did another walk, and saw another cat, not unlike Sam frolicking around Eranga St / Katoa St… however I also know there is a cat that lives in that area very similar to Sam (possibly a Burmese or Russian Blue). This cat dived under a parked van.

Update 2023-07-01T18:09 With the help of neighbour Tracey, I was able to get a photo and a small post sent to ‘The Gap Grapevine’ Facebook Group. Via that group, a resident in Tamboura Ct reportedly saw a cat matching Sam’s description around mid-day Friday. Tracey and I did a quick search in that area, and I re-visited that area this evening, walking up to where the old quarry was, crossing Settlement Road, and walking back. Thankfully no signs of fresh road kill, but no cat either.

Areas searched

I have done several walks around lower Eranga St. / Katoa St / Kaloma Rd / Settlement Rd, down to Chaprowe Rd. Neither the cat nor any signs of road kill were observed along the route.

I also did a walk down around Michalea Cres, with no sightings.


  • Name: Sam
  • Sex: Male
  • Breed: Russian Blue / Domestic Shorthair Cross
  • Age: Very close to 8 years old
  • Weight: 10.4kg at last weigh-in
  • Temperament: Usually quite relaxed, but is known to give people a nip
  • Desexed: Yes, but some parts (“decorative” in function now) remain
  • Microchipped: Yes, HomeSafeID tag ending in …1857
  • Collar: No
  • Diet: Eats a mix of roo or beef mince and dry biscuits usually a large teaspoon of mince and ⅛ cup of biscuits morning and afternoon. At present he’s on metabolic biscuits to try and get his weight down.
  • Health issues: none other than having a bit of weight on him.
  • Veterinary Clinic: The Gap Vet Surgery, corner Settlement Rd / Waterworks Rd, The Gap.

Contact details

No longer relevant.

Has he been known to roam before?

Yes, but usually the pattern is he’ll visit neighbours for a few hours, then return home.

Prior to me adopting him in 2020 from my maternal grandmother (who had suffered a fall that would later prove fatal), he had been known to occasionally go out on multi-night jaunts, but until now had always come home after an hour or two.

Outdoors access

He is normally let out in the mornings (as he is an outdoor cat) with the expectation that he’s back in a few hours. At 3PM he’s normally inside bellowing for dinner, so we usually will shut the door at that point and keep him indoors overnight.

There are no “cat doors” at our property.

Generating ball tickets/programmes using LaTeX

My father does a lot of Scottish Country dancing, he was a treasurer for the Clan MacKenzie association for quite a while, and a president there for about 10 years too. He was given a task for making some ball tickets, but each one being uniquely numbered.

After hearing him swear at LibreOffice for a bit, then at Avery’s label making software, I decided to take matters into my own hands.

First step was to come up with a template. The programs were to be A6-size booklets; made up of A5 pages folded in half. For ease of manufacture, they would be printed two to a page on A4 pages.

The first step was to come up with the template that would serve as the outer and inner pages. The outer page would have a placeholder that we’d substitute.

The outer pages of the programme/ticket booklet… yes there is a typo in the last line of the “back” page.
\usepackage[top=1cm, left=0cm, right=0cm, bottom=1cm]{geometry}


We thank you for your company today\linebreak
and helping to celebrate 50 years of friendship\linebreak
fun and learning in the Redlands.

May the road rise to greet you,\linebreak
may the wind always be at your back,\linebreak
may the sun shine warm upon your face,\linebreak
the rains fall soft upon your fields\linebreak
and until we meet again,\linebreak
may God gold you in the palm of his hand.


1973 - 2023\linebreak
Saturday 20th May 2023\linebreak
1.00pm for 1.30pm - 5pm\linebreak
Redlands Memorial Hall\linebreak
South Street\linebreak

Live Music by Emma Nixon \& Iain Mckenzie\linebreak
Black Bear Duo


Cost \$25 per person, non-dancer \$15\linebreak
\textbf{Ticket No \${NUM}}

The inner pages were the same for all booklets, so we just came up with one file that was used for all. I won’t put the code here, but suffice to say, it was similar to the above.

The inner pages, no placeholders needed here.

So we had two files; ticket-outer.tex and ticket-inner.tex. What next? Well, we needed to make 100 versions of ticket-outer.tex, each with a different number substituted for $NUM, and rendered as PDF. Similarly, we needed the inner pages rendered as a PDF (which we can do just once, since they’re all the same).


set -ex

pdflatex ticket-inner.tex
for n in $( seq 1 ${NUM_TICKETS} ); do
	sed -e 's:\\\${NUM}:'${n}':' \
            < ticket-outer.tex \
            > ticket-outer-${n}.tex
	pdflatex ticket-outer-${n}.tex

This gives us a single ticket-outer.pdf, and 100 different ticket-inner-NN.pdf files that look like this:

A ticket outer pages document with substituted placeholder

Now, we just need to put everything together. The final document should have no margins, and should just import the relevant PDF files in-place. So naturally, we just script it; this time stepping every 2 tickets, so we can assemble the A4 PDF document with our A5 tickets: outer pages of the odd-numbered ticket, outer pages of the even-numbered ticket, followed by two copies of the inner pages. Repeat for all tickets. We also need to ensure that initial paragraph lines are not indented, so setting \parindent solves that.

This is the rest of my quick-and-dirty shell script:

cat > tickets.tex <<EOF
\usepackage[top=0cm, left=0cm, right=0cm, bottom=0cm]{geometry}
for n in $( seq 1 2 ${NUM_TICKETS} ); do
	m=$(( ${n} + 1 ))
	cat >> tickets.tex <<EOF
cat >> tickets.tex <<EOF
pdflatex tickets.tex

The result is a 100-page PDF, which when printed double-sided, will yield a stack of tickets that are uniquely numbered and serve as programmes.

Mastodon experiment: a few months in

A little while back I decided to try out Mastodon, deploying my own instance running as a VM on my own hardware. This was primarily done to act as a testing ground for experimenting with integrating with it, but also as a means of keeping up with the news.

The latter is particularly important, as I no longer have the radio on all the time. I might hear a news item in the morning, but after the radio switches off, I’m unlikely to turn it back on until the next working day. A lot of news outlets moved to Twitter over the past decade, but with that site in its death throws, the ActivityPub ecosystem is looking like a safer bet.

Not many outlets are officially using this newer system yet. There are a few outlets that do publish directly to Mastodon/ActivityPub, examples being Rolling Stone, The Markup (who run their own instance), STAT, The Conversation AU/NZ and OSNews. Some outlets aren’t officially posting on ActivityPub, but are nonetheless visible via bridges from RSS (e.g. Ars Technica) and others are proxies of these outlets’ Twitter accounts (e.g. Reuters, Al Jazeera, The Guardian, Slashdot). Others are there, but it’s not clear how the material is being mirrored or if they’re official.

There’s also a decent dose of satire if you want it, including satirical news outlets The Chaser and The Shovel, and cartoonists such as Christopher Downes, David Rowe, Fiona Katauskas, Jon Kudelka, David Pope, Cathy Wilcox and Glen Le Lievre.

As you can gather, a big chunk of who I follow is actually news outlets, or humour. There are a few people on my “follow” list whom are known for posting various humour pieces from elsewhere, and I often “boost” (re-post) their content.

Meta (who run Facebook) have made noises they might join in with their own Twitter-clone in the ActivityPub fediverse. I wouldn’t mind this so much — the alternatives to them doing this is: (1) the rest of us needing dozens of social media accounts to keep in touch with everybody, (2) relying on the good will of some mega-site to connect us all, or (3) forgoing being in touch altogether.

I tried option (1) in the early part of this century, and frankly I’m over it. Elon Musk dreams of Twitter becoming option (2) but I think the chances of this happening are buckleys and none. (3) is not realistic, we’re social beings.

Some of these instances will be ad supported, and I guess that’s a compromise we may have to live with. Servers need electricity and Internet to run, and these are not free. A bigger cost to running big social networks is actually managing the meat-ware side of the network — moderation, legal teams to decide how moderation should be applied, handling take-down notices… etc.

ActivityPub actually supports flagging the content so the post is not “listed” (indexed by instances’ search engines), private posts (cannot be boosted, visible to followers only), even restricting to just those mentioned specifically. I guess there’s room for one more: “non-commercial use only” — commercial instances could then decide to they forgo the advertising on that post, or do they filter the post.

ActivityPub posting privacy settings on Mastodon

I did hear rumblings that the EU was likely to pass some laws requiring a certain level of interoperability between social networks, which ActivityPub could in fact be the basis of.

Some worry about another Eternal September moment — a repeat of the time when AOL disgorged its gaggle of novice Internet users on an unsuspecting Usenet system. Usenet users prior to AOL opening up in 1993 only had to deal with similar shenanigans once a year around September when each new batch of first year uni students would receive their Internet access accounts.

I’m not sure linking of a site like Facebook or Tumblr (who have also mentioned joining the Fediverse) is all that big a deal — Mastodon lets you block whole domains if you so choose, and who says everybody on a certain site is going to cause trouble?

Email is a federated system, always has been, and while participation as a small player is more complicated than it used to be, it is still doable. Big players like Microsoft and Google haven’t killed off email (even with the former doing their best to do so with sub-par email clients and servers). Yes, we have a bigger spam problem than we had back in the 90s, but keeping the signal-to-noise ratio up to useful levels is not impossible, even for mere mortals.

We do have to be mindful of the embrace-extend-break game that big business like to play with open protocols, I think Mastodon gGmbH’s status as a not-for-profit and a reference implementation should help here.

I’d rather throw my support behind a system that can allow us to all interoperate, and managing the misbehaviour that may arise on a case-by-case basis, is a better solution than us developing our own little private islands. The info-sec press seem to have been quick to jump ship from Twitter to Mastodon. IT press is taking a little longer, but there’s a small but growing group. I think the journalism world is going to be key to making this work and ensuring there’s good-quality content to drown out the low-quality noise. If big players like Meta joining in help push this along, I think this is worth encouraging.

A crude attempt at memory management

The other day I had a bit of a challenge to deal with. My workplace makes embedded data collection devices which are built around the Texas Instruments CC2538 SoC (internal photos visible here) and run OpenThread. To date, everything we’ve made has been an externally-powered device, running off either DC power (9-30V) or mains (120/240V 50/60Hz AC). CC2592 range extender support was added to OpenThread for this device.

The CC2538, although very light on RAM (32KiB), gets the job done with some constraints. Necessity threw us a curve-ball the other day, we wanted a device that ran off a battery. That meant going into sleep mode periodically, deep sleep! The CC2538 has a number of operating modes:

  1. running mode (pretty much everything turned on)
  2. light sleep mode (clocks, CPU and power stays on, but we pause a few peripherals)
  3. deep sleep mode — this comes in four flavours
    • PM0: Much like light-sleep, but we’ve got the option to pause clocks to more peripherals
    • PM1: PM0, plus we halt the main system clock (32MHz crystal or 16MHz RC), halting the CPU
    • PM2: PM1 plus we power down the bottom 16KiB of RAM and some other internal peripherals
    • PM3: PM2 plus we turn off the 32kHz crystal used by the sleep timer and watchdog.

We wanted PM2, which meant while we could use the bottom 16KiB of RAM during run-time, the moment we went to sleep, we had to forget about whatever was kept in that bottom 16KiB RAM — since without power it would lose its state anyway.

The challenge

Managing RAM in a device like this is always a challenge. malloc() is generally frowned upon, however in some cases it’s a necessary evil. OpenThread internally uses mbedTLS and that, relies on having a heap. It can use one implemented by OpenThread, or one provided by you. Our code also uses malloc for some things, notably short-term tasks like downloading a new configuration file or for buffering serial traffic.

The big challenge is that OpenThread itself uses a little over 9KiB RAM. We have a 4KiB stack. We’ve got under 3KiB left. That’s bare-bones OpenThread. If you want JOINER support, for joining a mesh network, that pulls in DTLS, which by default, will tell OpenThread to static-allocate a 6KiB buffer.

9KiB becomes about 15KiB; plus the stack, that’s 19KiB. This is bigger than 16KiB — the linker gives up.

Using heap memory

There is a work-around that gets things linking; you can build OpenThread with the option OPENTHREAD_CONFIG_HEAP_EXTERNAL_ENABLE — if you set this to 1, OpenThread forgoes its own heap and just uses malloc / free instead, implemented by your toolchain.

OpenThread builds and links in 16KiB RAM, hooray… but then you try joining, and; NoBufs is the response. We’re out of RAM. Moving things to the heap just kicked the can down the road, we still need that 6KiB, but we only have under 3KiB to give it. Not enough.

We have a problem in that, the toolchain we use, is built on newlib, and while it implements malloc / free / realloc; it does so with a primitive called _sbrk(). We define a pointer initialised up the top of our .bss, and whenever malloc needs more memory for the heap, it calls _sbrk(N); we grab the value of our pointer, add N to it, and return the old value. Easy.

Except… we don’t just have one memory pool now, we have two. One of which, we cannot use all the time. OpenThread, via mbedTLS also winds up calling on malloc() very early in the initialisation (as early as the otInstanceInitSingle() call to initialise OpenThread). We need that block of RAM to wind up in the upper 16KiB that stays powered on — so we can’t start at address 0x2000:0000 and just skip over .data/.bss when we run out.

malloc() will also get mighty confused if we suddenly hand it an address that’s lower than the one we handed out previously. We can’t go backwards.

I looked at replacing malloc() with a dual-pool-aware version, but newlib is hard-coded in a few places to use its own malloc() and not a third-party one. picolibc might let us swap it out, but getting that integrated looked like a lot of work.

So we’re stuck with newlib‘s malloc() for better or worse.

The hybrid approach

One option, we can’t control what malloc the newlib functions use. So use newlib‘s malloc with _sbrk() to manage the upper heap. Wrap that malloc with our own creation that we pass to OpenThread: we implement otPlatCAlloc and otPlatFree — which are essentially, calloc and free wrappers.

The strategy is simple; first try the normal calloc, if that returns NULL, then use our own.

Re-purposing an existing allocator

The first rule of software engineering, don’t write code you don’t have to. So naturally I went looking for options.

Page upon page of “No man don’t do it!!!”

jemalloc looked promising at first, it is the FreeBSD malloc(), but that there, lies a problem — it’s a pretty complicated piece of code aimed at x86 computers with megabytes of RAM minimum. It used uint64_ts in a lot of places and seemed like it would have a pretty high overhead on a little CC2538.

I tried avr-libc‘s malloc — it’s far simpler, and actually is a free-list implementation like newlib‘s version, but there is a snag. See, AVR microcontrollers are 8-bit beasts, they don’t care about memory alignment. But the Cortex M3 does! avrlibc_malloc did its job, handed back a pointer, but then I wound up in a HARDFAULT condition because mbedTLS tried to access a 32-bit word that was offset by a few bytes.

A simple memory allocator

The approach I took was a crude one. I would allocate memory in fixed-sized “blocks”. I first ran the OpenThread code under a debugger and set a break-point on malloc to see what sizes it was asking for — mostly blocks around the 128 byte mark, sometimes bigger, sometimes smaller. 64-byte blocks would work pretty well, although for initial testing, I went the lazy route and used 8-byte blocks: uint64_ts.

In my .bss, I made an array of uint8_ts; size equal to the number of 8-byte blocks in the lower heap divided by 4. This would be my usage bitmap — each block was allocated two bits, which I accessed using bit-banding: one bit I called used, and that simply reported the block was being used. The second was called chained, and that indicated that the data stored in this block spilled over to the next block.

To malloc some memory, I’d simply look for a string of free blocks big enough. When it came to freeing memory, I simply started at the block referenced, and cleared bits until I got to a block whose chained bit was already cleared. Because I was using 8-byte blocks, everything was guaranteed to be aligned.

8-byte blocks in 16KiB (2048 blocks) wound up with 512 bytes of usage data. As I say, using 64-byte blocks would be better (only 256 blocks, which fits in 64 bytes), but this was a quick test. The other trick would be to use the very first few blocks to store that bitmap (for 64-byte blocks, we only need to reserve the first block).

The scheme is somewhat inspired by the buddy allocator scheme, but simpler.

Bit banding was simple enough; I defined my struct for accessing the bits:

struct lowheap_usage_t {
        uint32_t used;
        uint32_t chained;

and in my code, I used a C macro to do the arithmetic:

#define LOWHEAP_USAGE                                                   \
        ((struct lowheap_usage_t*)(((((uint32_t)&lowheap_usage_bytes)   \
                                     - 0x20000000)                      \
                                    * 32)                               \
                                   + 0x22000000))

The magic numbers here are:

  • 0x20000000: the start of SRAM on the CC2538
  • 0x22000000: the start of the SRAM bit-band region
  • 32: the width of each word in the CC2538

Then, in my malloc, I could simply call…

struct lowheap_usage_t* usage = LOWHEAP_USAGE;

…and treat usage like an array; where element 0 was the usage data for the very first block down the bottom of SRAM.

To implement a memory allocator, I needed five routines:

  • one that scanned through, and told me where the first free block was after a given block number (returning the block number) — static uint16_t lowheap_first_free(uint16_t block)
  • one that, given the start of a run of free blocks, told me how many blocks following it were free — static uint16_t lowheap_chunk_free_length(uint16_t block, uint16_t required)
  • one that, given the start of a run of chained used blocks, told me how many blocks were chained together — static uint16_t lowheap_chunk_used_length(uint16_t block)
  • one that, given a block number and count, would claim that number of blocks starting at the given starting point — static void lowheap_chunk_claim(uint16_t block, uint16_t length)
  • one that, given a starting block, would clear the used bit for that block, and if chained was set; clear it and repeat the step on the following block (and keep going until all blocks were freed) — static void lowheap_chunk_release(uint16_t block)

From here, implementing calloc was simple:

  1. first, try the newlib calloc and see if that succeeded. Return the pointer we’re given if it’s not NULL.
  2. if we’re still looking for memory, round up the memory requirement to the block size.
  3. initialise our starting block number (start_nr) by calling lowheap_first_free(0) to find the first block; then in a loop:
    • find the size of the free block (chunk_len) by calling lowheap_chunk_free_length(start_nr, required_blocks).
    • If the returned size is big enough, break out of the loop.
    • If not big enough, increment start_nr by the return value from lowheap_chunk_used_length(start_nr + chunk_len) to advance it past the too-small free block and the following used chunk.
    • Stop iterating of start_nr is equal to or greater than the total number of blocks in the heap.
  4. If start_nr winds up being past the end of the heap, fail with errno = ENOMEM and return NULL.
  5. Otherwise, we’re safe, call lowheap_chunk_claim(start_nr, required_blocks); to reserve our space, zero out the actual blocks allocated, then return the address of the first block cast to void*.

Implementing free was not a challenge either: either the pointer was above our heap, in which case we simply passed the pointer to newlib‘s free — or if it was in our heap space, we did some arithmetic to figure out which block that address was in, and passed that to lowheap_chunk_release().

I won’t publish the code because I didn’t get it working properly in the end, but I figured I’d put the notes here on how I put it together to re-visit in the future. Maybe the thoughts might inspire someone else. 🙂

One year on in the Russia-Ukraine conflict

It was about this time, news was a-buzz with the talk of tanks lining up on Russia’s western border, then crossing over into Ukraine in a conflict that was meant to be over in a little over a fortnight.

Time must move slow for Vladimir Putin — 12 months in real time and they’re still at it! So that’s approximately one “Putin Day” equates to approximately 26 real days for the rest of us. (Some would argue the conflict actually began in 2014 — I guess there’s some merit in that opinion, but things really began heating up 12 months ago.)

I’ve actually learned a lot about the place. Okay, “a lot” is a relative measure, what I actually know could be scribbled onto the back of a postage stamp with a thick permanent marker, however I am picking up tidbits here and there.

12 months ago, I actually had to frequently correct my spelling — I kept missing the “i” (i.e. “Ukrane”). I wasn’t aware Chernobyl was actually on Ukraine’s northern border with Belarus (or that Belarus was even their northern neighbour). I might’ve heard of Moldova, but wasn’t sure where it was, I had not heard of the disputed territory of Transnistria. Nor did I realise they shared their western border with Poland.

Over the last 12 months I’ve slowly become a bit more familiar with where some of their more major cities are: Lviv in the west, the port cities of Odesa, Mykolaiv (and the general Kherson area — watermelon territory) and we heard lots about Mariupol, particularly the steelworks there. Dnipro and Luhansk in the east, Kharkiv and Sumy in the north-east… Kyiv up in the north.

Point me to a blank map 12 months ago and I wouldn’t have had much idea where those places were, but I have a vague idea now.

I could spot Cyrillic writing before this conflict but couldn’t read any of it. Today while I can’t identify the language, I’m starting to be able to pick out individual letters and recognise the odd word. Various news articles have covered various aspects of the Ukrainian culture. Of course, the before-and-after photos that pop up from time to time showing what was, and what’s just been pulverised by Russian shelling reveal a lot of ornate buildings that are now little more than rubble.

Okay, so little things… very basic facts. The depressing thing is it’s taken a bloody war to even gain a modest familiarity with these things. I have a fear of flying and have no passport, so there’s practically zero chance of me visiting that part of the world.

I guess there was no real necessity for me to really understand the geography of the area pre-conflict, it would have been a personal interest thing if I had done so. Whatever happens though, I think the rest of the world will have to be there ready to help pick up the pieces and help Ukraine re-build.

I wouldn’t be doing business with any businesses based in Belarus, Democratic People’s Republic of Korea (aka North Korea), Eritrea, Mali, Nicaragua, Russia or Syria… and I’d think twice about “no-limits” Russia supporter China.

If the governments in those places change their tune on this conflict, then we re-evaluate, but it’s a fact that supporting business there helps support that country’s government, which only positively-reinforces their current behaviour.

Sadly, with North Korea firing test missile after test missile into the sea, and China eyeing off Taiwan (and its proximity to the Mariana Trench — it’s just about chip fabrication) with jealous eyes — one can only wonder what the next few decades have in store for us.

The real scary thing, I don’t think we in Australia can really count on our allies. The United Kingdom is an utter basket-case post-Brexit and the United States is actually looking very much less united with every passing day as the society there slowly edges towards a race-fuelled civil war.

Methinks we need to start looking at doing things on our own soil, “global economy” looks like it’ll be taking a back seat for a little while!

Demise of classic hardware: the final act

So today I finally got around to the SGI kit in my possession. Not quite sure where all of it went, there’s a SGI PS/2 keyboard, Indy Presenter LCD and a SGI O2 R5000 180MHz CPU module that have gone AWOL, but this morning I took advantage of the Brisbane City Council kerb-side clean-up.

Screenshot of the post — yes I need to get Mastodon post embedding working

I rounded up some old Plextor 12× CD-ROM drives (SCSI interface) that took CD caddies (remember those?) as well to go onto the pile, and some SCSI HDDs I found laying around — since there’s a good chance the disks in the machines are duds. I did once boot the Indy off one of those CD-ROM drives, so I know they work with the SGI kit.

The machines themselves had gotten to the point where they no longer powered on. The O2 at first did, and I tried saving it, but I found:

  1. it was unreliable, frequently freezing up — until one day it stopped powering on
  2. the case had become ridiculously brittle

The Indy exploded last time I popped the cover, and fragments of the Indigo2 were falling off. The Octane is the only machine whose case seemed largely intact. I had gathered up what IRIX kit I had too, just in case the new owners wanted to experiment. actually has the images, and I had a crack at patching irixboot to be able to use them. Never got to test that though.

Today I made the final step of putting the machines out on the street to find a new home. It looks like exactly that has happened, someone grabbed the homebrew DB15 to 13W3 cable I used for interfacing to the Indy and Indigo2, then later in the day I found the lot had disappeared.

With more room, I went and lugged the old SGI monitor down, it’s still there, but suspect it’ll possibly go too. The Indy and Indigo2 looked to be pretty much maxxed-out on RAM, so should be handy for bits for restoring other similar-era SGI kit. I do wish the new owners well with their restoration journey, if that’s what they choose to do.

For me though, it’s the end of an era. Time to move on.

Earmuff headset reverse engineering

So, previously I’ve tried looking for a suitable earmuff headset, and drew blanks: they wanted $400+ for them and I wasn’t willing to spend that much. That said, there are times when such a headset is useful: if it’s raining heavily on the roof of the annex, hearing the radio is bloody difficult!

Now, my tactical headset should fulfil that, but really it was intended for less noisy environments. What if that’s not enough? Years ago, Brisbane WICEN used to help out with the car rallies, and there you really do need something that will muffle outside noise. I had tried to make my own, with limited success, but one wondered how the commercial options compared.

The other day, I spotted this earmuff headset. One thing I note, the seller seems unaware of how these things are worn — that’s a neck band fellas, not a head band. (Or maybe their ears are wider than they are tall? Mine are taller than they are wide.)

This is up the upper limit of what I was willing to spend, but what the hell… we’ll try it. They arrived today (about 6 days ahead of schedule). They’re comfortable enough — sound dampening is reasonable. I like the fact the microphone is on the right side. There’s a PTT button on the left ear-cup and a volume control on the right.

Being a behind-the-head design, it plays nice with my hard hat too. The head strap is a little tricky in my case, since my hard hat has a chin strap — I figured out I had to undo the head strap, thread the headset through the chin strap, then put hard hat and headset on together. I should be able to wear it with the coolie hat as well.

A downside is basically when I do this, I can’t take the headset off without taking the hard hat off too, but the intent of this was something that I was going to leave on anyway, and the same criticism is true of the tactical headset too.

The headset, with its packaging and cables.

One wrinkle is that this headset you can see, uses a Kenwood-style pin-out — my Kenwood TH-D72A died recently, so great timing there. Luckily for us though, it’s just a small pigtail: we can make our own up to suit this pin-out. The pig-tail actually is a 6-pin Mini-DIN: Jaycar part number PP0366. I was thinking of chopping cables, but this is even simpler, we’ll just make our own pigtail.

At the other end, it appears to be a 5-pin mini-XLR, but I haven’t tried buzzing that out at this stage. As is typical with comms headsets, this one is mono. There’s a 3.5mm jack (left earcup) for plugging in a comms receiver or media player, and it works — in mono. The microphone appears to be an electret.

For now, I’ve decided to have a look at reverse-engineering the pin-out to use the headset as-is. I rummaged around and found the aforementioned connector in my junk box, still sealed in its packet, so I opened that up, and used the little insert inside to plug into the socket, put the headset on, and went buzzing with the multimeter. Using the Kenwood pigtail for clues (since I know the Kenwood pin-out), I located the PTT, speaker and microphone connections on the headset cable.

One pin appears to be a no-connect; the PTT and microphone are commoned.

Reverse-engineered Mini-DIN 6 pin-out

Set up a Mastodon instance

So yep, following my recent post about Twitter, I bit the bullet after some thought… I’m now reachable over Mastodon. I decided I’d start small, deploy my own instance where I could play around and get to know it.

In particular, as I’ve started doing a few small websites for people based on WordPress — social media integration has come up in these discussions — I figure it’s better to test against my own instance rather than me throwing pre-alpha grade code at someone else’s production server. I can’t do this with Facebook, I can’t do this with Twitter, but I can do this with Mastodon. If either of those two decide to implement ActivityPub protocols, sure, I’ll let them connect.

There’s also the practice I’ve been engaging in for some years, of just emailing links to sites I stumble across to people who I think may be interested — some of those could be posted on Mastodon since this is a format that would suit that use case well. Maybe cartoons, images — although I need to watch copyright!

The fact that I was able to deploy it on my own hardware, means I can be 100% responsible for what I post there, and post there 100% on my own terms. While I’m unlikely to intentionally post something inflammatory, when someone else owns the house, they make the rules, and they can change the rules when they like. Some journalists found this out the hard way, when Twitter banned them for discussing the ElonJet Twitter account. Then scores of people got hit by the ban-hammer for simply mentioning rival social networks. A month ago, there was nothing wrong with doing this, now it’s taboo on that social network. Seems ironic that a “social” network must be so anti-social.

Individual server admins might block my server, and that’s fine, that’s their right. Big deal. As stated, this is more for me to learn in a controlled environment. By me posting here, I cost them nothing unless one of their users decides my content is interesting, and me subscribing to a few posts can be done with minimal impact. I think the risk of this is low.

Right now, I’ve just “followed” a few IT and general journalists… to get a rough “feel” for how this stuff works. Following someone “cross servers” like this is a little clunky, but I can understand why it is that way: when you visit the remote server’s page, to them you’re an anonymous user — I don’t think there is a way yet to safely “identify” yourself to a Mastodon server without identifying yourself to every Internet web page. Maybe that’ll be worked on as time progresses, who knows? Time will tell.

I don’t expect to “toot my own horn” on Mastodon much. Those who are interested in what I’m doing can look up what I’m up to directly. I think most of the Mastodon content I post will be articles others have written. Then again, this whole blog started in 2006 as a way of publicising my activities in Gentoo, and look where it is today? It has evolved, and so might this. Once again, only time will tell.

Yaesu FTM-350AR audio interface: part two

Today I rummaged through my junk box and pulled out:

  • a screw-terminal type RJ-45 jack
  • a 3.5mm stereo panel-mount socket

Sadly, the socket is too big to fit inside the RJ-45 jack housing, but I was able to cobble together a test using the jack as a break-out.

As it happens, there’s some repeater traffic that I’m hearing through the tablet beautifully. I set up Mumble to just transmit on VOX activity — this seems good enough. The signal out of the radio is quiet, so VOX works well enough for detecting the incoming signal with no false detection.

There’s a fraction-second delay, which is to be expected for a cobbled together Radio-over-IP solution such as this. It’ll be annoying if you happen to be next to the radio, but probably fine if you’re away from the radio (or you use a headset so you hear the delayed signal through the headset louder than the real-time signal out of the radio).

Things I need to look into from here:

  • Computer transmit audio interface
  • Computer PTT interface
  • Mumble integration into the above