Author Topic: Reducing or Eliminating Preamble  (Read 589 times)

ChemE

  • Sr. Member
  • ****
  • Posts: 402
  • Country: us
Reducing or Eliminating Preamble
« on: September 11, 2016, 09:48:14 AM »
I've had a look through this forum as well as some searches and I find nothing regarding anyone monkeying with the packet format to reduce how long a battery-powered mote must spend in its highest power state; transmitting.  Page 52 of the datasheet makes it seem that payloads can be as small as 1 byte.  To send back temperature and humidity as integers I think the payload can be as small as 2 bytes (1 byte to encode the temperature from -128 to 128F and 7 bits to encode the RH from 0 to 100).  Adding sync words, length, address, network etc represents a significant increase in payload and thus power consumption.  I recall reading some thoughts/discussion over at Jeelabs about changing the RFM12B packet structure to shave a few bytes out of the payload.  Has anyone done the same with the RFM69W* or am I striking out into new territory?  Using these awesome new TPL5110s means my power budget is strongly affected by my transmit time now that my sleep current is 38nA.  Not a bad problem to have!

emjay

  • Full Member
  • ***
  • Posts: 120
  • Country: nl
Re: Reducing or Eliminating Preamble
« Reply #1 on: September 11, 2016, 10:18:21 AM »
@ChemE,

Trimming back the preamble will start to affect the ability of the bit slicer to "lock in" to the incoming stream. Difficult to test since if the Tx & Rx xtals are *perfectly* aligned, you won't see this effect.
If your loop budget is adequate, why not increase the baud rate?  Just parameter changes, no code changes - microcoulombs consumed inversely proportional to the baud rate.
 

ChemE

  • Sr. Member
  • ****
  • Posts: 402
  • Country: us
Re: Reducing or Eliminating Preamble
« Reply #2 on: September 11, 2016, 10:35:11 AM »
I absolutely agree emjay and plan on going up to 300kbps baud rate for precisely this reason.  Still, I know a great many folks have no problems running at 300kbps so why stop there?  Trimming bytes out of the payload offers the next best path to power reduction (it would seem).