englund:
Sorry for spamming... I just managed to modify the ping-pong example to do what I wanted. Turns out the range is quite ok on these guys although some packets get lost. Is there a mechanism to auto re-transmit until successful or would I have to implement this myself by sending back an ACK packet (and re-transmit until I get that ACK)?
@englund
No problem. Nice to hear that you got it working. The current setting of the NRF24L01+ chip is auto-ack and max retransmission. But it is still possible that this is not enough and then the application layer needs to step in and issue a resend or consider the receiver "dead". There is a lot of noise on 2.4 GHz so there are bursts of noise that may exceed the retransmission limit.
A better protocol is needed. Right now this is a very raw communication channel. There is also some performance to be gained by using NRF24L01+'s ability to send a payload with the auto-ack message. This would work for sensor nodes that periodically push data. Messages "down-stream" could then be sent with the ack of the next data "up-stream".
englund:
It would be great if you could support wireless programming over nRF24L01+, is that something you would consider integrating into Cosa?
Yes, thats on the looong to-do-list. Any serious IoT/M2M framework will need to allow remote update of software. Before doing this I need to add more infra-structure for security. I have just started to add encryption algorithms (Vigenere and RC4). My intent is to modify one of the bootloaders so that it can use an encrypted IOStream or Socket as source. It would be difficult to get all this to fit in an ATtiny84. 8K program memory is not much.
Also I need to get a Cosa version of a W5100 driver in place. And obviously support for ATmega32U4/USB. It all adds up and it is soon back to my day job
Hum, that was kind of a spoiler on things to come.
Cheers and have fun().
BW Feel free to use the Issues handling on github for suggestions, bug reports, modifications, etc.