Questions about TRX-DUO

[Roturbo]

Hello,

first let me tank you for this great work.

I´m planing to buy a TRX-Duo to work mainly with Thetis and add some hardware like filters, PA etc, i already have one Anan 100D, the TRX will be a second transceiver.

After read many pages i ended here, but the more i read the more i get confused with the best firmware etc to use.

I know that the TRX-DUO is a cheap option (clone) of the Red Pitaya,

https://github.com/pavel-demin/red-pitaya-notes/issues/1088

Here i found that the TRX is a 16bit but is using 125mhz instead of 122.88, and the FPGA is the XC7Z010 instead of the XC7Z020, there is something that can be change in code but coding is not easy for me.

Also read the next link. https://github.com/pavel-demin/red-pitaya-notes/issues/1091

That makes me think if i replace the xtal (this i´m able to do) but than it need to change the code and make a build that i´m not able to do.

Now the questions.

What files (firmware etc) i need to use to make the TRX-DUO working with Thetis the more compatible as possible ? (choosing Hermes if i´m not wrong)

Diversity and Pure Signal is very important for me.

Is there any advantage changing to 122.88 Mhz xtal, for example more bandwidth or more options with different firmware ?

The use of the codec board is only to reduce the high delay if using VAC ?

What other images firmware are compatible with this TRX-DUO ?

https://github.com/pavel-demin/red-pitaya-notes/issues/1088

Maybe making some changes like you advise on that link ? .

. Sorry but i´m learning about it, and don´t get me wrong if i make none sense questions or if they were already answered and i didn´t see it.

Regards

[pavel-demin]

I am afraid that I cannot answer questions related to the TRX-DUO. I have never tested my applications with TRX-DUO and I do not know for sure what works and what does not.

Personally, I would not recommend buying TRX-DUO because it was already reported to be quite unreliable and made of refurbished parts of questionable quality.

If you want a 16-bit ADC, the 122.88 MHz clock and the XC7Z020 chip, then this is exactly the Red Pitaya SDRlab 122-16 board.

[Roturbo]

Hello Pavel,

I have made some search before but didn´t find much information about the quality of TRX-DUO, one friend did mention that on AlliExpress they were removing the bad reports and complains about this boards, and after reading your post i did a search on Ebay and under a private sell by the context i did notice the bad report on this board.

https://www.ebay.com/fdbk/feedback_profile/flyxy2015?filter=feedback_page%3ARECEIVED_AS_SELLER

DO NOT buy this. Get the Red Pitaya. I own both and this thing is junk. No problem with seller. (Private listing)

The buyer is comparing the TRX-DUO with the Red Pitays

Many tanks for your replay, i will take your recommendation and maybe later i will chose the Red Pitaya 122.16, also i hope others read this post and think twice before risking losing money.

And tanks also for your work, i hope one day i can use your files.

[dc7ds]

I bought a TRX-duo and placed it at DL0PF as low band skimmer with cwskimmer and cwsl_digi….up to now, it works as expected. Check http://wireless-access.de/ft8-skimmer/wspr-fd4-all.html for WSPR stats.  Let’s see how long that thing lives73 Stefan DC7DS

[pavel-demin]

Here is a link to the discussion that mentions the recycled ADC and FPGA chips used on TRX-DUO:

https://groups.io/g/NextGenSDRs/topic/trx_duo_new_radio/94134740

[enthru]

Hello!

If you need I can upload binary files for the 16bit 125MHz and 16bit 122.88MHz to somewhere.

It's not necessary to do something with clock and code at all. I just was interested how it works for xilinx and have unused 122.88 clock generator from another project.

About quality. I have had 2 trx-duos, first was okay and in good condition but died from my experiments. Second was bad and has been booting from second/third attempts and died near rd100 amp while I was tuning it (I think not fpga but voltage regulators, but I've decided to not waste time to figure out the issue). So looks like I'm eating cactus because I've just bought the third :D Anyway I can't say that all those devices are bad - it's just a lottery :)

What is not good for sure is that some things are not compatible on the hardware layer with the original red pitaya (disabled analog inputs, existent but not used pads etc). On the other side Pavels software is working great (except hardware limitations).

Taking this opportunity to say thanks to Pavel for the work :)

P.S. Analog inputs can be replaced with external I2C ADC with some small editing code of HPSDR server (sdr-transceiver-hpsdr.c), it also gives opportunity not to limit maximum input voltage to ADC in 3.3 volts.

[n6gn]

I have just recently purchased two TRX-duo's, I don't (yet) have a Red Pitaya of any version. My interest in these SDRs is especially for ionospheric study and in particular very narrow digital modes like WSPR and FST4W which needs very high spectral purity. For this I require quality external clocking.
I have successfully modified the TRX for external clock input and considering alternatives for a PCB design to make modification easier. Part of the decision of architecture, whether straight external clock input or injection lock of an on-board VCXO is driven by the problem of network failure when ADC clocking is lost. SInce I have no complete schematic I am now wondering if there is any kind of code work-around possible to avoid loss of networking. It is possible that the network circuits somehow re-use or otherwise rely on the presence of the ADC/DAC clock that I am improving. Can anyone tell me if loss of ADC clock failure is inherent in the HW designs of either TRX or Red Pitaya. If it is, I am probably going to have to lean toward an injection locking scheme which will cost slightly more due to the addition of a balanced mixer but will also provide a kind of 'automatic switching' between a normal mode and an externally disciplined one. Neither solution is without the requirement of user involvement at the HW level but if the networking loss problem can be removed in SW design it is possible that adequate external lock might be possible with a simpler design change though one still requiring the user to solder SMD components. Any insight into this welcomed. Glenn n6gn

[pavel-demin]

It is possible that the network circuits somehow re-use or otherwise rely on the presence of the ADC/DAC clock that I am improving.

I do not understand from your comment how you arrived at this conclusion.

As far as I know, the network interface is clocked by a separate 25 MHz oscillator. The CPU is also clocked by a separate 33.3 MHz oscillator.

Can anyone tell me if loss of ADC clock failure is inherent in the HW designs of either TRX or Red Pitaya.

If there is a problem with the continuity of the ADC clock signal, then the FPGA configuration resets every time the PLL inside the FPGA loses lock. This does not affect the network interface. Only the FPGA stops sending and receiving I/Q samples. If the reset occurs during an AXI transaction, the CPU will probably hang.

If the ADC clock signal stops completely while the SDR transceiver application is running, then the CPU will most probably hang when attempting to communicate with the FPGA.