Reading data from UART FIFO

Hi,

I'm trying to read data from my NFC tag SIC4310 with UART Interface. My NFC has 2 x 64-byte deep FIFO for UART/SPI data transfer via TX/RX.

With my code I get a ⸮192 for the letter E, does anyone has a idea? I already tested different baud rates.

Thanks :slight_smile:

#include <SoftwareSerial.h>

SoftwareSerial gtSerial(3, 4); // Arduino RX, Arduino TX

void setup() {
  Serial.begin(9600);    // serial / USB port
  gtSerial.begin(9600);  // software serial port
}

byte rx_byte = 0;        // stores received byte

void loop() {
  // check if byte available on the software serial port
  if (gtSerial.available()) {
    // get the byte from the software serial port
    // Serial.println("available");
    rx_byte = gtSerial.read();
    // Serial.write(rx_byte);
    Serial.println(rx_byte);
  }

}

factsheet-EN20150402172606-1279123908.pdf (322 KB)

What are you supposed to read ? Why the letter E should be there? You need to provide more info

It's a little bit complicated. I'm using a demo app for the NFC tag which sends different music tones through RX, TX in FIFO using uart. For the E tone I get ⸮192 but the other serial outputs are not consistent.
Is my code theoretically correct for just displaying everything that is received over RX/TX?

I want to send a picture over NFC with my smartphone to a e-paper display. The picture should be read with the NFC tag and the Arduino should get the picture over rx tx from the NFC tag. Then the picture will be displayed on the e-paper display connected to the Arduino board.

Your code is fine printing the bytes it gets. As you print a byte (and not a char) it’s normal to see numbers

You need to understand though how the NFC data is streamed => how do you configure UART mode, what triggers a read and how the data is structured coming in? There must be a more detailed datasheet for your component

Sry for the late reply, I tried to collect as much Information as possible before posting again.

  1. The send Data are byte Values plays a Midi Melody on a piezo speaker. Before sending the byte values, the method add the value 0xB1 for UART communication: buffer[0] = (byte) 0xB1;

  2. Using the code from this thread: Data Input demo sketch - Programming Questions - Arduino Forum , I was able to collect a little bit more Information about the received data.

    inputSeveral[0] = 0; // makes inputSeveral an empty string with just a terminator
    
    byte charCount = 0;  // the number of characters actually received - some may be lost
    byte ndx = 0;        // the index position for storing the character
    
    if (Serial.available() > 0) {
    
      while (Serial.available() > 0) { // keep going until buffer is empty
        if (ndx > maxChars - 1) { // -1 because arrays count from 0
          ndx = maxChars;     // if there are too many chars the extra ones are 
        }                     //   dumped into the last array element which will
                              //   be overwritten by the string terminator
        inputSeveral[ndx] = Serial.read();
        ndx ++;        
        charCount ++;
      }
      
      if (ndx > maxChars) {  // to make sure the terminator is not written beyond the array
        ndx = maxChars;
      }
      inputSeveral[ndx] = 0; // add a zero terminator to mark the end of the string
    }
    
    Serial.print("Num Chars Rcvd --- ");
    Serial.print(charCount);
    Serial.print("  ---  ");
    Serial.println(inputSeveral);

The Serial Monitor looks like this:

Num Chars Rcvd --- 7  ---  ⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 25  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 29  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 14  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 14  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 11  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 8  ---  ⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 26  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 29  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 12  ---  ⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 0  ---  
Num Chars Rcvd --- 11  ---  
Num Chars Rcvd --- 16  ---  
Num Chars Rcvd --- 17  ---

I'm definitely receiving some data, which (imo) are misinterpreted as 255 , 192, 0.

sorry don't get what you say... now you have a "Midi Melody on a piezo speaker" - where is the NFC from your first post ?

The SIC4310 (NFC Module) can play Midi sounds over a piezo speaker through the TX Port :smiley:
The SIC4130 gets the tone from a Android Application via NFC, and I can confirm that it's plays the right music.

I’m still unclear what you want to read. I feel your Android app is sending data through NFC it’s probably a hack to have the GPIO “vibrate” at the right frequency, your chip is not a midi player

I just want to read the output data over UART and I'm trying different ways to send data over NFC ( and the music is one of the ways ).

Here you can see a live video:

As you can read above, I can catch a few data, but there a not readable. I'm trying to understand how the data will be send over the UART communication and how to read them correctly.

Again - the data sent by the phone in this demo is most likely totally “unreadable” in the sense of expecting MIDI notes.

A buzzer generates a specific tone by making it vibrate at a certain frequency. Vibrating means a succession of HIGH and LOW state. So you have to Generates a square wave of the specified frequency (the tone function in arduino would have a 50% duty cycle ) on a pin.

Now if you send a byte at 11111111(bin) followed by a byte at 00000000(bin), your Tx pin will be HIGH for each 1 and LOW for each 0, meaning that you’ll see it vibrate at a certain frequency depending in baud rate.

By playing with the pattern sent you’ll vary the frequency the buzzer is producing hence the sound, but the value themselves are irrelevant, it’s a smart combination of baud rate and bits that is producing the sound

Thanks for the help, I found a way to read the data. It was a combination of false baud rate and that the serial monitor converts the output as ASCII. This topic can be closed.