STM32L496 (COMP1/COMP2): False Comparator Edges During LoRa TX/RX

[Mounika_Navtech]

Hello,

I am using STM32L496VGT6 with COMP1 and COMP2 to monitor the output voltage of a pressure transmitter. The MCU operates in STOP1 mode most of the time, where the comparator behaves correctly.

However, in RUN mode, whenever the SX1262 LoRaWAN module transmits or opens RX1/RX2 slots, I see continuous false edges from the comparator:

• If 0.255 < Vin < VL (0.275 V) → I get continuous falling edges.

• If VL < Vin < VH (0.55 V) → I get continuous rising edges.

• This only happens during LoRaWAN TX or RX windows, not during idle.

•  

  Log :

   

   

  **comp2 Falling edge TX on freq 866585000 Hz ...

  **comp1 Rising edge RX_1 on freq 865062500 Hz

  What I tried:

  • COMP configured with medium/high hysteresis.

  • Added blanking source using TIM3 OC channels, started before Radio TX/RX and stopped after.

  • Added RC filter (10 kΩ + 10 µF) at COMP input. Still see one false edge every TX/RX.

  • In STOP1 mode: comparator works fine (only one edge when Vin actually crosses threshold).

  • In RUN mode: false edges appear only during SX1262 activity.

  My setup:

  • STM32L496VGT6

  • SX1262 LoRaWAN module (SPI + DIO handled by MCU)

  • COMP1/COMP2 monitoring pressure transmitter voltage divider

  Questions:

  1. Is this a known issue where LoRaWAN TX/RX (RF or digital noise) couples into STM32 comparators?

  2. What is the best way to synchronize COMP blanking with LoRa activity (e.g. using SX1262 DIO pins to gate blanking)?

  3. Do you recommend hardware filtering/buffering (e.g. op-amp buffer before COMP input, shielded layout) to reduce RF-induced false triggers?

  Any application notes, example designs, or recommendations would be highly appreciated.

  Thanks in advance!

[Andrew Neil]

---

@Mounika_Navtech wrote:

I am using STM32L496VGT6 with COMP1 and COMP2 to monitor the output voltage of a pressure transmitter. !

---

What pressure sensor?

Please show your schematic.

Some good, clear photos of your setup may help.

See: How to write your question to maximize your chances to find a solution

 

---

@Mounika_Navtech wrote:

• 1. Is this a known issue where LoRaWAN TX/RX (RF or digital noise) couples into STM32 comparators?

---

Yes, RF and digital noise are both Real Things - Not specific to LoRa or SX1262 or STM32.

Also note that radios typically have high peak currents - which can cause power supply noise.

Have you put an oscilloscope onto those lines to see what's actually happening there?

 

[Mounika_Navtech]

Thank you for your reply,

No I did not use oscilloscope.  but I am connecting comparator output to normal gpio external interrupt . using comp1 for rising edge and comp2 for falling edge . whenever lorawan tx , rx1 & rx2 is coming  getting continuous falling edges / rising edges  based on given condition. 

 

we are using voltage pressure transmitter (ACMO) 12v input and output is 0 - 5v. but now iam not connecting PT. iam just testing with nucleo l496 board with lorawan connection and giving voltage to comparator from otii device.

please find below logs & kindly provide me any solution

2025-09-29 21:19:22 --> **comp2 Falling edge
2025-09-29 21:19:22 --> 24s263:TX on freq 866585000 Hz at DR 0
2025-09-29 21:19:22 -->
2025-09-29 21:19:22 --> ****** Health Frame Sent ********
2025-09-29 21:19:24 --> 26s267:MAC txDone
2025-09-29 21:19:24 -->
2025-09-29 21:19:24 --> **comp2 Falling edge
2025-09-29 21:19:24 --> calling LoRaMacProcess
2025-09-29 21:19:26 --> HAL_RTC_AlarmAEventCallback
2025-09-29 21:19:26 --> 27s304:RX_1 on freq 866585000 Hz at DR 0
2025-09-29 21:19:26 -->
2025-09-29 21:19:26 --> **comp2 Falling edge
2025-09-29 21:19:26 --> 27s510:MAC rxTimeOut
2025-09-29 21:19:26 -->
2025-09-29 21:19:26 --> **comp2 Falling edge
2025-09-29 21:19:26 --> cal
2025-09-29 21:19:26 --> ling LoRaMacProcess
2025-09-29 21:19:26 --> HAL_RTC_AlarmAEventCallback
2025-09-29 21:19:27 --> 28s267:RX_2 on freq 866550000 Hz at DR 2
2025-09-29 21:19:27 --> 28s358:MAC rxTimeOut
2025-09-29 21:19:27 -->
2025-09-29 21:19:27 --> **comp2 Falling edge
2025-09-29 21:19:27 --> calling LoRaMacProcess
2025-09-29 21:19:27 -->
2025-09-29 21:19:27 --> ###### ========== MCPS-Confirm =============
2025-09-29 21:19:27 --> ###### U/L FRAME:0003 | PORT:2 | DR:0 | PWR:0 | MSG TYPE:UNCONFIRMED

[Andrew Neil]

---

@Mounika_Navtech wrote:

No I did not use oscilloscope. 

you need to do that to understand what's actually going on.

Software logs won't help with a hardware problem!

Again, please post schematics and photos.

See: How to write your question to maximize your chances to find a solution

[Mounika_Navtech]

We don’t have an oscilloscope, but we do have a Picoscope. I will check with that and update you. Please find below the setup image, where a white jumper connects from Comparator 1 pin (PB2) to the supply through a 10 kΩ resistor

 

 

We are using a window comparator to monitor high and low threshold voltages, with the threshold levels provided to the comparator through the on-chip DAC peripheral. Please find below the schematic, which I have drawn for testing purposes. Since this is only for testing, we do not have any official documented schematic.

 

 

[Andrew Neil]

With masses of long flying wires like that, it's not surprising that you pick up noise!

[Mounika_Navtech]

Thank you for your suggestion.

I will solder the LoRaWAN pins to my Nucleo board, which should help avoid the false triggerings.

[Mounika_Navtech]

If we move this design to a properly routed PCB, would this noise issue likely be reduced or avoided?

 

 

I tried another approach by using blanking sources for both comparators with timers in output compare mode. This reduces the number of false triggers, but does not completely eliminate them. Is this a good method to avoid noise? If so, could you suggest the proper way to use the blanking source functionality, and how to configure the timer parameters in the .ioc file?