RFM69 Python Library for Raspberry Pi with Duplex Gateway

[daenny]

It seemed appropriate to open a new Thread for this topic, after hijacking the 2.1 release topic.

etrombly:
I tested your latest updates to the Python RFM library with the Gateway code. Thanks for the awesome work so far. This version it seems very usable to me!
Below a first "experience report"

My sender is an Arduino Uno 5V running your latest "Relay Node ino" but I removed all extra devices such that it is only transmitting version name, RSSI, uptime and txInterval. I set those devices to tx_periodically to have some periodic sending. 
The arduino is connected to the RFM69HW with voltage dividers as described in my other topic, but the power level is set now to 20. 

My experiences so far:
Raspberry Pi receives almost 100% of the messages, but sends out ACK only in about 95% of the messages. 

Especially if I publish a read request via MQTT.fx or commandline to any of the devices, i.e home/rfm_gw/sb/node02/dev00 "READ", the answer is received and processed at the raspberry pi (since I can see a new message coming in on the subscription), but in the Serial Monitor of my sender I get "no connection". So no ACK is received on the Arduino side for the last message. 

That behaviour is reproduced reliably. So it seems if there is little delay between the last send of the raspberry pi to the arduino and the reply, the ACK does not get received at the arduino. It does seem to get send though, since I did a print statement every time I send an ACK in the pigateway. 


Regarding the wrapping of the C Code (I used abouillot's piGateway port): I did some testing with SWIG. I got it to compile and could import the module. However there are some issues with the typedefs and volatiles. So I could not get it to send anything, the buffer for sending is a const void* which does not get wrapped well/easily... If I have more time, I will look deeper into that. Although the python library seems to work a lot better now, so I might just stick to that

[etrombly]

Awesome, sorry it took me so long to respond. I was on vacation back to the states. I'm assuming for now the problem with receiving the acks is that the python version isn't switching from tx to rx and the other way around fast enough. It could be something different though, I'm just making an educated guess.

The first option I've been contemplating is adding a sequence number to the packet format, which would also cut down on the number of retransmissions. You can send one packet and wait for a response. Currently it sends out a couple. The downside to this is you would have to maintain a message buffer, which would increase memory usage. Arduinos are pretty tight on memory as it is.

Another option would be to make a C version of the library with a python wrapper. I've only lightly researched this, and it seems like a little bit of a hassle. Probably the easiest solution in the long run though.

Any recommendations are welcome.

[computourist]

Did you consider increasing the time allowed to receive an ACK ?

It is presently set at 50 msec in my sketch:

#define ACK_TIME 50

[etrombly]

I've tried messing around with various delay values in different parts of the code. I was assuming the node was receiving the packet and returning the ack before the pi was able to switch to rx mode. I tried introducing a delay before it transmits node transmits the ack, but when you start playing around with thing like that you start getting issues because the library expects the next packet received to be the ack from the message it just sent. If it receives a different message it both discards the valid message and says it did not receive the ack...that's why I was considering a sequence number.