most tightly packed stream of packets?

[WhiteHare]

... you might want to wait for PacketSent before sending the next packet (except the first one of course )

Mark.

Except that, as Joe pointed out earlier above, once PacketSent goes HIGH, it apparently stays HIGH unless "Cleared when exiting Tx."  Thus, it would appear to be good for only one packet transmission, and any further packet transmissions would need to rely on something else.  The PacketSent flag bit is read-only, according to the DS.  Unless there's some other way to clear it? 

[perky]

Except that, as Joe pointed out earlier above, once PacketSent goes HIGH, it apparently stays HIGH unless "Cleared when exiting Tx."  Thus, it would appear to be good for only one packet transmission, and any further packet transmissions would need to rely on something else.  The PacketSent flag bit is read-only, according to the DS.  Unless there's some other way to clear it?

Yes, you're right. Quickest way to clear it would be to go to FS mode (as it's already locked) and back to TX. I was hoping it would clear when it starts to transmit a packet as well but unless auto mode acts differently that might put an end to pipelining new packets before the old one completes

Mark.

[WhiteHare]

Yes, you're right. Quickest way to clear it would be to go to FS mode (as it's already locked) and back to TX. I was hoping it would clear when it starts to transmit a packet as well but unless auto mode acts differently that might put an end to pipelining new packets before the old one completes

Mark.

I'm afraid so.  It seems like the alternative would be to try to use FIFO empty as the automode trigger (i.e. falling edge of FifoNotEmpty), but then presumably if FIFO is empty, there will be nothing to Tx.

I made the switchover to using SPI_CLOCK_DIV2, but it doesn't seem to be making much improvement. 

This may be the end of the road.   A couple options may remain though:
1.  Transmitting using continuous mode rather than packet mode in such a way that the continuous transmission looks like packets.  Has anyone ever tried this?  To make the spoof work, it may need to employ the delimiter Perky was referring to earlier.  The advantage would be that the mcu would have full control over how close together the packets are.  Or,

2.  Use Joe's old technique of waking up on simply an RSSI that's higher than some arbitrary threshold and then sort-out afterward whether it was an intentional trigger intended for the node or a false trigger of some kind.  Presumably the listen window for that could be a lot shorter (presumably a 128uSec Rx window, which is the minimum, would work just fine).    I'm starting to lean in this direction because the power savings could potentially be a lot greater than for #1.

Any other options worth considering?

[perky]

Transmitting using continuous mode rather than packet mode in such a way that the continuous transmission looks like packets. 

Well, when you say continuous mode you mean either much larger packets or unlimited packet length and stream it using FifoLevel to throttle the SPI. Now that might just do it, as you say you'd need to make the data look like individual packets (including a delimiter if indeed there really is one, sync words and CRCs calculated for each packet if you're using that too). The delimiter might be just replacing the last bit of a preamble with a copy of the previous bit rather than adding one into the stream and messing up the byte alignments.

A bit of experimentation would be needed to get the format right, but it would give you the fastest possible back-to-back transmissions. It would be relatively easy to test as well.

Mark.

[WhiteHare]

What I was thinking of was Continuous Mode (section 5.4 of the datasheet), as opposed to Packet Mode (section 5.5 of the DS).  However, maybe those other methods you mentioned would work as well.  It's all unknown territory for me, so I wouldn't rule anything out just yet.

I think I may take a crack at the RSSI approach (option #2).  It has its own issues, but I'm wagering it will come out best overall on power consumption (maybe an order of magnitude better than my current working Listen Mode packet based solution whose code I posted above).

[joelucid]

What I was thinking of was Continuous Mode (section 5.4 of the datasheet), as opposed to Packet Mode (section 5.5 of the DS).  However, maybe those other methods you mentioned would work as well.  It's all unknown territory for me, so I wouldn't rule anything out just yet.

I think I may take a crack at the RSSI approach (option #2).  It has its own issues, but I'm wagering it will come out best overall on power consumption (maybe an order of magnitude better than my current working Listen Mode packet based solution whose code I posted above).

Which problem are you trying to solve? Why not use packet mode, keep the radio in TX between packets and use FIFO Empty as substitute for packet sent?

Joe

[WhiteHare]

Which problem are you trying to solve?

Reduce power consumption even further.  Do I absolutely have to?  No.  It all works as is.  The only thing that will change is how big the supercap is and/or the solar panel is. 

Why not use packet mode, keep the radio in TX between packets and use FIFO Empty as substitute for packet sent?

Did that already.  It works (code posted above even).  However, Rx window is 1ms to get a high hit rate.  Even the theoretical limit on Rx window, given the number of bytes being transmitted, is about 600uSec.  So, although there's theoretically room left for improvement, it's already close to diminishing returns from further optimization of the packet approach.

[joelucid]

Did that already.  It works (code posted above even).  However, Rx window is 1ms to get a high hit rate.  Even the theoretical limit on Rx window, given the number of bytes being transmitted, is about 600uSec.  So, although there's theoretically room left for improvement, it's already close to diminishing returns from further optimization of the packet approach.

Aren't you using RSSI as listen exit criterion? If you do you only need the receiver on for two bits no matter how often you send packets. Provided of course that you leave the radio in TX  so that a continuous stream of preamble is sent between packets.

Joe

[WhiteHare]

Aren't you using RSSI as listen exit criterion?

By that do you mean using RSSI as the ListenCriteria (i.e. "Criteria for packet acceptance in Listen mode" which arises from setting Bit 3 of RegListen1 to 0?

If so, then so far I haven't been doing that.  I had been relying on Sync Address matching.

But that's now all just water under the bridge.  Suppose I did do as you suggest.  How then does one quickly identify, after the fact, whether or not the RSSI was above threshold?

I've tried reading the RSSI value with a statement such as:

Code Select Expand

theRssiValue=radio.readReg(REG_RSSIVALUE);

after the MCU gets woken up, but doing that I find that the minimum Listen-Mode Rx window is 4*64=256uSec.  Anything shorter and theRssiValue is always just 255, which suggests it's not reading correctly.

So, are you instead detecting it by monitoring the RSSI flag on DIO0?

[WhiteHare]

So, are you instead detecting it by monitoring the RSSI flag on DIO0?

Answering my own question, I just now tried this, and it does indeed appear to work even with a Listen-Mode Rx Window of 128uSec.  I trigger it, as suggested by Joe, by just putting the radio on the transmitting remote control into Tx mode with an empty FIFO.  Therefore, it simply sends a stream of preamble for as long as the button is pressed.

So, that's good news!  It means I can use an Rx window that is a factor of 8 shorter than what was needed when ignoring RSSI and only detecting for packet receipt.   

I actually would have preferred my earlier approach, but it turns out 300kbps just isn't as fast as what I need, so this approach is a compromise.  I haven't yet worked out how to efficiently confirm whether the RSSI pulse was intentional for a particular node or not.  However, for confirmation, I think I may simply program the mcu to widen the listen mode Rx window to 1024usec and use the same method I was using before.  Thus, the transmitting remote control will need to send a tightly packed stream of confirmation packets after first sending the 100ms preamble to wake the mcu.

[joelucid]

I haven't yet worked out how to efficiently confirm whether the RSSI pulse was intentional for a particular node or not.  However, for confirmation, I think I may simply program the mcu to widen the listen mode Rx window to 1024usec and use the same method I was using before.  Thus, the transmitting remote control will need to send a tightly packed stream of confirmation packets after first sending the 100ms preamble to wake the mcu.

No, no. You SHOULD send a tight sequence of packets, but interleaved with preamble rather than silence. Then when listen mode wakes up and triggers RSSI you just keep the receiver on and receive the next packet.

[WhiteHare]

No, no. You SHOULD send a tight sequence of packets, but interleaved with preamble rather than silence. Then when listen mode wakes up and triggers RSSI you just keep the receiver on and receive the next packet.

Ah, now that is elegant!   

As a related topic:  If using an RTC, have you had success in synthesizing an equivalent Rx window that's shorter than 128usec and that still works?  Because the 64usec Rx window Listen Mode is a proven NOP, the granularity of Listen Mode now appears to be getting in the way of squeezing out additional power savings.

[joelucid]

If using an RTC, have you had success in synthesizing an equivalent Rx window that's shorter than 128usec and that still works?  Because the 64usec Rx window Listen Mode is a proven NOP, the granularity of Listen Mode now appears to be getting in the way of squeezing out additional power savings.

I haven't worked on that in a while - but yeah in my mind our current listen mode is a crude crutch and needs to be replaced by short listen windows that are precisely targeted by the GW using synchronized clocks.

As I reported in a different thread even 256 uS doesn't work for me for all nodes. I have one that requires more. All that at 200kbit. I doubt very much that it can be done better manually than by listen mode. But manual has other advantages.

[joelucid]

As I reported in a different thread even 256 uS doesn't work for me for all nodes. I have one that requires more. All that at 200kbit. I doubt very much that it can be done better manually than by listen mode. But manual has other advantages.

BTW, I'm just thinking that one problem with my approach is that you don't necessarily detect RSSI during preamble. It could be while the packet is being sent. I would guess RSSI detection needs at least a 0/1 or 1/0 bit pair to trigger reliably.

Of course I use whitening to encourage as many bit transitions as possible. But maybe you can shorten the RX time by a couple of bits if you KNOW that you're either rx'ing preamble or nothing. At high bitrates that's academic, but at say 2400 baud it could have a noticeable effect. The synchronized method could take advantage of those gains.

Joe

[WhiteHare]

It works!

Presently I'm using a large Rx window, and use

Code Select Expand

  radio.writeReg(REG_RXTIMEOUT2,15);  //timeout after 15 bits after RSSI goes high if no packet received.
  radio.writeReg(REG_RXTIMEOUT1,1);

to make it more adaptable to circumstances.  That seems to yield a better hitrate than simply limiting the Rx window to 128usec.