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

https://ibb.co/ZGJBbPF

https://ibb.co/cDGMNb6

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.

Hi Vince, Wayne... It's based on work done by DuWayne KV4QB - http://kv4qb.blogspot.com/search?q=power+dummy
I have a few spare boards if you are interested...
/ Gerry

You may like to hear your modulation yourself with another receiver. You transmit into a dummy load and you receive without any antenna. I have ver. 3 and has no basses, say lower than 500hz. Listening to my SDR receiver I like my modulation a lot! Excellent for dx. I had generally excellent reports. However I trust more of what I hear myself than the reports by others. Not always their carrier is yours, they might have strange settings in filters, pbt etc

I've recently built a ubitx and hooked it up to a GR5V antenna that I borrowed from a member of my local radio club. This evening, I was working with a friend of mine who lives three blocks away to test the rig, but ran into some interesting problems.

When he transmits, his signal comes in very loud, but his voice is garbled. If I move a few kHz around the frequency that he's transmitting on, the pitch of his voice varies, but it remains garbled. It sort of sounds like the teacher from Charlie Brown crossed with a robot from an 80s kids movie, and I can't make out any of the words that he's saying.

If I transmit, he gets a similar effect, wherein my voice is loud but very garbled, and comes along with a high pitched carrier that he can hear whenever I'm transmitting.

For both tests, we were on 20M, around 14.247MHz. The antenna that I'm using is very homemade, and it probably isn't mounted high enough off the ground, but the fact that I'm hearing the signal loud and clear, but that it's garbled makes me think that the problem is with my radio rather than with the antenna configuration.

What can I do to troubleshoot this issue?

I've attached a couple of recordings of the problem. Hopefully somebody recognizes the problem from listening to them.

Thanks,

VA3JFZ

I took a look at it.  Simple, straight-forward, and most of the features I consider critical - you can do a lot with that.  If the battery test puts a small load on the battery while testing, that's a nice extra.  The small size is also a plus... and the voltage rating is sufficient for most uses.  (I wouldn't want to test a 480vac line with it!)

I'd be careful with the amps testing... no fuse.  A good idea would be to make an adapter that fit in the amps socket, which had a 10a fast-blow fuse that was replaceable.  They also have a time limit for that sort of tests, and I'd consider that the absolute maximum (better to be extra careful). 

All in all, not too shabby... good for general use.   I'd use one for a "tool-box" meter.