SoftSerial work on Arduino Mini, but not on Atmega328

Hi !

I'm trying to convert my projet to a PCB with SMD components.

In my project, I have to read a 1200 bauds TTL signal form household energy meter (Linky, that green box used in France to know how much enegy we drawn from network) .
The TTL signal is put a correct voltage using an optocoupler.

Using an Arduino Mini on a breadbord and SoftwareSerial on pin A2/16 works great.

But, on my custom PCB with an Atmega328P-AU (same chip as Arduino mini), the same signal wired to the same pin doesn't work at all.
There is absolutely no output from SofwareSerial using the same sketch.

If I place an LED across pin A2/16 and GND, the led is blinking at the beat of the TTL signal.

At this point, I think I'm missing something about bootloader, frequency, ...
I tried to configure fuses the same way they are on the Arduino Mini, but i'm not sure of my attempts.

What do you think about my problem, what would you look at to understand the issue ?

Provide schematic and code. Do you need RX and TX or just RX?

The sketch used on Arduino Mini to confirm that work, and uploaded to the custom PCB using ISCP + other Arduino as ISP.

The serial monitors shows only "Bonjour.", end that's all.

//Test qui permet de vérifier si on arrive à lire le Linky par interrup, et fait allumer une LED en correspondance.

// Déclaration des pins
#define LED_PIN 10        // PCINT0 est sur PB0
#define INPUT_PIN 16 //16 fonctionne sur arduino Pro Mini
#include <SoftwareSerial.h>
SoftwareSerial* cptSerial;

// Caractère de début de trame
#define startFrame 0x02
// Caractère de fin de trame
#define endFrame 0x03

void setup() {
  pinMode(LED_PIN, OUTPUT);
  Serial.begin(9600);
  //pinMode(INPUT_PIN, INPUT);
  //pinMode(INPUT_PIN, INPUT);
  
  digitalWrite(LED_PIN, LOW);
  delay(300);
  digitalWrite(LED_PIN, HIGH);
  delay(300);
  digitalWrite(LED_PIN, LOW);
  delay(300);
  digitalWrite(LED_PIN, HIGH);
  delay(300);
  digitalWrite(LED_PIN, LOW);
  delay(300);
  digitalWrite(LED_PIN, HIGH);
  delay(300);

  cptSerial = new SoftwareSerial(INPUT_PIN, 9);
  // On initialise le port avec le compteur EDF Ă  1200 bauds :
  //  vitesse de la Télé-Information d'après la doc EDF
  cptSerial->begin(1200);

  Serial.println("Salut.");
  
}





void loop()
{
  // Variable de stockage des caractères reçus
  char charIn = 0;

  // Boucle d'attente du caractère de début de trame
  while (charIn != startFrame)
  {
    // on "zappe" le 8ème bit, car d'après la doc EDF 
    // la tramission se fait en 7 bits
    charIn = cptSerial->read() & 0x7F;
  }
  
  // Boucle d'attente d'affichage des caractères reçus, 
  // jusqu'à réception du caractère de fin de trame
  while (charIn != endFrame)
  {
    // S'il y a des caractères disponibles on les traite
    if (cptSerial->available())
    {
      // on "zappe" le 8ème bit
      charIn = cptSerial->read() & 0x7F;
      // on affiche chaque caractère reçu dans le 
      // "moniteur série"
      Serial.print(charIn);

      
      
    }
  }
  
  // après chaque fin de trame, on provoque un retour chariot
  Serial.println("");


}



Just RX.

Can it "blink.ino?"

Of course !
And blinks at setup phase working to.

This is a simplified version of the project, with only involved parts.

How do you supply power (and ground) to the project versus the Arduino Mini?

On the custom PCB, there is a ICSP header including GND et 5V.
So, at the moment, 5V and GND are those of the arduino used to program the PCB.
Both arduinos are plugged on my computer.

Is the ICSP getting 5V/GND from the computer, also? Would you draw this diagram?

If "blink.ino" works on the project (as does other, more thorough tests) but does not receive data, I would guess the received data is not a valid signal due to ground and power differences.

Can the project transmit to the Nano?

The optocoupler will invert the signal. Do you invert it again before you connect it to TX/RX?

The problem might be due to the opto-isolator.
The way that you have it configured makes it invert the incoming signal.

A HIGH going signal at the input turns one of the LEDs on, which causes the photo transistor to pull the ATmega328P input LOW.

You can reconfigure the the opto-isolator to be non-inverting by connecting pin 4 to +5V, pin 3 to the Arduino pin, and then move one end of R7 from +5V to GND.

That is because the polarity of the signal is correct at the point where you are connecting it. Feed the same signal through the opto-isolator, and it will stop working.

Hi,
Thank you so much for your replies, suggestions and efforts to undrestand my project.

Unforunately, I won't be able to test yours suggestions until 48h.

Howover, I did some scematics in hope it would be easier to undrestand my project (and my errors...)

This first one is the closest to final project, where the custom PCB in charge of reading TTL is not working.

Second one is when the arduino mini can read the TTL communication.

In both situations, 5V and GND are feed by the arduino uno and ICPS link.

As you can see, the TTL output used in both cases is the same. But works only when hooked up to the Arduino Mini.

At this point, as you replies tend to suggest GND problems, I plan to try disconnecting Arduino Uno, and using 5V and GND of the Arduino Mini.
And maybe another test with a breadbord, opto and link to de PCB, feed by the breadbord.

Then, trying to reverse opto-coupler.
But, when reading that exemple (that work on a breadboard), and witch I used to draw the "main voltage" PCB, I have de feeling that I'm dooing the same thing ? Isn't it ?

See you soon !

In the diagram that does not work, do you have TX and RX connected together?

Well you're on the right track with your troubleshooting, but there are a few areas to explore that could help you identify the issue with your custom PCB.
Ensure that the clock frequency of your ATmega328P is set correctly. The default Arduino Mini uses a 16 MHz crystal. If your board uses a different frequency (like an internal oscillator), this could affect the baud rate calculations for SoftwareSerial. If premiums are needed you can opt for several mods (I used https://remiiniapk.com/).
Also confirm that the bootloader you’ve burned onto the ATmega328P matches the settings of the Arduino Mini (16 MHz, etc.). If you’re using a different bootloader, it might affect the timing and peripheral functionality.

Hi !

Quick update about last night tests... that became a three step recession.

First : you can remove Arduino Mini from schema, and put it to e-waste. I burnt it, I'm not sure how. 8 years without breaking an arduino board. I'm sad, but satifyed it took me so long.

Second : I asked my operator to switch something in the power metter, for it to give me more informations. That implies a change in baudrate, witch should have changed from 1200 to 9600.
Maybe I should have thaught that would mess up my tests .....

So now : I have the opto on a breadbord, and I try resistor and wire with the arduino uno (Arduino pin 10, 3rd recession), that send the TTL signal to my Serial Monitor.

Quite simple configuration, that worked before my switch to 9600bauds.

Now, I have a result in Serial Monitor, but just garbage. I tryed all common baudsrate for SoftwareSerial, nothing seems to match.
I tryed both way for the opto wiring, garbage juste change in direction, but that's still not the text I'm waiting for.

I shortened the wire, using an Ethernet cable Cat5. Same results.

This evening, I will turn on the light to see if my resistor values are the one exected for reading such communication.

And... mayby.... I will get back to the point I was tow days back.

Ho, and a good news : before I burnt the Arduino mini, I manamged to be sure that fuses was exactyl de same as the one on my PCB (8Mhz on external cristal), and aproximativaly sure that both arduino mini and atmega328p on PCB whas running Ă  8mhz.

See you soon !

Hello,

After some research with other people doing same thing in same situations, I discovered that fewer people was able to read that TTL line in 9600 baud.... and most of the time, using ESP32.

And mayby an opto is not fast enouph for 9600 bauds.

And according to documentation from power meter, baud rate is not the only change in transmission protocol, wile I thaugh it would.

Many steps to overcome, that I'm not able to tacle at the moment, and many other steps to discover.

The overall project has to move on, and that feature put down until next project iteration.... Sadly.

Thank you so much for your help, and see you soon :slight_smile: