Mixer to op-amp connections are different

[kholia]

The connections in https://dl2man.de/wp-content/uploads/2023/07/truSDX_Main_1_2-1.pdf look like:

Note that pin 11 of 3253 goes to the non-inverting terminal of the op-amp.

In this repository, pin 11 goes to the inverting terminal of the op-amp (which is different and opposite).

Does this matter? If yes, which way should the pin 11 (and pin 12) connections go?

Thanks for the help!

[dawsonjon]

Hi,

Yes, that's a good spot.... There isn't one right way to do it, but you need to be consistent in the way you drive s0/s1 and what the software is expecting.

On the Pico Rx this is the convention I adopt. I assume that the I channel is on the X axis, and the Q channel is on the Y axis, and that a "positive" frequency is a clockwise rotation around the origin:

I drive the S0/1 inputs in the order 0, 1, 3, 2 so (using my convention) the connections in the picorx result in clockwise rotation for positive frequencies, whereas the connections on the truSDX would give anti-clockwise rotations for positive frequencies. I expect the truSDX is either driving S0/1 in a different order, or the software is expecting the opposite rotation.

S              0    1    3    2    0    1    3    2
Pin           10   11   13   12   10   11   13   12

pico          -q   -I   +q   +I   -q   -I   +q   +I    = clockwise
truSDX        -q   +I   +q   -I   -q   +I   +q   -I    = anti-clockwise

If you end up with the opposite rotation, this can usually be corrected in software by swapping the I and Q channel.

[kholia]

Thank you!

From https://files.tapr.org/meetings/DCC_2020/2020DCC_KL7NA.pdf,

In my flavor of your PicoRX design, I am planning to use the quadrature clocks from Si5351, where the counting order seems to be 0, 1, 2, 3. The truSDX design uses quadrature clocks from Si5351 too. I am planning to use the quadrature clocks from Si5351 in hope of better RX performance.

truSDX schematic:

The truSDX is also closely related to https://github.com/threeme3/usdx/blob/master/usdx.png.

Mapping table:

S              0    1    2    3    0    1    2    3
Pin           10   11   12   13   10   11   12   13

truSDX        -q   +I   -I   +q   -q   +I   -I   +q

Is this a valid ordering / configuration (it is not a "gray code" anymore though)? Thanks.

[dawsonjon]

Hi, I have taken a closer look and added some comments in-line. Your project sounds very interesting, best of luck :-) Thanks Jon

From https://files.tapr.org/meetings/DCC_2020/2020DCC_KL7NA.pdf, This is a very interesting article, I will have to take a closer look.

I'm a little bit confused by this table, reading the article it sounds like the "counting" method is a work around to allow the Si5351 to work at low frequencies and switches in the order 0, 1, 2, 3. I think the "quadrature" method is the more usual method (employed by uSDX), where the device generates 2 clocks 90 degrees out of phase (i.e. in quadrature). The last line in the table says that the order is also 0, 1, 2, 3 but this seems to contradict the text and I think it might be a mistake.

In my flavor of your PicoRX design, I am planning to use the quadrature clocks from Si5351, where the counting order seems to be 0, 1, 2, 3. The truSDX design uses quadrature clocks from Si5351 too. I am planning to use the quadrature clocks from Si5351 in hope of better RX performance.

Great, I think that the Si5351 should improve the Rx performance. The Si5351 allows much more precise programming of the frequency so it should be possible to reduce the bandwidth of the Tayloe detector. This means that the oversampling ratio will be higher and this should improve the rejection of alias signals.

truSDX schematic:

The truSDX is also closely related to https://github.com/threeme3/usdx/blob/master/usdx.png.

Mapping table:

S              0    1    2    3    0    1    2    3
Pin           10   11   12   13   10   11   12   13

truSDX        -q   +I   -I   +q   -q   +I   -I   +q

Is this a valid ordering / configuration (it is not a "gray code" anymore though)?

I don't think this is a valid sequence, each step should rotate 90 degrees in the same direction. Moving from +I to -I or +Q to -Q is a 180 degree rotation. This suggests to me that the switching order in the truSDX isn't 0, 1, 2, 3. It would need to be either 0, 1, 3, 2 or 0, 2, 3, 1 to give a valid sequence.

Copying the truSDX is a safe option, it uses the Si5351 and we know it works. Worst case it will rotate in the opposite direction, but this can easily be fixed in software by swapping I and Q. This latest test build of software allows I and Q to be swapped through the menu, so should be easy to try it both ways.

[kholia]

I agree with you. With Si5351, the switching order has to be 0, 1, 3 ,2 too! There must be an error in that article.

Here is my understanding based on a picture borrowed from https://awsh.org/si5351-quadrature/ link:

Initially, both 'waves' are off. This gives us 00. Next, one signal ('wave') rises up. This gives us 01. Next, both waves are up, this gives us 11. Finally, the initial waves goes down and this gives us 10. Next, we get 00 again and so on. So the clocking sequences is naturally 0, 1, 3, 2.

...

The design is public @ https://github.com/kholia/PicoRX/tree/master/PCB/Easy-uSDX-v3.

Note: I have provided jumpers to switch the 11 and 12 connections as needed. I can copy the truSDX design as well but perhaps going ahead with these four jumpers for the first version is a more easier decision.

The board size is 45mm by 45mm.

...

In my experiments, having a large bandwidth (open) creates problem as I live next to a 100 KW AM station (792 kHz), and there is also a powerful radar system operating very next to the 10m band. Hence, my desire to operate with a narrow bandwidth.

Thanks for all the help!

[dawsonjon]

Sounds like a good way forward. That PCB looks really neat, would be interested to see how it turns out. Cheers, Jon