Peaberry TX not working as should

[hansvi]

Hi,

I made a gnuradio-companion file that outputs an analytical signal to the tx device. The amplitude of the signal is limited to 0.5, at that moment it reaches 1 Watt. I briefly tested and verified that if I turn the volume way up, I can output 2 Watt according to my meter.

Basically you need to run quisk, press PTT to enter transmit mode, and then run this program in gnuradio-companion (I'm using the Debian-supplied version, 3.5.3.2).

Setting the volume directly affects the power meter output, quite fun to play with in fact .

test_peaberry_audio.zip

Opens the tx device and outputs an analytical signal, has a volume slider.

(933 Bytes) Downloaded 544 times

.

[hansvi]

Another breakthrough..

After a lot of testing, I can now transmit using the following config file (only tested on a dummy load). I had some issues with choppy sound at first, this was resolved after I added the settings data_poll_usec and latency_millisec.

I'm now using both the microphone and the speakers of the peaberry.

Code: Select all

from softrock import hardware_peaberry as quisk_hardware
from softrock import widgets_tx as quisk_widgets

si570_direct_control = True
#si570_xtal_freq = 114225833
# Result of running "usbsoftrock calibrate". It returns the frequency in MHz, convert to Hz
si570_xtal_freq  = 114242957

# from http://quisk.973856.n3.nabble.com/Quisk-with-Softrock-RXTX-v6-3-td3971689.html
data_poll_usec = 1000    #default is 5000
latency_millisec = 1        #default is 150


sample_rate = 48000
playback_rate = 48000
name_of_sound_capt = "plughw:1,0"
name_of_sound_play = "plughw:1,1"
channel_i = 1
channel_q = 0

usb_vendor_id = 0x16c0
usb_product_id = 0x05dc

# Microphone capture: (these settings still need to be looked into)
microphone_name = "plughw:1,1" # Name of microphone capture device
mic_sample_rate = 48000
name_of_mic_play = "plughw:1,0" # Name of play device if CW or mic I/Q is sent to a sound card
mic_playback_rate = 48000 # Playback rate must be a multiple 1, 2, ... of mic_sample_rate
mic_out_volume = 1.0 # Transmit sound output volume (after all processing) as a fraction 0.0 to 1.0

Right now the only issue I have is that the frequency in quisk is not correct. However, if I use linrad, I'm spot on. So, once I have figured that out, I'll post a "final" config file for quisk.
If you could verify if the config works for you too, I'd like to hear your results. Also, if you could verify if you receive at the correct frequency...

Greetings,
Hans.

[CT1IQI]

I am probably using another hardware.py file than you curently are. So would need both to test your config.
Have noticed in the mean time, by looking into the quisk code, that there is potentially another problem.
My python harware code works fine in switching rx/tx and in controlling the sis570. Reception is really smooth and of fine quality.
But what makes quisk switch between receive and transmit is distributed over various pieces of code and the terminology 'key' and 'ptt'.
Key in my idea has to do with CW, and PTT with activating the transmitter, regardless of mode, but quisk seems to use 'key' in some code where ptt is meant , or v.v.
The Quisk C code either only receives, or wants to be switched RX/TX via a serial port, parallel port, or ethernet. Not just from clicking with the mouse
on its GUI's PTT box (the box can turn red on python GUI level without the C code that does the hard streaming and FFT work ever knowing it).
Am experimenting with that now to make sure a proper quadratrure data stream is being generated when TX is activated. It then reaching the DA is the other problem ....

[hansvi]

Yes I have noticed that too. I've been scratching my head over it quite long but I think I found an explanation.

I think the idea is to use a simple CW key, because if you select CW mode in quisk, it always transmits a carrier when PTT is pressed. So the key would control tx mode, which would then control the CW signal. That's not a great way to do CW with this transceiver, it's more like a duct-tape solution.

I have included my hardware file. I think yours is missing OnButtonPTT, in that case the PTT button is disabled from the GUI.

quisk_hardware_peaberry.zip

peaberry hardware driver for quisk

(3.12 KiB) Downloaded 540 times

Good luck,
Hans.

[CT1IQI]

Thanks; yes, your quisk code works, and so does the code I made, I discovered. It is indeed the usb streaming that is causing the problem. Adding plughw, i.s.o. hw: makes the difference but in my first trials it did not work first time on TX. Will experiment further this weekend.

[AE9RB]

Right now the only issue I have is that the frequency in quisk is not correct. However, if I use linrad, I'm spot on. So, once I have figured that out, I'll post a "final" config file for quisk.

Quisk is using the old protocols. Calibrate with CFGSR and always use:
si570_xtal_freq = 114285000

I talked with Jim and he's changing Quisk to bypass the USB error.

Linux audio is pure, distilled madness. I've been using PortAudio lately which seems to bypass some of the crazy.

[CT1IQI]

The transmitter function is not working properly and would like to ask for advice which part might be causing this.
The symptoms: in CW mode a carrier is produced that has very wide sidebands with a multitide of carriers, 1 kHz apart.
When I switch the receiver that monitors the Peaberry signal to AM mode the CW carrier appears modulated with a 1kHz tone that sounds quite distorted.
The Peaberry in SSB mode produces a very wide and distorted signal. Probably the underlying cause is equal for ssb and cw and something in the D/A conversion process is not working properly. Any idea what might cause this ? (reception works fine; the supply voltage is 13.8V and clean and easily capable of the current draw.)

[hansvi]

Could you describe your setup, and how you are measuring the signals?

Also, does the audio output of the peaberry work? If the speakers work fine, then you can already rule out part of the circuit.

[CT1IQI]

Tnx. Have tried the audio output now (had not soldered the connector in as I saw no use for the function) and with a small loudspeaker connected and the command
'aplay -D plughw:CARD=SDR,DEV=1 -V stereo /testmusic.wav'
the VU meter jumps to 30-40% but the audio is only there extremely weak, barely audible with your ear 'in the speaker'. The little I hear sounds undistorted though, just extremely weak.
Am using latest quisk and a kenwood transceiver to listen to the Peaberry that is connected to a 50 ohm dummy load.

[DJ&OA]

On reading the posts regarding problems with the Peaberry, I get the impression that most problems are self-inflicted.

1. A properly built Peaberry works 'out of the box' under Windows with HDSDR if you use the patches (.lib and .dll) provided by AE9RB.

2. If you prefer Linux and Quisk, get the latest Quisk version 3.6.10 (and nothing else) from the home page of N2ADR. This version is already patched for the Peaberry and has a quisk_config_peaberry configuration example which only has to be adapted as regards the soundcard situation. This also works 'out of the box' unless you have a subst-andard PC like my EeePC 900 I am using in the car. In the latter case, you have to use the alsa-functions for the two 'capture' configurations and portaudio-functions for the two 'play' configurations and possibly to increase the latency.

3. For cw, use the key0 socket like with any softrock design and not any button of the respective programs. Using the return key on your computer for cw is quite akward. For SSB use for your comfort a dynamic microphone with a PTT switch for grounding the ring terminal of the microphone socket after replacing R14 by a series combination of the input side of an optocoppler and a lower value resistor (depending on the optocoupler used). The output of the optocouler then is used for shorting key0 to ground for PTT.

4. Wide sidebands and a multitude of carriers on tx are almost always caused by a weak power supply which gives in on transmit when it has to supply nearly 0.5 A.
The Peaberry should have a constant noise free supply of at least 13V.

If you take care of the above points, you should have now problems wit a properly built Peaberry.

73, Rainer
DJ6OA