FWIW, here's some feedback. At the time of your writing, I didn't know enough to really comment.
tattema said:
I'm surprised that HopeRF don't supply these libraries :-(
In terms of setting expectations, I now think of HopeRF as taking the Semtech chip and making a module out of it. Period. At the end of the day, it's cheap enough and it does seem to work well. If you're vertically integrated, maybe you can do it better and/or make it cheaper. If so, then great, but at the moment they're the only ones actually selling such a thing that I'm aware of.
tattema said:
Implementation tips:
- In addition to the MISO, MOSI, CS, CLK pins for SPI, you'll need to map 5 INT pins to IO pins and a reset pin to the device. The implementation is such that it polls the pins rather than waits for interrupts so the INT pins can be wired to any available GPIO.
The conclusion I draw from reading various threads is that only one interrupt pin is typically needed. Generally, DIO0 is wired to D2 on the ATMEGA328P. That leaves one remaining external interrupt pin (D3) to be wired to whatever you want (e.g. a motion sensor or a leak detector) to wake a sleeping ATMEGA328P. If needed, you can remap the DIO pins using software. So, a total of 5 wires is all that's typically needed (not counting the antenna wire).
tattema said:
You'll notice a huge difference in performance. Firstly, you'll be able to sent huge packets without the 63/4 byte limitation (encryption engine limits still apply) imposed by the current JeeLAB and Motino implementations.
Secondly, the driver doesn't try to handle receive from within an interrupt.... once again poor design by Motino/JeeLABs. The detection of a preamble means you can reduce packet collisions.
Enjoy
There's been some recent discussion that long packets are more prone to getting lost. I'd be curious to know what the optimal length is if you have a lot of data to move (e.g. if you were doing OTA programming). For simple sensor stuff, I don't see a need for long packets. Do you?
I also think packet collisions are likely to be extremely rare. That's because with listen-mode in effect, your gateway can choose when to wake up a sensor using address select and request its output. So, the only possibility of a collision is with a sensor going off spontaneously, like a motion sensor or a leak sensor. The vast majority of the sensors (like temperature sensors, soil moisture sensors, light sensors, actuators, etc.) can be time multiplexed by the gateway, so it's only the spontaneous packets flying around that might collide. And for unplanned (spontaneously generated) packets, a mote can simply wait for an ACK and then re-transmit with a random Fibonacci backoff if it doesn't get the ACK. If you wanted to be extra conservative, you could also sample RSSI to check for clear air before starting Tx, and I imagine that would knock down the odds of collision even further. For packets requested by the gateway, if the gateway doesn't receive it, it will just re-request it. On top of all that, at 200kbps at 915Mhz (for example) you've got around 50 or so non-overlapping channels to choose from, so if collisions ever did become problematic, just use more channels! It would cost me only about $6 in parts to have a dedicated gateway fully monitor any given channel. I think I can afford that. Divide and conquer! In reality, I expect one channel will be all that's ever really needed for my simple needs, but it's nice to know that I have 50 additional channels available should I ever need them.
