pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
337 stars 209 forks source link

BPF/LPF and PA control from within WSPR? #730

Closed DH1KLM closed 6 years ago

DH1KLM commented 6 years ago

This is not an issue, its more a request or a suggestion. I refer to https://github.com/pavel-demin/red-pitaya-notes/issues/658

Interesting topic, is there any progress so far?

I have just dealt with WSPR, I noticed that transmission power can not be adjusted. Similarly, LPF / BPF can not be controlled from WSPR like it is done in HPSDR.

This may not be a problem for someone who only does WSPR, but if a BPF / LPF and also a PA is integrated in a multimode system, problems arise. For example, if WSPR goes in TX the PA will be switched to TX but the BPF / LPF will remain uncontrolled. In my case, all LPF relays are open and the power is not routed to the responsible LPF and antenna and so there is no output. Likewise, the PA is driven at the full power from Red Pitaya, which would result in a 100W WSPR signal being sent if the LPF were switched.

Would it be possible to expand WSPR with these settings? For example, in the file "transmit-wspr-message.cfg" the power out from RP and LPF / BPF setting.

// frequency freq = 10.1402; lpf = 1,0,0,1 (30M in my case); pout-level = 2dBm (or any other unit)

As already said, it's only a suggestion.

Thanks for all your work.

pavel-demin commented 6 years ago

If you're using the GPIO pins to control the filters, then these pins are controlled by the gpio-output program.

By default, this program switches on and off the PTT output (pin DIO0_P). This program is started from the transmit-wspr.sh and decode-wspr.sh scripts.

If I'm not mistaken, it should be enough to replace $GPIO 1 with $GPIO 137 on line 22 in transmit-wspr.sh. Where 137 corresponds to 10001001 in the binary format.

pavel-demin commented 6 years ago

For the level control, I could add a parameter varying from -90 to 0 dB. The following code could be used to convert it from dB:

level = level > -90 ? floor(32766 * pow(10.0, level / 20.0) + 0.5) : 0

However, I don't think that it's an efficient solution. A better solution would be to somehow reduce the PA amplification.

DH1KLM commented 6 years ago

Sounds not that bad. I may be wrong, but if i replace $GPIO 1 with lets say 137 it would not switch PTT. Am I missing something?

For the level control, I could add a parameter...

That would be great, since there is no other to reduce the amplification except a attenuator. and that is what i want to avoid.

pavel-demin commented 6 years ago

if i replace $GPIO 1 with lets say 137 it would not switch PTT.

In 137 (10001001), the bit 0 corresponding to PTT is 1. So, I think that 137 should switch PTT on.

However, I think that 137 isn't a correct value.

The correct value should probably be 145 (10010001), with bits/pins 7, 4 and 0 set to 1.

pavel-demin commented 6 years ago

I've just added the level parameter with this commit.

This code will be in the next release.

DH1KLM commented 6 years ago

I have to admit that I can not handle the settings for the LPF. If I use 145, the PA is switched to TX and the LPF is activated for 10m. 145 = 10010001 and this activate my 10m LPF. I have problems with the conversion.

These are my HPSDR settings and all works well.

psdr-filter

Could you please tell me what are the related decimal values.

pavel-demin commented 6 years ago

Could you test the following codes?

band code
160m 17
80m 33
60m 33
40m 49
30m 81
20m 81
17m 113
15m 113
12m 145
10m 145
pavel-demin commented 6 years ago

The following formula could be used to convert the BCD codes from the HPSDR settings to the GPIO parameters for WSPR scripts:

GPIO = BCD * 16 + 1

DH1KLM commented 6 years ago

This works, I am really excited. Thank you very much for your efforts. Now i will test the power level parameter.