¿ªÔÆÌåÓý

Cw offset in semi qsk


 

Hi again
Things are coming together quite nicely, and removing c91 and c92 got the USB working well. CW seems to work as it should with semi qsk turned off and set to CWL, however when semi qsk is on, the Cw offset doesn't seem to be working. I have verified this by listening to things on my yaesu, and tuning in a Cw station so the tone is 800 hz both on the yaesu and the bitx. With semis off, I get a nice 800 hz tone on the yaesu when transmitting with the bitx (zero beat with the received station). With semi qsk on, on TX, I am true zero beat on the yaesu ( no tone so 800 hz off the rx Cw signal frequency, as though I were in lsb mode). Hope this all makes sense.

Thanks
Brent


 

Brent,

Thanks for reporting, I will double-check and verify it on my own BitX
tonight.

Note that the offset should be applied during RX only, not in TX. The
'dial' frequency as shown on the display doesn't change.
So the dial frequency is always the transmitted frequency. The received
frequency is shifted by the same amount as the side tone pitch (default
800Hz, adjustable in the SETTINGS menu).

Note that not all commercial transceivers work identically. For example, I
own a Kenwood radio that applies the offset during TX, and also updates
the frequency on the display. I also own a Yaesu which uses RX offset and
does not update the dial frequency.

An easier way to test this, is as follows:
1. set the radio in CWL mode
2. tune in to a CW station and observe the pitch of the received tone
3. without changing the frequency, move the radio in LSB mode
4. the pitch of the received tone should now change by 800 Hz

The semiQSK setting of course should not make any difference. If it does,
then you've discovered a bug in the code which MUST be corrected.
I will check it tonight.

73 Allard PE1NWL

On Wed, September 27, 2017 15:57, Brent Seres wrote:
Hi again
Things are coming together quite nicely, and removing c91 and c92 got the
USB working well. CW seems to work as it should with semi qsk turned off
and set to CWL, however when semi qsk is on, the Cw offset doesn't seem to
be working. I have verified this by listening to things on my yaesu, and
tuning in a Cw station so the tone is 800 hz both on the yaesu and the
bitx. With semis off, I get a nice 800 hz tone on the yaesu when
transmitting with the bitx (zero beat with the received station). With
semi qsk on, on TX, I am true zero beat on the yaesu ( no tone so 800 hz
off the rx Cw signal frequency, as though I were in lsb mode). Hope this
all makes sense.

Thanks
Brent


 

Hi Allard

I just did some more investigating. The offset is indeed applied when using the ptt and with the cw mode not in semi qsk. When using semi qsk, it appears as though the receiver thinks its in single sideband mode. It says cwl on the display during key down, but switches back to lsb on key up. One interesting observation. If I have been in cwl with qsk off, then turn qsk on, everything is good, rx is where it should be and on the initial transmission the display says cwl. As soon as the ptt releases and you go back to rx, the display now says lsb, and the receive 800 hz shift goes away, as though the rx thints its back in lsb mode. One way I see to fix it might be to maintain a discrete cw mode that has to be selected, even when using semiqsk. Just a thought.

Thanks for all your help
73
Brent VE3CUS


 

Hi Brent,

I couldn't reproduce the issue on my BitX with v1.24.

When using semi qsk, it appears as though the receiver thinks its in single sideband mode. It says cwl on the display during key down, but switches back to lsb on key up.
It should stay on CWL, do you see LSB on the display on key up?
Are you perhaps in SPLIT mode? If VFO's A and B may be in different modes (one may be in LSB, the other in CWL). Please make sure SPLIT is off.
Are you perhaps manually pressing the PTT switch while you are in semiQSK? (you shouldn't)

If I have been in cwl with qsk off, then turn qsk on, everything is good, rx is where it should be and on the initial transmission the display says cwl. As soon as the ptt releases and you go back to rx, the display now says lsb, and the receive 800 hz shift goes away, as though the rx thints its back in lsb mode.
In semi QSK you should not manualy press the PTT switch (the whole idea of semiQSK is that the radio will switch between TX and RX automatically). If you press the PTT switch the radio will go back to LSB mode (no need to use the FB to switch modes).

If you want to use the PTT switch for CW then semiQSK should be OFF. In that case, to switch modes you need to use the FB (4 presses) to rotate through LSB-USB-CWL-CWU

73 Allard PE1NWL


 

OK
Here is what I have done and observed.?

Wired the ptt as per the diagram, using a 2n2222 fed from D7 through a base resistor
Connected the pttsense line. I used a 12k instead of 10 as that's all I could find at the time

Here is what happens:

In semi qsk, on key down, the radio automatically goes to TX as it should. The display reads CWL

After the qsk delay, the radio switches itself back to rx, and the display reads LSB

I am not manually keying the PTT.

The mystery continues....


 

Also, verified that I'm not using split, switching vfos, etc. Anomoly is the same whether using straight key mode or keyer. The pttsense line at the raduino reads 5v as it should in tx, and about 1.2 v in rx.


 

Brent,

Connected the pttsense line. I used a 12k instead of 10 as that's all I could find at the time

Perhaps this causes that the voltage on the PTTsense is slightly too high during RX. Try to use a lower value.

Alternatively you can try to disable the internal pull up resistor on the PTTsense input.
In the sketch, change the line
pinMode(PTT_SENSE, INPUT_PULLUP);
to
pinMode(PTT_SENSE, INPUT);
and see if that helps.

73 Allard PE1NWL


 

On my own BitX, I measure 1.25V during RX on the PTTsense input.
However when I disable the internal pull up resistor then I get true zero volts during RX.
So it seems anyway better to disable the pull up for better reliability. I'll correct that in the next version.

73 Allard PE1NWL


 

Thanks Allard. I'll give those suggestions a try. Forgive all the questions, as I am totally new to the Arduino. One question though. If the pttsense line was too high during RX, would I not also lose all of the additional functionality I gained by connecting it? Correct me if 8m wrong, but I assume that the internal pull up would normally hold that line high and then once connected it's pulled low in RX? I'm just trying to get my head around what is going on.

Thanks
Brent


 

Yes Brent, you're correct: Your PTTsense appears to be basically working,
as all the other functions related to it do seem to work.

But I was thinking that perhaps in your case it takes slightly longer for
the PTTsense signal to drop to a digital LOW after you switch from TX to
RX.
In that case the radio itself may already have switched back to RX, but
the PTTsense signal is still HIGH for a short period of time, hence the
Raduino will "think" that the PTT is pressed and switch the mode from CWL
or LSB.

The delay could perhaps be caused by the slightly larger resistor you're
using in combination with the pull up resistor. There is also a 0.1 uF cap
(c150) which needs some time to decharge.

But I do admit, this is only guess-work. So far I haven't heard of any
similar problems with the PTTsense.

73 Allard PE1NWL

On Thu, September 28, 2017 02:09, Brent Seres wrote:
Thanks Allard. I'll give those suggestions a try. Forgive all the
questions, as I am totally new to the Arduino. One question though. If the
pttsense line was too high during RX, would I not also lose all of the
additional functionality I gained by connecting it? Correct me if 8m
wrong, but I assume that the internal pull up would normally hold that
line high and then once connected it's pulled low in RX? I'm just trying
to get my head around what is going on.

Thanks
Brent


 

Hi Brent,

Here's another suggestion:
At lines 812 and 813:

??? digitalWrite(TX_RX, 0); // release the PTT switch - move the radio back to receive
??? delay(10);? //give the relays a few ms to settle the T/R relays

As you see on line 813 we allow 10 ms for the relays to settle. I experimented on my own BitX and found that when I set the delay to less than 7 ms, I get exactly the same issue that your reported (radio switches back to LSB mode).
So perhaps the 10 ms is too critical for your radio and you'd need a bit more delay. You could try to increase the delaytime somewhat and see if that helps.

73 Allard PE1NWL


 

Thanks again Allard

Yes, it all makes sense to me. I'll give it a try over the next couple of days and let you know. I was wondering about the same thing.

I really need to do some learning about programming the Raduino.

73
Brent


 

When the TX +12v rail shuts down at the end of a transmission, power into the LM78L05 at U3 gets cut off and you would think the 10k pot at RV1 would discharge the 0.1uF cap at C150 in something on the order of the RC time constant of ?10e3*0.1e-6 = 1 millisecond.
However the TX rail does not fall instantly, as there is a fair bit of capacitance out there as well. ?The 47uF at C124 in the microphone amp especially, even though it is hiding behind a 220 ohm resistor at R127. ?Adding a diode in series with R127 might fix this.

Another solution might be to add a 1k ?(could go as low as 100 ohms) resistor from U3 pin 1 to ground, in parallel with the 10k pot at RV1, so the regulated 5v bias drops faster.

A better solution might be to just wire the PTT switch up to a Raduino input pin and with pullup, and nothing else. ?The Raduino drives the old PTT wrire into the Bitx40 using the circuit shown here: ?
Downside is that users must do all of Allard's mods if they want more than the new function button, not pick and choose which mods to do.

On a related note, I'd feel much better about driving the old PTT wire into the Bitx40 with a 2n3904 if the diode and cap at D7, C130 were cleaned up to avoid spikes across the K1 coil at the end of a transmission: ?/g/BITX20/message/27483
But then we haven't heard any reports of that transistor blowing, so perhaps this is not absolutely necessary.

Jerry, KE7ER




On Thu, Sep 28, 2017 at 03:28 am, Allard PE1NWL wrote:

As you see on line 813 we allow 10 ms for the relays to settle. I experimented on my own BitX and found that when I set the delay to less than 7 ms, I get exactly the same issue that your reported (radio switches back to LSB mode).
So perhaps the 10 ms is too critical for your radio and you'd need a bit more delay. You could try to increase the delaytime somewhat and see if that helps.


 

A bit confusing, should read "driving the old PTT wire FROM the Bitx40"


On Thu, Sep 28, 2017 at 08:11 am, Jerry Gaffke wrote:
On a related note, I'd feel much better about driving the old PTT wire into the Bitx40 with a 2n3904 if the diode and cap at D7, C130 were cleaned up


 

On Thu, Sep 28, 2017 at 08:11 am, Jerry Gaffke wrote:
Adding a diode in series with R127 might fix this.

Another solution might be to add a 1k ?(could go as low as 100 ohms) resistor from U3 pin 1 to ground, in parallel with the 10k pot at RV1, so the regulated 5v bias drops faster.
True, but just having a few milliseconds of delay in the software works equally well and is a much easier work-around i.m.o.
The 10 ms delay we are using has always been sufficient (never heard of any complaints).
I guess in Brent's case 10 ms might just not enough because he's using a 12K series resistor instead of 10K for the PTTsense line.
I might increase the delay from 10 ms to say 15 ms in the next version just to make it less critical. Shouldn't do any harm? anyway I think.

73 Allard PE1NWL


 


Scratch that, the "correction" is likely the more confusing.
It was way too early in the morning.


On Thu, Sep 28, 2017 at 08:14 am, Jerry Gaffke wrote:
A bit confusing, should read "driving the old PTT wire FROM the Bitx40"
. . .


 

I must say, you're got the right attitude for this.
With thousands of Bitx40's out there, best to keep the recommended hardware hacks to an absolute minimum.

Perhaps V2 firmware could have the PTT switch wired only to a Raduino sense pin,
the Raduino driving the PTT relay coil.
?

On Thu, Sep 28, 2017 at 09:15 am, Allard PE1NWL wrote:True, but just having a few milliseconds of delay in the software works equally well and is a much easier work-around i.m.o.


 

On Thu, Sep 28, 2017 at 09:24 am, Jerry Gaffke wrote:
Perhaps V2 firmware could have the PTT switch wired only to a Raduino sense pin,
the Raduino driving the PTT relay coil.
Yes, the current solution is not ideal. For v2 we will need to revise the overall pin layout and the related wiring anyway, so that would be an ideal moment to also review the PTT circuit.

73 Allard PE1NWL


 

Allard,

If spikes from the K1 coil are ever determined to be an issue, you could add a 1n4148 diode between emitter and collector
of the 2n3904 in your PTT drawing. ?That would be easier than having everyone hack up their Bitx40 board
as suggested in post 27483


On Thu, Sep 28, 2017 at 08:11 am, Jerry Gaffke wrote:
On a related note, I'd feel much better about driving the old PTT wire into the Bitx40 with a 2n3904 if the diode and cap at D7, C130 were cleaned up to avoid spikes across the K1 coil at the end of a transmission: ?/g/BITX20/message/27483
But then we haven't heard any reports of that transistor blowing, so perhaps this is not absolutely necessary.


 

Success...finally

Allard's suggestion of increasing the delay worked. I arbitrarily set things to 25 ms, so I will have to try reducing that. Jerry, thanks for your suggestions as well.

Now, if someone has some good arduino tutorial suggestions, I would love to learn more about programming things.

Thanks again!
73
Brent