开云体育

Hello Sascha,

Useful measurements. The issue is that your Arduino RX input is not pulled low enough (rather than not high enough).

I had a look at the Sparkfun logic converter that seems identical to what you used and it relies on the low voltage (3.3V) input pulling the voltage down which then passed through a mosfet transistor.

Therefore if the TX output of your loop controller can't pull the voltage low enough it has no chance to do so through the voltage converter. It would be ok if it was two inverting common emitter npn transistors circuits but it is not designed like that.

I also checked the circuit diagram of the loop controller and it has two 1K resistors on the RX and TX lines at the TTL input/output the Teensy.

So I recommend that you keep the voltage adapter in line as you have now, leave the Raduino/Arduino circuits as-is and remove (short circuit) the 1K resistor that is in series with the TX1 pin of the Teensy in the loop controller. This should then allow for a better drive of your voltage converter input and consequently of the input of the Arduino. You can leave the 1K resistor that goes to the Teensy's RX line.

At present I strongly suspect that the issue is that the 1K resistor in the loop controller circuit, is connected in effect in series with the 1K resistor between the Arduino RX line and the USB controller, and it does not allow the voltage to swing enough and that explains the difference in the low value (TTL logical one) between a powered up and an un-powered Arduino.

Hope that makes sense.

All the best,

73, John (VK2ETA)

HEUREKA -

It finally works!!!

John, that was the solution - the 1k Resistor in the TX line of the loop controller circuit.

I was a bit afraid of bridging it first , soI changed it to a much smaller value - and finally the voltage dropped low enough so
that the Raduino was able to recognize, decode and answer the incoming signal.

Thanks a lot for your help! I had not really been optimistic that I would be able to make it work. Your insight and advice really made the difference!


And thanks Gary also for your note. That had been one of my first steps, changing the the RX and TX lines.

73

Sascha

Hello Sascha.

Thank you for keeping us informed and posting the videos.

Some ideas:

1. For my capacitor tuning (L-network, not a loop) I use an RC servo. The cheap SG90 servos (less than $2 on eBay) will do 180 degrees rotation in fact and the angular accuracy is good enough. Less noise but still not silent either. But you can drive the capacitor shaft directly since there is no need for gears and therefore it is easy to make a tiny sound proofing box for them. RFI into the servo was fixed with a simple toroid for the control cables just at the servo entry. If wanted you could cut power to the servo with a mosfet to save energy (a few milliamps) when not moving.

2. For tuning, you can use CW and reduce power by using Ted's method (see /g/BITX20/message/67662).

You would need to change the cat_lib.ino library a little. For example you could create an AM mode in the CatSetMode method that sets an AM flag to use later in the CatSetPTT method.

In the CatSetPTT method on a PTT ON command, if AM mode flag is set, you could use a startTx(TX_CW, 0) followed by cwKeydown();

On a CAT PTT OFF command just reverse with cwKeyUp(); followed by stopTx();

That's the logic I use for my tuner.

That way you don't need to change the loop tuner's code.

it took some time again to implement, but your advice is really most welcome.

I figured out I could reduce the noise a bit by slowing down the turning speed in the configuration - not perfect, but a bit better.
There are a lot of configuration options and buttons which can be pushed? (in the code and in the menu) and I have not figured
out everything yet. However I will have a look at those servos and the mosfet-mode you mentioned.

I have tried the code adjustments for AM-tuning you suggested, but it is not working yet as it should.

I guess I made a mistake somewhere. After pushing the Tune button on the controller, the uBITX starts sending a CW signal which
stopps after mayxbe three seconds again. Yet the side-tone of the "cwKeydown"-mode persisists and only turns of after having
used the screw-driver again to manually induce an RX/TX/RX change.

Any idea where I need to start looking?

I uploaded my changed code to Pastebin


For easy power control the method you linked to seems to be a good hack. Maybe I can wire in in a relays or an easy circuit to make the
power setting adjustable with a switch. Thanks again for this link too.

73

Sascha

Hi everybody,

the missing bracket was not the solution - in fact it did nothing at all.

I assume it is not the right position in the function, but I cant really imagine why this is so. The position seems plausible.
But I have to admit i do not understand in detail how the function works. It is a bit "nested" .

void CatSetPTT(boolean isPTTOn, byte fromType)
{
? //
? if ((!inTx) && (fromType == 2 || fromType == 3)) {
??? Serial.write(ACK);?
??? return;?
? }
?
? // Set PTT Mode
? if (isPTTOn)
? {
??? if (!inTx)
??? {
????? txCAT = true;
????????????? if (isAM == 0)
????????????? {
??????????????????? startTx(TX_SSB, 1);
????????????? }
????????????? else? {startTx(TX_CW, 1);
??????????????????? cwKeydown();
??????????????????? }
????? //Exit menu, Memory Keyer... ETC
????? if (isCWAutoMode > 0) {
????????????????????????????? isCWAutoMode = 0;
????????????????????????????? printLineF2(F("AutoKey Exit/CAT"));
???????????????????????????? //delay_background(1000, 0);
???????????????????????????? }
??? }
? }
?
? else // without PTT
? {
??? if (inTx)
??? {
???? // cwKeyUp(); was not working
????? stopTx();
????? txCAT = false;
??? }
? }

? Serial.write(ACK);

I tried something else then, I smuggled the cwKeyUp() then into the CatSetMode-function.
So everytime a new mode is selected (which happens after tuning mode), the CWkey gets lifted. I do not know if this has side effects, but at least it seems to work.

Shamefully this solves only the problem with the sidetone after pressing the Tune-Botton, not the issue with the interrupted TX-Mode

This is the persisting issue:

If the transmitter is switched on via CAT-Signal by the loop Controller (either via PC command or by pushing the tune botton), the triggered TX-Mode is always stopped
again after about 1,3 seconds.

This time I think the problem is the Loop Controller - because it seems to be intentional. Or at least this can be assumed by looking at the serial protocol of the Teensy.

The controller sends the AM -Mode and PTT command to the uBitx.? The TRX starts sending HF and after about 1,3 to 1,5 seconds it switches back to RX AND also
the previously active mode.

I have checked with another tranceiver and an addional SWR-Meter. There is really HF coming out, but the reason for stopping is absolutley unclear to me.

Maybe there is a failsafe procedure I do not find - or the loop lontroller expects a kind of feedback signal from the tranceiver. I have also already tried to increase the delay
after the TX-Start and the SWR measurement (assuming the signal needed to be on longer), but this was also fruitless.






I think the procdure of the tuning process is this:

Maybe somebody has an idea.

73s

Sascha

Hi John,

no problem - there is no excuse needed. And thanks already in advance.
You are not obliged top help at all ? :-)

Sascha

So, just to keep everything updated:

Today I played around a little bit more and inserted some serial.prints to check out which functions are
being calculated and where the program stops.
In the following screenshot you can see that the power measurement function seems to be working.



However I am not able to print the status of the progress variable, though I don't understand why.

It is defined as "2" at the beginning of the sketch and should therefore be? either a "2" or a "FAILED" I think.
There are some further declarations in the second page which define which number refers to which status.

It seems as if the variable does not get the new value?

(// Bool stuff
#define WORKING??? 0
#define DONE?????? 1
#define SUCCESS??? 1
#define FAIL?????? 2
#define NOPWR????? 3)

Sascha

// Token passing flagsfor SWR tune process

struct? {

????????? unsigned Prepare? : 1;??? // Do initial preparations

????????? unsigned Progress : 2;??? // Track tune progress

????????? unsigned Ask_SWR? : 1;??? // Request new SWR measurement - Yaesu special case...

????????? unsigned InitPWR? : 1;??? // Init Power Setting for Tune

????????? unsigned InitMode : 1;??? // Init Mode Setting for Tune

???????? } tune;

int32_t sample[SWR_SAMPLEBUF];????? // Ringbuffer for SWR averaging

int32_t mid_swr;??????????????????? // The SWR at midpoint, SWR_SAMPLEBUF/2 samples ago

Or at least i think that this is valid as a declaration, as I have never seen the "struct" construction before.

I had just mentioned the #define part, as I do not know if this is relevant to the value a variable gets passed.
Also the #define part is in the main *.ino file while the swr-thing is in another *ino file. So i just wanted to make sure I mentioned it :-)

I don't really think the declaration is the problem since everything works if the uBITX is already transmitting -
because in that scenario the progress-variable should get the correct value.

? // Check whether Transmitter is already puming out RF
? measure_power_and_swr();??????????? // Ensure we have one measurement available
? if (fwd_power_mw >= MIN_PWR_FOR_SWR_CALC)
? {
??? swr.rfactive_mode = true;???????? // We're good to go, no setup required
??? progress = SUCCESS;?????????????? // Setup for Autotune is initiated?
? }
?

Wait a second.

I just realized that the stepper motor always starts tuning - it just does not finish the tuning process if tuning is manually triggered.
So I might need to check for "canceling conditions" during tuning in the sketch. Though that does not explain why the progress variable is not printable.

Sometimes just summarizing and processing helps.... Another clue to investigate on.



Sascha