Page 1 of 1

New SW loads will not work, old ones work great...PAVEL HELP

Posted: Sat Dec 31, 2016 2:30 am
by martywittrock
Pavel or anyone,

I have had a Red Pitaya system running on my PiHPSDR setup fine with the old SW loads from a year ago or more. I just upgraded to the CODEC audio board and wanted to get it running on my Red Pitaya so I downloaded (from the Red Pitaya Marketplace) the latest SDR application for two receivers and one transmitter using HPSDR. When I checked it on my Serial Port (and also Ethernet) I can see that the Red Pitaya is coherent I can list things and see the filesystem fine. When I attach it to my PiHPSDR system it reports that it cannot find it using the old or new protocols. My old SW load works great - I can receive and transmit (the transmit audio is not good at all) but I can receive great with it and tune everywhere. But the new SW load refuses to be seen by the PiHPSDR application - just says it can't find it.

I've tried a number of things including downloading Pavel's 1GB Debian ecosystem to see if I can make that work...Same thing...Cannot be seen by the PiHPSDR app. I've even tried my openHPSDR app that ran great under Windows with the old SW, but the new SW does not work.

What am I doing wrong? I've written the microSD card a number of times with the SW load from Pavel's website and I've even downloaded from the Red Pitaya Marketplace, too...nothing works...

Please let me know as soon as possible - thanks!

de Marty, KN0CK

Re: New SW loads will not work, old ones work great...PAVEL

Posted: Sat Dec 31, 2016 9:06 am
by pavel
But the new SW load refuses to be seen by the PiHPSDR application - just says it can't find it.
I've even tried my openHPSDR app that ran great under Windows with the old SW, but the new SW does not work.
Hi Marty,

I've just installed SDR transceiver compatible with HPSDR (0.94-1451) from the Red Pitaya application marketplace and checked that PowerSDR mRX PS runs fine with the default settings.

Without knowing more details about the configuration of your network and of the PiHPSDR or PowerSDR mRX PS programs, I can only suggest to check the network connectivity of your Red Pitaya board and the setting of your programs.

Is it possible that you have some fixed IP addresses set in the PiHPSDR or PowerSDR mRX PS programs and with the new SD card images the IP address of the Red Pitaya board changed?

Best regards,


Re: New SW loads will not work, old ones work great...PAVEL

Posted: Sat Dec 31, 2016 3:16 pm
by martywittrock

Thanks very much for responding - here's what I'm doing with my SW loads...

I first take a microSD card that is unformatted and format it using BOOTICE for FAT32. This produces a blank SD card. I then took your ecosystem from your website (ecosystem-0.95-1-6deb253-sdr-transceiver-wide) and copied the RAR file onto the blank microSD card. Then I take the RAR file and un-RAR it by extracting the files from the ecosystem and allowing them to populate the blank microSD card. When that's done, I usually use TeraTerm under Windows to check to see if there's a filesystem on there. I will do a 'ls' and see nothing, but then do a 'cd ..' and then I'll see subdirectories in the format of a Linux filesystem. I also noted that the IP address of the Red Pitaya is Once I check that I'll get out of TeraTerm and then start PowerSDR mRX PS under Windows. Before I start the Red Pitaya it's in the HERMES mode and the app's IP address is I tried launching with those default settings and the PowerSDR app will pop a window that says "Error Starting HPSDR Hardware, is it connected and powered". I've tried changing the top IP address from to and restart the PowerSDR application from the beginning. Still has the same issue - cannot start. I've even tried to start it on PiHPSDR the same way and it will not start. One thing I've noticed is that the old SW loads there is a yellow light on the Red Pitaya that will blink at 1 second interval, but with the new SW load I'm not seeing that.

I've even done everything above, but I downloaded the same transceiver app from the Red Pitaya Marketplace and did all the things I've done above and it's still not starting.

Here is the log from the Serial monitor from the Red Pitaya when it boots:

U-Boot 2015.04 (Apr 14 2016 - 12:06:55), Build: jenkins-master_oldkernel_release095-1

Board: Xilinx Zynq
I2C: ready
DRAM: ECC disabled 480 MiB
I2C:EEPROM selection failed
MMC: zynq_sdhci: 0
In: serial
Out: serial
Err: serial
Board: Xilinx Zynq
Net: Gem.e000b000
Hit any key to stop autoboot: 0
Running script from SD...
Device: zynq_sdhci
Manufacturer ID: 3
OEM: 5344
Name: SS16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading u-boot.scr
528 bytes read in 15 ms (34.2 KiB/s)
## Executing script at 02000000
Set devicetree and ramdisk high loading address to 512MB-64MB
Loading from SD card (FAT file system) to memory
Device: zynq_sdhci
Manufacturer ID: 3
OEM: 5344
Name: SS16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading uImage
3975480 bytes read in 257 ms (14.8 MiB/s)
reading uramdisk.image.gz
9385264 bytes read in 588 ms (15.2 MiB/s)
reading devicetree.dtb
12509 bytes read in 16 ms (762.7 KiB/s)
Booting Linux kernel with ramdisk and devicetree
## Booting kernel from Legacy Image at 02001000 ...
Image Name: Linux-3.18.0-xilinx
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3975416 Bytes = 3.8 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 03000000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 9385200 Bytes = 9 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 04000000
Booting using the fdt blob at 0x4000000
Loading Kernel Image ... OK
Loading Ramdisk to 1b70c000, end 1bfff4f0 ... OK
Loading Device Tree to 1b705000, end 1b70b0dc ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 3.18.0-xilinx (jenkins@dragon) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11) ) #1 SMP PREEMPT Thu Apr 14 12:10:05 CEST 2016
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: xlnx,zynq-7000
cma: Reserved 16 MiB at 0x1d000000
Memory policy: Data cache writealloc
PERCPU: Embedded 10 pages/cpu @5cc10000 s8704 r8192 d24064 u40960
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 121920
Kernel command line: console=ttyPS0,115200
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 453476K/491520K available (5448K kernel code, 336K rwdata, 1780K rodata, 216K init, 238K bss, 38044K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0x5e800000 - 0xff000000 (2568 MB)
lowmem : 0x40000000 - 0x5e000000 ( 480 MB)
pkmap : 0x3fe00000 - 0x40000000 ( 2 MB)
modules : 0x3f000000 - 0x3fe00000 ( 14 MB)
.text : 0x40008000 - 0x407173fc (7229 kB)
.init : 0x40718000 - 0x4074e000 ( 216 kB)
.data : 0x4074e000 - 0x407a2160 ( 337 kB)
.bss : 0x407a2160 - 0x407dda3c ( 239 kB)
Preemptible hierarchical RCU implementation.
Dump stacks of tasks blocking RCU-preempt GP.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76360001
slcr mapped to 5e804000
zynq_clock_init: clkc starts at 5e804100
Zynq clock init
sched_clock: 64 bits at 249MHz, resolution 4ns, wraps every 2199023255552ns
timer #0 at 5e806000, irq=43
Console: colour dummy device 80x30
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x52e3d8 - 0x52e430
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB @ 0x5e880000
VCCPINT: 1000 mV
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
media: Linux media interface: v0.10
Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <>
PTP clock support registered
EDAC MC: Ver: 3.0.0
Advanced Linux Sound Architecture Driver Initialized.
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 9168K (5b70c000 - 5c000000)
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
futex hash table entries: 512 (order: 3, 32768 bytes)
jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 935
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dma-pl330 f8003000.dmac: Loaded driver for PL330 DMAC-241330
dma-pl330 f8003000.dmac: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
xuartps e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
xdevcfg f8007000.devcfg: ioremap 0xf8007000 to 5e86e000
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
loop: module loaded
CAN device driver interface
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
libphy: XEMACPS mii bus: probed
xemacps e000b000.ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
usbcore: registered new interface driver rt2800usb
usbcore: registered new interface driver rtl8192cu
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0007
Found SMSC USB3320 ULPI transceiver.
ULPI integrity check: passed.
zynq-ehci zynq-ehci.0: Xilinx Zynq USB EHCI Host Controller
zynq-ehci zynq-ehci.0: new USB bus registered, assigned bus number 1
zynq-ehci zynq-ehci.0: irq 53, io mem 0x00000000
zynq-ehci zynq-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver cdc_acm
cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
at24 0-0050: 8192 byte 24c64 EEPROM, writable, 32 bytes/write
cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 57
zynq-edac f8006000.memory-controller: ecc not enabled
Xilinx Zynq CpuIdle Driver started
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
sdhci-arasan e0100000.sdhci: No vmmc regulator found
sdhci-arasan e0100000.sdhci: No vqmmc regulator found
mmc0: SDHCI controller on e0100000.sdhci [e0100000.sdhci] using ADMA
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
nf_conntrack version 0.5.0 (7484 buckets, 29936 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
Registering SWP/SWPB emulation handler
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
ALSA device list:
No soundcards found.
Freeing unused kernel memory: 216K (40718000 - 4074e000)
mmc0: new high speed SDHC card at address aaaa
mmcblk0: mmc0:aaaa SS16G 14.8 GiB
mmcblk0: p1
Starting rcS...
++ Mounting filesystems
++ Running all startup scripts
Starting logging: OK
Starting mdev...
Initializing random number generator... random: dd urandom read with 1 bits of entropy available
Starting system message bus: done
Starting network...
++ Bringing up lo
++ Bringing up wlan0
WiFi: Access Point (AP) mode
ip: can't find device 'wlan0'
ip: SIOCGIFFLAGS: No such device
ifconfig: wlan0: error fetching interface information: Device not found
WiFi: Starting AP daemon
/etc/init.d/S40network: line 103: hostapd: not found
WiFi: Starting DHCP & DNS server
++ Bringing up eth0
udhcpc (v1.22.1) started
Sending discover...
xemacps e000b000.ethernet: Set clk to 25000000 Hz
xemacps e000b000.ethernet: link up (100/FULL)
Sending discover...
Sending select for
Lease of obtained, lease time 86400
deleting routers
route: SIOCDELRT: No such process
adding dns
++ Starting NAT & routing...
Starting sshd: OK
Starting nginx ... done.
Network: DHCP
To change your network configuration, edit /opt/redpitaya/etc/network/config.
# Red Pitaya GNU/Linux Ecosystem
# Version: 0.95
# Branch: master_oldkernel_release095
# Build: 1
# Commit: 6deb25343be65ef284c2b28f5f0ab1569d73a46b

What's your opinion on this, Pavel..? I'm REALLY stumped why I cannot get this to start in PowerSDR in Windows or PiHPSDR, but my old SW works like a charm on both platforms. I REALLY need the CODEC to work with my Red Pitaya for my project here...I'm SO CLOSE to making this work but the Red Pitaya side is not working.

Your input on this will be GREATLY GREATLY appreciated, Pavel - hope to hear from you soon.

73 de Marty, KN0CK

Re: New SW loads will not work, old ones work great...PAVEL

Posted: Sat Dec 31, 2016 4:30 pm
by pavel
I then took your ecosystem from your website (ecosystem-0.95-1-6deb253-sdr-transceiver-wide) and copied the RAR file onto the blank microSD card.
Thanks for the details. ecosystem-0.95-1-6deb253-sdr-transceiver-wide is the wrong image. Please use from this link. Here is a direct link to this file.

Re: New SW loads will not work, old ones work great...PAVEL

Posted: Sat Dec 31, 2016 9:31 pm
by martywittrock

THAT NEW ECOSYSTEM WORKED PERFECT..!! I downloaded that ecosystem. unRAR'ed it to a subdirectory on my Windows machine, extracted the contents from that ecosystem and wrote it to a blank FAT32 formatted microSD card, stuck it into my Red Pitaya and PiHPSDR saw it on the first try..! Used it on the Pi 3.0 audio at first and then powered everything down and tried the CODEC. WORKS PERFECTLY in receive, but my transmit audio is a little gravely...I need to figure that out, but the receive quality off the CODEC is perfect...Listening to it now and it sounds wonderful..!! I'm a VERY happy camper now..!!

Thanks SO MUCH, Pavel, for making this ecosystem available to me..! I'll keep you advised on the audio issue in transmit as I work that.

73 de Marty, KN0CK