FPGA - nRF24L01 connection
Hi, I have two Nordic wireless modules. I have wired one of them to my RPI, see photo, the other should plug into Pepino Oberon FPGA board. I have also compiled a gateway from `MySensors' git repo. Running the gateway gives following. ... Protocol version - 1.4 Created PTY '/dev/pts/2' Gateway tty: /dev/ttyMySensorsGateway ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 8 Mhz ================ NRF Configuration ================ ... When I use a serial cable over USB (FTDI), I just access serial as /dev/ttyUSB1 device, and I use PCLink at Oberon end. But, how do I exchange data with Oberon over wireless, what is the gateway device, do I need to modify RF24.Mod? Many thanks in advance. -- Tomas Kral <thomas.kral@email.cz>
In ProjectOberon - the module SCC.Mod is the wireless driver. - the module Net.Mod implements a simple file transfer protocol. Jörg -----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Tomas Kral Sent: Thursday, April 05, 2018 3:11 PM To: Oberon@lists.inf.ethz.ch Subject: [Oberon] FPGA - nRF24L01 connection Hi, I have two Nordic wireless modules. I have wired one of them to my RPI, see photo, the other should plug into Pepino Oberon FPGA board. I have also compiled a gateway from `MySensors' git repo. Running the gateway gives following. ... Protocol version - 1.4 Created PTY '/dev/pts/2' Gateway tty: /dev/ttyMySensorsGateway ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 8 Mhz ================ NRF Configuration ================ ... When I use a serial cable over USB (FTDI), I just access serial as /dev/ttyUSB1 device, and I use PCLink at Oberon end. But, how do I exchange data with Oberon over wireless, what is the gateway device, do I need to modify RF24.Mod? Many thanks in advance. -- Tomas Kral <thomas.kral@email.cz>
On Thu, 5 Apr 2018 15:23:23 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
- the module SCC.Mod is the wireless driver. - the module Net.Mod implements a simple file transfer
Hi Joerg, Thank you, now studying `nRF24L01' specs, as once encouraged by Paul Reed. Still with little understanding. I wish to make a simple echo test, between Oberon and RPI over wireless. ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 8 Mhz The gateway seems transmitting at 8Mhz channel as above, correct? What frequency channel is used by Oberon? Many thanks. -- Tomas Kral <thomas.kral@email.cz>
Please study Net.Start You will see that the channel is selected according to the HW switches you set. If you want to set it to a fixed channel, you have to change the initialization in Net.Start br Jörg -----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Tomas Kral Sent: Friday, April 06, 2018 2:41 PM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] FPGA - nRF24L01 connection On Thu, 5 Apr 2018 15:23:23 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
- the module SCC.Mod is the wireless driver. - the module Net.Mod implements a simple file transfer
Hi Joerg, Thank you, now studying `nRF24L01' specs, as once encouraged by Paul Reed. Still with little understanding. I wish to make a simple echo test, between Oberon and RPI over wireless. ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 8 Mhz The gateway seems transmitting at 8Mhz channel as above, correct? What frequency channel is used by Oberon? Many thanks. -- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Sorry, I meant SCC.Start ☹ Stupid me! Jörg -----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Jörg Sent: Friday, April 06, 2018 2:47 PM To: 'ETH Oberon and related systems' <oberon@lists.inf.ethz.ch> Subject: Re: [Oberon] FPGA - nRF24L01 connection Please study Net.Start You will see that the channel is selected according to the HW switches you set. If you want to set it to a fixed channel, you have to change the initialization in Net.Start br Jörg -----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Tomas Kral Sent: Friday, April 06, 2018 2:41 PM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] FPGA - nRF24L01 connection On Thu, 5 Apr 2018 15:23:23 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
- the module SCC.Mod is the wireless driver. - the module Net.Mod implements a simple file transfer
Hi Joerg, Thank you, now studying `nRF24L01' specs, as once encouraged by Paul Reed. Still with little understanding. I wish to make a simple echo test, between Oberon and RPI over wireless. ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 8 Mhz The gateway seems transmitting at 8Mhz channel as above, correct? What frequency channel is used by Oberon? Many thanks. -- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Fri, 6 Apr 2018 14:47:20 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
SCC.Start Yes, I see, With my current SW setting I got channel `5'. I changed RF_CH from 76 (default) to 5 and recompiled the gateway. These parameters are now reported.
================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xa8a8e1fc00 0xa8a8e1fc00 RX_ADDR_P2-5 = 0xff 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x20 0x20 0x20 0x00 0x00 0x00 EN_AA = 0x3b EN_RXADDR = 0x06 RF_CH = 0x05 RF_SETUP = 0x23 CONFIG = 0x0e DYNPD/FEATURE = 0x3f 0x06 Data Rate = 250KBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_LOW I wonder what other parameters I need to change to match Oberon SCC.Mod? Many thanks -- Tomas Kral <thomas.kral@email.cz>
Hi Tomas You sure find out whats wrong, after you read 1) the nRF’s data sheet http://www.nordicsemi.com/eng/nordic/content_download/2726/34069/file/nRF24L... 2) understand what parameters SCC.Start sets to initialize the chip 3) carefully compare these values with the chip initialization your gateway does. Jörg
Am 06.04.2018 um 20:22 schrieb Tomas Kral <thomas.kral@email.cz>:
On Fri, 6 Apr 2018 14:47:20 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
SCC.Start Yes, I see, With my current SW setting I got channel `5'. I changed RF_CH from 76 (default) to 5 and recompiled the gateway. These parameters are now reported.
================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xa8a8e1fc00 0xa8a8e1fc00 RX_ADDR_P2-5 = 0xff 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x20 0x20 0x20 0x00 0x00 0x00 EN_AA = 0x3b EN_RXADDR = 0x06 RF_CH = 0x05 RF_SETUP = 0x23 CONFIG = 0x0e DYNPD/FEATURE = 0x3f 0x06 Data Rate = 250KBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_LOW
I wonder what other parameters I need to change to match Oberon SCC.Mod?
Many thanks
-- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Just curious. Would it be possible to run Oberon on this retro computer? https://gigatron.io/ Introduction https://gigatron.io/?page_id=574 Greets, Frans-Pieter Vonck
Do you mean a) the Oberon language or b) the Oberon system? Oberon language obvoiusly needs an Oberon compiler (backend) generating the assembler code for this TTL vCPU. If you did the effort to build an Oberon compiler for it, you could start porting the Oberon system. I would say: will be rather difficult as the screen is only 160x120 pixels... The short answer: NO br Jörg
Am 07.04.2018 um 10:08 schrieb Frans-Pieter Vonck <fp@vonck.nl>:
Just curious.
Would it be possible to run Oberon on this retro computer? https://gigatron.io/
Introduction https://gigatron.io/?page_id=574
Greets, Frans-Pieter Vonck
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Frans-Pieter Vonck Sent: Saturday, 7 April 2018 5:38 PM To: ETH Oberon and related systems Subject: [Oberon] oberon on ttl - gigatron?
Just curious.
Would it be possible to run Oberon on this retro computer? https://gigatron.io/
Introduction https://gigatron.io/?page_id=574
No - but here are a couple of suggestions for feasible Oberon-based projects that involve this machine: 1. Write a cross-assembler using Oberon that targets the gigatron's instruction set. 2. Write a cross-compiler for the language PICL (or a variant of it) in Oberon that generates machine code for the gigatron. The PICL documentation and compiler sources are here: https://www.inf.ethz.ch/personal/wirth/PICL/index.html Regards, Chris Burrows CFB Software http://www.astrobe.com/RISC5
Thanks for the reply, I've read the 'A Microcontroller System for Experimentation' with much interest, back in 2008. There is a lot of tacit knowledge hidden behind Wirths text. In order actually build this board you need someone to help you in a workshop or hands-on course. I saw that there are several hackerspaces in Zurich. I Wonder if Oberon is still spoken in these places. Any idea who is practising oberon in the hackers/makers community? Greets, Frans-Pieter hris Burrows schreef op 2018-04-08 01:15:
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Frans-Pieter Vonck Sent: Saturday, 7 April 2018 5:38 PM To: ETH Oberon and related systems Subject: [Oberon] oberon on ttl - gigatron?
Just curious.
Would it be possible to run Oberon on this retro computer? https://gigatron.io/
Introduction https://gigatron.io/?page_id=574
No - but here are a couple of suggestions for feasible Oberon-based projects that involve this machine:
1. Write a cross-assembler using Oberon that targets the gigatron's instruction set.
2. Write a cross-compiler for the language PICL (or a variant of it) in Oberon that generates machine code for the gigatron. The PICL documentation and compiler sources are here:
https://www.inf.ethz.ch/personal/wirth/PICL/index.html
Regards, Chris Burrows
CFB Software http://www.astrobe.com/RISC5
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Hi Tomas I was wondering why your gateway used RF_CH = 76 as default. SCC.Mod does not know nor care whether you use 802.11 WiFi in parallel. If there is WiFi in your area, RF_CH = 5 will interfere with WiFi channel 1. To not interfere with WiFi you should set your RF_CH frequency to something higher to be beyond the WiFi spectrum. In the US, RF_CH=76 is a good choice as it is beyond Wifi channel 11. In Europe, it is possible to use up to Wifi channel 13, so RF_CH >= 85 would be a good choice. If you want SCC.Mod not to interfere with WiFi, you should set your switches so that n DIV 4 MOD 10H * 10 + 5 >= 85. br Jörg Von: Jörg Straube <joerg.straube@iaeth.ch> Datum: Samstag, 7. April 2018 um 00:44 An: ETH Oberon and related systems <oberon@lists.inf.ethz.ch> Betreff: Re: [Oberon] FPGA - nRF24L01 connection Hi Tomas You sure find out whats wrong, after you read 1) the nRF’s data sheet http://www.nordicsemi.com/eng/nordic/content_download/2726/34069/file/nRF24L... 2) understand what parameters SCC.Start sets to initialize the chip 3) carefully compare these values with the chip initialization your gateway does. Jörg Am 06.04.2018 um 20:22 schrieb Tomas Kral <thomas.kral@email.cz>: On Fri, 6 Apr 2018 14:47:20 +0200 Jörg <joerg.straube@iaeth.ch> wrote: SCC.Start Yes, I see, With my current SW setting I got channel `5'. I changed RF_CH from 76 (default) to 5 and recompiled the gateway. These parameters are now reported. ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xa8a8e1fc00 0xa8a8e1fc00 RX_ADDR_P2-5 = 0xff 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x20 0x20 0x20 0x00 0x00 0x00 EN_AA = 0x3b EN_RXADDR = 0x06 RF_CH = 0x05 RF_SETUP = 0x23 CONFIG = 0x0e DYNPD/FEATURE = 0x3f 0x06 Data Rate = 250KBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_LOW I wonder what other parameters I need to change to match Oberon SCC.Mod? Many thanks -- Tomas Kral <thomas.kral@email.cz> -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Sat, 7 Apr 2018 12:17:28 +0200 Jörg <joerg.straube@iaeth.ch> wrote:
SCC.Mod does not know nor care whether you use 802.11 WiFi in parallel.
If there is WiFi in your area, RF_CH = 5 will interfere with WiFi channel 1.
Hi Joerg, Reading Nordic document you suggested, I realised that channel is actually a frequency step from the base of 2400 MHz. I will experiment with values 76, and 85. Many thanks. -- Tomas Kral <thomas.kral@email.cz>
Hi, In `SCC.Mod', what is the meaning of the procedure `Available()' ? On my system it returns '0'. Many thanks. -- Tomas Kral <thomas.kral@email.cz>
Hi, I think I have done, best I could to set parameters to match `SCC.Mod', I should think. I now use `RF24' linux(RPI) generic examples, as `MySensors' gateway abstracts from it and uses specific sensor messages, different to Oberon. 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!!! `SCC.Mod' never sets RX_ADDR_P0,1 for pipes 0,1 nor TX_ADDR, which I do not understand??? In the RPI `RF24' example code, I set pipe 0,1 addresses to reset defaults. const uint64_t pipes[2] = { 0xE7E7E7E7E7LL, 0xC2C2C2C2C2LL }; Also I set these to match `SCC.Mod' // Setup and configure rf radio radio.begin(); radio.setChannel(5); radio.maskIRQ(1,1,1); // optionally, increase the delay between retries & # of retries radio.setRetries(50,50); // Dump the configuration of the rf unit for debugging radio.printDetails(); ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 4 Mhz ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xe7e7e7e7e7 0xc2c2c2c2c2 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00 EN_AA = 0x3f EN_RXADDR = 0x02 RF_CH = 0x05 RF_SETUP = 0x07 CONFIG = 0x7e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_MAX ************ Role Setup *********** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit)
I need help, as I have very little understanding of it. Many thanks in advance. -- Tomas Kral <thomas.kral@email.cz>
Hi Tomas, I'm wasting a huge amount of time trying to trace your steps. No doubt you're pretty frustrated too. Which RF24 library on the Pi are you using, and how have you installed it? Cheers, Paul
On Wed, 11 Apr 2018 13:54:31 +0100 Paul Reed <paulreed@paddedcell.com> wrote:
Which RF24 library on the Pi are you using, and how have you installed it?
Hi Paul, Sorry for being such nuisance, I did not mean to upset you :-) I now use `RF24' linux(RPI) generic examples, as `MySensors' gateway abstracts from it and uses specific sensor messages, different to Oberon. Compiled lib from https://github.com/TMRh20/RF24.git. 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. 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!!! 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 }; Also I set these to match `SCC.Mod' // Setup and configure rf radio radio.begin(); radio.setChannel(5); radio.maskIRQ(1,1,1); // optionally, increase the delay between retries & # of retries radio.setRetries(50,50); // Dump the configuration of the rf unit for debugging radio.printDetails(); My current RPI config below. ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 4 Mhz ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xe7e7e7e7e7 0xc2c2c2c2c2 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0xe7e7e7e7e7 RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00 EN_AA = 0x3f EN_RXADDR = 0x02 RF_CH = 0x55 RF_SETUP = 0x07 CONFIG = 0x7e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_MAX Many thanks for reading this. -- Tomas Kral <thomas.kral@email.c
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
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@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@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Thu, 12 Apr 2018 09:20:09 +0300 Jörg <joerg.straube@iaeth.ch> wrote:
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?
Hi, I tried both 0x05 and 0x55, making sure both ends use the same value. -- Tomas Kral <thomas.kral@email.cz>
On Wed, 11 Apr 2018 22:32:46 +0100 Paul Reed <paulreed@paddedcell.com> wrote:
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.
Hi Paul, Thank you for your advice. May I just ask which `RF24 lib' you suggest using on RPI, the one you have best results with network time server? Many thanks. -- Tomas Kral <thomas.kral@email.cz>
participants (6)
-
Chris Burrows -
Frans-Pieter Vonck -
Jörg -
Jörg Straube -
Paul Reed -
Tomas Kral