If i’m correct it has to do with the LimeSdr mini’s design.
Also the LimeSDR USB doesn’t perform at its best at lower freq’s, even after HF Mod
For the LimeSDR USB there is some info couldn’t find it for the mini.
So not even up-converting with their own clocks (32.72 or 40.00 MHZ) brings us in optimal range.
On the LimeSDR usb you could use the second TX port to drive the mixer to a better range. The Mini on the other hand you only got one which would mean no more TX possibilities.
Hence me using the clock output, plus its synced to the lime. An other possible way would be to have to the fpga drive a clock on a gpio pin. That would require some fpga work above my knowledge, and takes up pins we would like to use for switching.
Still assuming most users only are comfortable with soldering the 0.1" EGPIO pins on the mini or the 4 user LED pins on the Limesdr USB, or even pogo-pins could be used without the need for soldering and warranty issues later.
Also seeing multiple user wanting to use GPIO pins for switching still needs a solution:
For the LimeSDR_USB there is the GPIO board (only 8 switches)
One could bit bang a shift register over the user LED on the MCU
Or Bitbang a shift register over the user LED on the FPGA
For the Mini haven’t found anything yet
There is the grove starterkit bundle, only that connects to a raspberry pi and not to the Mini
Both seem to have a I2C master in their fpga and i.e the temperature sensor can be read out from LimeSuiteGui. If something like I2C or RS232 etc could also be routed to the EGPIO / USER_LED pins, we still need drivers to access this from soapy, gr-limesuite etc. Last Software like SDRangel, GQRX etc need to support this as well.
So before pinging a lot of people i think should be involved let’s see what @andrewback thinks we should ask to help us.