Can NRF24L01 be used with autoack in micropython?

[mogplus88]

I would like to use a pair of NRF24L01s (attached to Picos) as a master/slave pair, (for an R/C model application.) What I would like to do is access the autoack payload (as detailed in the spec sheet) for the receiver to send back one or two bytes. One for RSSI (although I haven't been able to find anything in the spec sheet about that), and the other a randomly generated number between 1 and 82.
My cunning plan is to implement a frequency hopping algorithm by getting the receiver to generate the next channel it wants to receive on and sending that to the transmitter. The transmitter will then send the next packet on that channel and wait for the ack with the next channel to use. The 1 to 82 limitation is because these are the only channels allowed to be used for applications such as this here in the land of Oz. UK too I believe. Channels 83 to 125 are reserved for something else apparently.
Is there a way to implement this kind of functionality with micropython?

[peterhinch]

Given that the driver is entirely written in Python there is no reason why you shouldn't add functionality to it.

You'd need some way of dealing with missing acks otherwise both ends might end up on different channels. Radio communications are never perfect...

[mogplus88]

@peterhinch thanks for the advice. I have looked at nrf24l01.py, and have understood some of it. the register manipulation I'm working through, but some of the tricky stuff ORing things with other things and ~ other things is way above my paygrade. I've started studying the spec sheet, and trying to learn how acks work. Hopefully, with the help of the examples in the driver I'll be able to get something happening. Should keep me busy for a while.
I've thought about the missing ack problem. The easiest (though probably not best) way it seems to me is if the tx doesn't get an ack within a set time it should switch to a predefined channel (say 44) and keep transmitting until it gets an ack. If the rx doesn't receive a packet on the channel it's expecting within a set time, it too should switch to channel 44. Hopefully communication is reestablished and hopping reinstated. If not, then the model receiver (not the nrf24l01 module) has to switch to failsafe mode. Standard procedure for R/C models. For an aircraft, usually low throttle and a gentle turn. With luck the crash won't cause too much damage, and hopefully it won't hit anything important.
;-)

[mogplus88]

Actually, one other thing that perhaps you could clear up for me.
In a lot of the examples on the net, a data rate of 250kbps is mentioned. This would be more than enough for my application. However I have found two versions of the spec sheet, and only one mentions 250kbps. It is version 1.6 and the latest update was in March 2009. The other version doesn't have a version number in the title, but the file name contains "V2.0", so presumably is Version 2.0. However, the last update for it is July 2007, and "250kbps" is not mentioned in the document. So, which one should I believe? The latter one is the one that's provided on the Sparkfun site BTW. The other one I found here. https://infocenter.nordicsemi.com/pdf/nRF24LE1_PS_v1.6.pdf

[mogplus88]

I think I discovered the problem, the other version of the doc I found is for an NRF24L'E'1, not an NRF24L'0'1. Biiiig, difference. Apologies for wasting your time.
:-\