Orion XS 12V/12V-50A Bluetooth Advertising Data

I’ve been reading https://community.victronenergy.com/questions/187303/victron-bluetooth-advertising-protocol.html and have got my C++ code decoding information from my smartlithium batteries.

I’m trying to recognize my Orion XS DC/DC charger and it appears to have a record type of 0x0f which is not in the pdf listed in that same thread. (https://community.victronenergy.com/storage/attachments/48745-extra-manufacturer-data-2022-12-14.pdf)

Is there an updated document listing structures of newer devices?

Here is the layout for the Orion XS:

@thiemovanengelen Thanks for sending that. Is there a link to where that data is published? (Is it on GitHub somewhere?)

Are the items in the Remark column described somewhere?

Am I correct that 0x0F in the manufacturer data byte 4 tells me to interpret the extended data using this bit packing?

I recreated it in Markdown for my own documentation and because it’s easier to copy/paste.

Orion XS

Start Bit Nr of Bits Meaning Units Range NA Value Remark
0 8 Device State 0…0xFF VE_REG_DEVICE_STATE
8 8 Error Code 0…0xFF VE_REG_CHR_ERROR_CODE
16 16 Output Voltage 0.01 V -327.68…327.66 V 0x7FFF VE_REG_DC_CHANNEL1_VOLTAGE
32 16 Output Current 0.01 V -327.68…327.66 A 0x7FFF VE_REG_DC_CHANNEL1_CURRENT
48 16 Input Voltage 0.01 V 0…655.34 V 0xFFFF VE_REG_DC_INPUT_VOLTAGE
64 16 Input Current 0.01 V 0…655.34 A 0xFFFF VE_REG_DC_INPUT_CURRENT
80 32 Device Off Reason 0…429496728 VE_REG_DEVICE_OFF_REASON_2
112 16 Unused

I don’t think we’ll ever get a complete list from Victron.
Part of them are found here: Victron registers
Still, for a somehow complete list, if you get a little creative, you can get them from inside the VictronConnect application. :wink:

Thanks for sending that. Is there a link to where that data is published?

Perhaps this will change in the future, but for now, this is not published anywhere.

Are the items in the Remark column described somewhere?

Some can be found in other documentation. As this is taken from our internal documentation, it is more meant for our own use.

Am I correct that 0x0F in the manufacturer data byte 4 tells me to interpret the extended data using this bit packing?

That is correct.

I thought that I’d share that I’m now recognizing and graphing the Orion XS in my C++ Code

4 Likes

Thank you for sharing. :+1:
From my experiences few came back to post their results for all to see and learn…

1 Like

Hello, where could we find such a protocol spec for AC Chargers, which were tagged as “subject to change” in the widely available PDF document in 2022 ?

Hi,

Here is the layout for AC Chargers:

Kind regards,
Thiemo van Engelen

1 Like

hi,

Thank you for your message.
However, this corresponds exactly to what we had in 2022 and in the publicly available document, we ca read:

AC Charger: Record layout is still to be determined and might change.)

I was guessing if a more recent and up-to-date version was introduced meanwhile, as decoding this type of frame gives bad results with what I read from my SmartIP 43 charger, with a recently updated firmware.
My decoder uses the following structure to decode the receiving frame:

struct RECORD_VICTRON_AC {
  VICTRON_DEVICE_STATE          device_state;
  VICTRON_ERROR_CODE            charger_error;
  uint16_t                      b1_v = 13;
  uint16_t                      b1_i = 11;
  uint16_t                      b2_v = 13;
  uint16_t                      b2_i = 11;
  uint16_t                      b3_v = 13;
  uint16_t                      b3_i = 11;
  int8_t                        temp = 7;
  int16_t                       i_input = 9;
} __attribute__((packed));  // to avoid automatic alignment

which of course gives me random values for battery currents/voltages …

Thanks again for your precious help !

Bruno

Take a look at the two columns. Start bit and number of bits…
The info is not aligned on 8 bit boundaries, so you need to properly align your variables in order to receive correctly the info. :wink:
I have the feeling that your compiler, even if you defined the variables to be a certain lenght, it stills align the variables to uint16_t
Take a look at the code with a debugger / disassembler…

Hi @bmedici

Since the publication in 2022, the specification for the AC charger record has been finalized and has not changed since 2022. So the current contents will not change anymore (but it may be extended).

This is not the way to provide the length of a field in a struct. It should be like this:

struct RECORD_VICTRON_AC {
  VICTRON_DEVICE_STATE          device_state:8;
  VICTRON_ERROR_CODE            charger_error:8;
  uint16_t                      b1_v:13;
  uint16_t                      b1_i:11;
  uint16_t                      b2_v:13;
  uint16_t                      b2_i:11;
  uint16_t                      b3_v:13;
  uint16_t                      b3_i:11;
  int8_t                        temp:7;
  int16_t                       i_input:9;
} __attribute__((packed));  // to avoid automatic alignment

Please be aware that the behavior of packing in combination with bitfields is highly compiler dependent so while this may work on one platform/compiler combination, it will certainly not work like this with for example msvc.

With kind regards,
Thiemo van Engelen

My bad. How come I didn’t spot the typo from the start! Looked everywhere but not on my structure and bitfields…

No problem with the compiler as I have control on the one we use, and this approach works perfectly for some other parsing structures.

In case it is of any help for anyone, here is the raw frame, the AC-specific raw payload, and the decrypted ac payload I’m trying to parse :

e1 02 10 00 42 a3 08 ec b4 82 c0 4a c6 80 e3 01 b1 7c 41 1d e1 da 52 <= raw frame
                              c0 4a c6 80 e3 01 b1 7c 41 1d e1 da 52 <= AC Charger crypted payload
                              06 00 d5 aa 01 ff ff ff ff ff ff ff ff <= AC Charger clear payload

Which decodes to:
device state: 0x06 (6=storage)
v1 = 27.73 V
i1 = 1.3 A

Thanks for pointing out the syntax !