Cannot open 2 RX pipes

[HasAndries]

Hi Nathan,

I'm trying to open 2 RX pipes at the same time. When I open the 2nd RX pipe, the 1st pipe becomes unresponsive and no longer emits the 'data' event. Here's kinda what I'm doing:

var radio = NRF24.connect(config.spiDev, config.pinCe, config.pinIrq);
radio.channel(config.channel).transmitPower('PA_MAX').dataRate(config.dataRate).crcBytes(config.crcBytes).autoRetransmit({count: config.retryCount, delay: config.retryDelay});
radio.begin(function () {
inbound.broadcast = radio.openPipe('rx', config.broadcastAddress);
inbound.broadcast.on('data', function (data) {
  console.log(['BROADCAST>>', JSON.stringify(data)].join(''));
});
inbound.broadcast.on('error', function (err) {
  console.log(['BROADCAST ERROR>>', err].join(''));
});

inbound.command = radio.openPipe('rx', config.commandAddress);
inbound.command.on('data', function (data) {
  console.log(['COMMAND>>', JSON.stringify(data)].join(''));
});
inbound.command.on('error', function (err) {
  console.log(['COMMAND ERROR>>', err].join(''));
});

In this example, the inbound.broadcast pipe dies. Could you please point out if I'm doing something wrong, or is there a trick to getting 2 RX pipes active at the same time?

Thanks, Andries

[natevw]

Thanks for filing this. I will try look into it soon — it should work but there is still some debugging to do [especially] with mixed/multiple TX and RX streams.

One important question: how many bytes each are config.broadcastAddress and config.commandAddress? Sorry the documentation for this is missing (I'll start it here ;-) but you may have better results if the second is only one byte.

Basically the nRF has six "pipes" for listening:

• 0 — up to 5 byte address, but also used for TX ack receipt
• 1 — up to 5 byte address
• 2–5 — may differ only in last byte from pipe one (pass just the final byte to node-nrf)

The way node-nrf handles these is by assigning the first 3/4/5-byte address to pipe one, then crossing its fingers and hoping the next ones are all single bytes, then finally if you really must use all six pipes can assign a second full-width address to pipe zero. But when this happens it has to constantly swap in/out if you do any TX (beyond just writing ACK payloads to an RX pipe) and I'm afraid I haven't even exercised all that logic yet.

Long story short: If you're passing two full-width addresses, the second will end up using pipe zero which may have extra lingering bugs. (This is still beta, and I've been busy with porting the current progress to a second platform. But I'll try look into this soon…please let me know if you figure anything out too!)

[HasAndries]

Hi Nathan,

I first tried with two 5 bytes addresses, and investigated the code when it didn't work. I figured, like you say, that I need to pass single byte addresses after the 1st address. In my example, config.broadcastAddress=0xF0F0F0F0F0 and config.commandAddress=0xF1. Maybe my address values are invalid?

Thanks for your help. Edit: I've also tried to pass in a Buffer like so:

var commandAddress = new Buffer(('0'+config.commandAddress.toString(16)).substr(-2), 'hex');
inbound.command = radio.openPipe('rx', commandAddress);

[natevw]

The addressing can matter just for optimizing reception/lost packets but what you describe sounds probably just a bug in my code. (Sorry I haven't looked into it yet, have a client who just put me in charge of a deliverable he'd needed literally last week so this might be a few days yet.)

Both hex numbers and buffers should work, if not that's also a bug. The first step to debugging might be to either set nrf._debug = true on your instance and/or nrf.printDetails() once it stops working. This will [respectively] show what the library is doing, and, log the "ending" state of the radio config/status registers.

[side note, leaving this link here for my own future reference because it explains in another context the same the pipe0 problem this library deals with: http://maniacalbits.blogspot.com/2013/04/rf24-avoiding-rx-pipe-0-for-enhanced.html]

[natevw]

And FWIW when I was last testing on the RasPi, I saw at least one as-of-yet undiagnosed issue where if I tried to simultaneously TX and RX or something, the chip stopped behaving the way my code expected and things got stuck. So there's definitely still some bugs, it's 95% chance not your fault…this is a brand-new/from-scratch driver implementation. I know there are a few low-level "their chip"/"my code" quirks that haven't gotten chased down yet.

Basically my list looks like:

• 0. Keep my reputation up with paying clients :-)
• 1. Get basics working on both platforms
• 2. Chase down quickly-hit odd bugs like these
• 3. Add a bunch of basic/coverage/performance tests

[HasAndries]

Cool thanks a lot for your time, totally understand your priorities. I will keep hammering away in the meantime.

[natevw]

Did you figure anything out on this? I've finally got the Tessel side of things mostly "caught up" and am now moving back to general testing and debugging. If this is still an issue I should try the same thing, otherwise would love to hear what you figured out!

[natevw]

I think I found the cause of this bug, hope to fix it soon.

In the meantime, if it is what I think it is, you can probably workaround by opening the second pipe a little later (250ms should be more than plenty…) rather than right away.

[catharsis79]

Hi Nathan, I am in the same situation described here...when trying to open a second rx pipe the first one get stuck... Did you find any fix/workaround? what do you mean with "opening the second pipe a little later (250ms should be more than plenty…) rather than right away"? maybe it is a stupid question but my node.js skills ->0....

[natevw]

The workaround would look something like:

inbound.broadcast = radio.openPipe('rx', config.broadcastAddress);
inbound.broadcast.on('data', function (data) {
  console.log(['BROADCAST>>', JSON.stringify(data)].join(''));
});
inbound.broadcast.on('error', function (err) {
  console.log(['BROADCAST ERROR>>', err].join(''));
});

setTimeout(function ()
    inbound.command = radio.openPipe('rx', config.commandAddress);
    // rest of setup …
}, 250);

I've got an idea to fix this (basically cache simultaneously-modified values for correctness) and hope to tackle this soon.

[natevw]

This trouble should be avoided in v0.8.2 which I just published. Please let me know if you still have trouble!

[catharsis79]

will try pulling the newest release, Nathan

thx for your support!