开云体育

开云体育

Right Joe, if you need many of them you end up paying more. And the ones I mentioned, rated at 300w, might not even needed for that amp. However if some have some ferrous toroids (say red, yellow or white) in the drawer buying just the mica caps may make nice filters based on a good and simple design.

开云体育

I am in the opinion that a LPF like that at 50usd is overpriced. Toroids seem small, what about the capacitors? Are these ceramic or silver-mica, rated at what voltages? You may have a look to http://www.communication-/fl1-15/,? the manuals are instructive.

Do not use receivers that have an antenna connected. Remove the whip of the degen if possible. Transmit into a 50ohm dummy load and not to the antenna for these tests.

开云体育

开云体育

So once again I made some progress. I have not located the exact cause of the end of the transmission yet, but I am sure the problem lies within the fake AM mode of the uBITX:

So, i used my USB to TTL-Adapter to spy on the communication between the Loop Controller and the uBITX on both lines, RX and TX,
and could not find anything unusual in the commands.

No that's actually not correct:

In fact I noticed that the uBITX switched back to RX even before the loop controller had sent the command to do so.
You could see these also by watching the commands on the computer monitor and the power output of the swr-meter.
The timing just did not fit as it should have.

Otherwise the commands were actually okay - as well as the loop controllers answers:

I did some serial.printing here and made it give out? the measured forward and reflected? power, the calculated power and the VSWR.
Until here everything was okay.

Then I made it print the value of the Progess variable - before and after a new value should have been assigned:

????? trx_set_am_mode();????????????? // AM mode
????? delayloop(50);
????? if (radio.pwr_available) trx_set_min_pwr();? // Set Minimal power
????? delayloop(50);
????? trx_set_tx();?????????????????? // TX mode
????? delayloop(250);???????????????? // Give time for Power to come up
????? measure_power_and_swr();??????? // Ensure we have one measurement available
?????? Serial.print("FWD:");
?????? Serial.println(fwd_power_mw/1000);
?????? Serial.print("REF:");
?????? Serial.println(ref_power_mw/1000);
?????? Serial.print(" PWR ");
?????? Serial.print(power_mw/1000);
?????? Serial.print(" SWR ");
?????? Serial.println(measured_swr);
?????? myState = tune.Progress;??? // myState ends up with the value 0 or 1
?????? Serial.println("alter Fortschritt");? //old progress
?????? Serial.println(myState);?
????? progress = SUCCESS;?????? // Setup for Autotune is initiated
????? myState = tune.Progress;??? // myState ends up with the value 0 or 1
????? Serial.println("neuer Fortschritt");? //new progress
?????? Serial.println(myState);?

It turned out the variable? does not get updated. I did then another round of serial printting withing the SWR-HUNT function,
in the section where the output power was checked again - and voilà, not power anymore.

??? // FAIL - Not enough Transmit Power to determine SWR
??? else
??? {
????? tune.Prepare = false;???????????????????? // Clean up for next time
????? tune.Progress = NOPWR;
????? Serial.println(ref_power_mw); // tested forwared AND reflected power here
????? Serial.println(MIN_PWR_FOR_SWR_CALC); // minimum output power to do the calculation
????? Serial.println("shit"); // abort due to no power





Sorry for the german language within the screen shots.

So the loop controller just sends the commands:

0000000003 (report frequency and mode)

0400000007 (change mode to AM)
0000000008 (start TX)
0000000088 (end TX)
0000000007 (change mode to LSB)

The uBITX answers with 8 zeros

00000000

I did again some reverse engineering within the uBitx code (changed out "0"? to "1" in the Serial.prints) and found out that the change mode command as well as ther start
and stop tx commands are always answered with "00" by the uBITX So four times "00" makes 8 zeros. Nothing unusual here.

Then I came to coclusion that the next reasonable thing was to turn off the loop controller and just use the uBITX cat control with the PC,
triggering AM mode and TX via PTT.

I did this then with Ham Radio Deluxe and noticed that HRD always switched back to CW after switching to AM.
Of course, the uBITX did react to the "get into AM" command, but if asked what mode it was in, it still answered with CW.

So i modeified the uBITX code a bit to make it also send back the AM identifier within the cat_libs.

void CatGetFreqMode(unsigned long freq) //for remove warning messages
{
? int i;
? byte tmpValue;
? unsigned BCD_LEN = 9;

? if (BCD_LEN & 1) {
??? CAT_BUFF[BCD_LEN / 2] &= 0x0f;
??? CAT_BUFF[BCD_LEN / 2] |= (freq % 10) << 4;
??? freq /= 10;
? }
? for (i = (BCD_LEN / 2) - 1; i >= 0; i--) {
??? tmpValue = freq % 10;
??? freq /= 10;
??? tmpValue |= (freq % 10) << 4;
??? freq /= 10;
??? CAT_BUFF[i] = tmpValue;
? }

? //Mode Check
? if (cwMode == 0)
? {
??? if (isUSB)
????? CAT_BUFF[4] = CAT_MODE_USB;
??? else
????? CAT_BUFF[4] = CAT_MODE_LSB;
? }
? else if ((cwMode == 1)&&(isAM == 0))
? {
????? CAT_BUFF[4] = CAT_MODE_CW;
? }
? else
? {
????? CAT_BUFF[4] = CAT_MODE_CW;
? }
? if ((cwMode == 1)&&(isAM == 1)) // else davor?
? {
????? CAT_BUFF[4] = CAT_MODE_AM;
? }
? SendCatData(5);
}

This did the trick and HRD stayed on AM after having it set to AM.

So I finally was able to try to make it switch to TX on AM:

The result was the same as with controlling the uBITX with the loop controller.

TX starts and when it is about half a second in transmitting, it switches back to RX. Also the sidetone is still in function
and does not get turned off, though I have the "keyup()" command on two locations.

Once in the CatSetPTT()? (which did never work at all)

void CatSetPTT(boolean isPTTOn, byte fromType) //inTx==1 bei Sendebetrieb, egal ob cw, ptt oder cat
{
? //
? if ((!inTx) && (fromType == 2 || fromType == 3)) { //fromType normal : 0, TX : 1, CW_STRAIGHT : 2, CW_PADDLE : 3, CW_AUTOMODE : 4
??? Serial.write(ACK);? //already checked
??? return;?
? }
?
? // Set PTT Mode
? if (isPTTOn) // isPttOn = indirect logic: Ptt=1 means RX
? {
??? if (!inTx)
??? {
????? txCAT = true; // if TX due to CAT
????????????? 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 // if already in TX miode
? {
??? if (inTx)
??? {
????? cwKeyUp();// is not working
????? stopTx();
????? txCAT = false;
??? }
? }


and once in the CATSetMode() (which worked with the loop controller)

As the CatSetMode is not triggered with HRD ( where just? the TX-Mode gets stopped) I strongly suspect that the problem
is caused by a function / condition within the ubitx firmware, which collides with the fake AM mode.

I also assume it is related to the CAT-Code as the TX-mode is not aborted if I use my external CW-KEY (aka skrewdriver)
to make the rig send.

I did try to find this condition, but was unsuccesful. I also could imagine, that this is a programming gap as normally the cw key
is not controlled via cat. Could this be possible?

I first thought that it must work as you John are using it with your antenna tuner - but then i remembered having read somewhere,
your CW-Signal is generated not with the CW but the SSB clock?

I would be glad if anyone had an idea what to do.

This was a long post now (which surely could have been a lot shorter if focused on the results of the experiments),
but I wanted to write down how i came to these results / conclusions. Maybe I did not interpret everything correctly.

Sascha

Hello,

thank you all for your excellent replies: I'm going to make the BFO calibration procedure, and listening by myself on my good old DEGEN 1103 chines receiver.

And yes, I was surprised at first by the too higly pitched received modulation: it is a good second facts that leads to a BFO calibration problem.

I will let you know!

All in all this uBitx is a great transceiver for the price, and for many like me a chance to transmit with something else but commercial hardware.

And many thanks again for great support.

Best 73's.
--
Laurent F5FIE.