Keyboard Shortcuts
Likes
Search
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,
toggle quoted message
Show quoted text
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 |
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.... |
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 |
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,
toggle quoted message
Show quoted text
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 |
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 |
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. 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). |
A bit confusing, should read "driving the old PTT wire FROM the Bitx40"
toggle quoted message
Show quoted text
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.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:
|
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,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,
toggle quoted message
Show quoted text
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 |
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 |