This is better, as if anyone allocated memory before, we will not use
that memory, and still use uninitalized memory..

Better describe how to hook things up..

Also, document all the commands, and the difference between the
immediate commands and the queue commands..

Provide a comment on how to address it..

Mark this as a Markdeep document..  If you hard link or copy README.md
this to an html file, it will reader it as a nice html document..

These will be integrated into the code shortly..

Before this, I was VERY frequently having to retry..  changing just
the gw improved things significantly, but changing it on both results
is no observable retries..  This is also the default that the example
apps in loramac uses..

Don't start up w/ the first four channels on...  We only want that
for the LED to let us know it's running...

This gets basic comms working and setunset working as well...  It
makes the LED blink!

Turns out that the base TimeoutError is different than the asyncio
version, and so we weren't actually retrying packets, just terminating
early...

eliminate the strobe code as it isn't used, this just pushes
packets back and forth..

be transmitted now.

This can now easily be expanded to support other projects as well..

both take a shared key as an argument...

the respondent arg (-r) takes an argument specifying the function to
call w/ the messages...  The form is: module_path[:name.of.func].  If
the name is not specified, func will be used.

this is more of a problem w/ the utility function being in lora
which loraserv imports...  if/when that happens this could be reverted..

This just makes sure things are a little tighter wrt protocol
compliance, ensuring that a corrupted initiator doesn't do bad
things..

This also adds a check to make sure that the allocated structure matches
the C code so that things won't break.

This breaks out the session state into it's own object... allowing a
common function to handle the state machine...

This also adds a new powerful testing tool.  It's a Synchronization
primitive that will ensure blocks of code run in the expected order,
and only run when the previous block has fully run...  This helps
ensure ordering between many tasks, to cause race conditions that
would otherwise be hard to cause..

are ignored, and it triggers a resent of the previous packet...

3-4 seconds to gather all this...  need to add a blinking light to this
so it's clear that it's still starting..

This is better than using RAM, as it keeps the state between power
cycles...