Dear Mehtap, I'm going to write this email in two parts:
1. Why your request is not going to be fulfilled by anyone serious 2. Why this is no problem at all (and why GNU Radio is awesome!) Why your request is not going to be fulfilled by anyone serious =============================================================== Read the 6 offerings you've got so far: all these are people that have "worked with python" (or c++) so far, but have zero knowledge of GNU Radio, or SDR for that matter. They have absolutely no clue of what you're trying to do, and they have no clue that they have no clue, and even then they have the audacity to offer their services. As I was one of these mailers that told you it was unlikely you'll find anyone for 250$: As I said in my mail, consider the consulting overhead (invoicing, tax reports), and the fact that you're expecting people to know a very specific piece of software, or in-depth understand it on the time you're paying for. And then you're in a sector, satcom, that's again not something that you want to do without understanding what you're doing. When hiring a consultant, you do not only pay for the hours they work solving your problem. You also pay for the hours they spend understanding what the problem is, understanding the specific tools (in your case, GNU Radio, gr-ccsds, gr-osmosdr, LimeSDR,…) you're demanding, writing reports, verifying what they've done, communicating with you… and most importantly, you also pay for their experience. I've sent you a wild guess on how many hours one would estimate to spend on your problem in a private email. That is all *assuming* the contractor would already roughly know gr-ccsds. And if you didn't notice, Dan himself, the author of that module, wrote to say "LOL". I guess your best bet here really is trying to understand *why* things fail, and try to diagnose that. We're really a helpful bunch here, and the more precise your questions become, the easier it's to answer them in a friendly dialogue on the mailing list. What we can't offer is "solve my complex problem that I don't have the time to approach" for free, and 250$ is damn close to "for free" in this context. That would not even cover the price of one half of the two LimeSDRs that anyone would need. Did you notice that you currently can't even order them (you can, but they won't be shipped this month)? So, anyone having one of those is pretty much having a definitive market position to expect you to pay at least half of their investment cost for these SDRs. So, actually, what you demand is not only working "for free", but using hardware "for free": Really, really not happening! By the way, if I was to invoice you for the time I spent writing my previous (not including this one) answers to you, your 250$ would probably already be gone. Why this is no problem at all (and why GNU Radio is awesome!) ============================================================= Based on your price expectation, I'm pretty certain you're not working in an engineering company. (If you're in fact working in a company, or a stately funded research institution, ask your boss for budget. He will – hopefully – laugh at your expectation to buy a solution for 250$.) That means this is probably a learning / skill-building effort on your side, in the bigger picture. Considering you seem to have expensive Ettus equipment, you're probably a student at a university. That means, we, the GNU Radio community, would really like to learn _together_ with you about your use case. That would **also** be the case if you were a company, for example. But that has to be a two-way effort. I've been reading your previous mails and honestly, they are all of the same type: "Hi, I have a problem that is related to GNU Radio, but I don't give you the bigger picture of what I'm trying to achieve, or what I've researched so far. Please solve my problem. Best regards, Mehtap" If you gave us a bit of a bigger picture of what you're trying to achieve, we would have been much better at helping you _understand_ what you're doing. This time, we at least learned that you want to implement a CCSDS modem with a LimeSDR. And you see frame drops with your LimeSDR, but not with your USRP (are you sure you even wrote the device type of the USRP correctly? The N310 has been out for only very, very short time). That's all we learned. Nothing about what is actually wrong about the signal, other than that the constellation looks "funny": That's really no way to engineer anything. So, even if you do end up outsorcing this to anyone else, they would require to describe the problem in much, much more detail (or, they would have to reconstruct the same problem, and that's time you're going to pay for – see above). Start by describing what a frame drop is, how often it occurs, in numbers. Then, you already seem to have started debugging this, but: actually share a view of the constellation. Investigate the spectrum. Look at synchronization. Just, for every single piece of your signal processing chain, look at it and ask yourself "how can I prove this is working optimally?" and then, do that diagnosis. **Document** when that diagnosis leads to an observation that doesn't reflect your expectation. I'm pretty sure your problems are solvable – but I'm also pretty sure that you're always just asking about *extremely* localized special _symptoms_, and never address what your overall challenge is. We *can* help you – and in exchange, we just need you to contribute what you're trying to achieve (because that's what we can use to make GNU Radio better in the long term), and how GNU Radio poses problems that you can't solve on your own. Again, a somewhat comprehensive background is necessary, and specific questions that arise from the specific problem you're solving. So, I'm really, really looking forward to more mails that describe what you're trying to do, and where exactly you're stuck! We really, really love to help each other. This is NOT restricted only to hobbyists, or students, or enthusiasts: *A lot*, if not *most* of the people on this mailing list actually earn their money with signal processing. You're tapping a very resourceful community, and might not be realizing how precious that can be. We all happily cooperate with companies, and if you got any serious consulting to do, someone *will* be found to solve your issues. Sadly, serious consulting doesn't start at 30–250$. So, hope to hear more from you! Best regards, Marcus On Mon, 2018-03-05 at 20:21 +0300, mehtap özkan wrote: > Dear All, > We received a lot of mails stating that the flowgraph we wanted can not > completed within the budget or in time. > You are right if we would request a CCSDS implementation from scratch. In > fact what we were asking for is already completed for USRP and it is here: > https://github.com/dcajacob/gr-ccsds > Our problem is that we could not get the example working with LimeSDR (too > many frame drops). It is either us or the Osmocom blocks but we needed > another one to check it. Thats why we decided to hire someone to fix it. > > > 4 Mar 2018 18:04 tarihinde "Dan CaJacob" <[email protected]> yazdı: > > LOL, $30 - $250 budget for a CCSDS modem. > > > > On Sun, Mar 4, 2018 at 5:39 AM mehtap özkan <[email protected]> wrote: > > > https://discourse.myriadrf.org/t/just-posted-two-freelance-jobs/2421?u=booth > > > > > > If you are interested send me a message. > > > _______________________________________________ > > > Discuss-gnuradio mailing list > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > > Very Respectfully, > > > > Dan CaJacob > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
