www.h-i-r.net Open in urlscan Pro
2a00:1450:4001:802::2013  Public Scan

Form analysis
1 forms found in the DOM

http://www.h-i-r.net/search

<form action="http://www.h-i-r.net/search">
  <input width="80px" name="q" type="TEXT">
  <br><input type="SUBMIT">
</form>

Text Content

skip to main | skip to sidebar



2021-05-27


DEDICATED PAGE FOR MULTI-BOOTING WINDOWS 10 AND OPENBSD

Posted by Ax0n

I've created a dedicated page with my guide for Multi-Booting Windows 10 and
OpenBSD. This supersedes the earlier blog post on this topic. I've been running
this setup for a few months now and I seem to have ironed out most of the
gotchas, including how to, as elegantly as practicable, deal with Windows'
BitLocker shenanigans as well as its tendency to override the rEFInd boot
manager.





Digg This! • Email this • Save to del.icio.us

0 Comments

Labels: boot, bsd, openbsd, unix, Windows




2021-05-01


OPENBSD 6.9 RELEASED, PHP/MYSQL PAGE UPDATED

Posted by Ax0n

 


The 50th release of OpenBSD hit the mirrors last night, but I had some problems
installing packages -- they were out of sync a bit. Anyhow, today, all of the
package repositories on all the mirrors seem to be working swimmingly (you see
what I did there?) and getting OpenBSD's built-in HTTPD working with PHP 8.0.3
and MariaDB (a MySQL Fork) 10.5.9 is a breeze. I've updated the OpenBSD
HTTPD/PHP/MySQL page accordingly.



I'm most excited about a number of fixes in the VMM hypervisor that mean it can
once again run some of my Linux virtual machines that have newer kernels. That
had been broken for quite a while. There are also some changes to video and
audio subsystems that I feel like might have been driven by some of my input on
the mailing lists. The world may never know. 

In news that's related only by virtue of OpenBSD tinkering, I also managed to
get OBS Studio working on OpenBSD-CURRENT, which just required me to figure out
how to get the excellent openbsd-wip ports tree working alongside the official
OpenBSD Ports. I'm still figuring out how to tune OBS to get high-quality live
streams working, and at present, directly attaching the webcam to OBS results in
a Kernel Panic. So there are some bugs to iron out.






Digg This! • Email this • Save to del.icio.us

0 Comments






2021-03-23


REVIEW: OPENBSD 6.8 ON 8TH GEN LENOVO THINKPAD X1 CARBON 13.3"

Posted by Ax0n

10 days ago, I bought this X1 Carbon. I immediately installed OpenBSD on it. It
took me a few days to settle in and make myself at home, but here are my
impressions.

This was the smoothest experience I've had getting OpenBSD set up the way I like
it. The Toshiba NB305 in 2011 was a close second, but the Acer I used between
these two laptops required a lot more tweaking of both hardware and kernel to
get it to feel like home.


THE BAD NEWS


Let's start with what doesn't work flawlessly on the ThinkPad under
OpenBSD-STABLE (6.8 with all patches to date applied), roughly in the order I
noticed them. At the moment, the issues with the TrackPad and browser webcam are
the only outstanding annoyances. Everything else was easily addressed with basic
configuration adjustments.



THE RESOLUTION IS JUST TOO HIGH. 

First world problems. While I admire cramming a full-blown 4K UHD into this
diminutive portable workstation, at 3840x2160 on a 13-inch-class display,
everything was too small to read. Windows and MacOS both handle the ever-growing
number of pixels on a display by having a "scale" item in the display
properties. While display managers designed for BSD and Linux, such as XFCE or
GNOME, do have the ability to scale items, these scale settings don't work
globally across all applications in a predictable way.


The high-DPI display was most problematic during installation, wherein the
kernel modesetting used the native screen resolution for the text-mode
installer, with each line of text being barely a millimeter tall. I literally
wore a headset magnifier to install OpenBSD on this thing. After install, the
console was a reasonable size. I don't know why the installer used such a high
resolution, but suppose it could be related to firmware for the on-board
graphics adapter that's not present in the install media but is present after a
full install and fw_update.

Upon logging in to X and opening a terminal window, I had to bump up the font
size just to see what's going on. I opted to just decrease the resolution of my
display to solve this problem. Using xrandr to experiment with different 16x9
resolutions, I settled on 2048x1152, though plain old 1080p is also quite
pleasant. I added this lovely gem to my .xinitrc file before calling the desktop
environment:

xrandr --output eDP-1 --mode 2048x1152





THE TOUCHPAD OCCASIONALLY GOES NON-RESPONSIVE. 

I think this may be hardware-level wrist-detection stuff at work, but backing
completely off the computer and trying to use the touchpad doesn't fix it. I
often have to use two or three fingers at a time and repeatedly tap the touchpad
to get it to come back. Thinking about it now, I should probably see if it works
after I just leave it alone for a few seconds. In the meantime, I disabled the
trackpad in the BIOS and I'm trying my very best to embrace the TrackPoint
"Eraser Head" pointer. If you know what's going on with the touchpad, let me
know.

 


THE TRACKPOINT DOESN'T SCROLL BY DEFAULT UNDER X.

On Windows, you can scroll by holding the center TrackPoint button while moving
the TrackPoint head. This didn't work by default -- center button is "paste" by
default under X. I was able to make some more additions to the beginning of my
.xinitrc file to get it right, where clicking the center button pastes the
clipboard contents, and holding it allows you to scroll with the TrackPoint:




xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5

 


AUDIO QUALITY WITH THE DEFAULT SETTINGS

The audio sounded a little tinny and not all that loud when I first played audio
over them. Part of the backstory of my admiration of the ThinkPad X1 line is
that I pay attention to OpenBSD developers and what they say about hardware.
ThinkPads get a lot of praise from the developers I follow, and in one of jcs@'s
recent-ish blog posts about the previous generation of X1 Carbon, there was some
concern about the audio output. I noticed that while sound was coming out of the
"bass" speakers on the bottom of the wrist rest and the "treble" speakers on top
near the screen hinges, the tone of the sound coming out of all of the speakers
seemed amiss -- and muting the small speakers made it sound better. It turned
out to be the same problem as jcs@ noted on the 7th gen X1 Carbon, and adding
this line to /etc/mixerctl.conf fixed it, while providing crystal-clear sound
through all 4 speakers:

outputs.spkr2_source=dac-0:1


When this laptop's audio is firing on all cylinders, it sounds positively
amazing given its size. I've had big old chunky gaming laptops with big old
woofers inside them that didn't sound this good. What it has in audio quality,
it lacks, just a little, in maximum volume, but it's more than loud enough to
fill my workspace with sound, whether I'm in the back of my camper-van or
hacking away in my home office.





WEBCAM SUPPORT IN THE BROWSER

YouTube, Discord and some other sites will TRY to use the webcam and microphone
- and take note of the kern.audio.record (and upcoming kern.video.record) sysctl
options. On Discord's web app, I briefly see my webcam video as the webcam
activity LED illuminates, then the LED turns off and Discord returns an error.
On YouTube, I never see my own video, but the webcam activity LED blinks
briefly. Video capture tools such as ffmpeg and vlc work quite well with the
webcam. Given that, I believe there's probably a simple fix to make it work
flawlessly, I just haven't found it yet. I'm looking forward to a time,
hopefully soon, when I can use an official package or port of OBS Studio, maybe
even with working virtual camera support.


 


THE FINGERPRINT READER ISN'T SUPPORTED

jcs@ also noted the same of the 7th generation X1 as of 2019. It doesn't bother
me in the least. Maybe it'd be neat to log in to OpenBSD with a fingerprint, but
I've been using OpenBSD for 21 years without it, so I don't miss the
functionality and it's only barely worth mentioning.  





NO BLUETOOTH


Bluetooth has been unsupported by OpenBSD for many years. I don't miss it, but
if you decide to try OpenBSD, you might notice that there is no Bluetooth stack.



THE GOOD NEWS

What works? Basically everything else. 

 * The function keys for volume, mute, brightness, and keyboard backlight worked
   without any hassle
   
 * The built-in ethernet port (which requires a dongle to use) has full support
   in the kernel via em(4) without requiring a firmware blob.
 * After loading firmware, the on-board Intel WiFi6 adapter is fast and
   functional via iwx(4). 
 * Sleep/suspend/wake works well via zzz(1) or simply closing the laptop lid.
   Similarly, using sysctl to disable sleep when the laptop is closed works and
   it will stay running while closed.
   
 * WebGL applications, such as some of my favorite online games, work fine now.
   About a year ago, none of them worked. It could just be that my old laptop
   didn't have enough resources for these web applications.
 *  YouTube, Social media applications, Google Drive, etc... all good.
   
 * Even the USB microscope that I use for small electronics work and examining
   small mechanical parts such as those found in locks and analog watches works
   great with VLC once I'd created /dev/video2 and set up device permissions.

Battery life seems good. I have been using this laptop for about 3 and a half
hours before and during the writing of this review, with moderate screen
brightness, several "hungry" tabs open in Firefox and with pianobar (a CLI
Pandora client) blasting my "Orbital" inspired playlist. I have two OpenBSD
virtual machines running in vmm, though I'm not currently doing anything intense
with them. I've been on battery the whole time and I've got 43% battery
remaining, with an estimated run time of about 2.5 hours remaining. I can deal
with 6 hours of untethered run-time under my usual working conditions.


The system temperature has hovered in the 40-60*C range most of the time, though
it got a little warmer when certain browser tasks get rolling. The cooling fan
has remained off almost the entire time, but when it's running, it's still very
quiet.


I was a little worried that I'd have a "never meet your heroes" moment when I
bought this laptop, and that it might not live up to the expectations that I
had. So far, it's everything I need and then some.






Digg This! • Email this • Save to del.icio.us

1 Comment

Labels: laptop, openbsd, unix




2021-03-17


MULTI-BOOTING OPENBSD AND WINDOWS 10 ON MODERN HARDWARE WITH REFIND

Posted by Ax0n

The information here has been refined and documented in a dedicated page for
Multi-Booting Windows 10 and OpenBSD. That page has all up-to-date details, and
this post is no longer the best available source of information on this topic.


I recently purchased a 13.3" 8th Gen Lenovo ThinkPad X1 Carbon. Frankly, the X1
series has been my dream machine for years. I like small laptops, and this one
is light, powerful and is similar to what's used by many of the OpenBSD core
developers, so I knew it would probably be well-supported. My previous laptop --
the Acer I upgraded to an i5 for VMM years ago -- was set up for dual-boot, but
somewhere along the way, the Windows boot manager stopped booting OpenBSD so I'd
been using a modified OpenBSD install image on an SD card to load the OpenBSD
kernel from the internal SSD, I set the BIOS to prioritize the SD card for
booting, and I just remove the SD Card from my Acer if I need to boot Windows.
That laptop is growing long in the tooth, but it's served me well for the past 5
years.


I decided to try properly dual-booting Windows and OpenBSD again with my new
ThinkPad. And that's where things got ugly.

The steps to get Windows and OpenBSD working together, as outlined in the
OpenBSD Multibooting FAQ seem to not work at all on recent Windows 10 versions,
and especially on modern PCs with EFI and GPT disks. I tried several times
without any luck, and I also rendered my system unbootable a number of times in
my quest. Fortunately, I had made recovery media so I could blow away my X1
Carbon to factory defaults when things went sideways. That's a 45 minute process
each time.

Start with a Windows install, and have good backups, including, if possible,
external recovery media from the manufacturer. Several times, the drive
partition table was so screwed up that the recovery partition was missing as
well, leaving me with the recovery USB stick as my only way forward. To resize
the Windows partitions, you will have to completely disable BitLocker full-disk
encryption if it's enabled. I am a fan of FDE, but we have to turn it off for
this to work. You can re-enable it when you have your whole system back up and
running, but there are come caveats at the end.

Create a Live USB of GParted.

On another USB stick, write the contents of the OpenBSD installXX.img. This link
references install68.img from OpenBSD 6.8, which may be out of date or a broken
link when you read this.

Boot into the gparted live distro. On modern EFI/UEF systems, you will probably
need to adjust secure boot and/or legacy boot options in your system's BIOS to
continue.

Shrink the main Windows partition by some amount to make room for OpenBSD. I
gave myself 120GB. That's how much room I have dedicated to OpenBSD on my Acer,
and it seems to be a good size. I also usually create another FAT32 or Exfat
partition that I can store files on to be accessed from both OpenBSD and
Windows, but that's beyond the scope of this write-up.

Create a new partition for OpenBSD in the empty space. GParted doesn't know
about OpenBSD partition types, so you'll have to then close GParted and launch a
terminal window from the live environment. You'll have to launch gdisk via sudo
and address your drive's device. For example:

sudo gdisk /dev/nvme0n1

Use the "p" option to print a list of partition entries. Find the one you
created and use the "t" option to change the partition type to "A600" which is
what OpenBSD expects to use for its disklabel entries. "w" will write the GPT
and exit. You may also want to use the "b" option before you exit to make a
backup of your partition tables just in case you mess something up. You'll have
to store it to a USB drive, but you can probably store it on the same USB stick
you booted GParted from.

At this point, I decided to reboot and make sure Windows still works.
Thankfully, it did. Reboot into the OpenBSD installer using the USB stick you
created. I won't walk through the whole installer process, but pay very close
attention to the disk partitioning options. When prompted for the disks to
install OpenBSD to, you should see an "OpenBSD Area" option and that should be
the default disk partition to install to. If that option doesn't exist and you
choose "gpt" or "whole disk" you will destroy the GPT record on your drive and
destroy the Windows installation. Your system will only boot into OpenBSD if you
proceed. You can probably use gdisk and your backup of the GPT to recover the
partition table if you didn't actually install OpenBSD, or you may have to
reinstall Windows and start all over again, and that isn't fun. Trust me. I've
done that four times this week. Don't let the system do an auto-layout. Choose
"custom." Unless you know what you're doing, just make one big disklabel
partition for OpenBSD's root drive.

Once OpenBSD is installed, exit to the shell. You will need to copy the EFI boot
executable to some other media so you can access it from Windows. I inserted a
USB stick that was formatted for FAT32. It showed up as sd1 and the first
non-BSD partition typically shows up as "i"

mkdir /usb
mount /dev/sd1i /usb
cp /mnt/usr/mdec/BOOTX64.EFI /usb/bootx64_openbsd.efi
umount /usb

Go ahead and reboot. It should boot into Windows. Fingers crossed!

Now, go download rEFInd and unzip the archive. I followed the Windows manual
install instructions to get rEFInd working. I rebooted again, simply because I'd
become so accustomed to bricking my shiny new laptop. To my surprise, rEFInd
presented me with a boot menu. Windows showed up, and an additional menu item
called "Fallback boot" also appeared. This menu option booted me into OpenBSD.
That could be pretty much the end of it, but I wanted an actual OpenBSD menu
option.

To accomplish this, I borrowed some mojo from this somewhat dated blog entry on
FunctionallyParanoid

You have to access the EFI system partition from a privileged command shell
(hearkening back to the instructions to manually install rEFInd from Windows),
so I copied the refind.conf file off to my Documents folder, edited it with
notepad, then saved it and copied it back over to the EFI system partition.
I added this clause near the end of the refind.conf file:

menuentry “OpenBSD”
{
icon \EFI\refind\icons\os_openbsd.png
loader \EFI\boot\bootx64_openbsd.efi
}

Make sure to download the OpenBSD icon and place it in the \EFI\refind\icons
folder, too. Once I did that and rebooted, rEFInd still had the "fallback" menu
item, but OpenBSD showed up with its own logo alongside the Windows logo. Both
operating systems boot, and my mission was finally accomplished.








Digg This! • Email this • Save to del.icio.us

0 Comments

Labels: hardware, laptop, openbsd, unix, Windows




2020-09-21


MOBILE WEATHER BALLOON CHASING RIG

Posted by Ax0n

A few locals (mostly part of the SecKC crew) have been chasing weather balloons
for the past few months. It's an interesting way to get out of the house and go
do something. We are also trying to reverse engineer the guts of these weather
balloon payloads, but that's a story for another post.


WEATHER BALLOONS AND RADIOSONDES

In the US, a number of National Weather Service offices (I'm guessing about a
third to half of them) deploy weather balloons every day at about 0:00 and 12:00
UTC, give or take an hour either way. They often launch at about 45 minutes
ahead of time, but they can be delayed by severe weather. That's over 700
weather balloons per year from each of the dozens of stations that launch them!

The weather balloons carry something called a radiosonde into the stratosphere.
This package contains a battery, radio transmitter, GPS, and weather sensors.
The radio transmissions include position information, humidity, temperature and
other metrics, once per second. Position information is used to determine wind
speed and elevation to correlate with the other metrics. This data is shared
internationally and is used for local forecasts and models, and worldwide
climate trends. 

Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6
Radiosonde.



The air gets thinner and the pressure lowers as the balloon climbs past 100,000
feet, and it eventually bursts. The package, weighing less than a pound, falls
back to the ground under a small parachute so that it doesn't hurt anyone or
anything when it lands. 

Here's a video I shot through a telescope, of a weather balloon bursting at
about 130,000 feet. You can faintly see the radiosonde swinging beneath the
balloon. When it bursts, the parachute expands as the package falls.

 


A recovered weather balloon, after untangling all of the rope.



The National Weather Service does not recover these devices from the field. Some
of them have a mailing bag and shipping label attached so that folks who find
them can return them to be refurbished. The radiosondes that we've been finding
have no instructions aside from "dispose safely". That is to say, once they have
fulfilled their mission and landed, these radiosondes are very much "finders
keepers" and are no longer government property. They can land more than a
hundred miles away from the launch site, depending on jet streams and wind
conditions closer to the surface.


TRACKING

To facilitate the tracking of these devices, a number of software tools have
been created to make use of software-defined radio receivers (such as the
RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My
favorite tools are radiosonde_auto_rx and chasemapper, both part of Project
Horus, an amateur radio high-altitude-ballooning project in Australia. The tools
to monitor amateur balloons happens to work just fine for tracking weather
balloons, and folks have added code to help decode the payload data for weather
balloons. 

radiosonde_auto_rx scans a small range of frequencies you define, looking for a
signal that's likely to be a radiosonde. It then tunes to that frequency and
tries to decode the location data. Once it's locked on, it continuously tracks
the location of the balloon. It can also upload balloon location data to
websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon
tracking), so folks can share data about these balloons' trajectories with a
world-wide audience.

Screen shot from sondehub.org showing multiple weather balloons in flight, and
locations of auto_rx sites:






Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your
location from local GPS data, then draws a map of your location and the
payload's location, in a browser session. This is a nice visual aid when you're
planning on recovering a radiosonde. Here's a screen shot showing my vehicle's
track and a radiosonde payload location on a recent balloon chase. The payload
location doesn't have a track following it because I rebooted my setup to move
it to my car. The movement was from me hiking toward my car while unplugging the
battery.





BUILDING THE MOBILE TRACKER

I decided I'd like to build a semi-mobile balloon tracker that I could leave
running at home most of the time, but also quickly toss into my car or even
carry with me if a radiosonde was going to be landing nearby, to help me recover
it from some corn field or woods or an 8-foot tall patch of thistles and prairie
grass out in the middle of nowhere. These things never seem to land anywhere
convenient, like in the ditch of a dirt road. 

I decided to make do with stuff I already had laying around. You may recognize
some pieces from previous articles. The below links are Amazon affiliate links
to the parts I used if you wish to reproduce my exact setup, and purchasing from
these links supports this site).



 * Raspberry Pi 3 with an AdaFruit 3.5" TFT
 * RTL-SDR v3 receiver kit or NooElec NESDR Nano Three kit (you only need one
   SDR, both of these models work in this setup)
 * Inseego MiFi 8800L WiFi Hot-Spot
 * Rii wireless mini keyboard/trackpad
 * 26800mAh USB battery pack






The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx
can upload location data and chasemapper can download map data, but it also has
a GPSd server integrated so other devices (like the Raspberry Pi) can use the
GPS location of the hotspot. You must log in to the MiFi admin page to activate
the GPS Service. By default, it runs on port 11010, and it's recommended to
leave that default set.

Actually getting chasemapper to use that GPS data turned out to be more trouble
than I had bargained for. You may be better-off connecting a USB GPS to your
Raspberry Pi. I'll cover how I managed to cobble everything together as I go
through this post. 

The first order of business was installing the latest RasPiOS to a fresh 16GB SD
Card. There is more than enough documentation on raspberrypi.org to get you
started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick
your poison. I chose to use the nano-receiver because bluetooth seems to not
like to auto-reconnect on reboot some of the time. Feel free to use whatever
kind-of-portable human-interface device you like.

Next, I had to get the display working. 

I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with
Kali Linux, and the instructions I wrote about setting up fbcp worked fine on
the latest RasPiOS. You can follow most of the instructions in that article to
get the AdaFruit TFT working, just keep in mind the touch screen won't work with
the fbcp driver. The digitizer on my display actually broke a few years ago, so
I don't miss it.


For my setup, I uncommented the following lines in config.h. Note that these
lines need the # at the beginning of the line. I removed the // from these two
lines to uncomment them:



> #define DISPLAY_ROTATE_180_DEGREES
> 
> #define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING






I used the following options to build fbcp:

cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 ..


As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top
of /etc/rc.local so that it runs on boot.

I set my display up to run in 480p mode since the display is so tiny. The
entirety of my /boot/config.txt file is:



> hdmi_force_hotplug=1
> 
> dtparam=audio=on
> 
> hdmi_group=1 
> 
> hdmi_mode=3 
> 
> dtoverlay=pwm,pin=18,func=2




Reboot and make sure the TFT display works.




Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to
install a bunch of dependencies. They recommend installing rtl-sdr from source.
I just added it via apt, and it supported the bias-tee option. Make sure you
install the udev rules and module blacklist options per the instructions. 

Keep following the instructions. Maybe, if you're lucky it'll just work. For me,
though, I had to do some hacky garbage to get it to compile. If build.sh fails,
you can try these tricks: 

I had to tell the compiler use the c11 standard for compiling fsk_demod by
adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:

> gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o
> fsk_demod



I had to tell the compiler to use the built-in alloca() for some reason, and the
real baffler was having to define the meaning of freaking Pi, twice.

In utils/fsk.c, I added these lines to the "includes" block near the top:



> #define alloca(x)  __builtin_alloca(x)
> 
> #ifndef M_PI
> 
>     #define M_PI 3.14159265358979323846
> 
> #endif






And I added the following to utils/modem_stats.c, also near the top. 






> #ifndef M_PI
> 
>     #define M_PI 3.14159265358979323846
> 
> #endif



With all that out of the way, the instructions for setting up Radiosonde_auto_rx
work just fine. Make sure to edit station.cfg. You probably want to specify a
name, callsign or handle for uploading to HabHub (and enable uploads), and you
should specify your latitude and longitude. You could, in theory, also use gpsd
for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even
when I'm mobile, the reports appear to come from the hard-coded location in
auto_rx. I'm fine with that.

It seems that the National Weather Service relies mostly on radiosondes made by
Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one
operating between 400 and 406 MHz and the other one operating around 1680 MHz.
The Vaisala RS41 is a newer radiosonde model used at some locations, and it also
operates around 400 MHz. You should ensure the proper frequency range for your
location is enabled. The 1680  MHz radiosondes also work best with a
circular-polarized antenna, similar to those you might use for certain FPV drone
video.



SETTING UP CHASEMAPPER

The instructions for Chasemapper mostly work out of the box, with the exception
of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON
output which Chasemapper requires, so I ended up running a modern version of
 GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that
toward the end of the article. I also had some trouble running GPSd on the
default port of 2947, so of course I ran it on port 1337. 

For horusmapper.cfg, I changed only the following lines:

car_source_type = gpsd 

gpsd_port = 1337

habitat_call = [my amateur radio callsign]





TYING IT ALL TOGETHER

I didn't set up systemd services for anything, but you may want to follow the
instructions in the git repositories to enable systemd services if you plan on
building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with
a simple shell script that I call "loon.sh":



> #!/bin/sh
> 
> 
> gpsd -S 1337 gpsd://192.168.1.1:11010
> 
> cd ~/radiosonde_auto_rx/auto_rx
> 
> python auto_rx.py&
> 
> cd ~/chasemapper/
> 
> python horusmapper.py&

Everything runs in the background, and the terminal will fill up with logs about
both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web
browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the
auto_rx status page. 





Digg This! • Email this • Save to del.icio.us

0 Comments

Labels: gps, map, radio, radiosonde, raspberrypi, sdr, weather




2020-08-04


GMRS AND YOU

Posted by Ax0n








With the availability of handheld radios that are more powerful than cheap
walkie-talkies, even more powerful radios for your home and vehicles, antenna
masts and a small network of repeaters, GMRS allows your family some of the
benefits of amateur radio, at a marginal cost, and without every member having
to pass an exam. With a decent home and mobile GMRS radio set-up, your family
could likely stay in touch even if you stray several miles from home for work or
errands.



With the potential of a wide-spread infrastructure outage in an emergency, and
increased tracking of location data via smart phones, payment card transactions
and the like, adding GMRS to your family's communications strategy can make a
lot of sense.



FRS VS GMRS

General Mobile Radio Service (GMRS) is a UHF Land Mobile Personal Radio Service,
not much unlike Citizens Band (CB) or Family Radio Service (FRS). In fact, 14
frequencies used by GMRS are shared with FRS.



Up until the rules changed in 2017, one had to obtain a GMRS license to use
channels 15-22 on FRS/GMRS handheld radios that look a lot like the one on the
left in the title photo above. That radio is actually a 5 watt Midland GXT-1000
GMRS radio, but with a few caveats, it can be used for FRS as well.


Recent changes were made to allow up to 2 watts on channels 1-7 and 15-22 as
part of FRS without obtaining a license. Channels 8-14 are still reserved solely
for FRS use in the US, with a maximum of 500mW output. A number of FRS radios
are available that run close to 2W on legal channels, but today I'll be focusing
on GMRS specifically. The primary differences between FRS and GMRS are:

 * GMRS handheld radios are allowed to transmit up to 5W
 * GMRS mobile and base-station radios are allowed up to 50W
 * Removable antennae are allowed
 * Repeaters can be used on GMRS
 * An FCC license is required for GMRS, but there is no exam.
 * Businesses can legally use FRS for operations, but business use of GMRS is
   mostly disallowed.
   


THE RULES

A short, multi-page primer on GMRS is provided by the FCC.

The full rules for operating on GMRS are in FCC Part 95 subpart E.



The short, short version of the rules that should cover most of the highlights:
 * No "public broadcast" messages, advertising or music
 * No profanity
 * Only communicate with other GMRS or FRS users. Communication with amateur
   radio stations is not allowed.
   
 * No "Jamming" or continuous transmissions
 * Don't use GMRS to assist in any criminal activity
 * You must identify your call sign (e.g. WRBX000) in English or morse code
    * At the end of a single transmission that you do not expect a reply to
    * At the end of a conversation
      
    * At least once every 15 minutes while communicating

 * You can authorize any family members to use your license with your
   permission.
    * Your parents, children, grandparents, nieces, siblings and uncles can
      legally operate on GMRS under one single license, if you give them
      permission and ensure they know the rules.
    * If they break the GMRS rules under your license, your license is likely in
      jeopardy. You are ultimately responsible for the actions of those using
      your license.

While GMRS is provided as a convenient way for family members to stay in touch,
an authorized GMRS user is allowed to talk to others outside of their family.
They do not need to be physically close enough to you to communicate with you as
the license holder as long as they obey the rules.


LICENSING

Most adult United States citizens are eligible to apply for a GMRS license. As
of 2020, the license fee is $85, and it is valid for 10 years from the date of
issue.



One can apply for a GMRS license online through the Universal Licensing System,
or by mail. Either way, you must fill out FCC Form 605. Filing online requires
you to register for an FCC Registration Numer (FRN) if you do not already have
one. Amateur radio operators may use their existing FRN, for example.



Once logged in to ULS, click "Apply for a new license" and choose "ZA - General
Mobile Radio Service" from the very bottom of the drop-down list.



Upon completion of FCC Form 605 for GMRS, you will be required to make an online
payment. Your license will usually show up within a few hours or on the next
business day. You will also likely receive an email about your license grant.



HARDWARE

YOU MUST NOT USE AMATEUR RADIO EQUIPMENT* ON GMRS.



Transceivers specifically designed for amateur radio are not allowed on GMRS.
Some hams use commercial radios that have been tuned to work on amateur radio
frequencies, and there's a bit of a grey area there.



Until recently, hardware specifically designed to take full advantage of GMRS
was pretty rare. Radios must be type-certified under FCC Part 95 to operate on
GMRS and strict standards must be met with regard to channel deviation,
frequency stability at a wide variety of temperatures, and spurious emissions.
It just so happens that commercial land mobile UHF Radios type-certified under
FCC Part 90 meet or exceed the specifications for GMRS, so long as they do not
exceed 50 watts of output power. As such, many GMRS users will re-program
commercial UHF radios to operate on GMRS frequencies. The FCC hasn't ever given
a straight answer about if this is allowed, but most repeater operators are okay
with it. The Motorola Radius in the above photo is one of these, but a variety
of 15-45 watt mobile radios and 2-5 watt handhelds from the commercial lines of
Motorola, Kenwood, Bendix/King and others can often be found inexpensively on
the used market. Just make sure you, or the seller, can program them properly.


BTech (purveyors of the ubiquitous, cheap "Baofeng" ham radios) markets two
GMRS-specific radios: the GMRS-v1 handheld and the GMRS-50X1 mobile radio. These
two have been type-certified for GMRS, have the ability to use GMRS repeaters,
and are legal. The GMRS-V1 is, in fact, the only GMRS-specific handheld radio I
was able to find that has repeater capability.



Midland, Cobra, and Uniden have also been making a variety of type-certified
GMRS radios. Most of the handheld units, like the Midland GXT-1000 I have, do
not have the capability to use GMRS repeaters, but the Midland Mobile and
Micro-Mobile radios, designed to be installed inside vehicles, do have repeater
capability.


Most GMRS radios are interoperable with FRS radios. The GMRS-specific radios
mentioned above may have more than 22 channels, but channels 1-22 are almost
guaranteed to work between any GMRS and FRS radio. If your family does a lot of
outdoor activity, you may find that inexpensive FRS radios work fine for kids,
and your GMRS radios will let you communicate with them.


Many old-school GMRS users refer to frequencies -- and especially repeaters, by
the kilohertz part of the frequency only. I suspect this persists in part
because GMRS users are begrudgingly sharing practically all of their frequencies
with FRS users and dislike the concept of channel numbers. At any rate, "700"
refers to either 462.700 MHz, or a repeater that uses 467.700 MHz on the input
and 462.700 MHz on the output.


You can see actual frequencies in this chart on Wikipedia:
https://en.wikipedia.org/wiki/General_Mobile_Radio_Service#Frequency_Table


REPEATERS

Like amateur radio, GMRS operators can run repeater systems. These repeater
systems listen 5MHz higher than the base frequency, and re-transmit the signal
on the base frequency so that all radios listening can hear the message. Not all
regions have GMRS repeaters, but here in the Kansas City area, there are several
to choose from. Unlike amateur radio repeaters, most of them require permission
from the repeater operator before you use them.


MyGMRS.com is probably the closest thing there is to a directory of all GMRS
repeaters in the United States. You can browse the repeater listings without
signing up for an account, but many repeater details (such as the CTCSS or DCS
codes to use them) are hidden until you log in. Some of these details are
completely unlisted, instead requiring you to ask the repeater owner for
permission. You can only create a MyGMRS account once your GMRS license has been
active for a day or two and the website has imported your license from the FCC.



You can also buy or build your own GMRS repeater, and it probably comes as no
surprise that commercial repeater hardware is also quite common. Repeater
building is a complex topic I won't cover here, but the cost is usually pretty
significant.










Digg This! • Email this • Save to del.icio.us

0 Comments

Labels: gmrs, radio




2020-05-12


YAESU FTM-400XDR - UNDOCUMENTED CROSS-BAND REPEATER MODE

Posted by Ax0n

I was in the market for a new dual-band amateur radio. I'm a bit of a Yaesu fan,
and I was torn between trying to find a used workhorse like the  FT-8900R, or
trying something a bit more modern, like the FTM-400XDR. The one thing I really
wanted the '8900R for was its cross-band repeater. That was the only thing
missing from the new '400XDR.

Cross-band repeater mode will listen on two different bands (usually 70cm and
2m) and repeat what's being "heard" on one of the bands, transmitting it on the
other. You can use this for a variety of purposes, but it's most commonly used
to boost the range of a small handheld radio when you can't feasibly take a
high-powered radio with you -- such as into an office building, down in your
basement storm shelter, or keeping in touch with a group of spread-out friends
while in an area without good repeater coverage.

Lo and behold, the FTM-400XDR does have a cross-band repeater built-in. It's
just not documented officially. It's actually pretty easy to set it up.

Start by configuring your radio's tuners the way you want them to work together.
Check that the frequencies, repeater offsets, squelch are all correct, and
disable APRS if you had it enabled.

In this case, I configured the top tuner to communicate with a local repeater,
on medium power. It might be kind of hard to see, but there are indicators "-"
and  "T-TRX" in the header of the top tuner that indicate a negative repeater
offset, and "Tone Squelch on Transmit and Receive" which are common radio
configurations for repeater use. You could instead set the upper tuner to a
simplex frequency if you want to run it as a stand-alone temporary repeater.

The bottom tuner has to be on the other band. Since the repeater I wanted to
talk through is on the 2m band, I selected a simplex frequency from within the
70cm band.  Since I plan on staying pretty close to my radio for this test, I
set the power level on the bottom tuner to low power, and made sure there was no
auto-repeater-shift offset. You'll notice there are no indicators in the header
of the lower tuner. You would not want to accidentally link two other repeaters
together. Don't cross the streams.



Power the radio off. Next, hold the SETUP, F and GM buttons under the power
button at the same time. Keep holding them while you power the radio on.



When it powers up, you will see an "X-Repeater" indicator in the middle of the
screen.







If you're setting up a stand-alone repeater, all users will have to configure
their dual-band handheld radios for "split" operation. This varies by make and
model, but you'll want them to transmit on the same frequency as the bottom
tuner, and receive on the same frequency as the top tuner of the '400XDR.
Anything transmitted by members of your party on the lower tuner's frequency
will be repeated out to everyone else listening on the upper tuner's frequency.

To use the cross-band repeater with another repeater like I did, you'll want  to
set your handheld radio to use the simplex frequency, without a repeater shift,
that's displayed on the bottom tuner. The cross-band will relay
bi-directionally, so whatever you transmit will be sent to the repeater
configured on the upper tuner, and whatever the repeater transmits will be sent
back to your handheld via the simplex frequency on the lower tuner.




To disable cross-band repeater mode, power the radio off, then use the same
3-finger-salute while powering it back on.

Caveats:

 * When the repeater isn't being actively used, you're still responsible for
   ensuring it is functioning properly. Your cross-band repeater has no way to
   identify itself. (e.g. CW ID) and lacks the sophistication of a real
   repeater.
 * You or someone you trust should be close enough to your cross-band repeater
   to shut it off quickly should it malfunction or otherwise transmit undesired
   activity (such as static, intentional interference, radio pirates).
 * Turn the radio off or disable cross-band repeater mode if you are not
   actively using it or are unable to monitor it.
 * Use the minimum power level possible for the communications required. This is
   just best-practice, but also, if you end up cross-band repeating a
   long-running discussion, you may overheat your radio and/or drain your car
   battery. Mobile radios like this are designed for a relatively low duty cycle
   -- transmitting only for a few minutes at a time, then given a chance to cool
   down while others talk. Low power (5 Watts) is probably safe for extended,
   continuous bidirectional operation.
 * The FTM-400XDR is capable of operating on Yaesu System Fusion (C4FM) digital
   modes, but under cross-band repeater mode, it will only operate in analog FM
   mode. You cannot cross-band repeat to a digital repeater from an analog
   handheld radio.
    * I do wonder if another Fusion radio could communicate through a cross-band
      repeater to a Fusion Repeater and vice/versa... I don't have a second
      Fusion radio to test this with.





Digg This! • Email this • Save to del.icio.us

0 Comments

Labels: ham, radio



Older Posts Home

Subscribe to: Posts (Atom)


PAGES

 * PHP/MySQL on OpenBSD's relayd-based httpd
 * Multi-booting Windows 10 and OpenBSD




SEARCH







SUBSCRIBE TO

Posts
Atom

Posts

All Comments
Atom

All Comments





DIRECT RSS LINKS

HiR Information Report
Security Bloggers Network




HIR FEATURED COLUMNS

 * Sysadmin Sunday
 * UNIX Tips
 * Reading Room
 * Physical Security
 * Crypto
 * Humor




HIR TOOLS

 * HiR Community Portal
 * HiR Blog RSS Feed




HIR CATEGORIES

 * Meetings
 * UNIX
 * Crypto
 * Mobile
 * Dumpster Diving




HIR ON TWITTER

Error loading feed.



ABOUT HIR

HiR is what happens when 1990s-era e-Zine writers decide to form a blog. Most of
us hail from the Great Plains region of the United States.

Ax0n, HiR founder and editor-in-chief is an information security specialist
currently working in the luxury goods industry.

Asmodian X joined HiR in December 1997 and currently works as a web developer
and SysAdmin in the education industry.

Frogman has been on board since May 1998 and has many technical passions. When
not experimenting with obscure hardware, he can be found leaping from one
rooftop to the next, making the world his office.

TMiB has also been helping since 1998. Also our resident Physicist and go-to guy
for xkcd jokes we don't get, The Man in Black currently works in the Internet
industry in an east-coast data center.



BLOG ARCHIVE

 * ▼  2021 (4)
   * ▼  May (2)
     * Dedicated page for Multi-Booting Windows 10 and Op...
     * OpenBSD 6.9 Released, PHP/MySQL Page updated
   * ►  March (2)

 * ►  2020 (5)
   * ►  September (1)
   * ►  August (1)
   * ►  May (1)
   * ►  February (1)
   * ►  January (1)

 * ►  2019 (4)
   * ►  October (1)
   * ►  September (1)
   * ►  April (2)

 * ►  2018 (12)
   * ►  December (1)
   * ►  November (1)
   * ►  October (4)
   * ►  September (1)
   * ►  July (1)
   * ►  April (2)
   * ►  February (1)
   * ►  January (1)

 * ►  2017 (6)
   * ►  September (1)
   * ►  August (1)
   * ►  May (1)
   * ►  April (3)

 * ►  2016 (6)
   * ►  November (1)
   * ►  October (3)
   * ►  April (1)
   * ►  January (1)

 * ►  2015 (7)
   * ►  December (4)
   * ►  October (1)
   * ►  June (1)
   * ►  April (1)

 * ►  2014 (11)
   * ►  November (1)
   * ►  October (1)
   * ►  May (1)
   * ►  April (3)
   * ►  February (1)
   * ►  January (4)

 * ►  2013 (11)
   * ►  November (1)
   * ►  October (1)
   * ►  July (1)
   * ►  June (3)
   * ►  May (2)
   * ►  March (1)
   * ►  February (2)

 * ►  2012 (16)
   * ►  November (2)
   * ►  October (1)
   * ►  July (4)
   * ►  June (2)
   * ►  May (1)
   * ►  March (1)
   * ►  February (2)
   * ►  January (3)

 * ►  2011 (22)
   * ►  December (2)
   * ►  November (2)
   * ►  October (2)
   * ►  September (1)
   * ►  August (4)
   * ►  July (3)
   * ►  May (2)
   * ►  April (2)
   * ►  March (2)
   * ►  January (2)

 * ►  2010 (64)
   * ►  December (7)
   * ►  November (2)
   * ►  October (5)
   * ►  September (7)
   * ►  August (1)
   * ►  July (2)
   * ►  June (3)
   * ►  May (4)
   * ►  April (5)
   * ►  March (11)
   * ►  February (10)
   * ►  January (7)

 * ►  2009 (149)
   * ►  December (14)
   * ►  November (12)
   * ►  October (14)
   * ►  September (6)
   * ►  August (13)
   * ►  July (24)
   * ►  June (3)
   * ►  May (12)
   * ►  April (14)
   * ►  March (8)
   * ►  February (9)
   * ►  January (20)

 * ►  2008 (227)
   * ►  December (22)
   * ►  November (19)
   * ►  October (19)
   * ►  September (25)
   * ►  August (26)
   * ►  July (17)
   * ►  June (5)
   * ►  May (4)
   * ►  April (20)
   * ►  March (22)
   * ►  February (30)
   * ►  January (18)

 * ►  2007 (51)
   * ►  December (10)
   * ►  November (11)
   * ►  October (4)
   * ►  August (1)
   * ►  July (5)
   * ►  June (1)
   * ►  April (4)
   * ►  March (4)
   * ►  February (11)




HIR IN REAL LIFE





LINKS AND BLOGS

 * Lockpicking 101
 * Slashdot
 * Hack In The Box
 * Digg
 * Packet Storm Security
 * KC PHP User Group


 

Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk