I love coding, but sometimes you hit the point where it gets laborious. I'm slogging through thousands of lines of code, trying to implement what works so well in simulation. The whole point of simulation is that you remove some variables, and you can build a controlled, full-scale environment in which to test certain aspects of the project. Moving from simulation to hardware means putting in some of those variables, giving up much of that control, and not having a full-scale environment for testing.

The major variables that I'm working with include:

• Packet structure
• Object structure (in RF24* libs)
• Simultaneous transmissions
• Dropped packets
• Multi-platform compatibility

My C# simulator was just over 1500 LOC. This included the algorithms that would run on the nodes themselves as well as the topology generator and environment simulation code. The libraries with which I'd like to integrate total nearly 20k lines of code, and actually require more memory than the Arduino UNO has -- just 2k. After I get a bit more things working in the code, I'll need to trim down the size just to be able to run it on the Arduino at all. That's truly a difficult challenge, but it's not the one I'm working on just now.

First, there is the challenge of just sending a packet successfully. Now that I've ripped out much of the code from the original libraries, I'm trying to put my own in and make it work. There is a certain level of coupling between the layers I'd like to change (RF24Mesh, somewhat RF24Network) and the layers I don't, (RF24, RF24Ethernet). It's something like trying to swap the engine of a Toyota into the drivetrain of a Ford. Things don't line up, the controls don't work the same, and the hood won't close properly. These things can be fixed, but it won't be easy...at all.

Next, there is the issue of hardware. Hardware is weird, but fortunately some of the libraries TMRh20 has done take out some of the weirdness. As I modify those libraries and remove/rearrange various parts of them, the weirdness comes creeping in from everywhere. It's not trivial to send a packet, let alone pause in the algorithm just long enough to listen for responses to some request you've just made. Do you listen for a set delay time? No, because that's inefficient and makes the process slow. Do you wait till you hear *something* and then move on? What if another node needed to respond but took longer? Did you hear all of the responses you were supposed to hear? These questions plague the code implementation, and I'm only just learning the techniques to solve them.

A note on my project(s): I do these projects as a learning experience. All of them are designed to primarily teach me something I want to learn. Often they do that and then proceed to teach me some things I didn't know I needed to learn. This project is not designed to create a marketable product, nor is it guaranteed to produce a working prototype. The project ends when I've learned all I can from it, which sometimes may be when it works, and sometimes may be when I realize that I've made some critical mistake (usually caused by some misconception I held at the beginning of the project). All this to say, I'm new to the field and you're reading the logs of a learning-experience. Now, go off and do something educational :)