I want to send a tightly packed stream of packets for the purpose of hitting a small Rx window in Listen Mode. This is the best I've come up with so far (the SPI code is slightly altered compared to the RFM69 library code):
void sendQuickPacketStream() {
while (digitalRead(4)) {//while button is pushed
radio.writeReg(REG_OPMODE,B00001000); //activate RFM69 FS mode.
//Load FIFO
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV4);
digitalWrite(10, LOW); //select();
SPI.transfer(REG_FIFO | 0x80);
SPI.transfer(4); ////SPI.transfer(sendSize + 3);
SPI.transfer(GATEWAYID); //SPI.transfer(toAddress);
SPI.transfer(NODEID); // SPI.transfer(fromAddress);
SPI.transfer(0x00); //CTLbyte
SPI.transfer((payload[0])); //just a one byte payload
digitalWrite(10, HIGH); //unselect();
while (digitalRead(2)) {} //guarantee any prior Tx mode exited after PacketSent
radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.
while (!(digitalRead(2))) {} //busy-wait until PacketSent
}
//Assertion: button is released
blockingActivateStandbyMode();
}
DIO0 is mapped to D2 using DIOx setting 00 (see table 22 of DS).
Is this as tightly packed as the packet stream can get? I had also tried just leaving the RFM69 in Tx mode after PacketSent and then loading the next packet into the FIFO, but doing that doesn't transmit the next packet. It seems that one must exit and then re-enter Tx mode after PacketSent in order to transmit the next packet. So, I'm exiting to FS mode so that the FS stays revved up.
Dunno, I wonder whether you can use auto mode:
Enter condition set to FIFO not empty
Intermediate condition set to TX
Exit condition set to packet sent.
Now what happens if you start in TX mode so that the state it will exit from intermediate state to is also TX? Does this mean you can stream data packets constantly into the FIFO using almost full to throttle without the FIFO clearing as it would never actually leave TX mode (which would of course clear the FIFO)?
Mark.
That's a clever idea! If it worked, it would save all that time lost from continually reloading the FIFO with the same packet. Definitely worth a try.
If it doesn't work, then the next step I was contemplating was to stick the first few bytes in the FIFO, launch Tx mode, and while that gets going I finish loading up the remaining bytes (as suggested by the DS for how to handle extra long packets). That would give at least some pipelining.
If that actually worked it would mean you could start loading in the next packet before the previous one has been sent. The problem with exiting TX at any point is the FIFO gets cleared. You will need to reload in the next packet though, the FIFO gets emptied as it transmits, but you would be constantly pipelining so won't waste any time by doing that.
Mark.
For certain you can enter TX on FIFO not empty and load a short packet while the radio is spinning up. At first I played safe and set it to kick on after a few bytes but quickly tested 0 bytes with no problems.
WH, we've covered this stuff quite a bit. For listen mode you need a continuous signal. So TX needs to be on between packets. That works as long as you don't use encryption and don't use packetsent as indicator (which will get set after the first packet is out, use fifo size instead). There was some success with encryption if the fifo is kept full enough at all times (https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/burst-message-weirdness-with-listen-mode-(solved-bad-radio)/) although I haven't tried to replicate that.
I haven't yet tried Perky's idea (which I definitely want to do), but based on the helpful comments from ChemE (Tx can be started with an empty FIFO and the payload added to the FIFO afterward) and Joe (staying in TX mode and using FIFO size rather than PacketSent to judge when to start sending the next packet), I did a quick change to my prior code, and it now does function with TX running continuously and not exiting TX mode between packets:
void sendQuickPacketStream() {
radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.
while (digitalRead(4)) {//while button is pushed
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV4);
digitalWrite(10, LOW); //digitalWrite(_slaveSelectPin, LOW);
SPI.transfer(REG_FIFO | 0x80);
SPI.transfer(4); ////SPI.transfer(sendSize + 3);
SPI.transfer(GATEWAYID); //SPI.transfer(toAddress);
SPI.transfer(NODEID); // SPI.transfer(fromAddress);
SPI.transfer(0x00); //CTLbyte
SPI.transfer((payload[0]));
digitalWrite(10, HIGH); //unselect();
while ((radio.readReg(REG_IRQFLAGS2)) & B01000000) {} //busy-wait until FIFO is empty
}
//Assertion: button is released
blockingActivateStandbyMode();
}
I suspect this part:
while ((radio.readReg(REG_IRQFLAGS2)) & B01000000)
is slow, as compared to checking a FifoNotEmpty pin that's mapped to from DIO1 or DIO2. The latter would require a bodge wire, but I've done bodge wires on the RFM69 before, and it's easy to do.
The above code does assume that the FIFO needs to empty before loading the next packet. It would obviously be preferable if the next payload could be loaded into the FIFO before the packet currently being sent is finished transmitting. IF that worked (?), then I would only need to avoid overflowing the FIFO.
[Edit1: I just now did a preliminary test, and it looks as though I probably can load the FIFO with the next n payloads prior to the current packet finishing its transmission. So, I'll now try doing a full coding of that which will keep the FIFO full without overflowing it. That should, in theory, give the tightest spacing between transmitted packets.]
[Edit2: And if *that* works, then the only thing left to look at (that I can think of) would be the ramp down time after a packet transmits. Perhaps that can be cut to either zero or near zero. Doing that should tighten the spacing between packets even further.]
Why have you got SPI_CLOCK_DIV4 for your clock divider? You need this clock to be as fast as possible, how about SPI_CLOCK_DIV2?
Mark.
You're right. Good catch. I did it that way only because the RFM69 library did it that way. I think it's to account for somewhat gimpy add-on flash memory (?), which isn't currently present on my remote prototype.
I'll change it. :)
[Edit: scratch that. It doesn't seem to work using DIV2. I have no theories, so I'm simply reverting back to DIV4]
In theory, by staying in Tx mode and not allowing the FIFO to ever empty, the following code should give rise to a tight packing of transmitted packets:
void addPayloadToFifo () {
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV4);
//SPI.setClockDivider(SPI_CLOCK_DIV2);
digitalWrite(10, LOW); //digitalWrite(_slaveSelectPin, LOW);
SPI.transfer(REG_FIFO | 0x80);
SPI.transfer(4); ////SPI.transfer(sendSize + 3);
SPI.transfer(GATEWAYID); //SPI.transfer(toAddress);
SPI.transfer(NODEID); // SPI.transfer(fromAddress);
SPI.transfer(0x00); //CTLbyte
SPI.transfer((payload[0]));
digitalWrite(10, HIGH); //unselect();
}
void sendQuickPacketStream() {
radio.writeReg(REG_FIFOTHRESH,B10101000); //set FIFO threshold to an arbitrary 40 (???)
radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.
while (digitalRead(4)) {//while button is pushed
while ((radio.readReg(REG_IRQFLAGS2))& B00100000) {} //busy-wait while FifoLevel flagged
delayMicroseconds(80); //??? not sure what's the best number to use
addPayloadToFifo ();
}
//Assertion: button is released
blockingActivateStandbyMode();
}
It contains a couple magic numbers though. It uses 80 microseconds delay between SPI burst transfers to the FIFO. I arrived at that through trial and error, and there's probably a better number to use. For sure, if there's no delay, it doesn't work. That at least makes sense. Strangely, though, if there's too much delay, it doesn't work either! At least so far, that part doesn't make sense to me.
The other magic number is 40, which I picked arbitrarily for the FifoThreshold used to trigger the FifoLevel flag. I started with 50, but that led to some packet corruption. I haven't put any thought yet into picking a principled number.
This first pass on the code was just to see whether I could get the concept to work at all. However, as I'm not sure that further fine tuning will actually make any a difference, it may be the final code as well.
After testing it out, though, the prior coding which waits until the FIFO empties before loading the next payload seems to work much better than the latter coding which never lets the FIFO completely empty. :o Go figure.
So, for now, I think I'll adopt the previous coding and simply speed it up a bit with a bodge wire.
Also, since the sx1231h allegedly transmits preamble when the FIFO is empty (at least, I seem to recall Joe reporting that), maybe I can transmit a shorter preamble on each packet (that is, if (?) the preamble while waiting is seamless with the explicit packet preamble) and thereby pack the packets a little tighter that way also. In that case, the waiting time wouldn't be wasted.
OK, I bodge wired DIO2 to pin D7 on the atmega328p, and I added a 10K pulldown resistor to D7 just to be sure it doesn't float.
Having done that, the following code gives me the tightest packet stream yet:
void sendQuickPacketStream() {
radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.
while ((radio.readReg(REG_DIOMAPPING1) != B00001100)) {
radio.writeReg(REG_DIOMAPPING1, B00001100);
}
radio.writeReg(REG_DIOMAPPING1, B00000000); //map DIO2 to FifoNotEmptyFlag
while ((radio.readReg(REG_DIOMAPPING1) != B00000000)) {
radio.writeReg(REG_DIOMAPPING1, B00000000);
}
//Note: DIO2 is bodge wired to pin D7 on atmega328p.
while (digitalRead(4)) { //while button is pushed
if (!(digitalRead(7))) { //if FIFO is empty
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV4);
digitalWrite(10, LOW); //digitalWrite(_slaveSelectPin, LOW);
SPI.transfer(REG_FIFO | 0x80);
SPI.transfer(4); ////SPI.transfer(sendSize + 3);
SPI.transfer(GATEWAYID); //SPI.transfer(toAddress);
SPI.transfer(NODEID); // SPI.transfer(fromAddress);
SPI.transfer(0x00); //CTLbyte
SPI.transfer((payload[0]));
digitalWrite(10, HIGH); //unselect();
}
}
//Assertion: button is released
blockingActivateStandbyMode();
}
It appears to perform much better than the earlier non-bodged solution. :)
With 4 preamble bytes, 3 sync bytes, 2 crc bytes, one length byte, 1 "from address" byte, 1 payload byte, and no encryption, I'm getting acceptable hit rates with a listen window of 1024usec. That's higher than I was hoping for, and also longer than it seems like it should have to be. Shorter listen windows "work," but the hit rate noticeably degrades.
The above 11 bytes at 300kbps should take only about 293usec of airtime to transmit. Therefore, a good listen window of closer to 600usec should be possible, at least theoretically.
That's why I've been pushing for a tighter packet stream. I'm guessing the gaps between packets must still be large.
I suppose I may need to do some measurements to figure out what's really going on.
Meanwhile, I'll see if I can get Perky's idea to work.
Alternately, maybe I could trigger the refill of the FIFO to start sooner. Keeping the FiFo relatively full didn't seem to work very well, but by setting a low enough FifoThreshold, maybe I could pipeline the refill so that it commences within moments of the FIFO becoming empty. Not sure, but as a last ditch effort, maybe it would be worth a shot.
I take it back. With the latest coding, using SPI_CLOCK_DIV2 does work. So, that should yield at least some improvement.
If you don't use auto mode I'm not sure what will happen if a PacketSent happens and you then write data into the FIFO without clearing PacketSent first. The hope with the auto mode version is that when a PacketSent is detected it will exit from intermediate mode back to TX mode and restart a new transmission if there's something still in the FIFO, auto-clearing the PacketSent interrupt. No guarantee it will do that though.
Remember the FIFO empty condition happens when the last data has removed from the FIFO by the transmit logic, but it's actually been placed in the shift register and is therefore still transmitting, so FIFO empty happens at least 8 bits time before PacketSent. That timing could have strange effects, you might want to wait for PacketSent before sending the next packet (except the first one of course ;) )
Mark.
Quote from: perky on March 17, 2017, 04:21:47 PM
... 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?
Quote from: WhiteHare on March 17, 2017, 04:35:09 PM
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.
Quote from: perky on March 17, 2017, 05:21:38 PM
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?
Quote from: WhiteHare on March 17, 2017, 05:49:08 PM
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.
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).
QuoteWhat 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
Quote from: joelucid on March 18, 2017, 07:01:00 AM
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.
Quote from: joelucid on March 18, 2017, 07:01:00 AM
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.
QuoteDid 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
Quote from: joelucid on March 18, 2017, 12:45:50 PM
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:
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?
Quote from: WhiteHare on March 18, 2017, 08:00:07 PM
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.
QuoteI 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.
Quote from: joelucid on March 19, 2017, 05:01:44 AM
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! :D
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.
QuoteIf 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.
QuoteAs 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
It works!
Presently I'm using a large Rx window, and use
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.
After looking at the current drain on an oscilliscope, I'm scrapping the use of timeout1 and timeout2 and just going with 128usec and the radio staying indefinitely in Rx when RSSI is above threshhold. TIMEOUT1 and TIMEOUT2 seemed like they might be a nice refinement, but they didn't seem to pan out.
Fortunately, the 128usec Listen-Mode Rx window is functioning according to prediction. :)
Quote from: WhiteHare on March 19, 2017, 12:39:25 PM
Fortunately, the 128usec Listen-Mode Rx window is functioning according to prediction. :)
Argh, I found some bugs in my hasty code, and I'm in the process of re-writing it. I'm now pretty sure that the shortest Listen Mode Rx Window that will work for RSSI detection is not 128uSec (as I stated above), but rather 3*64=192uSec. At least that's the result I'm getting now that I've stripped the code down to the bare minimum.
Has anyone actually gotten above-threshold RSSI detection to work using a Listen Mode Rx window of 128uSec? Doesn't seem to be an mcu coding thing. Rather, the radio either detects a high RSSI within the alloted window, or it doesn't. With a 128uSec Listen-Mode Rx window, I'm getting zero detections.