Above fixes are now released in v3.7.6
2 Likes
@F4EXB - Edouard,
I am NOT kiddingā¦SDRAngel RULES!! Itās working on receive and transmit AMAZINGLY well. This latest update (3.7.6-1) running on my Win10 64-bit LattePanda is working like a REAL HF rig nowā¦Itās incredible. I JUST experimented with it on 40m and itās working PERFECTLY now. WOW!! THANK YOU for installing this latest fix, Edouardā¦!
For the record, Iām running the Sampling rate at 7 MS/s and the transmit Sampling rate at 3.5MS/s both Channels (Sink and Source) running 64/16 and the audio quality for both is perfectā¦No distortion in transmit at all. Just perfect.
More playing to doā¦Itās like Iām a kid on Christmas Day with this latest updateā¦ 
!!
73 de Marty, KN0CK
2 Likes
Hello Marty,
glad to read the very positive feedback! Maybe it depends on the O/S and/or hardware but this delay after stream stop and start did the hell of a difference for me (Linux Ubuntu 16.04). I still donāt know why I just suspect that the stop/start stream is not effectively on spot and you have to add a little delay to let it complete. Anyway now I can say that multiple streams are working with the Lime.
Best regards, Edouard.
2 Likes
@F4EXB - Edouard,
Thanks for the speedy reply back - - I have found in transmit that while thereās a VERY slight delay in the transmit stream, itās no worse than Iāve observed with my Flex 5000A on PowerSDR or my Red Pitaya on Pavelās software. Both of those also have a very slight delay in transmit (like .1s) and SDRAngel working with the LimeSDR exhibits the same characteristic - - So I would not change anything in that regard. Itās not that much of an annoyance and most SDRs do this anyway. SDRAngel is working SO WELL right nowā¦Itās amazingā¦!
73 de Marty, KN0CK
1 Like
Hi, just my 2 cents if itās still relevant
All LimeSuite functions are not thread safe, except for LMS_SendStream/LMS_RecvStream.
At every stream start/stop this logic get executed Stream threads start/stop
- All wanted streams have to be setup before starting any of them, to allow configuring hardware for expected number of channels and selecting data format satisfying all setups.
- Rx and Tx threads are separate and being created/destroyed depending if there are active streams on itās direction, so LMS_StartStream/LMS_StopStream acts just as a reference counter if the appropriate thread is needed.
First call of LMS_StartStream() creates, last call of LMS_StopStream() stops itās thread.
1 Like
LMS_StartStream is immediate on first call, it starts streaming of all channels on the same direction, additional calls just increase reference count.
LMS_StopStream is immediate on last call, it stops streaming of all channels on the same direction, previous calls just decrement reference count.
Had a brief look over the SDRAngel code, but not enough to have completely clear idea of the LimeSDROutput/Input life cycles, so this is entirely speculation. Best guess delay prevents thread interacting with internal FIFOs while another thread is creating/starting/stopping/destroying streams which affects the FIFO, that is not suppose to happen.
Impossible to tell without running the code, but this seems sketchy https://github.com/f4exb/sdrangel/blob/aab1a773bedcac0564078a17dafed8fc7c59c45f/plugins/samplesink/limesdroutput/limesdroutputthread.cpp#L77
m_startWaiter.wakeAll(); should be placed after LMS_StartStream, as it now unblocks early and allows other thread to pottentialy also call LMS_StartStream/LMS_StopStream resulting in race condition.
1 Like
Hello,
thanks for the detailed explanation and having a look at SDRangel code. It may be not too easy if it is the first time you peek in. Anyway your remarks are quite relevant. In fact to make sure LMS_StartStream is called before m_startWaiter.wakeAll() it could be simply placed early in the startWork() method. Similarly LMS_StopStream can be placed as the last instruction of stopWork()
I tried this configuration and it works well too. It has the advantage to be more satisfying intellectually of course but also it does not introduce an unnecessary delay.
Thank you and best regards, Edouard.
Edit: delivered in v3.7.8
1 Like
F4EXB
Love SdrAngel ā¦
Iv added a comment on git hub to FFY00 audio pulse issues and hope to have Sidās Boyce help soon ā¦ he has the same Hardware as I do.
Id love some trouble shooting tips ā¦
Working great on my W10 machine too.
Have clean installation of Ubuntu 16.10 ready to install & try both 
Hello Edouard,
I am pleased that the TX function for PlutoSDR is back in version 3.7.8.
But I still have a few problems in TX-Mode:
1: With PutoSDR I still have no audio signal in all modulation types (LimeSDR is ok).
2: When I try to change the sideband in SSB mode (by pushing DSB / SSB toggle-switch or moving the slider), the program crashes, with PlutoSDR as well with LimeSDR.
In RX mode no problems.
73,
Bernd
Hello Bernd,
yes there seems to be a problem with the new settings object put in place and how it works between the GUI and the mod. On my side I saw an infinite loop when touching the SSB/DSB button. For the audio signal I donāt know you have to tell me what is the sample rate, the FIR interpolation and the software interpolation. If these values are too extreme bad things can happen if the hardware canāt cope.
Note: opened issue https://github.com/f4exb/sdrangel/issues/87
Best regards, Edouard.
@F4EXB - Edouard,
Iām pleased to report this morning that the SDRAngel release V3.8.0.6 appears to play REAL well in transmit and receive with Sampling rates set at 5.0 MS/s on Source and Sink. More testing will happen later today, but this release appears to be the best thus far - nice clean transmit and excellent responsive receive and this is running off the Win10 64-bit LattePanda. Running wonderfully so far - more to report later.
73 de Marty, KN0CK
2 Likes
Iām loving the newest release of SDRAngel (3.8.1). I can use my partially damaged LimeSDR much easier now by selecting 2nd RX channel directly. One very happy user here. Great job Edouardā¦
2 Likes
I am currently having another problem with SDRAngel. This is not related to the latest release as it has been doing it for quite some time now. The problem I am having is that the LP filter setting seems to be very hit and miss when trying to set it to anything above approx 30MHz. I end up getting BUFFER OVERRUNS (I suspect that the streaming is not going). Sometimes it will work if I set it to 30MHz, then stop streaming, set it to 40MHz and start the stream again. I have to repeat this process if I want to go higher but it stops at about 55MHz and wonāt let me go any higher without the buffer overrun problem. ALSO, the filter seems to work differently sometimes if I stop and start the stream (ie apparent gain changes)
Has anybody else experienced this problem ?
I donāt want to create a ticket for Edouard if it is only my setup having the problem.
I see very similar symptoms. Changing hardware decimation seems to effect gain but if I stop-start the stream it goes back to where it was. Changing BW while FIR is on causes FIR to disappear, stream restart makes it come back. Just clicking the FIR off and on may work, I donāt remember. Total lockups and display of wide noise while stepping through the frequencies is less common now.
Itās hard to detail exactly what the process of creating these symptom would be. Sometimes they donāt happen.
Hello Brendan,
Change in LP triggers calibration and calibration uses the LP bandwidth value for the bandwidth value of the calibration. Maybe that last point is not correct but I donāt know what ābandwidthā really means for calibration. Maybe this should not exceed the full bandwidth hence capped by sample rate.
Anyway 30 MHz and above would mean 30 MS/s and above (I think LP bandwidth is double sided bandwidth here) and this is quite fast. Depending on hardware you may expect some instability.
I suppose youāre trying to work on HF and therefore need a LP of 30 MHz and above. You donāt need a host sample rate as fast as 30 MS/s however what matters is that the ADC or DAC sample rate is above 30 MS/s. Then you can use the hardware decimator/interpolator to achieve this at much smaller host rates. But then it makes it critical to know what the calibration bandwidth does because if it has to be capped by the host sample rate then it needs to be much smaller than the LP bandwidth. I might try to see what capping the calibration bandwidth really does as there is not much literature about this.
Best regards, Edouard.
Edit: things look much more complex than I thought when writing the code: https://wiki.myriadrf.org/LMS7002Mr3_Calibration_Using_MCU There are actually 2 APIs for calibration:
- LMS_Calibrate uses channel bandwidth for calibration routines 1 and 2 i.e. DC offset and LO leakage (Tx), phase, gain imbalances
- LMS_SetLPFBW uses LP BW and is for calibration routines 3 and 4 i.e. analog filter bandwidth
The code does LMS_Calibrate after LMS_SetLPFBW and uses LP bandwidth. This seems to be quite wrong moreover since LMS_SetLPFBW invokes calibration routines all streams should be suspended while it runs.
Issue: https://github.com/f4exb/sdrangel/issues/92 opened with these findings.
1 Like
Hi Edouard,
Thanks for getting back to me so quickly about this issue (LP Filter). I, and Iām sure many others greatly appreciate the efforts you are putting in to SDRAngel. Is there any way we can send you a donation to help with coffee/food/beer while working on the software (perhaps beer AFTER working on software 
).
Kindest regards,
Brendan Jenkins,
VK3WWB.
I have been doing RX mostly.
Just now I have been doing TX on HF AM and it works but I keep getting locked up. I have to Ctr-C the term I started in to get out.
Almost anything causes this. Changing input, gain. modulation %, nothing, anything. Restarting SDRangel is not enough. I have to hit the reset button on the board to get it to restart. Otherwise the Lime does not show up. I hope this is an interim thing, that it will go away with the next update. meanwhile RX has been working better than ever.
Thanks Edouard, I would also like to be able donate to the effort. I will have a drink for you. 
@Axeman - Lance,
Iāve been finding that the modulator and demodulator (Channel) windows if certain controls are adjusted everything freezes, but what Iāve done to temporarily fix that is to adjust the controls to what I want in an earlier version of SDRAngel, set a preset, and then start it in the latest version of SDRAngel - runs fine then and I donāt mess with the control or controls that create the lock-up. Itās a new issue, to me, and Iām going to report it as a finding on Github.
I, too, want to contribute to the effort to ensure that Edouard is able to get some compensation for all his hard effort over the past 6 months and into the foreseeable future. Weāre very fortunate to have an app for transmit and receive for the LimeSDR and no hard effort should go unrewarded. So I stand ready to āput it forwardā for Edouard when that happens, too.
73 de Marty, KN0CK
Yes Christmas is around the corner I know
Well I do this for pleasure, education a little bit and also I am a big fan of SDRangel. I came across its ancestor SDRangelove some 2.5 years ago and was attracted by its appeareance first somehow looking like the faces of LeCroy instruments. It also had some distinctive features with the plugins and channels approach. It was also relatively light on CPU considering the features. I needed more features and there was not much development going on with it anymore and I do programming as a day job and guess whatā¦ I am passionate about programming. I wanted to make some drastic changes internally so I decided to continue on a different project with the same base. I also wanted it to be an Open Source project like its ancestor. Basically this is amateur radio construction but in software and when you build your rig in your garage you donāt ask money for it (it costs you in fact!). With physical construction you can share plans but in software you can just share the whole thing and thatās also a great feature of SDR in Amateur Radio.
You guys do contribute to this project by throwing in ideas and do the testing I have no time or opportunity to do. Some great improvements and new featrues ideas have come from this forum or the issues in Github. I have reshaped things a bit doing a āProduct Ownerāsā job. The idea to have a headless version and a control via a web REST like API was definitely shaped up after your remarks. I once considered the headless thing foolish as GUI and core were so much entangled but as this fosters better design and a bunch of new opportunities for this piece of software I decided to go for it. This is still going on and there is a little bit of it at each version until the big 4.0. In fact the refactoring is a large part of my work now.
To be honest LimeSDR gives me a hard time and so does Pluto (maybe less now but it also has less testersā¦). It is very difficult to sort out where the problems are coming from: my software, LimeSuite, the hardware? The Lime guys have been helpful and most of the recent improvements and fixes come from their remarks but the way their interface works is still difficult for me to grasp. I donāt have the same issues with the rest of the supported hardware including BladeRF which is based on a chip from Lime also.
Best regards, Edouard.
4 Likes