OpenHPSDR - no power control

[peterschrader2]

piHPSDR V2 from Apache-labs. Radio is OpenHPENSDR with Atlas bus, Mercury receiver, Alex filters and Penelope exciter. All with the most recent firmware.

The Power control sliders have no affect on power output, that is, full power is output no matter where the slider is placed.

All receive functionality works great.

[dl1ycf]

Ah. For penelope, the drive control is different than for all the other boards. This means there is no drive control but rather the IQ samples need be scaled. In principle this is in the code but perhaps the penelope was not recognized correctly.

[Bob4xv]

I had this issue as well but managed to trace it back to not having checked the box menu>radio>Penelope Tx It seems that without this box checked penelope still transmits but does not enter transmitter.c line 1057 if(radio->device==NEW_DEVICE_ATLAS && atlas_penelope) { as atlas_penelope is not set and thus does not apply the scaling factors and so transmits full power. Probably the real issue is that it still transmits when not checked?? I'll think about it.

[dl1ycf]

The penelope has no programmable TX level, so the IQ samples have to be scaled in the TX module. This must not happen if the TX drive level is set by the programmable TX output booster on the SDR board. So without knowing it is a penelope, the SDR program correctly uses the "booster" rather than scaling. The conjecture is transmits full power is wrong, it transmits maximum-amplitude IQ samples and this leads to the desired power since the drive level field of the HPSDR protocol is respected on all boards newer than penelope.

[Bob4xv]

Ok so here is the issue I have. After re-installing pihpsdr I forgot to check Menu>Radio>Penelope Tx, then moved to the Tune function knowing the drive was set to 10% clicked the Tune button. At this point Munin produced full power(86Vrms into 50ohms) causing the smoke to be released from the auto ATU while it tried to tune with the input power so high.
This is because in transmitter.c line 1057 it tests for (NEW_DEVICE_ATLAS && atlas_penelope) and because the above checked box was not checked the code failed to enter the braced code, the IQ samples were not scaled. At this point the software has determined we have "Atlas Bus" "OLD Protocol" "No Penelope" so it assumes we have a Pennylane board which controls the drive in the FPGA as the other devices do. However during discovery we had detected penelope because the CLI output displays its firmware version. So to avoid this pitfall I suggest we set the variable "atlas_penelope" during the detection of penelope in the discovery phase. This can be done by adding a line into the brace at line 1110 of old_protocol.c "atlas_penelope=1;" which sets the checkbox that I forgot to set automatically. eg if(penelope_software_version!=control_in[3]) { penelope_software_version=control_in[3]; g_print(" Penelope Software version: %d (0x%0X\n",penelope_software_version,penelope_software_version); atlas_penelope=1; //Vk4xv } I cant see this effecting the operation of any other devices and the software is more forgiving for the likes of me. Bob Vk4xv.

[dl1ycf]

(By the way, you ran into this problem because you discarded your "props" file.)

In the original HPSDR protocol, the "C0=00000xxx" control bytes are indeed defined as follows (from the protocol P1 document):

C2 – Mercury software serial number (0 to 255) - set to 0 when Hermes C3 - Penelope software serial number (0 to 255) – set to 0 when Hermes C4 - Ozy/Magister or Metis or Hermes software serial number (0 to 255)

so your suggestion boils down to switch to "penelope" mode whenever C3 is non-zero. This definition says little what happens "beyond Hermes". There are not so many penelope's out there but a lot of, say, HermesLite radios, and these hijack this C3 byte in the protocol for another purpose (TX FIFO count and under/overflow markers).

So I am with you that if one knows it is a penelope the "atlas_penelope" flag should be set for security reasons, but one needs a definite info on that and I have no access to such a radio. The natural place to detect this is in the discovery process.

So perhaps look at what happens in the discovery process. Can one tell there for sure it is a penelope? Then one could initialize atlas_penelope to 1 before reading the props file (in radio.c).

Yours Christoph DL1YCF.

[Bob4xv]

OK Good point so I did some more investigation and found the following. In old_protocol.c the switch statement at line 1094 case 0 there is an if statement if (device != DEVICE_HERMES_LITE2) { (which includes within the brackets the test for penelope software version) that elimates hermes lite2. So at this point we know its not hermes lite2 but is atlas bus and we have found a penelope with a software version 18 in my case. So if we now test for penelope with software version 18 "true" as below.

    if(penelope_software_version!=control_in[3]) {
      penelope_software_version=control_in[3];
      g_print("  Penelope Software version: %d (0x%0X)\n",penelope_software_version,penelope_software_version);
    if(penelope_software_version == 18){    // the only version available now and the last more than likely
            atlas_penelope=1;                           //Vk4xv 
        }
    }

My research of the old hpsdr site shows the latest and only firmware for penelope available, is version 18.

Using my old favorite cli cammand <grep -Hn 'control_in[3]' *.c> from within the pihpsdr directory i get: old_protocol.c:854: control_in[3]=buffer[b++]; old_protocol.c:900: if(penelope_software_version!=control_in[3]) { old_protocol.c:901: penelope_software_version=control_in[3]; old_protocol.c:927: alex_forward_power=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // from Alex or Apollo old_protocol.c:932: AIN3=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // For Penelope or Hermes old_protocol.c:936: current+=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // HL2 old_protocol.c:947: AIN6=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // For Penelope or Hermes

old_protocol.c:1110: if(penelope_software_version!=control_in[3]) { old_protocol.c:1111: penelope_software_version=control_in[3]; old_protocol.c:1140: alex_forward_power=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // from Alex or Apollo old_protocol.c:1145: AIN3=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // For Penelope or Hermes old_protocol.c:1149: current+=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // HL2 old_protocol.c:1160: AIN6=((control_in[3]&0xFF)<<8)|(control_in[4]&0xFF); // For Penelope or Hermes old_protocol.c:1204: control_in[3]=b;

So these c&c bits are only used in the old_protocol.c file. In this file lines 817-1042 are commented out. Note line numbers here are incremented 3 after 1112 in this code due to the insertion 3 test lines added here to test for penelope. So possible effected devices apart from atlas bus devices could be Hermes and HL2 using protocol1. We could add a test if(control_in[2] !=0 to eliminate Hermes, My Mercury returns 34.

So for my old atlas gear this addition works fine so far for me, but I don't have either Hermes or HL2 here. Whatyou think? Bob Vk4xv. ps. cloning pihpsdr from git and doing a build on a new device is prone for loosing the .props hi!

[dl1ycf]

Well, the problem I see is that in your suggestion "atlas_penelope" is constantly over-written, even if for some reason the user has chosen to uncheck it in the radio menu (or through the props file). So this is not fault tolerant.

Is it really not possible to "detect" a penelope in the discovery process?

I guess in your case it reports (since you are running the old protocol) device = METIS (byte 10 of the discovery buffer == 0), and what is the software version reported in byte 9 of the discovery buffer?

There must be a line in the log file of type

old_discovery: found device=xxx software_version=yyy status=zzz address=AA:BB:CC:DD:EE:FF

and what interests me is whether penelope has a nearly unique combination of xxx and yyy. When starting the radio, one could init atlas_penelope once with "true" for certain xxx/yyy combinations.

BTW, perhaps we continue the conversation via email (dl1ycf@darc.de), and we can then report the outcome.

I think a "safety belt" as you suggest make very much sense, but it must have some tolerance against "false penelope detection".

Yours, Christoph DL1YCF.