RFM69 with Bean+ very slow. 1.5 seconds to do simple send(). Probably config

[IndyBob67]

I'm using the RFM69HCW module from SparkFun running on a PuchThru Design Light Blue Bean+ and the RF69 library from low power lab.

What I'm seeing is that it is taking about 1.5 SECONDS to send a packet without an ACK.  Packet size does not seem to make much difference.  If an ACK is requested, takes 3.5 seconds.

But I've seen suggestions that 40ms is more appropriate for a send with ACK.

Am using the Gateway/Node examples from the example library. I have commented out the references to the SPIFlash.

The above makes me think I've something wrong in the configuration.

FYI, my app is a commercial one with a central device that triggers some special hardware to do stuff.  The remote is a small plastic shell with electronics installed and also 2 push buttons.  Press right one and central does something.  Press the left one and central does something else.  This is all in production right now but it is using BLE which is very range limiting.  Thats why we are looking at the ISM bands.

Required turn around time is 100ms or better.

Thanks in Advance,
Bob

[TomWS]

The Light Blue Bean documentation shows that the SPI interface is managed by the CC2540, not the 328P.  How is the RFM69 radio connected?  And where is the interrupt line attached?

Tom

[IndyBob67]

Tom,

D0 is the interrupt.  DIO0
SCK - D9
MISO - D8
MOSI - D7
NSS - D6

And of course, 3.3v, ground and the antenna.

I'm thinking I've got the wiring ok as it is "working", just incredibly slow.  Or is this bad thinking?

Bob

[TomWS]

I'm thinking I've got the wiring ok as it is "working", just incredibly slow.  Or is this bad thinking?

If the SPI is being managed by the CC2540 and routed from the 328P SW via the UART interface as the architecture diagram shows then maybe it will 'work' but it will be incredibly slow...  Which is why I asked.  Do you know that the radio is directly connected to the 328P?

Tom

[IndyBob67]

Does seem according to the block diagram https://punchthrough.github.io/bean-docs/_assets/images/guides/getting-started/tech-specs/bean+-block-diagram.png

That all interrupts are via the 2540. Which makes sense since the interrupts will bring the 328p out of sleep mode.

I've asked your question on the Bean forum to get an intelligent and accurate answer to how things work for interrupt and data pins. 


If this is all true, we may have to rethink our base platform and go from the Bean to an arduino. But we really don't want to give up the BLE or our existing code base.

I'm a big iron software dude expanding (shrinking??) my horizons and this hardware stuff is well out of my current comfort zone.  But I'm learning!

Bob

[TomWS]

Check out RFduino...  BLE + Arduino.  I haven't seen a port of the RFM69 to it, however.  It should be possible as there is SPI on the RFduino.  There may not be enough pins, however, if you want to debug.  I think there is a newer version that has more GPIO brought out.

Another good choice are modules based on Nordic Semiconductor's chips nRF51422 & nRF51822.  These are full blown ARM Cortex M0+ with 2 SPI busses. And then there's...   LOTS to choose from!

Tom

[IndyBob67]

So you think I'm sunk getting this to work at any reasonable speed on a Bean?

I'm dealing with a production product that has been out in the wild for some time now (measured in years).  I might be able to change hardware on the peripheral/sensor side, but not the central device. And the central device will still need to talk ISM.

Would a different radio work better? I'm not locked into any radio or even band. It just needs to be inexpensive and have >50m range thru walls, tree's and other obstacles.  As I understand you, the problem is in the SPI communications, not the driver or radio chip.

Would you expect the RadioHead drivers to work any better?

Bob

[TomWS]

I sent you a PM, check that out and we can go from there.

Tom

[RoSchmi]

Hi,
before you give up I would have a look on the values of CSMA_LIMIT and RF69_CSMA_LIMIT_MS in the file RFM69.h. May be that calling the method cansend waits for the end of the timeout RF69_CSMA_LIMIT_MS (1000 MS) before the message is send because CSMA_LIMIT (-90) is to low for your board. Perhaps you can try with -60.
Kind regards
RoSchmi

[TomWS]

Hi,
before you give up I would have a look on the values of CSMA_LIMIT and RF69_CSMA_LIMIT_MS in the file RFM69.h. May be that calling the method cansend waits for the end of the timeout RF69_CSMA_LIMIT_MS (1000 MS) before the message is send because CSMA_LIMIT (-90) is to low for your board. Perhaps you can try with -60.
Kind regards
RoSchmi

Are you thinking that emissions from the Light Blue Bean would be creating a false read on the CSMA sensing?   OP didn't say what frequency he's using for his RFM69 radio but I expect that it would be pretty far separated from 2.4GHz.

Tom

[RoSchmi]

Yes, I saw the problem with other boards than the Moteino that, may be because of noise, the value of -90 was to low.

[IndyBob67]

Hi,
before you give up I would have a look on the values of CSMA_LIMIT and RF69_CSMA_LIMIT_MS in the file RFM69.h. May be that calling the method cansend waits for the end of the timeout RF69_CSMA_LIMIT_MS (1000 MS) before the message is send because CSMA_LIMIT (-90) is to low for your board. Perhaps you can try with -60.
Kind regards
RoSchmi

I will try setting those define's.  Right now, the radio's are inches apart.  In production, it'll be anywhere from a few meters up to 100+ meters.

Tom, I'm using the 915mhz band.  Tho when we go to production, we will also be using the 433mhz band as we've a fair number of customers overseas and are just setting up a distribution agreement with somebody in Australia.