I haven’t tried tx’ing with limesdr for a little while so I’m not sure if the problem I am thinking of with COR is still relevant but from past experience even while there is no tx stream present, there is still a carrier present. Has this been rectified in a recent release ? If not, then COR will be problematic.
1 Like
Hello,
this has been fixed then fix was removed and then back again I think. Looking at the present code I would say that the transmission should stop (destroy stream + disable channel on stop).
Best regards, Edouard.
2 Likes
@9a4db - Djani,
Agreed, but in CW/SSB mode I would add functionality to delay a relay switch using an R/C time constant that would delay (hold up) the relay from switching for up to 1 to 3 seconds (adjustable R/C). I also have in mind just using a straight PTT function from the mic to control the relay as another switching option and have a slight delay in the keying release to accommodate the sight delay all SDRs have getting their TX stream completed. So in total there would be three modes that could be selected: 1.) Straight stream switching (true COR), 2.) Delayed COR for CW/SSB and intermittent operation, and 3.) PTT with delayed release.
As well, I’ve decided that rather than do a SPDT relay to switch between the transmit and receive connections from the Lime that I’m going to keep those functions isolated by their own relay and path with only the antenna being the common connection between them. I didn’t want to have (too much of) the transmit path so close to the receive path even though the receive will be terminated into 50 Ohms during transmit. So that’s another design consideration I’m weighing, too.
I’m planning to put the design down in EagleCAD on Wednesday night with the intent that I would start putting the PCB over the following 2 days. I’d like to get this submitted to the board shop over the weekend such that sometime around the first of December I’ll have one in my hands to prototype.
Thanks for the feedback, Djani - 73 de Marty, KN0CK
1 Like
@F4EXB, Edouard,
I have been looking through the code to find hooks to use as control. Is your code for REST-ish interface in there somewhere?
A UDP command channel would work, too. Maybe just set a buffer and a flag that acts like the GUI function has been used that the program senses and does an update? The user sends a command that sets a flag, possibly with included data, which alerts the program to perform the same function that the GUI action would have performed. That seems redundant but I wanted to be clear.
Thanks,
Lance
Hello,
The way SDRangel is designed makes switching Rx/Tx in a PTT like manner a bit complex. Rx and Tx streams are essentially independent and you have to stop one and start the other. Rather than implementing a complex hook let alone to know which Tx to stop and which Rx to start or the opposite (you can have many) I’d rather leave it to a programmatic way available to the user something we can trivially call a macro.
In order to do this and to do it in the most possible generic way I’d like to have a REST kind of API (maybe not applying all of the RESTful manifesto) that can be called via Python or anything. In the Linux version I know Python interpreter could be embedded to start it from inside and provide more direct hooks to the REST API (skipping the JSON interpreter for example). In any case I would like it to be controllable from the outside and through the network thus ideally a web REST API.
The UDP thing sounds like a horrible hack to me and if it was to be put in place it will have to be removed as soon as a proper API is available.
For now I have done most of the preparatory work to separate the GUI from the core of the application thus being able to command the core and reflect it in the UI from the API engine. As another benefit it opens the possibility of having a headless version of SDRangel controlled via API only for server like applications (transponder, repeater… or just to be able to run on “small” devices).
I am just starting to think about the API and designing it in Swagger. The next version is probably going to include a swagger directory with all that stuff in it. I believe this has to be designed carefully so please be patient. I do not foresee an operational version before early next year.
Best regards, Edouard.
3 Likes
@F4EXB - Edouard,
For the purpose of the switching I’m proposing to do with the LimeSDR will reside entirely outside of the SDRAngel code and will sense RF from the transmit port (TX1 or TX2) to make the decision to switch. The PTT will also not be connected to the LimeSDR board digitally - it’ll just rely on the fact that transmit was initiated by the operator (mouse click of the transmit start on the SDR Angel GUI) and then using the station mic’s PTT keying line to actuate hardware externally from the LimeSDR to perform the antenna switching - for now. I realize that this may seem a little odd, but I know you’re busy with the code and that some of this functionality is evolving over time - I’m just making do with what’s there now so it can operate receive and transmit switching from either a carrier or mic-line PTT signal to switch the antenna and load the receiver with 50 Ohms. But I do agree that in the long run it’ll be a bigger benefit to have hardware switching from the LimeSDR that SDRAngel may apply by communications to the LimeSDR to make that happen. For now, I’m just sensing the TX1 or TX2 ports for signs of RF and then making the switch without any request from the API.
73 de Marty, KN0CK
I have been using wsjtx full duplex with tx and rx on different offsets, different antennas. I use a dipole for tx and long wire for rx. The tx is always on and only the presence of modulation changes. The ssb doesn’t cause too much interference since the program halts decoding while in tx and I am not running much power. I have an abundance of RF thingies around to make something, if I get the time, to do some switching. I am now starting to get more comfortable using the sdr than my regular rig for digital modes.
I understand the difficulty of getting a PTT type interface because of the plugin nature making so many complications. Edouard, this is your baby. You obviously have thought out the future some distance. I am patient enough. There are always too many other things I can focus my beam on.
1 Like
Just spent 1,5 h in play with all kind of settings in SSB TX mode doing CW test on 1296 in loop.
Receiving on the same SDRAngel and CubicSDR with RSP1 and Agilent SA.
Can not get pure signal without carrier and other sideband present.
Good news is that program hangs only once, when TX was on while doing some
setting on RX.
0,02$
On my side only trick with DBM, playing with levels can help to have decent pure
TX signal out to some PA and antenna.
@9a4db Djani,
I have seen something like you said so I was wanting to check this. I got home and hooked mine up to the SpecAn and found the carrier was well suppressed except when I send a 1KHz tone and then quit the tone, the carrier remained. Turning the mic on and off gets rid of the carrier. Turning off the tone seems to be equivalent to setting it to zero. I got some lockups but it was from other things all running at the same time, pavucontrol-qt especially. Never saw the other sideband, but if I turn the dB output too high there starts to be a lot of harmonics quickly. That’s the nature of A/D and D/A converters though. I hear this in music recordings all of the time. Sudden clipping from running out of numbers. The maximum signal I got cleanly by upping the gain was about .3mW, or about -5dBm. I could get it higher by driving the audio more on a lower gain setting, so it seems to be a dynamic range or conversion issue. I haven’t tried the AGC and compression features yet but they may come in handy here.
1 Like
Do you mind to share pic of your settings?
I travel away today. It will be a while, until after the 20th, until I am back to my setup.
Tnx. No rush at all 
AD5NL - Lime work bench update
3 Likes
Thanks for the video!
I just received a LimeSDR Mini from Lime Micro which is pretty cool 
I tried it right away with SDRangel and it is recognized as a LimeSDR and as expected it enumerates only one Rx and one Tx so things seem to be working as they should. The only thing to know is that the one and only Rx connector connects the the “wide” input and the one and only Tx connector connects to the “high” output. Then you should be able to use it as a LimeSDR with the known limitations.
Thanks again to the LimeSDR guys!
Best regards, Edouard.
5 Likes
LimeSDR Mini Rx RF port can be switched to either LNAW or LNAH, and Tx RF port can be switched to either BAND1 or BAND2. There’s just additional on board controls that need to be configured.
Hello,
is this done by software? What is the API call for this?
Best regards, Edouard.
Yes it’s done by software, currently it’s implemented in GUI by writing fpga register using LMS_WriteFPGAReg, so no dedicated API function. It controls which paths are connected to RF connectors and inverse of that are connected into loopback.
Hi,
If you are using LMS_SetAntenna() to select antenna port, then it should set RF switches automatically based on selected path.
Hello,
I do but this does not seem to be effective. Is this a very recent implementation? I’m on LimeSuite tag v17.10.0 (commit: 0f0dae1 5 weeks ago).
Best regards,
Edouard.
Yes, it is quite recent. It is not implemented in the version that you are using. LimeSutieGUI from your version also doesn’t have controls for switching RF ports.