Category Archives: Amateur Radio

Ham Radio articles, research, experimentation, discovery, commentary.

Stratux – repartition to use entire sd card

The issue..

It’s been an ongoing tail of woe, when it comes to installing a new version of STRATUX on a new card; out of the box, at least in all the installs I’ve done, it fails to make use of the entire card. With any sort of logging enabled to measure performance, run tests or just keep even a short history of contacts received.. you’re out of disc space… FAST:

Here is the ‘df’ dump of a STRATUX fixed position station running the latest version (released September 2019). As you can see, it’s only allocated 2GB of the 32GB card’s total available space. That is a lot of wasted space on the card.

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.8G  1.6G  110M  94% /
/dev/mmcblk0p1   60M   20M   41M  34% /boot

Get total device size:

fdisk -l | grep Disk

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
...
Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors

Disklabel type: dos
Disk identifier: 0xe6a544c8

Repartitioning the Device

With the physical partition located.. start fdisk:
fdisk -u /dev/mmcblk0

I like to increase the size of the main partition to 6G to leave room for installing more system updates and tools.

To do this you will need to know the starting and ending blocks of the partition. That is available with the ‘print’ command:

Command (m for help): p

Results:

Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Disk identifier: 0xe6a544c8

Device         Boot  Start     End Sectors  Size Id Type
/dev/mmcblk0p1        8192  131071  122880   60M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      131072 3887103 3756032  1.8G 83 Linux

To increase the size, the partition must first be deleted, then re-create at the exact same starting block, or the filesystem will become corrupted.

First, delete the partition with the ‘d’ command, selecting partition #2.

Next, re-create the partition with the same starting block, but now with increased filesystem size:

Command (m for help): d 

  Partition number (1,2, default 2): 2

  Partition 2 has been deleted.

Command (m for help): p
 
  Device         Boot Start    End Sectors Size Id Type
  /dev/mmcblk0p1       8192 131071  122880  60M  c W95 FAT32 (LBA)


Command (m for help): n

  Partition type
     p   primary (1 primary, 0 extended, 3 free)
     e   extended (container for logical partitions)
  Select (default p): p
  Partition number (2-4, default 2): 2

First sector (2048-62333951, default 2048): 131072

Last sector, +sectors or +size{K,M,G,T,P} (131072-62333951, default 62333951): +6G

  Created a new partition 2 of type 'Linux' and of size 6 GiB.

Command (m for help): w
  
  The partition table has been altered.
  Calling ioctl() to re-read partition table.
  Re-reading the partition table failed.: Device or resource busy

  The kernel still uses the old table. The new table will be used
  at the next reboot or after you run partprobe(8) or kpartx(8).

The partition table will have been modified but the kernel will not be able to take that into account as some partitions are mounted.

In theory, the command ‘partx /dev/mmcblk0’ is all that is required.. however I’ve found that rebooting is the only way to really reload the partition, so that the filespace can be increased.

reboot

Once system comes back up, run ‘resize2fs‘ to expand the filesystem.

Fill up drive with current filesystem

Execute `resize2fs` and run an on-line expansion of the filesystem, and finally verify it again with ‘df -h’

resize2fs /dev/mmcblk0p2

  resize2fs 1.43.3 (04-Sep-2016)
  Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing
  required
  old_desc_blocks = 1, new_desc_blocks = 1
  The filesystem on /dev/mmcblk0p2 is now 1572864 (4k) blocks long.

Running df shows that it has in fact resized. STEP 1 COMPLETED

root@STRATUX-FIXED:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       5.9G  1.6G  4.2G  28% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           463M     0  463M   0% /dev/shm
tmpfs           463M  6.2M  457M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           463M     0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p1   60M   20M   41M  34% /boot

Dual Band Rubber-Duck Antenna Testing (SWR)

I recently acquired a new wide-band SWR meter from Amazon, and I wanted to revisit the antenna tests I’d run in the past with my old 70’s 11m test equipment.

So, today I got together all of my the rubber-duck dual-band antennas, picked one of my ChiComm radios and took some measurements.

Here are the antennas I tested (left to right).

  • Nagoya NA-701
  • SaineSonic INF-641
  • Nagoya NA-771
  • Baofeng stock (long)
  • Baofeng stock (short)

Here are the results for my test. I ran each antenna 3 times in each band; at the lower phone boundary, upper phone boundary and close to the center of the band.

VHF Lo – 144.1 MHzUHF Low – 420.0 MHz
VHF Center – 146.0 MHzUHF Center – 435.0 MHz
VHF High – 148.0 MHzUHF High – 450 MHz
AntennaVHF(l)VHF(c)VHF(h)UHF(l)UHF(c)UHF(h)
NA-7012.19:11.83:12.44:12.18:11.17:11.31:1
INF-6411.79:11.09:11.37:11.08:11.02:11.77:1
NA-7712.39:12.20:12.21:12.08:11.16:11.97:1
Stock (L)1.59:11.03:11.02:12.07:11.07:11.15:1
Stock (S)2.76:12.18:11.79:11.09:11.59:11.70:1

I was really surprised by how well (from an SWR standpoint) the little SaineSonic that came with my GT-3TP was. I was also shocked at how bad the two Nagoyas seemed to be. There was a 6th antenna (not stock, or Nagoya) that was in the 3:1+ range across all the bands. Either it was damaged, a fake.. or maybe they are simply garbage.

These tests are hardly scientific. I did, however, hold the radios in free space away from me, instead of testing them on the bench surrounded by metallic objects.. for those about to try and drop some truth bombs on me.

Once I figure out a fair rig to install the antennas into, I’ll hook up my little nanoVNA and see what it has to say. Could confirm these results, or it could say something completely different. What I’d like to see from the nanoVNA are some gain estimates. The little antennas might match well, but do they also have good gain; that is an important question.