Hello,
I am reading a lot about Moteino and RFM69hw and soon will make an order in the shop.
Right now I am using ESP8266 and XBee in my own home control and RPi as gateway. In the case of the XBee it will send a string to RPi who will call a website which will do mysql inserts, and various other things.
My current string looks like this...
My door node sends: ?json={unixtime:1444510867.72,Node_ID:5,Vcc:5897,uptime:138749,temperature:27500,value1:0}
My power node sends: ?json={unixtime:1444510868.04,Node_ID:10,Vcc:4897.00,uptime:94839.00,temp_box:25.56,temperature:24.31,tempDHT:21.00,humDHT:43.00,weather_status:3.00,Apparent_power:348.88,Irms:1.52,ArduinoMonthMeter:196806.5}
(some decimals can be removed but still message will be quite long)
When I switch to RFM69HW I believe the maximum message length is 61 bytes, so, what options do you think I have to continue using this kind of strings?
Thank you very much.
I have found that packet length significantly affects packet loss rate. i can send 3 byte messages successfully to nodes that will very rarely receive a 60 byte packet. I haven't made the transition yet but I think an optimal protocol needs to be binary and space optimized to minimize packet loss and maximize battery life. Given the better rf robustness for small packets you can then select a higher baud rate further improving battery life.
Of course you could also just send several 61 bytes ascii packets for each string to keep doing what you're doing. It's not optimal but it will work.
@Joe: what is the bitrate you have trouble getting your long packets through the RF link? According to the DS, a infinitely long bitstream can be transmitted in continuous mode. There should be a way to make this work. Maybe lowering the bitrate would help?
Reading between the lines on other posts, I got the impression that 200kbps is the sweet spot. That is, if you were to standardize on just a single bitrate (not that you have to), 200kbps would probably be it.
This is the sewage pit mote, which for wireless installs which use large packets downgrades the bitrate to 19200. However I can successfully use listen mode in 200kbaud where the packet sent is just a few bytes.
I've never used more than 200kbaud since I wasn't able to flash faster than that and my higher bitrate attempts originated with wireless install. I do have 300kbaud settings that work.
It's clear that long packets are problematic: as soon as one bit goes missing you lose the whole packet. With many short packets only the one that contains the corrupted bit is lost, leaving many others intact.
I honestly arrived at the 55k sweet spot after a lot of initial testing during the development of the library, hence that's the library default at init(). I did not really see a proportional loss rate as message length increases.
My RFM69 lib uses the packet mode of the SX1231h chip on the RFM69 module, which allows up to 66 bytes and because I have CRC/encryption enabled and also have some other header bytes for ACKs and such, this comes down to 61. That is way plenty for most things and I believe it's another sweet spot between usability and low power, and why I cherry picked this radio for my platform. The ESP can stream data but its wifi and will never be low power enough. So there's the tradeoff, completely different technologies, like gas and diesel.
You can compact a lot of data into 61 bytes. Your keys are VERRRY long, i mean ... T is good enough for temp, W for watts, etc etc. I doubt your ever gonna need more than double precision on your floats, again a huge space waster. Then you can compact even more and use structs instead of clear ASCII, all your numbers will shrink a lot there. Then if you still need more space .. just send 2 packets or send the metrics that dont need updating so often at other intervals. For instance a low incrementing counter is pointless to send on every single packet ... or battery life ... many many ways to optimize.
If you want to ditch the packet mode you loose the encryption and CRC but you can stream data if you want ... then you have to mess with the lib a little to make that possible since it's not supported out of the box. But still its a versatile radio and can do a lot of things.
That's interesting about the 55K. I had previously wondered why that magic number was the library default. ::) I didn't know there was data behind it.
I did a fairly large amount of packet loss testing on the NRF24L01+ (bear with me, this story actually does have a point to it). As expected, in my testing at range, 1Mbps had a lower packet loss than 2Mbps. What surprised me though was that on average the 1Mbps datarate also had a lower packet loss rate than when the datarate was set at 250Kbps. I don't know why it was the case, but that was the upshot of the packet loss evidence I collected. Based on that and there being only 3 possible datarates, I deemed 1Mbps to be the sweet spot for the NRF24L01+.
@Felix: when you say your testing pointed to 55K as being the sweet spot for the RFM69, was it a similar thing? If not, how was it you arrived at 55K? Was interoperability with RFM12B's a consideration, or was it unrelated to that? I know next to nothing about RFM12B's, so maybe that's a stupid question, but I do notice it falls toward the middle of the range of datarates that the RFM12B's internal demodulator can handle without an external RC filter (according to its datasheet), so that's what prompted the WAG.
I did a blog post and video (http://lowpowerlab.com/blog/2013/06/20/rfm69-library/) about introducing the RFM69, the awesome new features compared to RFM12B and you'll find more details there. I have not tested all the possible data rates combinations with all the other settings that are critical, but I tried a bunch. There may be other good sets of settings but in RF there are many many many factors that influence a good reception. So ... its all relative to a lot of things. There's no holy grail magic sweet spot per se, but the laws of physics do dictate certain limitations. The higher the bitrate the higher the chance of a loss (bits shorter time on air), and the lower the chance of a collision (bits shorter time on air = faster transmit).
Also check this post (http://lowpowerlab.com/blog/2013/12/18/can-rfm12b-talk-to-rfm69/) about RFM69 talking to RFM12B. At this point RFM12B is dead to me.
Quote from: Felix on October 12, 2015, 07:58:32 AM
At this point RFM12B is dead to me.
With availability of 'C' versions of all RFM69s, I can understand this.
Tom
Yup, the RFM69CW versions are the "C"ompatibility variants for RFM12b pinout based hardware. I don't stock them since the HCW is not pin compatible with C (HCW is the "C"ompatible version of HW for RFM22 legacy pinout compatibility) and I wanted to have both W and HW variants in the same pinout, hence I stock W and HW only. However all Moteinos so far support RFM69C versions since they have RFM12B footprints as well.
In fact the MoteinoLR and MoteinoMEGA-LoRa support the RFM69HCW as well, besides the RFM92-98 LoRa radios.
Quote from: Felix on October 12, 2015, 08:39:44 AM
I don't stock them since the HCW is not pin compatible with C...
WHOA! I totally missed that! I modified a design to RFM69CW and, when seeing the availability of the RFM69HCW, I thought, "Cool! I can use this in the same design!" Well, I guess that's why "ASS U ME" is spelled the way it is!
Thanks for saving my bacon!
Tom
Quote from: TomWS on October 12, 2015, 09:19:14 AM
Thanks for saving my bacon!
Tom
Hehe, I didn't know it myself (I just knew they are different pinouts but not that the C stands for compatibility with RFM12B and RFM22B respectively)... in a way it's a good thing I guess, more choices are always good to have.