[Oberon] FPGA - nRF24L01 connection

[Paul Reed]

Hi Tomas,

> Sorry for being such nuisance, I did not mean to upset you :-)

Don't worry, I didn't mean you wasted my time - I meant that debugging
poorly-documented, badly written, over-complicated code is a hugely
time-wasting activity (unless you enjoy it I suppose).

I'm really happy to help if I can, but please stop cc-ing me in your
emails, just send to the mailing list - thanks.


> I now use `RF24' linux(RPI) generic
> examples, as `MySensors' gateway abstracts from it and uses specific
> sensor messages, different to Oberon.

Right, I wasted a lot of time with MySensors and gave up, before I wasted
a lot of time with RF24.  And people who know me can testify that I don't
give up easily. :(


> Compiled lib from  https://github.com/TMRh20/RF24.git.

This library is a bit weird: the documentation is not in the README.md
like most github projects, and the documentation suggests to download a
.zip, not clone the github code.  And the install.sh script is very
misleading.  But then it suggests a manual install method which does clone
the repo, and that's the only way I got it working anyway.  Sigh.


> I have tried two configurations with drivers RPi(default) and (SPIDEV)
> --driver=[SPIDEV|MRAA|RPi|LittleWire]
> They seem both working, at least I can read/write NRF registers.

But both seem to be a bit dodgy on my hardware (RPi-B) and sometimes mess
it up for any further work with the nRF modules without a power-cycle.  As
you know, I have my own timeserver written in Oberon for the ETH class,
which uses the linux SPI device spidev, and it sometimes doesn't work if
I've used the RF24 library. (The first thing my program does is display
the nRF registers, which is why it was frustrating that the RF24 library
messed it up.)


> I have coded simple ping/pong procedures in Oberon, and I run similar
> in c++ on RPI.
> It should send payloads with header back and forth, but still nothing
> received at either end!!!

There is a great deal to get right here, you really need to know exactly
how these chips work unless you get very lucky.  Hence a thorough
understanding of the datasheet is a must.  At 78 pages it's a lot shorter
than most datasheets these days, yet it's very comprehensive (without
repeating itself).


> I realised `SCC.Mod' makes use of default RX/TX addresses, and
> I therefore set pipe 0,1 addresses to reset defaults.
>
> const uint64_t pipes[2] = { 0xE7E7E7E7E7LL, 0xC2C2C2C2C2LL };
...

You sent this code before.  But you don't say how these constants are
used.  When posting code please make it short but complete if you can.


> ================ SPI Configuration ================
> CSN Pin  	 = CE0 (PI Hardware Driven)
...

These are interpretations of the register values, but I would stick to the
actual values and refer to the datasheet for proper interpretation.

Please consider taking the approach I suggested before, which follows the
exercise we do in the class.

Broadly speaking, in this context, this means setting up the RF24 program
on the Pi to blindly transmit - the gettingstarted ping out example will
do here, and for simplicity keep everything at defaults - and then
experiment with the Oberon end to try to receive something.

Note that the gettingstarted diagnostic output doesn't seem to be right
the first time - you need to run it twice to see how it programmed the
registers after it printed them.  Grr.

Since a lot of parameters need to be correct for proper two-way
communication, first simply try to detect a carrier signal in Oberon by
scanning register 9 (Received Power Detector) bit 0 (see the datasheet and
the class notes).

Once you've detected a carrier signal on a particular channel when the
RF24 program is running, you could change the RF24 channel to be sure that
it's the RF24 transmissions you're receiving.

Sweeping through all the channels checking for a carrier is the basis of a
simple spectrum analyser, and it's the first program I wrote for these
modules because you only need one module. :)

I hope that helps a bit, please let us know how you get on.

Cheers,
Paul