@martywittrock can remind me where you shared details of your experiences with HF and v1.2 hardware. I seem to recall you were happy with the performance at the time and, based on general feedback from beta testers, I understand the decision was made not to change the matching networks from what v1.2 boards had.
Currently we are using components on LNA inputs to fine tune for some cellular bands. On the final version of the LimeSDR we shall match the receivers for the optimum broadband performance.
But they did not remove the components on LNA inputs from v1.2 to v1.4. Am I correct?
No @andrewback, @Bernard is right. I received my LimeSDR (v.14s - sadness) today, and a few hours later I found this thread… Like @Bernard I placed order for a LimeSDR coverage of 100 KHz to 3.8GHz. It seems to me that the problem is hardware, and not just configuration. We are talking of the input filters and these are not changed by software, isn’t it?
Obviously I have no way to change the filter components (SMD stuff), so I nearly quote @Bernard and I expect from you a fast solution so that MY LimeSDR can operate in reception and in good conditions in the part of the spectrum HF from 100 KHz and that on two inputs of reception.
I did mentioned on the other subject that there is no filter on the RF ports at all. There are 1:1 transformers with the matching network and there is a pair of RF switches. The design is OK and according to the LMS7002 evaluation board. The transformer used is a good approach and I do not suggest to remove it. The data sheet does not show clearly the transformers performance down to 100khz but from the graphs, there should not be a problem using them also on low frequencies.
I download the S parameters from the manufacturer and just by quickly looking the figures it seems that used transformers are good from 1Mhz. There is a data starting 300khz up to 4Ghz and it is complex as this is a 4 port device.
I may try to simulate the performance together with the matching network to get the picture how it looks like but this is probably done by designers and they should have the simulations with the S parameters, i hope they have used such approach. This will save me or others from spending time on simulations.
It is strange that Simon has the problems on 100 Mhz, so it may lead to the sw configuration problem rather than hardware problem. The fron-tend is so simple that there is not much to do around it.
As a Beta Tester, I always had acceptable performance with the V1.2 LimeSDR operating from 10 MHz and up. All my testing was observational (non-scientific) and compared to other SDRs I owned (Red Pitaya and RTL-SDRs with upconversion). The videos I posted with the SDRConsole and GQRX apps running show the LimeSDR receiving on 20m (14 MHz). Performance of the V1.2 LimeSDR below 40m (7 MHz) was marginal and that’s what inspired all the discussion in the July-August 2016 timeframe (when HF was just beginning to work on the LimeSDR) by the beta testers about changing the front end matching networks to improve the lower frequency (including HF Band) performance. Plus, there were schematic observations by others that the inputs were optimized for much higher frequencies (> 100 MHz) and they, too, wanted to see lower frequency performance improvement. When the curves were released by Ricardas, it appeared that we would get that better performance we were looking for from the LimeSDR, so I - like many others - were excited to see this happen. But thus far in the V1.4 boards, I’m not seeing that improvement. In fact, it just seems a weaker at 40m (7 MHz) than it did before, but I’m holding out hope that there are firmware adjustments coming to either be baselined with the V1.2 boards or better.
I am also of the opinion that if you publish specs for a product you have to live up to those claims as the manufacturer. Ultimately, the manufacturer of any product has to perform formal testing on their own to the specs they publish to be in compliance with their consumers. Beta Testers are there to play with the hardware and report the findings. The findings showed a deficiency in the lower frequencies (including the HF Band) and that was discussed. The curves were the solution to that issue by the manufacturer. What happened after that is anyone’s guess.
Since I’m an experimenter by nature, it was always my intention that if I didn’t get what I wanted out of the LimeSDR I was going to ‘roll my own’ to make it work. I may still do that, but right now I’m waiting to see if there will be firmware improvements that will finally set this radio right. One can only hope…
To improve HF received , Lime MUST modify input , no way to improve in firmware because all input they using a coil 10nH or 8.2nH parallel with RX input , the impedance of coil at HF is very low so it reflects all HF back ( impedance of coil 10nH at 10MHz is 0.628 , very low )
Yeah, you see, I bought the highlighted in green with an arrow pointed at it part of the “Developers Kit” that you’re referring to. Development board or not, people have reasonable expectations…Especially with the way it was presented on CrowdSupply.
The opening line to their campaign is “A Software Defined Radio for Everyone”…now all of a sudden that’s getting narrowed down to A Software Defined Radio for Everyone…who wants an SDR optimized for 700 MHz - 2.8 GHz??..
What’s next? A Software Defined Radio for Everyone…who knows how to program and holds an RF Engineering degree??
Yes it was a crowd sourced product, of course there might be some risks, but by investing in this we also put a our trust that they’d deliver what was advertised. You shouldn’t be so accepting of this sort of thing. If more people think like you, it’ll only encourage future companies that are looking for crowd funding to do the same…over promise and under deliver…shouldn’t there be some accountability? If not, I’ve got some dehydrated water to sell you.
I think they use it for matching at 900MHz , the problem is simple if LimeSDR team focus to solve it . For temporary if you want to improve at HF just remove that coil I sure it should be OK, for best performance you need a HF band pass filter at input .
Ok … i can see that parallel resonance of 1.5pF with 8.5nH (with some more inductance from the transformer) would be in the area of 900Mhz … essentially its also a poor bandpass filter …
Remove the 8.5nH and the dead short on 10Mhz(HF) on the Rx is gone …
Frankly a loss of sensitivity above 500Mhz is meaningless … i don’t think any ham is going to NOT use a 1.5NF (or less) preamp on the microwave bands …
Well … unless its in the order of 10db – some one might complain … but i kinda doubt the reduction at microwave will be that much …
Now i wonder what kind of drop in Tx power is there from 1mhz compared to 1ghz with such small value chokes … 270nH in series with 100uH … coilcraft has some wonderfully large bandwidth bias T / chokes that would work well up to 5ghz – (going from memory on the upper freq end)
Wonder if a BCR-221JLB could replace the 2 chokes and fit on the board …
[quote=“martywittrock, post:45, topic:690”]
When the curves were released by Ricardas, it appeared that we would get that better performance we were looking for from the LimeSDR, so I - like many others - were excited to see this happen.[/quote]
I’ve just commented on that thread, noting that following overall feedback on v1.2 hardware, the decision was made to not modify the matching networks. This will not be welcome news for HF users, but a number of solutions are being investigated and a detailed update should be posted later today.
This should not be the case and in testing Lime engineers have found the performance of both hardware revisions to be the same.
As I say, update due later today on improving HF performance. Please be assured that any delay in offering solutions or commenting further thus far has been due to wanting to be in possession of all the facts and actual measurements, and having given sufficient time to investigating the optimal solution(s).
I do not say that 8.2nH may not be a problem but,I take some time and went through the LMS7002M datasheet.
What I saw is that the frontend configuration is almost the same as the recommended by the LMS manufacturer. Same setup as the evaluation board setup. They do declare the coverage from 100Khz to 3.8 Ghz so it should work using that matching configuration and transformer.
What I also found, is that there is a combination of the chip integrated low pass analog and digital filters, both on the receiving and transmitting side and looking the graphs, they are quite step. This may be one of the reasons why there is degraded reception in some cases. I suggest to consult the LMS7002M datasheet for the proper low pass filter configuration. The set up is not so simple to explain in few words as there is a combination of 3 lowpass filter used. This is explained on pages 5 & 6 of the datasheet.
The low pass filter is after RXMIX so it effects to IF bandwidth , not front end input.
The recommended frontend of LMS is for 700MHz and about . I think the engineer who designs LimeSDR never check and verify the input front end at HF frequency and lower ( 100KHz range ), they just stupid copy the recommended by LMS for range 700MHz-2.6GHz .In this schematic the LMS note very clear range 700MHz-900MHz , 700MHz-2.6GHz and 2-2.6GHz for three input.
The fix is simple but some peoples can do it, some can not, so I think Lime should be give an option to return the board to fix it.
Yep, you are right, the filters are after the mixer, agree.
Well, can somebody do the mods and verify that the problematic are only 2 SMD parts at the end ?
I will be looking forward to the argument from both sides, and please do share your results and whether you get any success by doing modifications to the board.
I will await the information later today but I can tell you that my decision to invest in a second board for personal use in a low frequency phased array at was totally driven by the contractual commitment by Ricardo who works for LimeMicro that the design of the input matching networks would be changed on the 1.4 version boards to better honour the wide Band performance specification offered. The thread on the forum on this topic at the time is clear including your comments . The fact that this has now not been delivered will influence the business use evaluation for which I bought the first board which could have resulted in some interesting business for LimeMicro . As a Professional Engineer I like to work with equipment vendors who honour their product development and product specification commitments . I am currently not seeing this from LimeMicro in what has been delivered with the version 1.4 cards . This is unfortunate .
But as I say, data is forthcoming.