2

I am designing an IoT device.

In first version, I forgot to put the LC filters as in the datasheet.

I found it after I get the prototyping board on my hands, but I thought it would be fine without these filters as I'd never seen such filters in the middle of internal UART lines before.

The first prototype is made. In testing, the UART communication often fails at checksum testing or some additional bits are appended at the end of stream.

As the pins are too small, it's difficult to check with an oscilloscope.

I suspect it might caused by the missing LC filter.

I updated the design with correct LC filters and it is still in PCBA process.

I'm not so sure if this will solve the buggy UART problem.

Why does it happen? Are there similar filter examples in low-speed digital communication between RF modules?

enter image description here

JRE
  • 67,678
  • 8
  • 104
  • 179
PCBCrew Engineer
  • 1,469
  • 1
  • 13
  • 1
    What data sheet are you referring to in your first sentence? How are you doing UART testing? What powers your circuit? Is it earthed? Did you route a ground connection between the circuit and the thing that tests the UART comms? Much detail is needed. – Andy aka Mar 08 '23 at 14:21
  • http://download.mikroe.com/documents/datasheets/M20050-1%20Datasheet.pdf – PCBCrew Engineer Mar 08 '23 at 15:07
  • The above comment is the datasheet I referred. My circuit is powered by batter and an LDO. No matter of such possible bugs in PCB layout, why did the module manufacturer put such LC filters on the UART rails? This was my question. – PCBCrew Engineer Mar 08 '23 at 15:08
  • Please incorporate the responses to my comment into your question please. – Andy aka Mar 08 '23 at 15:09
  • I added datasheet link to the question. – PCBCrew Engineer Mar 08 '23 at 15:12

2 Answers2

1

Probably a not so great way of stopping high frequency conducted emissions from reaching the GPS module. Usually ferrite beads are used.

Voltage Spike
  • 75,799
  • 36
  • 80
  • 208
-2

Why did the module manufacturer put such LC filters on the UART rails?

Normally you do not find such a second order low-pass filter for a UART connection.

Possibilities:

  • They have an internal problem with the microcontroller and use it as bugfix. Possibly you can find this in the errata of this chip what is used inside of this module.
  • The antenna-circuit can interfere somehow with the powerline and the GPIO-pins.
  • Another option would be the crystal on the module, if it is not very accurate, then this could explain the shift of the timing.
JRE
  • 67,678
  • 8
  • 104
  • 179
MikroPower
  • 1,338
  • 2
  • 11
  • Well, I never met any microcontroller having UART issue like that, from 8051 to ARM SoCs. In my opinion, If you know any microcontroller with such UART issue, please comment about it. The UART is very robust and easy-to-implement protocol. For crystal-problem, I cannot agree, either. UART is an asynchronous protocol, that means it is not much depending on both end's clock differences. – PCBCrew Engineer Mar 08 '23 at 17:16
  • 1
    I highly doubt any of the reasons you mention are solved by a filter on UART. To look from another perspective, what if the filter is not to make UART work, but to prevent noise from entering the sensitive GPS receiver via UART pins from a noisy MCU or PC? – Justme Mar 08 '23 at 17:45
  • @PCBCrewEngineer - If you send a long string and the timing is a bit out of sync, then the difference is getting bigger with the length of the string. I had this problem. The error in the µC baud-rate is mostly a bit different, so if the problem occur I shorten the strings which I send. In the datasheet you can see the error-listings for every baud-rate. Which frequency is the µC of your board using and which baud-rate do you use? Look at the error-values. – MikroPower Mar 08 '23 at 18:14
  • @Justme - The LC-filter is designed in such a way, that the outgoing (from the GPS-Module to the µC) noise will be filtered. So there must be a issue inside of the module. – MikroPower Mar 08 '23 at 18:18
  • 1
    @MikroPower If you send a long string, each byte (character) will be separately synchronized. It can't go out of sync, unless the baud rate is horribly wrong. UARTs tolerate baud rate mismatch up to 1% or 2% easily. And about the filter, you are correct that the caps are on MCU side of inductor, but it also means the inductors still block RF between chips, and caps still shunt any RF and noise from MCU, limit slew rate, and anyway one pin is in and one is out. – Justme Mar 08 '23 at 19:36
  • @Justme - The noise can go out, even from an input (RX) and with the separately synchronization at the beginning of each character you have right. – MikroPower Mar 08 '23 at 20:25
  • RIght now, I can get a valid reading value from MCU side only once per 3~4 tryings. I tried lower baudrates, too. Most messages are short enough, less than 16 bytes mostely. (but cannot be shorter cue to the default GPS messaging protocol). I cannot say whether baudrate/message length can improve correct receiving rate or not. To judget it, my current board is too noisy on this UART bus. – PCBCrew Engineer Mar 08 '23 at 22:06
  • I just hope my next PCBA will not have this issue again. And I also hope this question can help some people to not forget putting LC-filters when using this "annoying" GPS module. – PCBCrew Engineer Mar 08 '23 at 22:07