Peaberry TX not working as should

[CT1IQI]

When the 1 kHz has kicked in, it is massively present when listening in AM to what is supposed to be a clean carrier; it appears fully modulated with an unclean 1 kHz. Listening with ssb or cw filtering there is a plethora of spikes at 1 kHz intervals because clearly the 1 kHz modulation is not a sine wave but something wit a squarish envelope and many overtones. There are times when the modulation is absent (after trying ptt on / off multiple times) , present all the time, and sort of randomly crackling between present and not. None of it under influence of what one does to the Peaberry board in terms of touching circuits or even exerting some force on the board. The RF path appears stable in itself; the heatsink of the BS170s gets warm but it just amplifies an unclean signal that emanates already from the DA stage but is not unstable in terms of tendencies to oscillate.
The PC motherboard is a modern Asus P8H67-I Pro board with an i7-3770 CPU @ 3.40GHz × 8, 8 GB DRAM, and running Ubuntu 12.04. Am wondering whether perhaps the PCM3060 has an internal problem. Just not looking forward to redoing the ssop soldering ... Or that perhaps the usb clock gets a spread spectrum treatment that unsettles this audio sync ??? But then I do not understand how reception could be fine. It is really only TX that gives problems.

[AE9RB]

If the SPKR jack produces a clean tone then the problem is not with the PCM3060 or PSoC. There's only one DAC which is switched between the speaker and transmitter. I would try a different computer before you start reworking parts.

[hansvi]

Just thinking along a bit:

• If the problem is USB clock jitter, you can potentially test that if you have another PC/portable lying around. Or perhaps borrow one from a family member (they don't really need it) and boot from a live USB stick.
• Another thing to make sure is that you're not chasing ghosts. I'm making a very wild guess here, but perhaps you have watched this youtube video and had the same "hmmm..." moment as I have (I've been testing this way using a dummy load and an old hf receiver). The thing is, depending on the amount of rf coupling, maybe you could be totally overloading the receiver, and getting all sorts of weird stuff going on.

I mention this because I have seen something similar on the RX side when I was experimenting with a dip meter. I held it very close to the receiver, and when I tuned in, i saw a lot of spurs everywhere (I didn't measure the spacing, but I could test it again if you want). But the signal was so massively strong that I dismissed the result as unreliable.
At the local ham club we have a signal source. When injecting a proper signal, there was no trace of spurs.

I must say that I have not yet transmitted on the air, mainly because I haven't built the filter for 40m yet (at 20m I hardly get any reception but that's another thread). But once I get my act together and finish everything up, I had planned to do some short tests where I listen to a websdr receiver while transmitting, or perhaps have some friendly people helping me. Without proper measuring equipment, that may be the only way to go.

[DJ&OA]

Martin:

Just stumbled over your very first post in which you indicated that you are still using the VK6JBL version of Quisk. Both HDSDR and the VK6JBL version of Quisk are based on the original DG8SAQ driver.

By the way, did you set in usbsoftrock the 'BPF Enabled' to 0, otherwise you anyhow get unpredictable results. Check with usbsoftrock status -v.

I darkly remember that I had a similar picket fence of signals on testing my rx-tx-ensemble (which needs the usbsofrock driver) on the bench and there was a short interruption of either the USB or the power connection, I can't remeber.

Perhaps you should switch to the latest version quisk-3.6.10 from the home page of N2ADR. This version is patched for Peaberry and has a sample .quisk_config_peaberry.py which only has to be adapted as regards the sound cards and supplemented by key_poll_msec = 50 (or any other value) so that you may switch the Peaberry from rx to tx by connecting its PTT tip termnal to ground. Quisk simply turns the frequency display to red and blocks if there is or was an external error, like an inrerruption of USB or reduction in power. Never trust any jack connector end especially not the power jack of typical sdr transceivers.

Possibly this either solves your problem or at least results in a hint to the problem.

73, Rainer
DJ6OA

[CT1IQI]

@DJ&OA
Since the initial problems I analysed how Quisk works and also the Peaberry firmware and had already adapted all code to the commands the Peaberry knows so that no Python exceptions would be thrown in Quisk. Made it such that I can do PTT from the screen button per mouse. The problem I see does not depend on the program used (also saw it with HDDSR from windows and with the latest tests under Linux, not using Quisk at all) so it is something specific of my Peaberry board.
If it were RF feedback there would be some effect from handling the board and touching components, but the effect is not there. So I assume AE9RB is right in assuming something with the USB does not work as it should in TX mode as apparently the 1 kHz is likely to be USB related. Will give it a try on a laptop with USB 2.0 to see whether that behaves different compared to my modern desktop system that has usb2.0 and 3.0.

[CT1IQI]

RESOLVED !!!
Thanks for all help given. It is indeed the USB I/O of the computer Motherboard that seems to have an incompatibility with the Peaberry.
Before trying another PC I tried all usb ports of the P8H67-I motherboard and all USB2.0/1.0 ports (8 pcs.) give the problem, but the USB3.0/2.0 ports (2 pcs.) do not.
Noticed on the Asus website that they have a new BIOS available and there is a mention of "Enhance compatibility with some USB devices." Will give that BIOS a try out of curiosity whether that would make the usb 2.0/1.0 work as well.
In any case I can now consider the Peaberry building project as having been successfully completed. Thanks again for all help and tips and AE9RB in particular for the hint in linking the 1 kHz noise to USB.

[CT1IQI]

just for the record and to document the issue:
upgrading of the Asus BIOS of the 'P8H67-I Pro' has made no difference, nor enabling/disabling legacy usb support features in BIOS.
Plugging the Peaberry to a usb3.0/2.0 slot still makes connection to a usb2.0 hub but the driver used (and hardware used) is different.
what works: the usb driver loaded is xhci_hcd
the 1 kHz problem: the driver loaded is ehci_hcd; this is what gets loaded on all usb2.0/1.0 ports.

Update1:
also in 96 kHz sample mode the Peaberry now works fine in both RX and TX. Earlier the RX sounded distorted when connected through the usb 2.0/1.0 ports but
the other usb3.0/2.0 hardware and drivers make the audio sound good at 96 kHz.

Update2:
Using Quisk (3.6.10) have now returned the definition of the alsa interface for transmit purpose from plughw:1,0 to the original hw:1,0 and that works flawlessly at both 48 and 96 kHz!