How to access clk_sel on the 4ch RP in C to select an external CLK

[fbalakirev]

We have the Heatsink interface - https://redpitaya.com/product/heatsink-interface/
You can attach it to a bigger metal enclosure to keep the whole board cool. You can also cool it with a fan. The aluminium case can also be attached to an external cooling heatsink to further reduce the heat, but it might be a bit more tricky as it does not have predrilled holes.

Thank you for the suggestions. We got 30x30x6mm 5V DC fans and they seems to fit under the shield with a few mm to spare for the air flow.

We tried to check the shield schematics, but the schematics link in the https://redpitaya.readthedocs.io/en/lat ... hield.html ends in 404 error. Is there a functioning link?

Our schematic-related questions: what logic pins are connected to shield trig in and trig out? Is it DIO0_P (G17) and DIO0_N (G18) respectively? Is there any way to transmit clock from on-board RP oscillator to clock outputs of the shield?

We would like to continue using both software and hardware trigger options. If the above trigger pin assignment is correct, what shield jumper combination would let us set up a following trigger propagation:

primary trig-in -> primary DIO0_P in-> primary PL -> primary DIO0_N out -> primary trig out -> secondary trig in -> secondary DIO0_P in ?

What is the connector type for the clock and the trigger on the click shield?
P.S. never mind, I guess it is U.FL

[redpitaya]

Thank you for letting me know about the links, they are correct, but apparently, we failed to upload the relevant documentation. The links should be up and running sometime next week (the developers are on holiday). If you need the relevant documentation, please write to support@redpitaya.com and I will share the materials.

- That is correct. TRIG_IN is connected to DIO0_P (EXT_TRIG) pin and the TRIG_OUT is connected to the DIO0_N.
- The onboard clock cannot be shared between the boards, but you can either use the oscillator on the click shield or provide an external clock - both are then shared across all Click Shields in the line.
- The trigger transmission is meant to work as one of the following options:
- primary device receives trigger condition => outputs it to DIO0_N => primary TRIG_OUT ==> all secondary devices receive it on TRIG_IN (DIO0_P).
- external trigger condition => triggers all devices (primary + secondaries) that receive it on TRIG_IN (DIO0_P).

The intended pin configurations are described in the docs under the examples: https://redpitaya.readthedocs.io/en/lat ... les-of-use
If you just want to sync the triggers then ignore the clocking part and use the trigger jumper positions as a reference.

Yes, the connectors are U.FL.

[fbalakirev]

Thank you for the clarification.

I guess we'll wait for the schematics' uploads to figure out the best course of action.

What voltage levels does the shield's trig in input expect?

[redpitaya]

The voltage levels should be 3V3 logic as the trigger IN/OUT pins are directly routed to Red Pitaya's GPIOs.

[redpitaya]

I sent the schematics and 3D models via email. Otherwise, the developers will upload them once they are back (the link will start working then).

[fbalakirev]

Thank you for sending the schematics, it was quite useful for us.

We trying to to work out if there's a way with the current shield schematics to condition the external asynchronous trigger source in the PL of the primary board and then issue a synchronous trigger to all boards. Otherwise, with the recommended connection schematics, it's possible that when the external trigger arrives during clock transition, different boards can trigger on different clock cycles of the shared clock.

[redpitaya]

Yes, good thinking. It is definitely possible to include this, but it will require some code modifications.

In such a case, I would recommend applying the external trigger to the jumper 6 pin that is closer to the mikroBUS 2 connector (this will apply the external trigger to the DIO0_P pin of the primary board) or to another digital pin (either on the Logic Analyzer connector or through on of the microBUS connectors). Then filter that signal internally (modify the functionality of the C API functions to check the pin and then trigger the trigger condition). The downside is you will have to us pin connectors and not U.FL ...

I will report this to the team, so that we can apply this modification for the next hardware revision of the Click Shields.

The other option is to make sure the external trigger is synchronized with the external clock .

[fbalakirev]

In such a case, I would recommend applying the external trigger to the jumper 6 pin that is closer to the mikroBUS 2 connector (this will apply the external trigger to the DIO0_P pin of the primary board)

Thank you for the suggestion. I tried it and it addressed the trigger synchronization issue for us from the looks of it. It also lets us keep the software trigger option.

The other option is to make sure the external trigger is synchronized with the external clock .

...but the PL of the Red Pitaya is the most obvious place to make it happen

[redpitaya]

Well yes of course. The simplest would be to modify the FPGA image in case you want to synchronise this (perhaps use one of the additional digital GPIOs for this filtering) .

Just a question. What is the reasoning behind the possibility of the external trigger arriving on different boards on different clock edges? Theoretically, given that the cable lengths between the boards are almost the same, the asynchronous trigger should not be capable of arriving at different boards at different clock edges. The clock signal also has to travel down the transmission line, so the phase between the clock and the trigger should be the same on all the boards. Alternatively, you can always control/correct the phase delay on boards inside the software by moving the signal a sample up or down.