Response not detected #241

reflexsa · 2024-04-10T19:34:48Z

Thanks again for the library.
I seem to have some connectivity between my ELM327 and my Wemos D1 R32. However on the rpm example I receive "Response not detected", followed by 'WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0"

It looks like some of the AT queries function but I'm not sure if I am missing something for the rpm.
I'm not sure if the lack of response is due to not selecting a specific protocol.
Apologies for the formatting of the below, looks fine in editing but seems to have no spacing when previewed for some reason.

Thank you for any assistance.

Sending the following command/query: AT D
	Received char: T
	Received char: D
	Received char: A
	Received char: 8
	Received char: 1
	Received char: _
	Received char: V
	Received char: 0
	Received char: .
	Received char: 1
	Received char: 2
	Received char: \r
	Received char: \n
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: TDA81V0.12OK
Clearing input serial buffer
Sending the following command/query: AT Z
	Received char: A
	Received char: T
	Received char: _
	Received char: Z
	Received char: \r
	Received char: E
	Received char: L
	Received char: M
	Received char: 3
	Received char: 2
	Received char: 7
	Received char: _
	Received char: v
	Received char: 2
	Received char: .
	Received char: 1
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATZELM327v2.1
Clearing input serial buffer
Sending the following command/query: AT E0
	Received char: A
	Received char: T
	Received char: _
	Received char: E
	Received char: 0
	Received char: \r
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATE0OK
Clearing input serial buffer
Sending the following command/query: AT S0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT AL
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT ST 00
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT SP A0
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0`

The text was updated successfully, but these errors were encountered:

jimwhitelaw · 2024-04-10T21:08:18Z

Note that any time you get a "?" response it means the ELM327 did not understand the command sent. This can happen even with documented AT commands as some clones don't implement the full command set.

When setting protocol to Auto, the ELM327 does not do the protocol search immediately, rather it does so on the first PID query to the ECU. The protocol search can take some time, so you need to account for that or it will time out. If you're using myELM327.begin(), this will be done for you, otherwise you can copy the code into your own program.

ELMduino/src/ELMduino.cpp

Lines 104 to 138 in e81f308

    
           // Automatic searching for protocol requires setting the protocol to AUTO and then 
        
           // sending an OBD command to initiate the protocol search. The OBD command "0100" 
        
           // requests a list of supported PIDs 0x00 - 0x20 and is guaranteed to work 
        
           if ((String)protocol == "0") 
        
           { 
        
               // Tell the ELM327 to do an auto protocol search. If a valid protocol is found, it will be saved to memory. 
        
               // Some ELM clones may not have memory enabled and thus will perform the search every time. 
        
               sprintf(command, SET_PROTOCOL_TO_AUTO_H_SAVE, protocol); 
        
               if (sendCommand_Blocking(command) == ELM_SUCCESS) 
        
               { 
        
                   if (strstr(payload, RESPONSE_OK) != NULL) 
        
                   { 
        
                       // Protocol search can take a comparatively long time. Temporarily set 
        
                       // the timeout value to 30 seconds, then restore the previous value. 
        
                       uint16_t prevTimeout = timeout_ms; 
        
                       timeout_ms = 30000; 
        
                       int8_t state = sendCommand_Blocking("0100"); 
        
                       if (state == ELM_SUCCESS) 
        
                       { 
        
                           timeout_ms = prevTimeout; 
        
                           connected = true; 
        
                           return connected; 
        
                       } 
        
                       else if (state == ELM_BUFFER_OVERFLOW) 
        
                       { 
        
                           while (elm_port->available()) 
        
                               elm_port->read(); 
        
                       } 
        
                       timeout_ms = prevTimeout; 
        
                   } 
        
               } 
        
           }

reflexsa · 2024-04-11T04:50:36Z

Thanks for the reply, so I assume I would add this to the 'void setup()'?
I plan to use protocol #6 as my vehicle seems to not be too happy when on automatic mode:
myELM327.initializeELM(6,500);

jimwhitelaw · 2024-04-11T05:22:35Z

Yes, that should work. If you specify the protocol in initializeELM()) then the protocol search is not needed.

reflexsa · 2024-04-11T05:54:07Z

For some reason if I add that it seems that the ESP gets stuck in basically a bootloop. I'm not sure if it is just the placement of the initialize function. I suspect it should maybe move between the ELM port connect and before the myELM327.begin. I'm using the ESP_Bluetooth_Serial example to start with so the setup looks as follows:

void setup()
{
#if LED_BUILTIN
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
#endif
  myELM327.initializeELM(6,500); //set protocol and data timeout
  DEBUG_PORT.begin(115200);
  SerialBT.setPin("1234");
  ELM_PORT.begin("ArduHUD", true);
  
  if (!ELM_PORT.connect("OBDII"))
  {
    DEBUG_PORT.println("Couldn't connect to OBD scanner - Phase 1");
    while(1);
  }

  if (!myELM327.begin(ELM_PORT, true, 2000)) //,ISO_15765_11_BIT_500_KBAUD can add instead of auto initialize?
  {
    Serial.println("Couldn't connect to OBD scanner - Phase 2");
    while (1);
  }

  Serial.println("Connected to ELM327");
}

PowerBroker2 · 2024-04-11T14:23:27Z

I would not call initializeELM() directly, but set all parameters in begin() instead.

reflexsa · 2024-04-11T16:52:26Z

Sadly I'm still a bit stuck. Seem to just get this response after the initial AT items. I tried setting the protocol in 3 ways. Leaving it as auto and then tried these:
if (!myELM327.begin(ELM_PORT, true, 2000,6))
And
if (!myELM327.begin(ELM_PORT, true, 2000,ISO_15765_11_BIT_500_KBAUD))

It could be that I'm changing that in the wrong place. If I am assuming correctly it looks like I can talk to the adapter but not to the vehicle. It does work in torque so I'm guessing it's just a setting or something

Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0

PowerBroker2 · 2024-04-12T00:40:43Z

"NO DATA" means your ELM can't talk to the car for that particular PID. "?", however, means the ELM doesn't recognize the PID request. Not sure why it wouldn't recognize 010C1, considering it's an often used and standard PID...

reflexsa · 2024-04-12T04:28:59Z

Thank you. I may mess around in Torque to see if I can find out what request it is using for RPM for example. I did not set up anything special in the app so I assumed it was using fairly standard PIDs. Sorry that the testing and responses take so long, I suspect we are in rather different time zones and I only have an hour or so in the evenings to experiment

jimwhitelaw · 2024-04-12T05:15:32Z

@reflexsa It's easier to help if you can post as much data as possible. The full sketch and the serial debug output.

reflexsa · 2024-04-12T08:12:50Z

Is the serial debug output basically what is in the serial monitor when the debug option is 'true' in the . begin function?

reflexsa · 2024-04-12T08:25:02Z

Below is the sketch which is the "ESP32_Bluetooth_Serial" example using the pincode. For the protocol I have tried changing:
if (!myELM327.begin(ELM_PORT, true, 2000))
to
if (!myELM327.begin(ELM_PORT, true, 2000,6))
to
if (!myELM327.begin(ELM_PORT, true, 2000,ISO_15765_11_BIT_500_KBAUD))
to
if (!myELM327.begin(ELM_PORT, true, 2000,'6'))

#include "BluetoothSerial.h"
#include "ELMduino.h"


BluetoothSerial SerialBT;
#define ELM_PORT   SerialBT
#define DEBUG_PORT Serial


ELM327 myELM327;


uint32_t rpm = 0;


void setup()
{
#if LED_BUILTIN
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
#endif

  DEBUG_PORT.begin(115200);
  SerialBT.setPin("1234");
  ELM_PORT.begin("ArduHUD", true);
  
  if (!ELM_PORT.connect("OBDII"))
  {
    DEBUG_PORT.println("Couldn't connect to OBD scanner - Phase 1");
    while(1);
  }

  if (!myELM327.begin(ELM_PORT, true, 2000))
  {
    Serial.println("Couldn't connect to OBD scanner - Phase 2");
    while (1);
  }

  Serial.println("Connected to ELM327");
}


void loop()
{
  float tempRPM = myELM327.rpm();

  if (myELM327.nb_rx_state == ELM_SUCCESS)
  {
    rpm = (uint32_t)tempRPM;
    Serial.print("RPM: "); Serial.println(rpm);
  }
  else if (myELM327.nb_rx_state != ELM_GETTING_MSG)
    myELM327.printError();
}

The output in the serial monitor is the below (once it begins asking for PID12 it will just keep repeating the same section that I posted above).

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4
Clearing input serial buffer
Sending the following command/query: AT D
	Received char: T
	Received char: D
	Received char: A
	Received char: 8
	Received char: 1
	Received char: _
	Received char: V
	Received char: 0
	Received char: .
	Received char: 1
	Received char: 2
	Received char: \r
	Received char: \n
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: TDA81V0.12OK
Clearing input serial buffer
Sending the following command/query: AT Z
	Received char: A
	Received char: T
	Received char: _
	Received char: Z
	Received char: \r
	Received char: E
	Received char: L
	Received char: M
	Received char: 3
	Received char: 2
	Received char: 7
	Received char: _
	Received char: v
	Received char: 2
	Received char: .
	Received char: 1
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATZELM327v2.1
Clearing input serial buffer
Sending the following command/query: AT E0
	Received char: A
	Received char: T
	Received char: _
	Received char: E
	Received char: 0
	Received char: \r
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATE0OK
Clearing input serial buffer
Sending the following command/query: AT S0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT AL
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT ST 00
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT SP A0
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0

jimwhitelaw · 2024-04-13T03:22:18Z

Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work

Looks like it's still trying to set Auto protocol search and then times out on the next call ("010C1"). If the specific protocol is being set properly in your begin() method, then we should see:

Sending the following command/query: AT SP A0

reflexsa · 2024-04-13T10:40:45Z

Ideally I should use protocol ID 6. With the above I just left the default code which I assumed would try the auto search. I'm not sure why it would not send SP A0 and is for some reason sending SP 0.

I'm not sure if I am getting closer or further away at this point using '6' for the protocol:

Clearing input serial buffer
Sending the following command/query: AT TP A6
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 6
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work

PowerBroker2 · 2024-04-13T13:15:27Z

Thanks to @jimwhitelaw this should be fixed in #242. Can you retest with the main branch?

reflexsa · 2024-04-13T13:36:19Z

Thank you both. I will hopefully retest in an hour or so

reflexsa · 2024-04-13T15:09:23Z

This is the new output:

Clearing input serial buffer
Sending the following command/query: AT TP A6
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 6
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0

reflexsa · 2024-04-14T06:23:22Z

I also wanted to ask. I see the query for RPM is being sent as '010C1'. What is the 1 at the end for?

jimwhitelaw · 2024-04-14T08:11:07Z

The 1 at the end is telling the ELM327 that we expect only one response for this query. This can speed up some queries because the ELM doesn’t have to wait for possible additional responses.

reflexsa · 2024-04-15T11:03:16Z

Is it easily possible to remove this 1 from the query? I would just like to test if that is what is causing my issue. I have been browsing through the cpp file but I'm not exactly sure where is the best place to change this.
I suspect my adapter's firmware may not support requesting a single response but I will check the firmware tonight as it looks like this was only introduced in v1.3

PowerBroker2 · 2024-04-16T01:55:08Z

You can use the ESP32 test sketch to input AT commands and PID queries manually for testing purposes like this.

reflexsa · 2024-04-16T18:08:48Z

Ok I think I have some progress to report. I tried out the ESP32 test sketch and had the following responses. I have noticed that my adapter is not the 'PIC' kind so maybe doesn't support all the functions. I have ordered what I hope is a PIC based version but will see when it arrives. In the meantime please see the 'serial output' below. It looks like if I query with '010C' I get a response but when using '010C1' it does not (just included from where I set the protocl):

>AT SP 6
OK

>010C
410C0000
410C0000

>010F
410F40

>01011
?

>010B
410B64

>010C1
?

>010C
410C0000
410C0000

>010C
410C0D70
410C0D78

>010C
410C0D74
410C0D74

>010C
410C0D74
410C0D58

jimwhitelaw · 2024-04-16T18:45:59Z

Yes, it looks like some progress and I agree that what you're seeing is probably related to the specific adapter you're using. It seems a bit unusual that some queries return a single response and most return two responses. In any case, as you've discovered, appending the 1 is not understood by the adapter. If you wanted to permanently stop sending the suffix 1 for your queries, you'd want to modify this code in the formatQuery() method to set query[6-8] all to '\0', although I think a different adapter is a better option:

ELMduino/src/ELMduino.cpp

Lines 230 to 245 in 464ecaa

    
           if (num_responses > 0xF) 
        
           { 
        
               query[6] = ((num_responses >> 4) & 0xF) + '0'; 
        
               query[7] = (num_responses & 0xF) + '0'; 
        
               query[8] = '\0'; 
        
               upper(query, 8); 
        
           } 
        
           else 
        
           { 
        
               query[6] = (num_responses & 0xF) + '0'; 
        
               query[7] = '\0'; 
        
               query[8] = '\0'; 
        
               upper(query, 7); 
        
           }

reflexsa · 2024-04-16T18:57:53Z

Thank you both for the help so far. I'm hoping the other adapter will also happen to work on auto protocol as well just to make things more convenient. Will report back in the next day or two

PowerBroker2 · 2024-04-16T19:51:51Z

I added a specifyNumResponses boolean flag to the main class. If you set it to false and then run the queries, you should have success without having to edit the lib files.

Can you test the main branch code and let me know if it fixes things for you?

reflexsa · 2024-04-17T17:03:05Z

Ok I have bad news and bad news.
So I tested using the main branch and ESP_Bluetooth_Serial sketch changing the flag using the following:
myELM327.specifyNumResponses = false;

This resulted in the below output. Strangely, the "C" in the query has become a "<". I'm not sure if that is because of the way I set the flag. The second unfortunate thing was the new adapter I ordered turned out to have the exact same hardware even though it was advertised otherwise. I will order a different one and hope for the best...

Service: 1
PID: 12
Normal length query detected
Query string: 010<
Clearing input serial buffer
Sending the following command/query: 010<
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410<
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning

jimwhitelaw · 2024-04-17T18:06:30Z

I found the issue with the “<“ char and submitted a fix (#244). Please update your main branch and retest. Thx

reflexsa · 2024-04-17T19:17:24Z

Thank you! It looks like we have had success! For reference the adapter that was giving the hassles shows up as a version v2.1 in Torque with some notes of it being a cheap clone. I still plan to get a better adapter but glad this one can work especially for initial prototyping.

Please see the output below, rpm looks correct:

Service: 1
PID: 12
Normal length query detected
Query string: 010C
Clearing input serial buffer
Sending the following command/query: 010C
	Received char: 4
	Received char: 1
	Received char: 0
	Received char: C
	Received char: 0
	Received char: D
	Received char: 9
	Received char: 6
	Received char: \r
	Received char: \n
	Received char: 4
	Received char: 1
	Received char: 0
	Received char: C
	Received char: 0
	Received char: D
	Received char: 8
	Received char: C
	Received char: \r
	Received char: \n
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 410C0D96410C0D8C
Expected response header: 410C
Double response detected
64-bit response: 
	responseByte_0: 150
	responseByte_1: 13
	responseByte_2: 0
	responseByte_3: 0
	responseByte_4: 0
	responseByte_5: 0
	responseByte_6: 0
	responseByte_7: 0
RPM: 869

PowerBroker2 · 2024-04-17T22:12:33Z

Fixed in version 3.3.0

reflexsa added the question Further information is requested label Apr 10, 2024

reflexsa assigned PowerBroker2 Apr 10, 2024

jimwhitelaw mentioned this issue Apr 16, 2024

How to change OBD protocol #240

Closed

PowerBroker2 closed this as completed Apr 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Response not detected #241

Response not detected #241

reflexsa commented Apr 10, 2024 •

edited by jimwhitelaw

Loading

jimwhitelaw commented Apr 10, 2024 •

edited

Loading

reflexsa commented Apr 11, 2024

jimwhitelaw commented Apr 11, 2024

reflexsa commented Apr 11, 2024

PowerBroker2 commented Apr 11, 2024

reflexsa commented Apr 11, 2024

PowerBroker2 commented Apr 12, 2024 •

edited

Loading

reflexsa commented Apr 12, 2024

jimwhitelaw commented Apr 12, 2024

reflexsa commented Apr 12, 2024

reflexsa commented Apr 12, 2024

jimwhitelaw commented Apr 13, 2024

reflexsa commented Apr 13, 2024

PowerBroker2 commented Apr 13, 2024

reflexsa commented Apr 13, 2024

reflexsa commented Apr 13, 2024

reflexsa commented Apr 14, 2024

jimwhitelaw commented Apr 14, 2024

reflexsa commented Apr 15, 2024 •

edited

Loading

PowerBroker2 commented Apr 16, 2024

reflexsa commented Apr 16, 2024

jimwhitelaw commented Apr 16, 2024

reflexsa commented Apr 16, 2024

PowerBroker2 commented Apr 16, 2024

reflexsa commented Apr 17, 2024

jimwhitelaw commented Apr 17, 2024

reflexsa commented Apr 17, 2024 •

edited

Loading

PowerBroker2 commented Apr 17, 2024

Response not detected #241

Response not detected #241

Comments

reflexsa commented Apr 10, 2024 • edited by jimwhitelaw Loading

jimwhitelaw commented Apr 10, 2024 • edited Loading

reflexsa commented Apr 11, 2024

jimwhitelaw commented Apr 11, 2024

reflexsa commented Apr 11, 2024

PowerBroker2 commented Apr 11, 2024

reflexsa commented Apr 11, 2024

PowerBroker2 commented Apr 12, 2024 • edited Loading

reflexsa commented Apr 12, 2024

jimwhitelaw commented Apr 12, 2024

reflexsa commented Apr 12, 2024

reflexsa commented Apr 12, 2024

jimwhitelaw commented Apr 13, 2024

reflexsa commented Apr 13, 2024

PowerBroker2 commented Apr 13, 2024

reflexsa commented Apr 13, 2024

reflexsa commented Apr 13, 2024

reflexsa commented Apr 14, 2024

jimwhitelaw commented Apr 14, 2024

reflexsa commented Apr 15, 2024 • edited Loading

PowerBroker2 commented Apr 16, 2024

reflexsa commented Apr 16, 2024

jimwhitelaw commented Apr 16, 2024

reflexsa commented Apr 16, 2024

PowerBroker2 commented Apr 16, 2024

reflexsa commented Apr 17, 2024

jimwhitelaw commented Apr 17, 2024

reflexsa commented Apr 17, 2024 • edited Loading

PowerBroker2 commented Apr 17, 2024

reflexsa commented Apr 10, 2024 •

edited by jimwhitelaw

Loading

jimwhitelaw commented Apr 10, 2024 •

edited

Loading

PowerBroker2 commented Apr 12, 2024 •

edited

Loading

reflexsa commented Apr 15, 2024 •

edited

Loading

reflexsa commented Apr 17, 2024 •

edited

Loading