Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Troubles getting comms between rbpi & arduino #1

Closed
arrie opened this issue Jan 15, 2014 · 7 comments
Closed

Troubles getting comms between rbpi & arduino #1

arrie opened this issue Jan 15, 2014 · 7 comments

Comments

@arrie
Copy link

arrie commented Jan 15, 2014

Hi Nathan,

First off, thank you for the time and effort you put into these projects - really appreciated by somebody as inexperienced as me. I'm extremely new to the world of programming for hardware and still learning, so please bear with me.

In short: I'm trying to get comms from a rbpi to an arduino via a node restfull service. I'm currently testing using express with node 0.10.2. I have confirmed that the rbpi can indeed communicate with the arduino by running stanleyseow's pingtest - so as far as I know the actual hardware seems to function as expected. In all the tests stanleyseow's ping app is loaded on the arduino.

I've tried using this repo (node-nrf) in order to get things going, but with no luck thus far. I installed all the dependencies via sudo npm install. The app seems to runs fine, but with either option (ping/pong) when running node test.js there seems to be no comms sent or received from the arduino when I look at the serial monitor on the arduino. I know this is a bit vague, but i'm not sure how one would go about debugging a problem like this? My first thought was that perhaps it's got something to do with permissions, or perhaps that for this project the nrf module needs to be hooked up differently?

I've also tried using your other project (node-rf24) where you created a node wrapper for stanleyseow's implementation. I fixed the compile error for node 0.10.x by adding the needed type cast 'uv_after_work_cb' to the 'uv_queue_work' methods where applicable, but unfortunately ran into problems here as well. Everything compiled fine, and node-gyp successfully compiled the node module, but it seems that when I try and do any call, I get a segmentation fault, after-which the service simply stops. I've seen the segmentation fault before when running the RF24 pingtest example without elevated permissions. I have tried running node as root - but this seems to have no effect.

I was hoping you would be able to provide me with some insight or possible solutions for my problems in order to get going - as the project i'm working on only needs really simple comms just to get started with the rest layer in order to do a poc. Hope to hear back from you.

Kind Regards,
Armand.

@arrie
Copy link
Author

arrie commented Jan 15, 2014

Hi Nathan,

In an attempt to provide you with some more information on my current scenario, i've flashed again and started from scratch. I loaded the arduino with the irq ping sample(learn something new every day). Also rewired the rbpi according to this link: (https://gist.github.com/natevw/5789019)

Results are closer it seems, below the feedback from the 2 units:

on the arduino(ping)
Now sending 75146
Now sending 76147
Now sending 77148
Now sending 78148

on the rbpi(pong)
PONG back

Then switched roles around with the following result

on the arduino:(pong)
RF24/examples/pingpair_irq/
ROLE: Receiver
STATUS = 0xff RX_DR=1 TX_DS=1 MAX_RT=1 RX_P_NO=7 TX_FULL=1
RX_ADDR_P0-1 = 0xffffffffff
RX_PW_P0-6

on the rbpi(ping)
PING out
Piping out 0
Piping out 1
......
Piping out 16

This time I was actually able to see an error begin thrown:
events.js:72
thow er; // Unhandled 'error' event
^
Error: Packet timeout, transmit queue flushed.
at index.js:340:28
at index.js:79:25

Here's where i'm currently stuck. Think i'm very close - but obviously still missing something. Any ideas?

Kind Regards,
Armand.

@natevw
Copy link
Owner

natevw commented Jan 15, 2014

Thanks for the detailed report! Could you paste in the result of a .printDetails() call?

One thing, if you've also been using the C++ version, it handles the chip select pin wrong in a way that messes up correct usage. Every time after you run any of the code in https://github.com/stanleyseow/RF24 you will need to:

sudo modprobe -r spi_bcm2708
sudo modprobe spi_bcm2708

…before the node version will work. This basically "reboots" the SPI kernel driver without needing to reboot the whole Pi. See this thread for a longer explanation.

You may or may not (i.e., probably do) need sudo, I usually DO run with that because I've taken no steps to allow other users access, but seems to occasionally work without it — it all depends on the permissions of the underlying /dev entries which I haven't really watched closely yet.

@natevw
Copy link
Owner

natevw commented Jan 15, 2014

Also you say:

on the arduino:(pong)
RF24/examples/pingpair_irq/
ROLE: Receiver
STATUS = 0xff RX_DR=1 TX_DS=1 MAX_RT=1 RX_P_NO=7 TX_FULL=1
RX_ADDR_P0-1 = 0xffffffffff
RX_PW_P0-6

This looks like things are not working properly on the Arduino either: everything is reading back as 0xFFs! This should not be the case if all your connections are hooked up correctly.

@arrie
Copy link
Author

arrie commented Jan 16, 2014

Hi Nathan,

So i rewired and tested the arduino connections and code by setting two of them up with the one grounded via the role pin on pin 7. My wiring for the arduinos are as follows:

nRF Arduino
1 (GND) GND
2 (VCC) 3.3V
3 (CE) 9
4 (CSN) 10
5 (SCK) 13
6 (MOSI) 11
7 (MISO) 12
8 (IRQ) 2

And here's my result:

Sender:

Port open

RF24/examples/pingpair_irq/
ROLE: Sender
STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    Now sending 1090
Send:OK
Ack:0
Now sending 2091
Now sending 3091
Send:OK
Ack:1
Now sending 4092
Now sending 5093
Send:OK
Ack:2
Now sending 6093
Now sending 7095
Send:OK
Port closed

Receiver:

Port open

RF24/examples/pingpair_irq/
ROLE: Receiver
STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1         = nRF24L01+
CRC Length   = 16 bits
PA Power     = PA_HIGH
Got payload 2091
Ack Payload:Sent
Got payload 3091
Ack Payload:Sent
Got payload 4092
Port closed

The comms between the two arduinos seems to be working correctly. So next i'm on to the rbpi... I've made the connections as mentioned on the gist here: [https://gist.github.com/natevw/5789019] like so:

nRF Rbpi
1 (GND) 20
2 (VCC) 17
3 (CE) 18
4 (CSN) 24
5 (SCK) 23
6 (MOSI) 19
7 (MISO) 21
8 (IRQ) 22

First i tried the Arduino as the sender and rbpi as receiver:

Ardruino output:

RF24/examples/pingpair_irq/
ROLE: Sender
STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    Send:Failed
Now sending 1090
Send:Failed
Now sending 2091
Send:Failed
...
Port closed

Rbpi output:

PONG back

Nothing was traced on the rbpi for this setup, so swopped roles around with the Arduino as the receiver:

Ardruino output:

RF24/examples/pingpair_irq/
ROLE: Receiver
STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    = 0x0f
DYNPD/FEATURE

Rbpi output:

PING out
Piping out 0
Piping out 1
Piping out 2
Piping out 3
Piping out 4
Piping out 5
Piping out 6
Piping out 7
Piping out 8
Piping out 9
Piping out 10
Piping out 11
Piping out 12
Piping out 13
Piping out 14
Piping out 15
Piping out 16

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Packet timeout, transmit queue flushed.
    at /home/pi/projects/node-nrf/index.js:340:28
    at /home/pi/projects/node-nrf/index.js:79:25

This time a little more descriptive. The result of .printDetails() like you asked is the following:

SPI device:      /dev/spidev0.0
CE GPIO:         24
IRQ GPIO:        25
STATUS:          0xe RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
PING out
RX_ADDR_P0–1:    0xf0f0f0f0e1 0xf0f0f0f0d2
RX_ADDR_P2–5:    0xc3 0xc4 0xc5 0xc6
TX_ADDR:         0xf0f0f0f0e1
RX_PW_P0–5:      0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:           0x3f
EN_RXADDR:       0x03
RF_CH:           0x4c
RF_SETUP:        0x07
CONFIG:          0x0e
DYNPD/FEATURE:   0x03 0x07
Data Rate:       1Mbps
Model:           nRF24L01+
CRC Length:      16 bits
PA Power:        PA_MAX

From what i could gather it seems like the code for the arduino is only refering to one pipe to do all comms, whereas the node app has got one for tx and one for rx - my absolute noobness is telling me that this might also cause and issue?

Thanks again
Armand

@arrie
Copy link
Author

arrie commented Jan 16, 2014

Hi again,

You're going to hate me for this one, but my "noob-sense" was correct it seems. I was loading the incorrect sketch on the arduino. After correcting this it seems to work fine, with only one catch. When you're trying to transmit - the receiver has to be ready, otherwise it raises that exception from node's side (same as above). Is this expected behaviour?

Example below node is transmitting, until i power down the arduino - and then the exception occurs.

Piping out 1297
Piping out 1298
Piping out 1299
Piping out 1300
Piping out 1301
Piping out 1302
Piping out 1303
Piping out 1304
Piping out 1305
Piping out 1306
Piping out 1307
Piping out 1308
Piping out 1309
Piping out 1310
Piping out 1311
Piping out 1312
Got response back: 1295
Got response back: 1296
Got response back: 1297
Got response back: 1298
Got response back: 1299
Got response back: 1300
Got response back: 1301
Got response back: 1302
Got response back: 1303
Got response back: 1304
Got response back: 1305
Got response back: 1306
Got response back: 1307

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Packet timeout, transmit queue flushed.
    at /home/pi/projects/node-nrf/index.js:340:28
    at /home/pi/projects/node-nrf/index.js:79:25

Armand.

@natevw
Copy link
Owner

natevw commented Jan 16, 2014

Awesome, looks like you've got it working! The "unhandled error event" is just that — the current test.js code does not detect the error and reconnect the pipes, so I just let it crash. In a real app you'd want to handle pipe errors.

@natevw
Copy link
Owner

natevw commented Jan 22, 2014

Closing this since it looks like you've got it working. Let me know if you have any further questions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants