Another major step forward for the LimeSDR yesterday…
As a part of the continuing development of the PPAs for Ubuntu and other distros, the LimeSDR is now supported for native HF tuning - - no transverter required. Receive has been functionally tested from 7.0 MHz to 56 MHz and even with the matching networks as they are in the LimeSDR I have (which is not what will be delivered in November - the LimeSDRs the backers will receive in November will have modified matching networks to be more broadband and perform better than what I have right now) the receive quality was very good with my applied HF station antenna (ground mounted vertical for 80m - 6m). I shot two videos yesterday of the LimeSDR operating on the 20m band - one with USB voice and one with CW/RTTY on the contest weekend for RTTY (REAL active). I ran this completely from a USB 3.0 Flash Drive plugged into a Dell 3020 and booted from that Flash Drive to operate the LimeSDR. The Flash Drive is loaded with Ubuntu Xenial (16.04), all the applied support files (SoapySDR, GNURadio, OsmoSDR. etc) and the application GQRX to tune and demodulate the LimeSDR. The setup worked VERY well and the results can be viewed with the two videos provided here:
Again, I was impressed with the quality of the direct, native, HF tuning of the recent updates to LimeSuite. Having this functionality in LimeSuite finalizes for receive, but I still need to check out the transmit. It’s my hope that Simon Brown’s SDR Console V3.0 will update with the new HF tuning improvements such that I can use his app on Windows to do a full checkout in receive/transmit with the LimeSDR and hopefully apply it to the WSPR app to have the LimeSDR operate HF digital modes on the HF band and Amateur Radio frequencies to have the first true LimeSDR operation benchmark.
I fully intend to have Flash Drive images available for download once I put the final touches on the Flash Drive I have. This will allow all Hams that want an instant solution for booting Ubuntu and running GQRX for receive to use their LimeSDRs right out of the chute without having to install ANYTHING provided that they have a PC that is decently fast (3.0 GHz, 8GB RAM) and has USB 3.0 ports on the PC. I’m looking for a reliable means to read/write the Flash Image and then take the image and ‘burn’ other USB 3.0 Flash Drives with the image. Once I have that reliably working, I’ll post the image and the Flash Drive app so ANYONE can make their own from a blank 32GB to 128GB Flash Drive.
More to follow on the HF transmit as I have those apps and check that out - - Stay tuned…!
Thanks for writing back on this and the suggestions. I’ve been using a couple of USB imaging tools to get (what I think) is a reliable image, but the image (a complete Linux install) I’m getting is getting misreported and ‘looks’ huge compared to what’s really on the USB 3.0 stick. For instance, I pulled the image off the USB 3.0 stick (and this is a 128GB USB 3.0 stick) and the file image (to Win 10’s file manager) says that it’s 198GB in size…! There’s no way that can happen. and when I go to write it back to another blank 128GB USB 3.0 stick the app says it can’t because the image is larger than the media. Anyway, that’s what’s been driving me batty over the past day or so here. Let me know if your suggestions will work for this issue.
Thanks again for writing, Mike - 73 de Marty, KN0CK
Yep - time to get SDRConsole V3.0 recompiled and get Tx going, too…! THIS is gonna ROCK to have INCREDIBLE coverage from low HF to SHF frequencies. LimeSDR is GONNA RULE and be a Ham’s dream to use…!
For anyone interested, here is the video I shot this morning of the LimeSDR running a Lubuntu installation with LimeSDR in Native HF tuning mode with GQRX under VirtualBox on Windows 10. It’s running GREAT there, too:
Again, just a short video (1 minute) showing the performance of the LimeSDR under this VirtualBox session on the 20m Ham Band early this morning (where the propagation isn’t perfect yet here in Iowa).
Thanks much and please do - the mis-reporting of the image size to clone these images to other Flash Drives is my primary obstacle at the moment. Let me know what you find out, because I’m out looking, too.
Its not so much as a miss reporting … as much as you don’t need to clone the entire flash drive … you only need to clone to the end of the partition. I’ll also add that if you have 30gig of un-used space in that partition – that too will be cloned (for no good reason).
When you have a desire to make a clone/image … used gparted (linux) to reduce the main operating partition down to a 10meg or more just above the data used-- or to at least 5% less than the target flash size. in reality – to speed things up … i always reduce the partition as much as i can including not using “swap space”. That way there is less to transfer.
This is a script that i use to clone my sdcard of Odroid-X2 (while its running on the odroid-x2 – nifty huh, clone a SDcard while its in use-- lol)
#!/bin/sh
#I do it directly on the odroid. Just insert a flash drive and use dd. This is the little script I use.
date format
NOW=$(date +“%F”)
NOWT=$(date +“%T”)
date
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/mmcblk0 conv=sync,noerror bs=1M count=25000 | pv | gzip -c > /media/odroid/545dba2d-7858-499d-ae63-cfe26e2bd3bb/Backups/backup-$NOW-$NOWT.img.gz
ls -s -h /media/odroid/545dba2d-7858-499d-ae63-cfe26e2bd3bb/Backups
echo 3 > /proc/sys/vm/drop_caches
date
#Substitute your values for “if=/dev/yoursdcard” and “> /media/mountpoint of your flash drive” The file #name is the date and time the backup started.
the part that is “count=25000” limits the size of the clone to 25gig
If your not familiar with linux … i can help to produce a DD command to do the clone – wish Sid Boyce (G3VBV i think) was on this forum … and now that iv said it, ill see if he is yet – i know he is getting a Limesdr too ( i think) – i usually bug him with my linux questions … also a Ham.
PS… i had to edit the post to fix some text issues … there is a “space” in front of any “#” to fix formatting
this is the core of the clone …
so
if=/dev/mmcblk0 — this is the source device name
conv=sync,noerror bs=1M count=25000 | pv | gzip -c >
/media/odroid/545dba2d-7858-499d-ae63-cfe26e2bd3bb/Backups/backup-$NOW-$NOWT.img.gz and this is the destination
pv is a compression program that operates on the fly and gzip is also
Ill need to send you the script looks like – there are formatting issues that i cant fix. if you dont know what the parts are doing.
Because file systems do not always fill up disks from the beginning to the end in sequential order. I hear data being lost screaming at me when I look at your dd truncating command.
I would be inclined to do something like the following to make a disk image file (untested):
# Create a 12Gib file.
## too slow ## $ dd if=/dev/zero of=file.img bs=1M count=12288
$ fallocate -l 12G file.img
# create a loopback device for the file
$ sudo losetup /dev/loop0 file.img
# make one large partition and make it bootable starting at block 2048
$ (echo n; echo p; echo 1; echo “”; echo “”; echo a; echo w;) | sudo fdisk /dev/loop0
# check that the partition was created and is bootable
$ sudo fdisk -l /dev/loop0
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 * 2048 25165823 25163776 12G 83 Linux
# first partition is at 2048x512=1MB, create a new loopback device for this partition
$ sudo losetup -o 1048576 /dev/loop1 file.img
$ sudo mkfs ext4 -F /dev/loop1
$ mkdir -p /tmp/mnt
$ sudo mount -o rw /dev/loop1 /tmp/mnt
$ sudo chmod -R ug+rw /tmp/mnt
# backup the current full harddisk to the image file (subsequent updates could use --delete-before read man page first)
$ sudo rsync -aAXv --exclude={"/dev/","/proc/","/sys/","/tmp/","/run/","/mnt/","/media/","/lost+found"} / /tmp/mnt
# for security delete the ssh keys, new ones will automatically be created by the sshd script on startup
$ sudo rm /tmp/mnt/etc/ssh/ssh_host_
# remove silly commands you have typed in the past
$ sudo rm -f /tmp/mnt/root/.bash_history
# scrub the logs (saves disk, and if properly configured in /tmp/mnt//etc/logrotate.conf all will be recreated)
$ sudo rm -f /tmp/mnt/var/log/*
# find out the UUID of the root partition inside the file
$ sudo blkid /dev/loop1
/dev/loop1: UUID=“12345678-9ABC-DEF0-1234-567890ABCDEF” TYPE=“ext2”
# fix /tmp/mnt/etc/fstab to use the correct uuid of the root partition for /
# fix up /tmp/mnt/boot/grub/grub.cfg to use correct UUID
$ sudo grub-install --force --removable --verbose --boot-directory=/tmp/mnt/boot/grub /dev/loop0
$ sudo losetup -d /dev/loop0
$ sudo unmount /tmp/mnt
$ sudo losetup -d /dev/loop1
Although if you have the working copy on a physical USB device it might be far easier just to shrink the file system ( https://access.redhat.com/articles/1196333 ) and then use dd
This may be true …
I have used it a few times on an Odroid-X2 and the image that was made was placed onto another flash card and did boot with no errors nor did i detect any missing/corrupted data …
I took an image from a 64G flashcard (that the partition was reduced and moved below the 32g thresh hold - with gparted) and limited the the data copied with the for mentioned line and then placed onto a 32G card (with Win32DiskImager-0.9.5) – which after using gparted to stretch the partition to the end did boot ( im still using it this very moment (about 8months of use) as a remote SDR receiver)
Thanks for the info - I’ll be playing around with this more tomorrow. This evening I was busy building a smaller formatted stick for Ubuntu Xenial (16GB) - it’s playing REAL NICE on HF right now…More tomorrow on this, Stay tuned.
