LimeSDR mini order

Is there any more information on delivery timescales on the limesdr mini?

I backed on September 26th and was given an estimated shipping date of December 31st. This got delayed, and after the posts in late January saying the first boards had shipped, my delivery date got pushed out to February 16th. The date just got silently bumped to February 28th. And it was still saying 28th February until yesterday when it’s now been changed to March 15th on my order details page, again with no communication about the delay.

As all the updates to date have suggested that things are on schedule and the update before last promised that all the boards would have shipped by end of February, can we have another update with the current timeline for all the remaining boards and orders?

LOL, this update got posted about an hour after my post here:

Hi ralf, I have the same trouble.

I bought my limesdr mini few mounths ago and I still not receiving anything. This is really distrurbing when you see on the website (when you’re going to buy the item) that expected delivery should not take more than fews weeks.

And now, delayed, delayed delayed… Damn that’s not possible. There are not information on update I dont know what to do.

Is limesdr mini really ready to go to production or not ? Or is there just place for big buyers ? At least indicate true excepected ship date -_-

H.

PS : and when I see that kind of thread :




I’m not confident at all.

Don’t get your hopes up. Documentation is non-existant and there is absolutely no support from Lime. I spent countless hours trying to get my LimeSDR to work, but not a single piece of software can get anything remotely resembling a signal out of it. This was a waste of over €150.

2 Likes

Glad to hear that …

I think this is more than a little unfair. There is quite a lot of documentation on the wiki and you appear to have been receiving support here:

As the author of SDR Console noted, he doesn’t check these forums that often and for issues concerning a particular application, its mailing list or forum is nearly always going to be the best place to get support. Getting back to your issue, if you’d like to engage constructively we can work to get you up and running.

2 Likes

Hi,
I think there’s some unwarantted negativity here. As someone not affiliated with MyriadRF and just a simple user, my personal experience with the LimeSDR mini (ordering not involved) is:

  • spent two hours on the wiki reading documentation
  • spent half an hour building all relevant software according to instructions (at the time I did not use distro packages since they were too old or missing)
  • spent a day or two discovering bugs and quirks of the software and implementing workarounds in my own software
  • made sure the application worked as advertised and captured in demo

Now, there are indeed some issues.
I felt the wiki did contain a lot of information, but it was not very well organised and involved a lot of clicking around to cover a topic. Perhaps a technical writer might help with this aspect. Also, I think more time spent on QA rather than development might avoid some user frustration. Since my LimeSDR mini was a pre-producion board, the software support was probably still in infancy. I did not verify if it has improved, but I’d expect time to iron out issues.

To the users: I don’t see the LimeSDR as a turn-key solution. It’s not really something you just plug in and expect to work. Since we’re talking about software defined radio, I think the clue is in the name: to make the most out of it, you need to have good knowledge about software. There is a tradeoff between user friendliness and flexibility. Using the LimeSDR, like any other similar device, allows you to define your own signal parameters and experiment with non-mainstream ideas that were not implemented by someone else before. That capability comes with a demand to learn the system you are using very well. A beginner needs to expect some frustration and a very shallow learning curve. Also, since this is a community project and you are getting all the software for free, you need to apply due dilligence and at least report issues properly using the dedicated channels or even fix them yourselves if you’re willing to learn.

Best regards,
Adrian

I’m not blaming the author of SDR Console for anything. I’ve tried multiple apps on multiple OSses without success. I asked the Lime people for support, and the only response I get is that they think my LimeSDR is working correctly because it can detect a 1W carrier wave transmitted from 50cm away.
However, when I ask them to prove it with a piece of software they say is fully compatible, I don’t get any response for over a month. You tell me who has been receiving support. It wasn’t me.

1 Like

Adim,

I would like to confirm what you’re saying but like the topic purpose said : shipping is a shame.
Making software solution working with limesdr mini is another thing, maybe you should open another topic to discuss about that but clients want to know.

Treating customers like crap (it looks no support, not informing about shipment or not making drive updates etc) is really bad for the company image.

Hope LimeMicrosystems will change their minds about that, when a company grow, everything need to grow. And much more in growfunding, they need to know that their clients are people who make the company working.

There might be plenty of documentation available but if the device doesn’t work the documentation serves no purpose. I am not sure about everyone else but, when I decided to preorder my decision was based on then information provided on the lime mini site. “We just made software defined radio more accessible.”read the motto on the intro video. My question is to who? Reading on this forums you would realize there are two people that post, one of them frequently who apparently never have any issues, and never broke a sweat trying to get this thing to work as advertised.

There are countless posts about the issues, they somehow always end up being treated as “it’s the user”. They set it up wrong… write your own software so on and so on. Yet, the issues seem to repeat themselves over and over. I saw the demo videos of the device working with SDRAngel, URH, a post about the ExtIO driver for HDSDR, yet nothing works. It is a shame, I ordered mine last year and even brought some other people and made them aware of the project and they crowdfunded also. Our evening talks now days are about that 100$ too light to be a paperweight device that sits on our desk hoping one day a cure will be found and it would work as advertised.

I saw this as a step up from the 2 times priced hackrf I’ve owned since inception and tbh at this point I would just order another one at twice the price if I could get rid of this thing and get the money back. This is without mentioning the months of delay to get the product without any word of the production / shipping status.

1 Like

pisstaco,

I must admit, I have to agree with most of what you say.

I have been unable to make mine work consistently, in spite of compiling everything from the latest source. Not on Windows 10 and not on macOS 10.13.3.

On Windows, SDR Console will usually work at 15Mhz sample rate and pick up local FM radio stations. Other sample rates and the audio (and waterfall) stutters. There are errors in SDR Console’s log - it tries to set CLKGEN to 160 or 320 MHz. 320 always fails. 160 sometimes fails. Same failures if I try the same rates from LimeSuiteGUI.

On the Mac, I finally got gqrx to run at a sample rate of 7.68MHz. I always get “[ERROR] SetPllFrequency: error configuring phase”, but I can get audio from the local FM stations. But do anything that involves stopping/starting the radio and no new data comes from the radio - the waterfall reapeats the same data, the spectrum is frozen and… silence. Something as simple as enabling RDS freezes it. LimeQuickTest will work and all the tests pass before running gqrx, but after stopping gqrx and running LimeQuickTest, the last test will fail! The radio gets in a state that LimeQuickTest’s initialization cannot fix! Nor does setting defaults from LimeSuiteGUI fix it. The only way to fix it is to unplug the Mini and plug it back in.

Since both gqrx and LimeQuickTest go through the LimeSuite library, there is something seriously wrong with the library that allows the Mini to get in such a state that the radio needs unplugging!

And as for the library currently in homebrew, it was last seen throwing segmentation violations.

Frustrated? You bet!

Now it could be that those of us complaining here have a broken unit and the rest of those shipped by Crowd Supply are working fine… or more likely sitting on the self waiting for a “'round tuit”.

1 Like

I’ve been an SDR user/developer since 2004. It has only been in the last couple of years that I’ve seen expectations shift from SDRs as components in a development framework to “ready-to-go-end-user-device”.

For ANY SDR company, how far up the “user experience” chain should they go to make their users happy? Lime sure as hell didn’t write GQRX, nor any of the other dozens of bits of end-user software out there. Should it be Lime’s responsibility to make sure that they all work, in all possible usage scenarios, on all possible OS variants, on all possible configurations of system libraries and kernels? I would say, probably not.

Granted, the “bits and pieces” that Lime supplies – the hardware itself, and the libraries to drive it, need to be solid enough that the purveyors of high-level “app” software can be successful in making their apps work. But let’s be SUPER CLEAR. The responsibility for making any random app X work with new hardware Y, is undeniably the responsibility of the author of X, and not the maker of hardware Y.

Let’s use what I call a “proximate analogy”. Intel brings out a new CPU with some whizzy new feature on it that apps can use to do amazing things. You load up with your new CPU and find that only two apps actually recognize and use the new feature. Is that Intel’s problem?

Let’s use a less-proximate analogy. You buy a whizzy new car from Ford. You take it out on the highway and find that the highway is clogged with traffic most of the time, making your experience of your new car less than delightful. Is that Ford’s problem? You pull the same car up to a shady looking gas-station, and find that the pumps are issuing forth a substance that smells a lot like gasoline, but has almost none of the desirable properties of gasoline. The car fails to start. Is that Ford’s problem?

New SDR hardware does tend to get rushed to market. Not just from Lime. Most developers are somewhat used to this in the hardware space. But hobbyists and ham-radio folks are used to “appliance radios”, and don’t always recognize that an SDR is a component in an overall system, and that expecting it to be an “out of the box amazing ham-radio experience” is unrealistic. It is the high-level APP software that makes it a “user experience”, and THAT is simply beyond the zone of responsibility of hardware vendors. I’ll assert that if a hardware vendor DOES attempt to bring that layer into their “responsibility envelope”, that they will fail at it, miserably, unless they drop considerable resources into the problem, at which point, the price of the product will double, guaranteed…

1 Like

mieech,

Although it is true that Lime cannot test on all hardware/software combinations out there, the applications I have mentioned use the LimeSuite library and the errors that I see come from the Lime supplied library. You can hardly blame the app level software when the Lime library throws an error when setting a valid sample rate, or allows the device to get into a state where it needs unplugging to reset it.

To use your car analogy, it’s like setting the cruise control for 60mph and having the car stall… but it works if you set it for 45mph.

SDR Console V3 is a fine piece of software on windows - and when the (unfortunately rather old) Lime library condescends to set a sample rate and serve data, it works rather well. But I cannot substitute a newer library. Lime seem to have changed the ABI without changing the versioning. Certainly reviewing the git history, I see data structures in the C API changing. You can’t be changing data structures without versioning them and even worse, you can’t be deleting members from the middle of a data structure.

1 Like

So, the real issue for you is that your app vendor, SDR Console, hasn’t updated to a newer version of the libraries that don’t have these problems?

Other SDR vendors have this issue as well. “We changed our mind about how the API and/or ABI works, so, you’re going to have to recompile your apps”. That is squarely the responsibility of the APP supplier.

1 Like

_ let’s be SUPER CLEAR. The responsibility for making any random app X work with new hardware Y, is undeniably the responsibility of the author of X, and not the maker of hardware Y. _

Completely agree. However, when you are a hardware developer and demonstrate your hardware X operating with software Y. The analogy you are trying to use about a car and traffic, does not relate to the issue here in any way, shape or form. A more accurate description would be, You buy a whizzy new car from Ford which ford has advertised and demonstrated their whizzy new car working on dirt roads, asphalt, and concrete roads, Then you go ahead and take the plunge, buy the whizzy car and soon realize that the demos you saw do not reflect the reality of the product you just purchased. The car does not work in asphalt, or concrete, or dirt, it does work on a cotton road developed by Ford. But, when you call them for support, you are told, we do not make the dirt, concrete, asphalt road that we used to demonstrate. They do tell you it works on that cotton road we made, and we can’t promise it will work on those type of roads that we use to demonstrate our product.

The reason analogies like this and like the one you provided do not work is due to the fact that the situation is more complex and analogies are provided as an excuse to justify X or Y behavior or outcome. You talk about dumping resources to resolve issues and the outcome being an increase in price. But, there is so much more that can be done, collaboration goes really far in resolving those issues. It is evident there are issues with software compatibility, and it is understandable it is not the hardware developer. That being said is it the user’s fault? Was it wishful thinking to buy something under the impression that it would function with the software used to demonstrate the hardware?

There is a lot that can be done. Communication for example. Rather forcing the concept of “is everyone else’s fault rather than ours” or simply ignoring posts and threads about users having the same exact issues over and over, a better approach would be to actually address the issues. How can they do that if it is not their software? Perhaps collaborating with the software developers. Another thing that would be really nice is actually acknowledging the issues do in fact exist and communicating with the customers. It is easy to say that there is negativity on the users part, and that the users are bashing the developer for things out of their control but, imagine the feeling of multiple users who paid 100+ USD for a product that does not work as it was demonstrated.

1 Like

_ let’s be SUPER CLEAR. The responsibility for making any random app X work with new hardware Y, is undeniably the responsibility of the author of X, and not the maker of hardware Y. _

I’m afraid I’m going to have to disagree to some extent.

It’s in Lime’s best interest for their hardware to work well with existing apps. No apps, no sales. Anyone wanting to use the Lime hardware in their own design is going to want to see the Lime hardware working. Not in LimeSuiteGUI, not in LimeQuickTest, but in a real SDR application. And in fact, the Extio dll for HDSDR has a Lime copyright in the source. Pity it’s not working for me at 20MHz sample rate, complaining that SetFrequencyCGEN(160 MHz) failed. It does seem to work at other sample rates and will receive local FM Radio as long as the output bandwidth is maxed.

Consider someone wanting to buy many Lime Mini sized SDRs coming looking here. Why on earth would they consider Lime when there seems to be no interest in addressing the common issues here?

2 Likes

Well, I’m not going to defend, or criticize Lime’s processes, since that’s a sausage factory I don’t happen to work inside.

But I have worked inside many other sausage factories over the nearly 4 decades of my career.

I can tell you that because a demo appears to work just fine is no guarantee that it’ll work just fine in another apparent instance of the same thing.

The combinatorics become staggering pretty quickly. I’ve seen several different APPs mentioned in this thread and others, let’s call it a half-dozen. Multiply that by let’s say 3 recent revs of Windows, and perhaps only two revs of whatever libraries Lime stuff depends on. That’s 36 different test scenarios, and we haven’t even entered the “operating parameter space” of each application yet. Now in larger companies, they actually do this kind of stuff, they have a combination of QA monkeys and QA test-script writers, and automated testing. Your QA department doesn’t work for adulation and exposure…

Then, we move on to Linux, which is a massive combinatoric explosion all to itself. Everyone has their fave Linux distribution, and there are, conservatively, perhaps 10 “top distributions”, and usually several different revs “in the field” for each distribution.

I have no idea how many folks Lime/Myriad have working on this stuff, but I’m going to guess that at U$299.00/board, none of them are getting super-well-paid. I’m also going to guess that they have been completely taken by surprise on the magnitude of sales, and the diversity of the community that is using them. They will almost certainly need to tweak not only the usual things–fixing bugs in the hardware/software, but perhaps more importantly, look at their overall process for doing this thing.

I also have no idea how “collaborative” Lime/Myriad have been with APPs folks, in terms of giving/lending devices for dev and testing, answering those devs questions, etc. Many of the APPs we’re talking about are open-source, and free. Most of the devs of thse APPs have other work they do to put catfood on the table, and making their stuff work with yet-another-new-piece-of-hardware may not always be top priority.

I completely understand the point you are bringing from that perspective. However, it is perhaps because my experience has been on the side of delivering products and services to clients that I see things in a different way. Also just to clarify, I was and still am somewhat excited about this project. Love the concept and the price point but, communication overall has been less than desirable. For example, a product that was set to ship out on December 28, 2017 users that had preordered were not communicated the fact that it wouldn’t ship on said date until after the fact. Due to issues with the supply chain etc, etc. I can understand there were issues with the availability of components that ended up impacting the production and ultimately the initial shipment date. Now what I cannot understand is that customers were not notified until after the fact. Someone in the production team had to know this before December 28, actually well before that time someone had to know that production run wasn’t going to meet deadline, yet there was no communication to the people that actually funded the project. When dealing with clients that is always a no no. You do not keep the people that are funding you in the dark. Sadly this behavior has been a plague since crowdfunding became mainstream.

Another thing. From their site:
Risks & Challenges
As in the original LimeSDR campaign, the supply chain is the biggest risk – parts shortages could delay production. However, since the critical parts we’re using in LimeSDR Mini are the same as those in the LimeSDR, the Mini will benefit from the considerable work we’ve already put into creating the LimeSDR supply chain.

I can guarantee you there were not expecting to be in this position. No one does. If I, regular dude browses a crowdfunding site looking for interesting projects to fund and I come across this Risks and Challenges disclaimer. I think, hmmm well reasonable. Stuff happens, there will be delays. Ok. However they picture you are trying to paint should have made that Disclaimer about one paragraph longer.

You simply can’t deliver a product to a client and tell them “Hey about that project you funded for me, well it might not actually work as I made it seem. There is a risk that it might not work at all in the way that I presented it to you… Just thought you might want to know since you already invested in me.”

Worst than stating such thing would be complete and utter silence in the event that the device does not work as described. While you are completely right about that possibility, I do not think that at any time it was contemplated that it might not work as they presented it. What baffles me is the lack of communication towards the people that funded the project.

I do want this to work, I’m sure all the people that have shared an issue on this thread want the same. But it is simply inevitable that after having a product delayed for 3 months and sitting on a shelve for another 2 months waiting for a magic bullet, frustration is simply bound.

1 Like

Yes, the combinations explode when you consider OS versions, Compiler versions, library versions and so on, but program defensively and it’s not that bad. I have code running on Windows, OSX, iOS and Android (it ran on regular Linux too, but we were never interested in a Linux product). Since I was dealing with files and filesystems, I abstracted all I needed into an C++ interface class and created implementations for Windows, OSX and Linux(Android).

It’s actually not hard to write code for Windows that runs on XP through Windows 10. I have to. Compilers are a bit of a moving target, but avoid the more esoteric features of C++ and don’t shoot yourself in the foot by trying to export C++ classes (we learned that was a bad idea a long time ago) and you won’t go far wrong. Notice that you don’t have to recompile your application for each Windows release - build for XP with Visual Studio 2017 and it will run on Windows 10 (yes, MS are still supporting building for XP).

The availability of virtual machines makes testing many operating systems and/or operating system versions a lot easier - as long as your virtual machine monitor supports USB well. I know I’ve used our USB3 device in a Windows 10 VM running under Centos Linux and VirtualBox.

But we are getting way off topic here.

As for the delay receiving the product and lack of communication(?) that frustrates pisstaco, that’s been typical for crowd funded projects. I don’t actually have any complaints in that area. I’d have been very surprised if it had turned up much sooner.

2 Likes

I admit that I haven’t had the shipping frustration to deal with, and my experience WRT initial bugginess is with the LimeSDR, rather than the 'mini.

For the LimeSDR-USB, I had some initial problems, upgraded the libraries, because the AURs for Arch were out-of-date, upgraded the firmware, and I was “in business”. I produce apps for the radio
astronomy community, so my apps are somewhat “agnostic” with respect to hardware. But I’m not
going to claim my stuff supports any given hardware if I haven’t tested it myself. I certainly don’t expect the Limes and Blades and Hacks and Ettus’ and AirSpy’s of the world to do that testing for me.

I don’t have a 'mini yet in my lab at CCERA. But if someone wants to send me one for integration
into my radio astronomy toolchest, I’m game :slight_smile: Then I might end up joining the chorus of “this thing doesn’t work” or “it was a bit of a pain initially, but it’s working fine now”.

I’ll observe that when I and others complained about lack of proper phase-coherence in the implementation, the Lime dev folks responded in a timely manner, and the main codebase now does that correctly. So it’s not like they ignore their customer base.

-Marcus Leech
President
Canadian Centre for Experimental Radio Astronomy