Re: [Discuss-gnuradio] Just posted 2 job offerings

[CEL]

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" <address@hidden> yazdı:
> > LOL, $30 - $250 budget for a CCSDS modem.
> > 
> > On Sun, Mar 4, 2018 at 5:39 AM mehtap özkan <address@hidden> 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
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > -- 
> > Very Respectfully,
> > 
> > Dan CaJacob
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature