[Oberon] FPGA - nRF24L01 connection

[Jörg]

Tomas

You wrote you used setChannel(5), in the debug output it’s 0x55 however. Is that a left over from previous trials? Which channel do you want to use on both sides?

Jörg

> Am 12.04.2018 um 00:32 schrieb Paul Reed <paulreed at paddedcell.com>:
> 
> 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
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon