Contract programmer for hire

So I've got myself in quite deep over my head. I need to hire a programmer to help push me over the finish line on a project I have been working on for a while. I have hit a wall and am low on time so here are the issues.

I need two things.

I need help coding a reliable dynamic mesh network for remote sensors that is capable of reliable communications of data ranging in size from 50 Bytes to 14000 Bytes. Current mesh networks I have used are Radio Head mesh and my attempt at a mesh network. The Radio Head mesh works and then doesn't.

When the complete code is done I will need to hire someone for code review. Really need a proof reader to make sure I didn't do something truly stupid, or just moronic.

The organization this is for will want an Non-disclosure agreement of the code before they will authorize me to send code to you.

Please provide quote or inquiries for more information if you are interested.

System is running an Atmega1284p MCU with a HopeRF RFM69HCW radio, using low power labs DuelOptiboot Bootloader.

capable of reliable communications of data ranging in size from 50 Bytes to 14000 Bytes.

50 bytes once a week? 14000 bytes twice a second?

10 feet? 10 miles?

What is your definition of reliable? Less than 10 lost bits per million bytes? Less than 10 lost bytes per 20 bytes sent? Most of the bytes are sort of right sometimes?

What's the budget?

Fantastic questions and ones that make me very happy I included the line about inquire for more information. Sometimes things are very obvious to others that I can't see because I am right in the middle of it and don't think about the simple fact that people cannot read my mind.

Each sensor sends 50 bytes a few times a day, and the 14000 bytes is being sent in 50 byte packets once a day. Speed is not a major concern. Currently it takes between 10 and 12 seconds to transfer the 14000 bytes which is fine.

range between sensors is on average 30-50ft a recommended maximum of 100ft with an actual absolute maximum of 150ft. Maximum number of hops can be set anywhere between 10 and 30, with a maximum number of sensors being 250.

Reliability is a little bit tougher. 1 packet out of every 10,000 would be fantastic which I suppose translates into 50Bytes out of every 500KB.
1 dropped packet out of 2000 would be acceptable though (50Bytes out of 100KB);

as for the budget. Let's just say I'm open. You know what your time is worth, different parts of the world have different cost of living and labor. Name your price and I'll see if it is something I'm willing to pay. Truthfully I've never hired anyone this way before, seems a lot easier than placing a job ad, getting resumes, interviewing for weeks. This seems so much more efficient but I can't tell you how much you would charge and I don't truly have a figure in mind. General thoughts are that if you say $100, I'm going to question if you know what you're doing. You say a $100,000 and I'm probably not even going to respond.

If you really want to hire a professinal, you should remember some things:

  1. Without a hardware to test, nobody can really help you with non-trivial real-world problems.
  2. With the facts you provided, the only cost estimate that anybody can give you is his/her fee per hour.
  3. Without a specification sheet, you will most likely end up hiring a "no problem in sight"-person - which will at least delay the project till you specify ... and then hire a professional.
  4. Looking at 1) to 3), what do you really expect from the person you hire?

I'm sorry to say, but with the facts you provided I can give you my fee/hour, that's all I can do.

I need help finding a way to make the code work. I am actively testing the hardware and rarely sleep so collaboration and uploading to test the code as well as the results of the test will be easy and mostly seemless. As for what I expect it is more that I need help finding the problem and solving it or reevaluating the logical approach. This is very much a find the problem and solve it kind of gig.

I am game for an hourly rate, and I am fine with that, even knowing that I have no idea how far down the tunnel it is until daylight.


Sorry, still some questions (and I obviously live in a different timezone - GMT+1, so live assistance could be a challange):

What's your eqipment? You have an oscilloscope at hand? Logic analyser? Can you get the mesh work reliably on your desk with just 2 nodes (sender + receiver)? How did you set up communications (one way or 2 way)? Have you implemented a way to detect missing packages? Did you implement any resend logic? I did not read the datasheet of RFM69HCW in detail, but it looks like it does not implement meshing in firmware - so did you realy implement a multiroute meshing protocol on top of it or is it "just" intended to build somthing like like rangeextender with multiple hops?

Ad maybe the most impotant: What is the timeframe?

Unfortunately I am 3000 miles away from my hardware lab and when I was packing up I left my oscope in Arizona, but if we need one I can make one pretty quickly. As for everything else we should be alright on hardware testing.

The RFM69HCW does not have meshing in its bag of tricks though that would've been nice. Hindsight is such a pain sometimes lol.

In any event you could think of the mesh as an application level development I suppose. The radios themselves more or less communicate with any radio that is in range and from there when they get a signal, if it is for them then they do something with it, if not they either forward, or discard it. That is the basic principle of the Radiohead RH_RF69 Library.

Today I wrote a much simpler communications method for them since at any given point in time only one node is communicating with master unit and vice versa. So I hit on the idea of just have the nodes forward the message without the use of a route.

Any node that received it but wasn't the destination, waited a small random time, and then would rebroadcast the message. I gave each transmission a unique ID so that it would only be processed and/or forwarded once per node that got it.

With end to end acknowledgement this works perfectly with one sensor. Pretty good with 2 sensors, and gets exponentially worse as more sensors get added. So I have spent a significant portion of the day trying to find good ways to prevent collisions and broadcast storms.

I tried checking the rssi of the radio but ran into the same problem as the developer of the RH_RF69 library did with an major freeze when triggering the radio to take a new reading. I tried bastardizing the rf69.available() to make sure no one else was transmitting but that only worked so so.

Now I am back to the drawing board to figure out the best way to stop these collisions while still mass forwarding the payload, which with this new approach is 54 bytes.

Time frame to say this...I wanted to go home a month ago, so faster would be better than slower.

is it "just" intended to build somthing like like rangeextender with multiple hops?

Yes exactly that...that is all it actually needs to do. That would precisely solve the problem. Just wish it had of occurred to me as quickly as it did to you. I only thought it up last night after a month of trying and failing.


This sound like a fun project.

So, is it this library you are using: RadioHead: RadioHead Packet Radio library for embedded microprocessors ? If yes, which manager do you use, if you use any? Is there a link to the description of the packetstorm you saw? Does the send() and recv() function work reliably or are there possible lockups (i.e. is it verified that the CRC mechanism works reliably)? Can the radio receive and send simultanousely or not (I think it does not)?

Other question which might or might not need an NDA and which need to be cleared even it is a rangeextender: What's the network topology (i.e. are ther multiple paths which can change)? Do you have a simple drawing of the actual realworld scenario where nodes are placed, why they are placed, which nodes "see" other nodes etc. and the intended dataflow? Are nodes added and removed from the network dynamicly or is it a static setup? What is the intended behaviour when nodes fail? Is there a defined maximum delay from sending data from the node to receiving data on whatever-consumes-data? Is the network intended to be self-healing? What should happen when the network fails? What is the definition of a network failture in the first place?

If you can live with a communication delay, then I'm happy to assist you - please send me a PM for the details.

The RFM69HCW does not have meshing in its bag of tricks though that would've been nice. Hindsight is such a pain sometimes lol.

No radio has this by itself; that's the software layer. RadioHead offers mesh networking that's pretty agnostic to the underlying radio. This makes their code really portable between different radios.

Interesting project - for sure. I've been working with RFM69 radios on and off over the past half year, not mesh, just creating an ad hoc network between them. Same with LoRa.

This is a thing that is nigh impossible to test without the actual hardware. I think 4-5 nodes would be enough, those you can make into a small mesh network, but that's just for basic code and logic testing.

When it comes to reliability of your packet transfers, that is a different matter. If you use RadioHead, you can use the "reliable" method, which means every packet is acknowledged by the recipient. The radio itself will make sure the bits are transmitted correctly, so if you get back the ack, the data is transmitted correctly. This way you can implement your own retry scheme. Then getting actual working radio links is a real world problem, as it has to do with the physical placement of the nodes, the antenna design, etc.

Proof reading code, that doesn't really work. It's not a thesis that you can pick out grammar errors (the compiler did that for you already), and picking up logic errors by just reading code is really hard without knowing the intended logic flow.