pavel-demin / red-pitaya-notes

Notes on the Red Pitaya Open Source Instrument
http://pavel-demin.github.io/red-pitaya-notes/
MIT License
337 stars 209 forks source link

Broken input on Red Pitaya board - PPS not useable anymore #1081

Closed waterwin closed 1 year ago

waterwin commented 1 year ago

GPS PPS signal (DIO3_N) appears to be broken. Can I change something in the code so I can use another GPIO pin instead ? On my original STEMlab 125-14 the PPS input is reported as having no signal (Not enough PPS pulses), when I check the hardware on that pin the voltage is not ok as well so I assume that pin is broken maybe by me using 5V PPS signal instead of 3.3V when not having the level convertor in the lines.

I have tried to find that PIN in the code myself but get lost in hex memory locations in measure-corr.c ::

sts = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x40040000);

Is that indeed the signal and memory location I should change ? Or is this only for the general housekeeping and setting the pins for input

Or do I only change a port in ports.xdc

Expansion connector

like swapping these 2 lines/designations

set_property PACKAGE_PIN K17 [get_ports {exp_p_tri_io[3]}] set_property PACKAGE_PIN K18 [get_ports {exp_n_tri_io[3]}]

Which should then result in the PPS signal being read from DIO3_P instead of DIO3_N

Thanks Erwin

pavel-demin commented 1 year ago

I think that swapping the pins in ports.xdc is the easiest solution.

waterwin commented 1 year ago

Thank you Pavel for a very fast and helpful answer. I will do as you advise.

waterwin commented 1 year ago

I finally thought I understood the toolchain etc well enough to bite the bullet. I swapped the K18/K17, re-ran MAKE, first for the FT8 transceiver. Checked it on the hardware. Not enough pps pulses. Oh. dear. After some more deliberating I realized that I now need to use the other E1 pin and not the old one. Switched from n to p pin, works! Did a new MAKE for the wspr transceiver project. Works. Seeing pps based frequency correction being used. STEMlab 125-14 is again on same frequency as my SDRlab 122.88-16. Thank you Pavel for brilliant software, good documentation and support.  For you this will be all so simple of course, for me my baby steps are gigantic. To be continued with a little more confidence. ErwinPE3ES / F4VTQ