//I don't list the RX and TX as they are working and connected directly to the hardware pins that are appropriate#define FONA_RST 5 //Assuming I connect to GPIO 5#define FONA_RI 6 //Assuming I connect to GPIO 6

Yes, that's correct.

tkisner wrote:I did notice that there is an RST pin labeled on the MO board. Is that the pin I should use located in the top left of the pinout diagram of the MO

No, that's the pin that forces the SAMD21 microcontroller on the Feather M0 to reset. It's only an input, and will immediately terminate any code that happens to be running on the board.

The FONA's RST pin does the same thing to the SIM808 module, and you need to connect that pin to one of the Feather's GPIO pins. The Feather needs to be able to force the SIM808 to reboot in a known state.

tkisner wrote:I believe I want to use the IDE reference number for the GPIO pin, the numbers in purple, and not the physical pin numbers, the numbers in gray.

That's correct. The other labels describe alternate functions for each pin, and we include the physical pin number because that makes it easier to look things up in the datasheet.

You don't need any of that information if you're using a pin for simple GPIO with ditigalRead() and digitalWrite().

tkisner wrote:Am I also correct in my understanding in order for the SMS Auto Reponse sketch to work, RI needs to be connected and functioning in order to notify of the received SMS as an interrupt?

Yes.

By itself, the microcontroller has no way to know whether the SIM808 has received an SMS. It could use AT-commands to check at regular intervals.. a technique called 'polling'.. but that makes both devices do a lot of work for a condition where the answer is usually 'nothing new to report'.

That's why the SIM808 has an RI pin: it holds the voltage on that pin high most of the time, but pulls RI low for about 125ms when it receives a call or an SMS. Connecting the FONA's RI pin to a GPIO pin on the Feather lets the microcontroller check for messages without having to use AT-commands.

The microcontroller could poll its GPIO pin.. check it every 100ms to see if the signal is high or low.. which is faster and easier than using AT-commands, but still does a lot of work for something that almost never chages. The alternative is to configure another circuit connected to the pin so it sends the microcontroller a message any time it sees the signal drop from high to low. Together, the circuit and the message to the microcontroller are called an 'interrupt'.

When the microcontroller receives an interrupt message, it has the option to stop executing the code currently running and run another function called an 'interrupt handler' or 'interrupt service routine' (ISR). Then when the ISR is done, the microcontroller can go back to the previous code and pick up where it left off. Interrupts are a convenient way to inject new inforamation into code without having to poll for it.

and it looks like that code doesn't use interrupts at all. It checks the function .available() to see if there's any incoming message from the FONA. That would mean the problem is related to the Serial connection.

It wont let me post the exact code as it says that "I+M+E+I" and "i+m+e+i" are banned spam words but the code is just the FONA_SMS_RESPONSE example with the only change being my define which we have already discussed and then enabling hardware serial and commenting the 3 software serial lines out. i have posted that code below.

#include "Adafruit_FONA.h"

#define FONA_RST 5#define FONA_RI 6

// this is a large buffer for replieschar replybuffer[255];

// We default to using software serial. If you want to use hardware serial// (because softserial isnt supported) comment out the following three lines // and uncomment the HardwareSerial line//#include <SoftwareSerial.h>//SoftwareSerial fonaSS = SoftwareSerial(FONA_TX, FONA_RX);//SoftwareSerial *fonaSerial = &fonaSS;

Interesting thought, but the FONA was reporting FONA OK and the SMS was being received just not auto responded to.

So I got an Arduino UNO and hooked up the FONA 808 to it to make sure the Hardware was working and to limit some variables. It worked perfectly and was very easy to hook up. It used Software Serial and not Hardware Serial. Is there a board that can use both so I could test both ways on the same Hardware? So this leaves me wondering what is the difference in Software Serial from Hardware serial because this is the main difference as MO SAMD cannot use Software Serial. I thought this is where you were going in your last suggestion but that didnt fix it.

Can you set up a MO adalogger or proto with an FONA 808 and try it. It only takes a couple minutes to see the issue.

I will do that. I want to make sure I restate. The FONA 808 works with my MO through Hardware serial. I am not able to run the SMS_AUTO_RESPONSE correctly for some reason. I can run FONA_TEST and it works great.

Since you have it connected, can you run SMS_AUTO_RESPONSE and see if you get an auto response please?

Thank you,Travis

Last edited by tkisner on Mon Feb 11, 2019 3:54 pm, edited 1 time in total.

I would still really appreciate a response to my posts. If this were complicated ask then I would understand but I am merely asking does hardware serial work on FONA_SMS_Response example with a Feather MO adalogger and a FONA 808?

I can post a photo of my connections, but I think I found something relevant in the code:

I threw in some diagnostic Serial.print() statements to check the contents of the input buffer, and occasionally saw fragments of a string instead of a full message. Modifying the input read loop (lines 97-101) to spend longer waiting for the next input character got rid of the erroneous breaks:

That did not solve the issue it seems. I went back and tried to run FONA_TEST again and i did notice that the reads dont work as reliably as they should. Is there something that can be done to help with the reliability of the serial communication? The reads sometimes works such as the r and R command to read the texts stored in the Sim card but it is very intermittent. It does work after several tries but many times on the R (Read all), it will fail before reading 1, a few, or all of the texts on the Sim card. I wonder if that could be some indicator as to why the AutoResponse is not working as I believe it is checking to see if there is a text message that has been received.