[Oberon] FPGA - nRF24L01 `RPI Net' server

Paul Reed paulreed at paddedcell.com
Sun Apr 29 00:25:04 CEST 2018

Hi Tomas,

> I am somehow led to believe I chase some bad timing loops...
> ...Not any wiser.

By now you have, I think, already achieved the equivalent of the most we
ask of our students in the time protocol example, and then some.  To go
beyond the reception of a simple regular broadcast message is indeed, as
you have found, very challenging.

What I'm a bit concerned about is that you are describing a lot about the
(assumed) operation of code, and very little about the specifics of the
operation of the chip.  A better understanding of the chip at the
low-level would, I think, allow you to verify more, and assume less.

For example, as described in section 7 of the datasheet, the nRF24L01
packet-transfer protocol in the chip (Nordic calls it "Enhanced
ShockBurst[TM]") uses error-checking (a configurable-length CRC) to verify
the packet contents, and drops the packet if the CRC does not match.

So you won't be dealing with corrupt data (or control information), only
missed packets - your "bogus length" is surely just data from later in the
transmission, and somehow you have missed the packet containing the first
32 bytes - a framing error at a higher level, you might say.

If you have the stamina (and it certainly seems you do) I would certainly
encourage you to continue, because you are sharpening some very general
skills on a very real-world problem!

If you haven't already, I would advise you to make a very detailed study
of section 9 of the datasheet, the register map.  There's lots of
interesting stuff here.  For example, register 8, OBSERVE_TX, will give
you a count of lost packets, ie packets transmitted but not acknowledged
by the receiver (from the transmitter's point of view - the ack might have
been sent but not received by the transmitter of course).  In a simple
test, this count should of course match the number of packets lost as
inferred from the software trace.

I hope you have by now dispensed with the library on the Pi and are
talking to the chip yourself, controlling every aspect of its programming.
 After all, you have been doing this on the Oberon side, so the library
offers little and is probably getting in the way of understanding - it may
have helped in the beginning but I'm guessing you won't really be sure of
some things unless you completely control them.  And you do need to be
sure. :)


More information about the Oberon mailing list