womod

We keep a FreeDOS machine at work for dialing in to configure and service paging terminals and using old two-way radio programming software.

Most of the stuff I've moved over to run in DOSbox but it's still in use occasionally for the software that's difficult to port over.

Yup, thanks big M for making things fun as usual. I deal with the same thing on the P25 side.

There's quite a few clocks available that get their time over the air from the NIST WWVB radio station[0]. They usually have a little switch on the back if your area does/doesn't observe daylight savings.

[0] - https://www.nist.gov/pml/time-and-frequency-division/time-di...

Right, but more specifically they are most often used for scanning stuff like air-band and VHF/UHF two-way radio traffic. Nowadays with a lot of public safety being digital P25 (requiring more expensive scanners) and online streams being so easily available, there's not a lot of reasons to buy a scanner unless you're really passionate about it.

That's due to the DOCSIS standard for cable modems. They specced out more channels for downstream than upstream because of the limited bandwidth of copper and consumer priorities. With fiber there's an order of magnitude more bandwidth available, so the uneven split is much less (if at all?) common with the big backhaul lines between datacenters. For consumer fiber you'll usually get symmetric but for the most part it doesn't make sense as the vast majority of consumers just don't make use of their upstream bandwidth.

You'd be suprised, the shear amount of black box vendor nonsense out there borders on astronomical. Weird telco stuff, old cisco hardware, BMCs in servers, it would mean gutting probably millions of dollars of equiment. It's stupid, but throwing the baby out with the bathwater over openssh won't make anyone happy.

You can unlock the bootloader of the 2018 Fire HD 8 if you force it into download mode by opening it up and shorting the CLK test point to ground. Older tablets don't need to be opened up, it's all just software. Everything after that though has been unable to have the bootloader unlocked.

No. The last "mainstream" console to use hall effect sticks in the first party controller was the Dreamcast, and that was in 1999.

Controllers that use hall effect sensor sticks last much longer than the conventional potentiometer sticks. The pot sticks are subject to physical wear while the hall effect sticks are not because there is no contact.

There's some guides on aftermarket modifications of controllers to convert them to hall effect sensors, as well as 3rd party controllers made with hall effect sticks. If you want something to use on PC and/or switch the KingKong 2[1] from GuliKit is pretty good.

[1] - https://www.amazon.com/dp/B09QJN8ZD9

Gasoline is absolutely not that dangerous, at least relative to the risk involved every time one drives a car. For igniting gasoline fumes, a spark is almost always necessary. Realistically speaking, a lit cigarette has a better chance of setting a nearby trash can on fire than igniting the gasoline fumes. If a person were to spark a lighter to light a cigarette that'd be a different story.

https://www.pennlive.com/midstate/2010/03/gas-pump_fire_that...

https://content.nfpa.org/-/media/Project/Storefront/Catalog/...

MicroG is an option, it's an open source implementation of a good portion of play services, though not everything "just works". But for the bare minimum like functional push notifications, location services, etc it's not half bad. There exists a fork[1] of lineage with MicroG installed from the get-go, otherwise installing it can be a little painful.

[1] - https://lineage.microg.org/

That's funny, there exists a similar issue with the LG G7 that a friend of mine ran into several years ago. The fingerprint sensor on his phone just straight-up completely stopped working, and subsequent OS updates did nothing to fix it. At first we assumed it was hardware failure, and he was ready to send it to a repair shop. While investigating it I saw a comment somewhere that it had something to do with the light sensor, and after holding my thumb over it for 10 seconds it "magically" started working again after 4 months of being completely non-functional.

In the two-way radio world, most protocols are open (P25, DMR, LMR, etc.) but almost every digital protocol uses the AMBE[1] voice codec, which is not.

[1] - https://en.wikipedia.org/wiki/Multi-Band_Excitation

Google Play Services implements a lot of increasingly vital features and interfaces on Android. Not having it kills a good number of things people consider important, like push notifications (some apps are designed to still send push notifications like Signal, but it's kind of a hack and does drain the battery). If you're looking for almost the same functionality without google play services, MicroG[1] is an open source implementation of Google Play Services and its' associated components. I don't think it works on GrapheneOS unfortunately, but GrapheneOS already sandboxes all the Google Play Services components, so you should be fine as is. "Normal"/stock Android roms aren't set up the same way however, so you pretty much need either Google Play Services or MicroG for push notifications, location services, etc.

[1] - https://microg.org/

Such multi-site, same frequency broadcasting setups are usually called Simulcast, and are still used for some public safety trunked radio systems in the U.S. The biggest issue with simulcasting is the need for extremely precise clock synchronization and the audio carrier generation, to the point where something like using a slightly different soundcard can result in massively distorted received audio due to the effects of FM doubling. Clock synchronization is usually achieved via GPS, there's a good number of off-the-shelf solutions available. But when it comes to the audio path, it's typical to use the exact same hardware across all sites because otherwise controlling for even the smallest of differences when attempting to troubleshoot becomes an huge hassle. At the beginning of this blog post[1] is a brief overview of some things to take into consideration when building a simulcast system.

[1] - https://www.hamradiodx.net/building-a-simulcasting-voting-re...

Have a listen to USA CB Channel 6 (27.015 MHz / 27105 KHz) if you'd like a taste of what true freedom is like. Best way to listen in without an actual receiver is a WebSDR, here's one[1] that can tune to it.

[1] - http://kiwisdr1.sdrutah.org:8073/

Antenna type and design can make all the difference in the world with regards to performance. Even plain-old 2.4GHz or 5GHz WiFi can work great over large distances provided that you use a parabolic reflector, yagi, log-periodic, etc. Microwave linking is all the rage nowadays, with WISPs popping up all over the place and large commercial operators using microwave links as backhaul between internet-connected sites (usually cell tower sites). But LoRa is still really awesome for low-bandwidth data with minimal antenna considerations, and having it be such a convenient standalone package with some of the boards available is just icing on the cake.

A good number of stage lighting controllers have the ability to interface with and handle MIDI, but the vast majority of stage lighting equipment is controlled using DMX[1]. The two have a lot in common, being pretty much ubiquitous and rock-solid even given their age.

[1] - http://www.dmx-512.com/dmx-protocol/dmx-protocol-basics/

I agree that the lack of a microSD slot is annoying, though not entirely unreasonable with the whole value proposition of a "ruggedized" phone.

The FM radio is entirely baked-in to the MediaTek MT6789 SoC, and uses anything connected to the 3.5mm jack as the antenna for better reception. Assuming this thing is intended for use at jobsites, it's not entirely unreasonable to assume that having a functional FM radio and 3.5mm jack would be desired.

WSL2 is for the most part totally usable for everyday development, but it does have a handful of issues that either need workarounds or are just infeasible.

USB passthrough isn't yet supported, so it's necessary to make use of something like VirtualHere[1] or some another TCPIP tunneling daemon running on the windows depending on what you're trying to do.

There seems to sometimes be issues with resuming from S0ix sleep where the VM process is still "running" but it gets stuck in a state where new processes just will not spawn. It's been a while since I messed with it, but my "solution" was disabling a VM security measure, launching Process Hacker 2 as admin, searching for "lxss" in the process list and terminating the corresponding svchost.

The actual linux kernel running inside WSL2 is interesting, it's microsofts own custom kernel[2] with some magic sauce for making everything play nice. Unfortunately, it (still?) lacks a fully-functional SystemD so making some programs work can be a chore. Also all the kernel modules compiled in, and it doesn't allow loading them dynamically with modprobe. There are some alternative kernels out there that solve some of these issues, though I haven't bothered to try any since whenever I run into these sorts of issues it's less of a hassle to just switch to a dedicated linux box.

For all of the issues that come with Windows 11, having WSLg make running graphical programs "just work" out of the box with rock-solid copy/paste, alt+tab, etc., really makes it a joy to work with.

[1] - https://www.virtualhere.com/

[2] - https://github.com/microsoft/WSL2-Linux-Kernel

I recently managed to "hard-brick" my Motorola one 5g ace after updating magisk, getting stuck in a bootloop, and naively deciding to attempt to boot from the B slot instead. On qualcomm-based devices you can get into EDL (Emergency DownLoad) mode where you have nothing that is actually bootable on the device, and the phone will remain entirely unresponsive save for appearing as a serial device when plugged in over USB. You then need to "talk" to the phone with the appropriate protocol (Sahara or Firehose depending on the age of the device) and you can gradually work towards recovery. In my case I was able to manually reconstruct a valid bootloader.img for my particular software version, re-flash it, and get back into a "soft-brick" state from there.

However, I do know of some slightly older HTC devices that would have the EEPROM straight-up completely die, leaving the device permanently trapped in a "hard-brick" state unless someone felt like doing some BGA soldering.

Modern phones do have a lot of stuff running under the hood that makes it a lot harder to mess things up, but once you go off the beaten path things become much less certain.

OpenWebRX[1] is a similar open-source sdr frontend, KiwiSDR is based on a slightly older version before it was picked up by a new maintainer. It's really nice being able to use the digital protocol decoding baked-in to it. Usually in the VHF ham band you can park it on the default "PACKET" bookmark and look at all the APRS traffic going around, and if the person running it has added the VHF/UHF buisness bands in that particular area the POCSAG decoder works great. Same for the digi protocols like FT8 et al. on the HF ham bands.

There's also another online directory[2] of mostly all available KiwiSDR, OpenWebRX, and WebSDR receivers with a cool map view.

I ran an OpenWebRX node for a good while before taking it down with the intention of upgrading it to an SDR with a wider bandwidth and a few multi-band antennas for better performance, might get around to finishing that up now.

[1] https://www.openwebrx.de/

[2] https://www.receiverbook.de/

I think the radio engineers suffer at the hands of poorly-shielded switch-mode power supplies and inadvertent spark-gap transmitters caused by aging powerline infrastructure more than anything else.