How to cook Thetis - Githubissues

ja5aea commented 3 years ago

Hi Pavel,

I hope you are fine under recent COVID-19 crisis.

I was told that Thetis now talks protocol 1 and RedPitaya is connectable to it. Therefore, I installed the latest V 2.8.11 and am trying to work for RedPitaya for a few days.

It seems RedPitaya works any "Radio Model" selection, i.e. any models automatically recognizes either protocol 1 or 2, but the behavior of "Diversity" and "Pure Signal" are different. Diversity would not work from HERMES to ANAN-100B category and Pure Signal would not work except HERMES.

So, I am expecting the activation of Pure Signal by feeding the sniffing signal to IN1 with one of ANAN "D" models selection but it is unsuccessful and I can not see any Feedback indication.

Are you aware of any proper settings for RedPitaya community about Thetis?

I am expecting your response soon.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Hello Take,

I have not tested Thetis. I think since the implementation of protocol 1 is very recent, it is quite normal that some features are still missing.

Best regards,

Pavel

ja5aea commented 3 years ago

Hi Pavel,

Here is my findings of your RedPitaya codes and Thetis V2.8.11 and sent to Thetis developers. My impression is that Thetis provides the best performance for Intel and Microsoft users and I hope they will strongly support RedPitaya model which now becomes the world-wide dominant protocol 1 open platform.

73.

de JA5AEA

To the Thetis developpers,

Would you look into the codes of Thetis V2.1811 and check the behaviors of "Diversity" and "Linear" settings when it received ANAN address ID: "Hermes" (through RedPitaya) by Auto Detect Protocl?

Radio Model Diversity Linear HERMES menu do not activated good feedback response to RX2 PS signal input at two-tone test signal ANAN-100D menu activated and phasing control works no feedback response (GetPk="0") to either RX1 or RX2 PS signal input at two-tone test signal

I am waiting the response soon.

Regards,

take

de JA5AEA

DD8JM commented 3 years ago

Hello,

i use the software Thetis in the last version 2.8.11 and the current firmware from Pavel for the 14bit and the 16bit Red Pitaya. On both 14bit / 16bit Red Pitaya devices Pure Signal works without any hardware changes compared to PowerSDR 3.4.9.

With Pure Signal there is a highly sporadic problem that under certain conditions (which I haven't been able to determine yet) does not work and the signal becomes very wide and a batten fence in the spectrum is created.

I did not have this problem under PowerSDR 3.4.9.

In the setup I have set Hermes under Radio Model.

We radio operators would be very happy about a firmware protocol 2 from Pavel for the Red Pitaya.

Best regards Joerg, DD8JM www.cq-nrw.de

ja5aea commented 3 years ago

Joerg,

Thank you for comments.

We, i.e. JA RedPitaya community share all your observation including " a highly sporadic problem" of Pure Signal and it is actually creating a dangerous situation to have daily operation with pure signal to other non pure signal operators in the band. I have not yet confirmed but the similar problem is reported by other SDR platform and they might use the same puresignal source codes for their SDR program.

By the way, have you faced the difficulty that "Diversity" menu would not work at "Hermes" model setting?

Regards,

take

de JA5AEA

ja5aea commented 3 years ago

Hi Pavel,

How is your progress of your testing to find the Thetis support about protocol 1?

To answer a suggestion, which I obtained from a Thetis development thread reader, to set Theis "Radio Model" selection from "Hermes" to "ANAN-100D", I checked the protocol 1 specification and puresignal usage information by Google search.

Here is my findings.

Protocol 1 Specification: from "page 5 of Metis - How it works"

Board ID: 0x01 = Hermes --> 0x04 =Angelia

PureSignal Usage: from "[hpsdr] Pure Signal on ADC? by Warren C. Pratt on November 26 2016"

Hermes-14bit: RX1

Hermes-16bit: RX3

Angelia: RX4 <-- modify RX3 to RX4

Orion: RX4

Do you agree above modifications are required and proper modification from RedPitaya perspective?

I am waiting your response soon.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

How is your progress of your testing to find the Thetis support about protocol 1?

As far as I'm concerned, I'm currently not planning to do anything with Thetis.

Do you agree above modifications are required and proper modification from RedPitaya perspective?

I don't understand what you are proposing to modify.

If you want to select a different radio model, you can do it in Thetis via Setup->H/W Select->Radio Model.

The implementation of Protocol 1 in this repository is known to work well with PowerSDR mRX PS. So if some features you need don't work with Thetis, the easiest solution is to use PowerSDR mRX PS.

pavel-demin commented 3 years ago

BTW. If you want to use ANAN*D models, sdr-transceiver-hpsdr should be replaced with sdr-transceiver-hpsdr-ananxd in start.sh.

ja5aea commented 3 years ago

Hi Pavel,

I did not know "-ananxd" is the abbreviation of "ANAN*D models" and it is the program, which I am looking for, to support Angelia protocol 1 operation. Thank you for your "BTW" information.

Now, where can I find the details of "-ananxd" actual settings for PowerSDR mRX PS, especially concerning "Diversity and PureSignal"?

I am waiting your response soon.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

There are no special settings. HERMES radio model in PowerSDR mRX PS works with sdr-transceiver-hpsdr. ANAN*D radio models work with sdr-transceiver-hpsdr-ananxd. The only difference between these two programs is the receivers used for Pure Signal data.

ja5aea commented 3 years ago

Pavel,

Thank you for your quick response.

Would you elaborate on Pure Signal proper setting of RX settings of "sdr-transceiver-hpsdr-ananxd 1 2 2 1 2" and "attenuated feedback signal from the amplifier", either IN1 or IN2?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

A description of the command line arguments is available at this link. When the third argument is 2, the feedback signal should be connected to IN2. If you want to connect the feedback signal to IN1, the third argument should be set to 1: sdr-transceiver-hpsdr-ananxd 1 2 1 1 2.

ja5aea commented 3 years ago

Pavel,

Thank you again for your quick response.

Then, the following is a practical setting to test Angelia functionality for current "sdr-transceiver-hpsdr "users?

Swap IN1 and IN2 cables.
change to "sdr-transceiver-hpsdr-ananxd 2 1 2 1 2" in start.sh

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

It would be very helpful if you could provide a very detailed description of the problem you are trying to solve. Currently, I don't understand why you have to switch to Angelia and swap the inputs. I think the default settings should be OK and nothing should be changed in the start.sh file. As far as I know, switching to Angelia is only useful for controlling an additional attenuator connected to the second input.

ja5aea commented 3 years ago

Pavel,

I think I made a mistake in the previous memo. It should be as follows to be able to realize my purpose. of my question.

Swap IN1 and IN2 cables.
change to "sdr-transceiver-hpsdr-ananxd 2 1 1 1 2" in start.sh

The reason I swapped the first and second arguments numbers are to make identical between Hermes and Angelia Redpitaya programs concerning the first and second antenna allocation to RX1 and RX2 caused by physical cable swap action stated in item 1.

This question is not so much important and may lead to further bush-around arguments. So, I stop. Then, I will go into see the real behavior of -anandx based on our conversation and will come back later.

Always, thank you very much.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Maybe the inputs are swapped in real Hermes and Angelia. However, in my code the connections are exactly the same. The only difference is the way the Pure Signal data are sent from Red Pitaya to PC (Hermes: RX3 and RX4, Angelia: RX4 and RX5). This is a purely internal detail and it doesn't affect any external connection. To conclude, I think there is no need to swap cables and receivers when switching from Hermes to Angelia.

ja5aea commented 3 years ago

Pavel,

Thank you very much for your further note.

Yes, "Puresignal" works under "Anan-100D" Radio Model setting if I use "-ananxd" program. Both methods described you and me provides identical behavior on the screen and your method is actually better for current RedPitaya users who wish to set Radio Model as "ANAN-100D" without any hardware modification.

Based on the information you provided, I now need to modify "-ananxd" to fit my particular peripheral setting such as CAT control function through USB port, S-ATT control through E2 SPI pins. Would you provide c source of "-ananxd" program for me?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

The source code is in the usual place: either on the SD card or in this repository. Depending on the board model, it is in one of the following files: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr_122_88/server/sdr-transceiver-hpsdr.c

When compiling this code using make, both executables are created from the same source code (transceiver-hpsdr-ananxd is compiled with an additional compilation parameter -DANANXD).

ja5aea commented 3 years ago

Pavel,

Thank you for your comments and they are satisfactory for me.

By the way, I noticed -ananxd program is replying as "Hermes", not "Angelia" board ID to discovery broadcast and creates transmission audio distortion.

I am wondering the reason why this distortion comes from, whether my peripheral environment or -ananxd program.

Any hints?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

I am wondering the reason why this distortion comes from, whether my peripheral environment or -ananxd program. Any hints?

I can only suggest to try PowerSDR mRX PS which is known to work well with SDR projects in this repository. As far as I know, this combination can work without distortion. If the distortion persists with PowerSDR mRX PS, then the problem is most likely with your setup.

ja5aea commented 3 years ago

Pavel,

I recompiled my customized c file adding -DANANXD parameter and successfully created -ananxd program. Now it supports Puresignal as well as Diversity under ANAN-100D model setting. It runs under both Thetis and mRX PS. I forgot the necessity of the audio clock frequency change from 12.8MHz to 12MHz for my audio injection board to eliminate the audio distortion. Problem is gone. It in fact came from my peripheral environment.

I changed the last integer from "1" to "3" of reply integer in c file and I confirmed Thetis indicates Board ID as "Angelia". But mRX PS says it is "3". I think "3" is the appropriate number under protocol 1, right?

I will play with this -ananxd program for a while and will report actual performance to you later.

Thank you for your advice. I made a big progress.

Regards,

take

de JA5AEA

ja5aea commented 3 years ago

Hi Pavel,

We found out the behavior difference of RX2 audio and display between mRXPs and Thetis when we use -ananxd program. Practical behavior problem is "RX2 DSP Group" would not work even "RX2" icon is selected (On the other hand, Diversity RX1 and RX2 selection works). I am guessing this is caused by the mapping philosopy difference of DDCn between two programs, i.e. Thetis expects ADC2 signals comes from DDC3 as well as DDC1 but -ananxd program ignores it as mRXPS did not not expect. I am thinking this may be a good tutorial for me to understand the signal handle between RedPitaya and SDR programs. I am especially interested in the function of void handler_eps(void arg).

I am happy if you provide your suggestion to explore the solution when you have time.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Please explain me why you have to use Angelia and not Hermes. I still don't understand it.

ja5aea commented 3 years ago

Pavel,

Do not ask me. I had not participated the design of Hermes and Angelia at all. I was learned the name of Hermes from you.

By the way, I recently found "Path_Illustrator" was defined in 2015 at HPSDR community and it is in Thetis "PI" tag. After reading the diagram, I guess they define Hermes as single ADC architecture and Angelia as dual ADC one and that may be the reason I received a suggestion that RedPitaya to be Angelia or ANAN-100D.

Above is my guess and I still wish to hear the reason why OpenHPSDR folk changed their mind by Thetis. design.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Thank you for the additional details. I've just re-read all of your comments and here is what I understand now:

you want to use Thetis and diversity (I still don't understand why Thetis and not PowerSDR mRX PS)
in Thetis, diversity is only supported for radio models with two ADCs
Hermes has one ADC, so diversity doesn't work with this model in Thetis
sdr-transceiver-hpsdr-ananxd works with radio models with two ADCs
sdr-transceiver-hpsdr-ananxd doesn't send DDC3 data

networkproto1.c in Thetis contains the following code that copies data from protocol 1 streams to protocol 2 streams:

switch (nddc)
{
  case 2:
    twist(spr, 0, 1, 1035);
    break;
  case 4:
    xrouter (0, 0, 1035, spr, prn->RxBuff[0]);
    twist (spr, 2, 3, 1036);
    xrouter (0, 0, 1037, spr, prn->RxBuff[1]);
    break;
  case 5:
    twist (spr, 0, 1, 1035);
    twist (spr, 3, 4, 1036);
    xrouter (0, 0, 1037, spr, prn->RxBuff[2]);
    break;
}

void twist (int nsamples, int stream0, int stream1, int port)
{
  int i, j;
  for (i = 0, j = 0; i < 2 * nsamples; i += 2, j += 4)
  {
    prn->RxReadBufp[j + 0] = prn->RxBuff[stream0][i + 0];
    prn->RxReadBufp[j + 1] = prn->RxBuff[stream0][i + 1];
    prn->RxReadBufp[j + 2] = prn->RxBuff[stream1][i + 0];
    prn->RxReadBufp[j + 3] = prn->RxBuff[stream1][i + 1];
  }
  xrouter(0, 0, port, 2 * nsamples, prn->RxReadBufp);
}

I think that nddc is 5 for Angelia and the twist function copies data from two protocol 1 streams to a single synchronous protocol 2 stream.

Here is a list of data streams in sdr-transceiver-hpsdr-ananxd:

DDC0 and DDC1 are used for diversity, RX1 and RX2
DDC2 isn't used
DDC3 and DDC4 are used for Pure Signal

I think that the code in networkproto1.c does the following:

copies DDC0 and DDC1 to 1035 (probably for diversity)
copies DDC3 and DDC4 to 1036 (probably for Pure Signal)
copies DDC2 to 1037 (probably RX2)

I think that to send the RX2 data to DDC2 the lines 1438-1447 in sdr-transceiver-hpsdr.c should be replaced with the following code:

#else
        if(size > 14)
        {
          memcpy(pointer + 12, data1 + data_offset, 6);
        }
        if(size > 20)
        {
          memcpy(pointer + 18, data2 + data_offset, 6);
        }
        if(size > 26)
        {
          memcpy(pointer + 24, data3 + data_offset, 6);
        }
#endif

ja5aea commented 3 years ago

Pavel,

A quick report based on your suggestion.

Yes, the replacement of lines 1438-1447 activated RX2 Display. But the display does not respond to the change of VFO B change.
Thus, I I copied case 6 and case 7 and created case 8 and case 7 in void process_ep2. By this addition, RX2 display responds to VFO B and "RX2 DSP Group" started to function.

Remaining issue is RX2 audio is distorted and modulated with low frequency hum. I suspect the functionality of Thetis AUDIO MIXER at this moment.

First of all, thank you very much for your scrutiny of my comments in this thread. Following is my further explanation to your question of "I still don't understand why Thetis and not PowerSDR mRX PS"

I understand mRXPS has terminated their development activity two years ago. Thus, we can not expect further improvement. of mRXPS. Recently Thetis changed their development objective i.e. promotion of protocol 2 by the addition of "protocol 1 support". They have already enriched GUI and functionality compare to mRXPS. Therefore, I expect you, who has the richest knowledge among RedPitaya community, will lead the work.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Thank you for this new tests.

Yes, the replacement of lines 1438-1447 activated RX2 Display. But the display does not respond to the change of VFO B change.

To me it feels like a dead end.

If Thetis requires five independent receivers to work with ANANxD models, it won't work well with the current version of my HPSDR protocol implementation for Red Pitaya 125-14. My current implementation has four receivers (RX1, RX2 and two receivers for Pure Signal) and the FPGA resource usage is close to 100%. Adding one more receiver isn't trivial.

Thus, I I copied case 6 and case 7 and created case 8 and case 7 in void process_ep2. By this addition, RX2 display responds to VFO B and "RX2 DSP Group" started to function.

I don't think changing the frequency of the same receiver from two different commands is a good solution.

As I've already mentioned several times, if somebody needs a working solution, I recommend to use PowerSDR mRX PS.

Now I can add that if anyone wants to use Thetis the best solution is to use it with a compatible device that supports the new protocol.

ja5aea commented 3 years ago

Hi Pavel,

Have you ever mentioned the above "dead end story" for us and OpenHPSDR community?

Then, my suggestion is to request "RedPitaya" radio model setting in OpenHPSDR SDRs supplying the information of RedPitaya "RX1, RX2 and two receivers for Pure Signal" and "dead end story" to OpenHPSDR community. I do not know the style of realization approach to implement this request either documentation or code supply but I believe they will convince it is necessary to Thetis by the fact mRXPS did provide the functionality for us in the pact. Peripherals are not always the slaves of the CPUs, right?

If you did the above action and if they refused, I really wish to hear the reason to reject.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Have you ever mentioned the above "dead end story" for us and OpenHPSDR community?

I've just learned about this problem yesterday from your test results. I don't know how to contact the OpenHPSDR community and I'm not sure if they're interested in this kind of information.

Then, my suggestion is to request "RedPitaya" radio model setting in OpenHPSDR SDRs supplying the information of RedPitaya "RX1, RX2 and two receivers for Pure Signal" and "dead end story" to OpenHPSDR community.

If Thetis could be adapted to the limitation of my protocol 1 implementation for Red Pitaya 125-14, then this could be a solution.

I think the most efficient would be to find out exactly what needs to be changed in Thetis and then send a patch to the Thetis developers asking them to integrate it into their code.

Yes, the replacement of lines 1438-1447 activated RX2 Display. But the display does not respond to the change of VFO B change.

I've just found the following bug reports on the apache-labs forum: https://apache-labs.com/community/viewtopic.php?f=9&t=3585 https://apache-labs.com/community/viewtopic.php?f=9&t=3588

Looks like Thetis 2.8.11 doesn't work correctly with the protocol 1 implementation for the real Angelia radios. I think once this bug is fixed in Thetis, it'll work with sdr-transceiver-hpsdr-ananxd.

ja5aea commented 3 years ago

Pavel,

I am glad to read your provided comment saying "If Thetis could be adapted to the limitation of my protocol 1 implementation for Red Pitaya 125-14, then this could be a solution.". I see the dominant players of SDR hardwares under OpenHPSDR are ANANs plus Hermes Lite and RedPitaya. If you "send a patch to the Thetis developers asking them to integrate it into their code", I am sure they will welcome home-brewed community contribution which indicates full featured alternative path, i.e. "Hermes Heavy".

For a while, I am happy to play with your "sdr-transceiver-hpsdr-ananxd" which provides Diversity and Puresignal function to the current Thetis program.

Thank you very much for entertaining with 29 comments for one thread.

Regards,

take

de JA5AEA

ja5aea commented 3 years ago

Hi Pavel,

I have been searching where the confusion was occurred about DDC mapping of pure signal, dual receiver, and diversity and the following is my guess at this moment.

First, "Release notes_v1.3 to v3.1.txt" contributed by VK6PH and K5SO of Hermes Protocol 1 firmware says; ------------------------------------------------------------------------------------------------------------------------------- 4 Jun 2014 - Fixed bug in iambic.v - Reduced receiver number to 4

Moved PureSignal feedback to receivers 3 & 4 on Tx
Using receiver2 module for Rx3 and Rx4****
Added C&C bit control of Rx attenuation to use when Tx is active, atten value for this case is contained in bits C3[4:0] when C0 = 0001_110x.
closed timing 10 Jun 2014 - Fixed bug with firmware CW keying
Added "PureSignal Enable" control using C&C bit C2[6] when C0=0001_010x; 0 = disabled, 1 = enabled This bit controls what input is used for Rx4 during Tx; 0 = temp_ADC (duplex operations), 1 = DACD (PureSignal operations)
changed version number to v2.9 -------------------------------------------------------------------------------------------------------------------------------**

So, it is clear that Hermes Protocol 1 changed and fixed Puresignal to RX3 and RX4 connected to receiver 2 module with four DDCs in 2014. Thus, RedPitaya14-125 has been meeting OpenHPSDR defined Hermes configuration. Therefore, networkprotocol1.c of Thetis must be modified so as to OpenHPSDR mRXPS.

Next, W2O pointed out this issue when "Path_Illustrator" was proposed in 2015 at HPSDR community saying:

Comment: DDC2 is shown as connected to ADC0 and RX1 display. Same for DDC3 and RX2 display. If that's how it really works that is great to learn that! I thought DDC0 fed RX1 display and DDC1 fed RX2 display?

But comment was denied by K5SO saying "Your thought was incorrect." and "Path_Illustrator" was established.

Finally, at the same timeframe i.e. year 2015, OpenHPSDR Ethernet Protocol i.e. Protocol 2 says in page 9

Note1 The protocol provides for any ADC to be used for Puresignal RF and DAC feedback. However, due to FPGA size limitations and timing requirements, for all current implementations RF feedback will be via DDC0 and DAC feedback via DDC1.

Above statement is wrong if they properly read 4 June 2014 statement of Hermes Protocol 1 firmware and must be corrected. Apparently, 2014 change of Hermes did not properly transferred to 2015 protocol 2 and Path_Illustrator. This is the creation of confusion in 2021.

At least, you do not have any responsibility.

If you have any comments, please let's me know.

Regards,

take

de JA5AEA

ja5aea commented 3 years ago

Hi Pavel,

This is not my intention to discuss about the protocol 2 implementation here but DD8JM stated in his December 20 saying "We radio operators would be very happy about a firmware protocol 2 from Pavel for the Red Pitaya.". A few days ago, I found the interesting discussion at hermes-lite@googlegroups.com titled "HL2 on protocol2?". Particularly, Steve stated "Like Sid and Alan said, HL2 does not support protocol2. Protocol2 makes demands on the FPGA that just don’t work well with the smaller less expensive FPGA used in the HL2" on January 24. I wish to hear your technical analysis of RedPitaya14-125 compare to HL2?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Particularly, Steve stated "Like Sid and Alan said, HL2 does not support protocol2. Protocol2 makes demands on the FPGA that just don’t work well with the smaller less expensive FPGA used in the HL2" on January 24. I wish to hear your technical analysis of RedPitaya14-125 compare to HL2?

The new protocol is developed with the Angelia and Orion platforms in mind. Angelia and Orion have large FPGAs (EP4CE115, EP4CGX150) with 3-5 times more FPGA resources than available on Red Pitaya 125-14 (XC7Z010).

So, Red Pitaya 125-14 doesn't have enough resources to support all the functionality (more receivers, higher sample rates) of the new protocol.

Hermes-Lite 2 has an even smaller FPGA (EP4CE22) and some of the FPGA resources are used to implement a network stack.

ja5aea commented 3 years ago

Pavel,

Good morning.

As I coined as "Hermes Heavy", we need additional FPGA cells than HL2 such as conversion clocks from 125MHz to 122.88MHz, process, dual ADC processing, 48kbps audio support e.t.c. . Considering these constraints, I agree with him to avoid the path to protocol 2. Steve is clever enough to spin the topic to the extension of protocol1 in his memo saying:

For visualization, it is often not necessary to send 1.5MHz real baseband to visualize 1.5MHz of spectrum. If you want to visualize 1.5MHz of spectrum on a typical monitor with 1920 pixels width and refresh rate of 30 or 60 Hz, then you could cut down the amount of data to only what is required to provide a reasonable visualization to the eye (1920 FFT bins, updated 30 times a second). We have the bandscope data on the HL2 to visualize the entire HF spectrum, but I would be interested in enhancing that to enable better visualization of portions of the band. I'd like to be able to pick and zoom into about 1 MHz of any portion of the bandscope data and still see a good representation of HF activity. My understanding is that the receive-only Kiwi SDR supports this.

It may be possible to extend protocol 1 and add wider bandwidths, but I'm not sure what the application would be except for visualization. SparkSDR can create many slice receivers for skimming, but even a 192kHz bandwidth is enough to capture all CW,FT8,WSP,JT9,PSK signals on a band. Maybe transverter users will have applications for wider bandwidth. But below 30MHz, all the modulated signals I know of are under 12kHz wide.

Ok, now we need to complete the several tasks fixing our own issues before jumping on Steve's revelation. If you need JA resources for this task, please let's me know.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Ok, now we need to complete the several tasks fixing our own issues before jumping on Steve's revelation. If you need JA resources for this task, please let's me know.

I'm not sure if I understand the tasks and issues you have in mind that require action on my part.

The point I'm trying to make from the start of this issue is that in my understanding my implementation of the HPSDR protocol is working correctly. All the issues you see are due to bugs in the implementation of protocol 1 in Thetis.

ja5aea commented 3 years ago

Pavel,

Remember you asked me "Please explain me why you have to use Angelia and not Hermes. I still don't understand it." 13 days ago. The message I sent 3 days ago, is my reply. In this reply, my conclusion is that it is not "bugs" and it is "wrong codes" by breaching Hermes definition and we need to convince them to correct their codes knowing that they made the breach. First, I need your comments. If your reply is positive, then, we need to plan to convince them. If your comments are negative, then we need to change our plan.

If I am allowed me to raise my question to you, would you show me the documentation of Hermes you referred when you designed your codes?

Is your documentation saying as follows?

Reduced receiver number to 4
Moved PureSignal feedback to receivers 3 & 4 on Tx
Using receiver2 module for Rx3 and Rx4**

I am waiting your response soon.

take

de JA5AEA

pavel-demin commented 3 years ago

I think there is a misunderstanding somewhere in our communication or maybe a misunderstanding of the current situation.

In the following I will try to summarize my understanding of the situation.

Requirements: you want to use Red Pitaya 125-14, Thetis, Pure Signal, Diversity, two independent receivers (RX1 and RX2) simultaneously.

Problem 1: Thetis does not support diversity for protocol 1 in HERMES mode. Problem 2: Thetis requires five receivers for protocol 1 in ANAN-100D mode and works differently compared to PowerSDR mRX PS.

Problem 2 was already reported on the apache-labs forum: https://apache-labs.com/community/viewtopic.php?f=9&t=3585 https://apache-labs.com/community/viewtopic.php?f=9&t=3588

PowerSDR mRX PS doesn't have these problems.

If PowerSDR mRX PS is the reference implementation of protocol 1, then these two problems in Thetis are bugs and would be great if they could be fixed.

Do you agree?

I don't see the point of going into any further technical details until we agree on an understanding of the situation.

ja5aea commented 3 years ago

Pavel,

Thank you for your quick reply and comments. Here is my answer and their comments.

Requirements: you want to use Red Pitaya 125-14, Thetis, Pure Signal, Diversity, two independent receivers (RX1 and RX2) simultaneously. : No, "two independent receivers (RX1 and RX2) when Diversity is disabled"
Problem 1: Thetis does not support diversity for protocol 1 in HERMES mode. : Yes.
Problem 2: Thetis requires five receivers for protocol 1 in ANAN-100D mode. : Yes, so I gave up ANAN-100D mode. It is a band-aid solution, not the solution.
Problem 2 was already reported on the apache-labs forum: https://apache-labs.com/community/viewtopic.php?f=9&t=3585 https://apache-labs.com/community/viewtopic.php?f=9&t=3588 : Sorry, I do not understand these two reports are related to our discussion. If you provided me further comments, I will read them once again. However, I understand these reports do not prevent our claim submission to Thetis developers. It is claimed in apache-labs forum, not Thetis developer thread . Correct?
PowerSDR mRX PS doesn't have these problems.: Yes.
If PowerSDR mRX PS is the reference implementation of protocol 1, then these two problems in Thetis are bugs and would be great if they could be fixed.: No. I could not find the clause saying "PowerSDR mRX PS is the reference implementation of protocol 1" in Thetis document. Show me the evidence of your claim.

I am waiting your response soon.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

I'm surprised by some of your comments and questions. They confirm that there is indeed a misunderstanding. So let's try to clarify it.

Sorry, I do not understand these two reports are related to our discussion.

In both these reports it's clearly written that RX2 doesn't work with the real Angelia board (100D) with the real protocol 1 firmware.

It's exactly the same problem that you described in this comment.

It is claimed in apache-labs forum, not Thetis developer thread. Correct?

I don't know what is "Thetis developer thread".

I could not find the clause saying "PowerSDR mRX PS is the reference implementation of protocol 1" in Thetis document. Show me the evidence of your claim.

I'm not claiming anything. I wrote "If PowerSDR mRX PS is the reference implementation of protocol 1, ...".

In my understanding PowerSDR mRX PS is the only program that implements all the features of protocol 1. PowerSDR mRX PS as well as the Hermes and Angelia firmware were developed at the same time that protocol 1 was documented.

I think that if there is only one complete implementation of the protocol developed by the authors of the protocol, then this makes it the reference implementation.

pavel-demin commented 3 years ago

I did some optimizations and managed to add the fifth receiver. This new version can be downloaded from this link.

So far I have only tested Pure Signal and RX2 with Thetis 2.8.11 in ANAN-200D mode.

I changed some code in the CW tone generator for the audio codec but I didn't test this part. So it's possible that it's broken in this version.

ja5aea commented 3 years ago

Pavel,

Here is my quick report on your new bit and c file which you claim five DDCs included.

I compiled the attached c file with -DANANXD and ran them with both mRXPS and Thetis.
Dual display works and decoded sound of RX2 is fine.
Diversity simultaneously works along with dual display. I will further check the detail behaviors,
CW operation works under mRX PS with proper monitor sound but needs the comments from CW experts about the transmitted wave.
I will check the rest of the function after I modify c file for my environment.

A quick question, what it the purpose of additional argument, related to the fifth DDC?

I will report you with after additional trials.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

Thank you for the tests.

I just tested the CW tone generator for the audio codec and it works. The amplitude and frequency of the sidetone signal are the same as in the previous version. So it looks like my optimizations haven't broken it.

I also changed a parameter in the part of the FPGA configuration used to output the envelope signal. So it's also to be tested.

A quick question, what it the purpose of additional argument, related to the fifth DDC?

The additional argument is required to select the RF input for the new additional receiver.

The new version of the sdr-transceiver-hpsdr program expects six command line arguments:

sdr-transceiver-hpsdr 1 2 2 2 1 2

The first four arguments are for the receivers (RX1, RX2, RX3, RX4), where 1 corresponds to IN1 and 2 corresponds to IN2.

The last two arguments are for the outputs (OUT1, OUT2), where 1 corresponds to the TX signal and 2 corresponds to the envelope signal.

In Thetis (ANAN*D modes), RX1 is shown as RX1, RX2 is used for diversity, RX3 is shown as RX2, RX4 is used for Pure Signal.

Maybe the first four arguments could be removed and the ADC assignments in Setup->General->ADC could be used instead.

pavel-demin commented 3 years ago

All the changes in this new version can be found in this commit.

ja5aea commented 3 years ago

Pavel,

Yes, I agree with your comment, i.e. "Maybe the first four arguments could be removed and the ADC assignments in Setup->General->ADC could be used instead." noting RedPitaya can support up to 5 DDCs.

The following is not technical topic but I do not like to use ANAN nomenclature, i.e. "ananxd" by the reason it indicates commercial "Product" name of Apache Labs. I am comfortable to use Angelia or Orion following your tradition if we will not take the bold approach, which I once mentioned , to recognize "RedPitaya" to OpenHPSDR society like HL group did. What do your thought?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

I do not like to use ANAN nomenclature, i.e. "ananxd" by the reason it indicates commercial "Product" name of Apache Labs. I am comfortable to use Angelia or Orion

I don't agree. The ANAN radio models are what is written in the radio model lists in Thetis and PowerSDR mRX. Using other names to reference these models will cause more confusion.

If you don't like sdr-transceiver-hpsdr-ananxd, don't worry. It's just a temporary name that will go away once I'm sure all features work in the new version.

to recognize "RedPitaya" to OpenHPSDR society like HL group did. What do your thought?

I don't understand this part because I can't see how Hermes-Lite is recognized more than Red Pitaya by OpenHPSDR.

I think the recognition level for both devices is the same:

they are both mentioned on OpenHPSDR website as derivative projects
neither is directly supported by Thetis or PowerSDR mRX

I have nothing against adding Red Pitaya to the radio model lists in Thetis and PowerSDR mRX PS. If you think it should be done, do it. Just don't ask me to do it for you.

ja5aea commented 3 years ago

Pavel,

Ok, keep in the record that I express my concerns to use "ananxd" at this moment. That is enough for me at this moment.

However, it is strange for me they mention Hermes-lite and Redpitaya as "derivative projects" but they do not assign Board ID for RedPitaya but they assign for Hermes-lite in Metis (page 5) and Protocol 2 (page 43). And "neither is directly supported by Thetis or PowerSDR mRX". What is the hell of the developers under OpenHPSDR doing?

Regards,

take

de JA5AEA

ja5aea commented 3 years ago

Pavel,

An additional information about the subject, Radio model defined by LinHPSDR written by G0ORX covers not only cover ANANs but also Hermes, Angelia, Orion and even SoapySDR.

I do not have any intention to ask you to talk OpenHPSDR for me. I thought it might be worth to discuss who we are.

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

I do not have any intention to ask you to talk OpenHPSDR for me.

I don't think that talking will be of much use. I think most open source developers mainly work on features that interest them. Asking them to work on something that only you want to be implemented is usually not the best strategy.

I think a more efficient approach would be:

find out exactly what needs to be changed in Thetis
implement these changes
test the result
send a patch to the Thetis developers asking them to integrate it into their code

To give an example of such an approach, here is a version of PowerSDR mRX PS being adapted for Hermes Lite: https://github.com/mi0bot/OpenHPSDR-PowerSDR https://groups.google.com/g/hermes-lite/c/dGGOPgxM0is/m/Q1i6MkrbAAAJ

Just to make my point even clearer if it wasn't clear in my previous comments. If you want something to be implemented in PowerSDR mRX PS or Thetis, it's up to you to do it. Not me, not some abstract community.

ja5aea commented 3 years ago

Pavel,

A question for you.

By today, who made such task for us

i.e.

find out exactly what needs to be changed in Thetis
implement these changes
test the result -send a patch to the Thetis developers asking them to integrate it into their code

I think your answer is none.

That indicates RedPitaya does not require to changes in Thetis as long as their interface specification is clear enough for us. As you did, it is upgradable from Hermes to Angelia board by .bit and .c file changes. Could other OpenHPSDR community achieved such magic?

Regards,

take

de JA5AEA

pavel-demin commented 3 years ago

A question for you.

I'm not sure if I understand what is the question. I'll try to answer those that look like questions.

I think your answer is none.

If this is the question, then my answer is "I don't know".

It was your idea to add Red Pitaya to Thetis. I see that it's being done for PowerSDR mRX PS and Hermes Lite 2. So I think it's a good idea.

That indicates RedPitaya does not require to changes in Thetis as long as their interface specification is clear enough for us.

I don't know. For example, if in the next version of Thetis, it will communicate differently with the Angelia radios via protocol 1, the solution with five receivers can become broken again.

Could other OpenHPSDR community achieved such magic?

I don't know.

It looks like I can't really answer any of the questions.

ja5aea commented 3 years ago

Pavel,

Good. We are at almost near agreement.

I share the nightmare as you stated "if in the next version of Thetis, it will communicate differently with the Angelia radios via protocol 1, the solution with five receivers can become broken again.".

We have the practice to ask them to write down the official document of "the minimum requirements of Angelia radio via protocol1" which guarantees the interoperability. Of course, they have the freedom to add any fancy features out side of "the minimum requirements" in the next Thetis calling them as "optional". If they can not provide the fancy features without changing the minimum requirements, they call such minimum requirements as next generation or "Orion". This is the common practice among world-wide standard bodies, the decision will be simple whether they will follow or not.

If you ask me to do that job, yes, I can do.

Regards,

take

de JA5AEA

pavel-demin / red-pitaya-notes

How to cook Thetis #988