syntax = "proto3";

option csharp_namespace = "Meshtastic.Protobufs";
option go_package = "git.janky.solutions/finn/matrix-meshtastic-bridge-go/meshtastic/protobufs";
option java_outer_classname = "PowerMonProtos";
option java_package = "com.geeksville.mesh";
option swift_prefix = "";

package meshtastic;

/* Note: There are no 'PowerMon' messages normally in use (PowerMons are sent only as structured logs - slogs).
But we wrap our State enum in this message to effectively nest a namespace (without our linter yelling at us)
*/
message PowerMon {
  /* Any significant power changing event in meshtastic should be tagged with a powermon state transition.
    If you are making new meshtastic features feel free to add new entries at the end of this definition.
  */
  enum State {
    None = 0;

    CPU_DeepSleep = 0x01;
    CPU_LightSleep = 0x02;

    /*
    The external Vext1 power is on.  Many boards have auxillary power rails that the CPU turns on only
    occasionally.  In cases where that rail has multiple devices on it we usually want to have logging on
    the state of that rail as an independent record.
    For instance on the Heltec Tracker 1.1 board, this rail is the power source for the GPS and screen.

    The log messages will be short and complete (see PowerMon.Event in the protobufs for details).
    something like "S:PM:C,0x00001234,REASON" where the hex number is the bitmask of all current states.
    (We use a bitmask for states so that if a log message gets lost it won't be fatal)
    */
    Vext1_On = 0x04;

    Lora_RXOn = 0x08;
    Lora_TXOn = 0x10;
    Lora_RXActive = 0x20;
    BT_On = 0x40;
    LED_On = 0x80;

    Screen_On = 0x100;
    Screen_Drawing = 0x200;
    Wifi_On = 0x400;

    /*
    GPS is actively trying to find our location
    See GPSPowerState for more details
    */
    GPS_Active = 0x800;
  }
}


/*
 * PowerStress testing support via the C++ PowerStress module
 */
message PowerStressMessage {
  /*
   * What operation would we like the UUT to perform.
     note: senders should probably set want_response in their request packets, so that they can know when the state
     machine has started processing their request
   */
  enum Opcode {
    /*
     * Unset/unused
     */
    UNSET = 0;

    PRINT_INFO = 1; // Print board version slog and send an ack that we are alive and ready to process commands
    FORCE_QUIET = 2; // Try to turn off all automatic processing of packets, screen, sleeping, etc (to make it easier to measure in isolation)
    END_QUIET = 3;   // Stop powerstress processing - probably by just rebooting the board

    SCREEN_ON = 16; // Turn the screen on
    SCREEN_OFF = 17; // Turn the screen off

    CPU_IDLE = 32; // Let the CPU run but we assume mostly idling for num_seconds
    CPU_DEEPSLEEP = 33; // Force deep sleep for FIXME seconds
    CPU_FULLON = 34; // Spin the CPU as fast as possible for num_seconds

    LED_ON = 48; // Turn the LED on for num_seconds (and leave it on - for baseline power measurement purposes)
    LED_OFF = 49; // Force the LED off for num_seconds

    LORA_OFF = 64; // Completely turn off the LORA radio for num_seconds
    LORA_TX = 65; // Send Lora packets for num_seconds
    LORA_RX = 66; // Receive Lora packets for num_seconds (node will be mostly just listening, unless an external agent is helping stress this by sending packets on the current channel)

    BT_OFF = 80; // Turn off the BT radio for num_seconds
    BT_ON = 81; // Turn on the BT radio for num_seconds

    WIFI_OFF = 96; // Turn off the WIFI radio for num_seconds
    WIFI_ON = 97; // Turn on the WIFI radio for num_seconds

    GPS_OFF = 112; // Turn off the GPS radio for num_seconds
    GPS_ON = 113; // Turn on the GPS radio for num_seconds
  }

  /*
   * What type of HardwareMessage is this?
   */
  Opcode cmd = 1;

  float num_seconds = 2;
}