A customer is using Telegraf for telemetry collector and this customer reports that telegraf has some issue for the values being read out of EVO PTX.
He shared us these symptoms "incorrect character/value" for both "lane_laser_output_power_dbm" and "lane_laser_receiver_power_dbm" from the collector.

This customer tried to use GNMIC subscribing the telemetry data from PTX EVO router, then got the same issue as below:

---------------------------------------------------------------------
    {
      "Path": "optics/lanediags/lane[lane_number=0]/lane_laser_output_power_dbm",
      "values": {
        "optics/lanediags/lane/lane_laser_output_power_dbm": "??" <<<
      }
    },
    {
      "Path": "optics/lanediags/lane[lane_number=0]/lane_laser_receiver_power_dbm",
      "values": {
        "optics/lanediags/lane/lane_laser_receiver_power_dbm": "?Y??-DD" <<<
      }
---------------------------------------------------------------------

The root cause is that the telemetry collectors are not interpreting the oc:ieeefloat32 data correctly.

The oc:ieeefloat32 data type is a typedef for a bytes value of length 4,so the data being received is 4 bytes of data in network byte order.  
The collector side should be receiving the data as defined in the render yang file and is responsible for interpreting the bytes correctly.

EVO PTX CLI outputs:

show interfaces diagnostics optics et-0/1/0 |grep "Lane|power" |except "threshold|alarm|off" 
    Module max power                          :  1.5 W
  Lane 0
    Laser output power                        :  0.7 mW / -1.54 dBm <<<
    Laser receiver power                      :  0.607 mW / -2.16 dBm<<<
<snippd>
    
    
1st test:

Collector VM gnmic display:

>gnmic -a 10.85.173.171:50051 -u labroot -p lab123 --log --insecure sub --mode once -e proto --path "/junos/system/linecard/optics"

--------------------------------data part -----------------------------
{
  "source": "10.85.173.171:50051",
  "subscription-name": "default-1746732742",
  "timestamp": 1746732743576238939,
  "time": "2025-05-08T19:32:23.576238939Z",
  "prefix": "interfaces/interface[name=et-0/1/0]",
  "updates": [
    {
      "Path": "snmp_if_index",
      "values": {
        "snmp_if_index": 668
      }
    },
    {
<snipped>
    {
      "Path": "optics/lanediags/lane[lane_number=0]/lane_laser_output_power_dbm",
      "values": {
        "optics/lanediags/lane/lane_laser_output_power_dbm": "v8AAAA=="  <<<<<<< base64 display 
      }
    },
    {
      "Path": "optics/lanediags/lane[lane_number=0]/lane_laser_receiver_power_dbm",
      "values": {
        "optics/lanediags/lane/lane_laser_receiver_power_dbm": "wAeuFA==" <<<<<<<<< base64 display 
      }
    },
    {
      "Path": "optics/lanediags/lane[lane_number=0]/lane_laser_bias_current",
      "values": {
        "optics/lanediags/lane/lane_laser_bias_current": 6.953
      }
    },
--------------------------------data part -----------------------------

Root Cause:

This is the Base64 interpretation and if you decode from base64 to binary, you can quite easily convert it to ieeefloat32. 

For example:

Base64: v8AAAA==
Binary: 10111111 11000000 00000000 00000000
Float32: -1.5

Base64: wAeuFA==
Binary: 11000000 00000111 10101110 00010100
Float32: -2.12

Tool links:
https://www.h-schmidt.net/FloatConverter/IEEE754.html
https://cryptii.com/pipes/base64-to-binary

2nd test:

Collector VM gnmic display:

>gnmic -a 10.85.173.171:50051 -u labroot -p lab123 --path /junos/system/linecard/optics --encoding PROTO sub --mode once --insecure --format flat

--------------------------------data part -----------------------------

interfaces/interface[name=et-0/1/0]/optics/frequency_error: NA
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_bias_current: 7
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_bias_current_high_alarm: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_bias_current_high_warning: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_bias_current_low_alarm: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_bias_current_low_warning: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_output_power_dbm: [191 197 30 184] <<<<< flat decimal display 
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_output_power_high_alarm: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_output_power_high_warning: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_output_power_low_alarm: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_output_power_low_warning: false
interfaces/interface[name=et-0/1/0]/optics/lanediags/lane[lane_number=0]/lane_laser_receiver_power_dbm: [192 7 174 20] <<<<<<flat decimal display 

--------------------------------data part -----------------------------

Root Cause:

This belongs to Decimal interpretation  and if you decode from decimal to hexadecimal, you can quite easily convert it to ieeefloat32 as below:

For examples:

Decimal:      191 197  30   184
Hexadecimal: 0xBF 0xC5 0x1E 0xB8
Float32:     -1.54

By using these links, you might convert "BFC51EB8" to -1.54.

Decimal:      192   7   174   20
Hexadecimal: 0xC0 0x07 0xAE 0x14
Float32:     -2.12

By using these links, you might convert "C007AE14" to -2.12.

Tool links:
https://www.h-schmidt.net/FloatConverter/IEEE754.html
https://cryptii.com/pipes/base64-to-binary

https://gnmic.openconfig.net/user_guide/event_processors/event_ieeefloat32/