problem with GPS module using an attiny 1604 [SOLVED, it was just bad weather]

Hi everyone,
I'm building a device that should detect PM10 concentration values in the air with a simple sensor and send them together with its latitude and longitude to a server using a LoRa module.
I'm using an attiny1604 (I'm kinda forced to use it) as a microcontroller, the adafruit ultimate breakout as GPS module and a RFM9X for the transmission.
The problem is the GPS as I can send and read the PM10 values from the server, while I can only get 0.00 for latitude and longitude. I made tests close to windows and outdoor and I still get 0.00.
I'm using jtag2upidi (megaTinyCore) as programmer and default timer.
For the library I'm using TinyGPS++.
I used "prova" in order to see if the code inside the while cycles works and it doesn't as prova will always be==1.

Here the main code (sorry some comments are in italian)

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#define gpsPort ssGPS

#include <Arduino.h>

#include "LoRaWAN.h" 
#include "secconfig.h" 

/******************************
 DEFINIZIONI MODULO LoRa
 ******************************/
#define DIO0 1 //PIN FISICO 3
#define NSS 0 //PIN FISICO 2
RFM95 rfm(DIO0, NSS);
// Definisce la lunghezza del buffer dati
uint8_t Data_Length = 0x10;
// Definisce il layer LoRaWAN
LoRaWAN LoRa = LoRaWAN(rfm);
// Frame Counter per contare ogni Payload inviato
unsigned int Frame_Counter_Tx = 0;

/******************************
 DEFINIZIONI MODULO GPS
 ******************************/
static const int Rx = 7, Tx = 6;
static const uint32_t GPSBaud = 9600;

// The serial connection to the GPS device
SoftwareSerial ssGPS(Rx, Tx);
float lati, longi;
int latid, longid;
float latif, longif;
// The TinyGPS++ object
TinyGPSPlus tinyGPS;
// sensore
#define sensor 3 

int prova=1;

void setup( ) {
  Serial.begin(9600);
//Inizializzo il modulo RFM
 rfm.init();
/*Inizializza le chiavi di sessione ed applicazione e l'indirizzo del
nodo per il joining tra Nodo e Network Server attraverso tecnica ABP*/
 LoRa.setKeys(NwkSkey, AppSkey, DevAddr);
 pinMode(sensor,INPUT);

//   pinMode(Rx,INPUT);
//   pinMode(Tx,OUTPUT);   
  ssGPS.begin(GPSBaud);
}
void loop( ) {

 delay(4000);
 //smartDelay(1000);
 while (ssGPS.available()){
      tinyGPS.encode(ssGPS.read());
      prova=3;
 }
 unsigned char Data[Data_Length];
 int val=analogRead(sensor);
 while(tinyGPS.location.isValid()){
 lati=tinyGPS.location.lat();
   //longi=tinyGPS.location.lng();
   prova++;
 }
   
//aumento il Frame Counter
 Frame_Counter_Tx++;

 //Provo a stampare e trasmettere distanza come parte intera e decimale --> sprintf per l'attiny ha funzionalità limitate
  char *sgn = (lati < 0) ? "-" : "";
  //lati = (lati < 0) ? -lati : lati;
  latid = lati;                 
  latif = lati - latid;      
  int latiff = trunc(latif * 100); 


//Creo la stringa in cui stampo il buffer Data contenente la stringa di invio
 Data_Length = sprintf(Data,"Valore ~  %d ppm, Latitudine :%s%d.%02d , prova %d", val,sgn, latid, latiff, prova ); // 33 BYTE
/*Send_Data già modificato nella libreria; mancavano alcuni parametri che
permettevano la trasmissione a certi SF(Spreading Factor) e BW(Larghezze
di Banda)*/
//A fine sketch sono riportati i canali con SF e BW modificati nella libreria (sono riportati come riferimento per ricordarsene)
//txParameter viene scelto uguale a 5 perchè individua la casistica 5 per
//la trasmissione; quindi trasmetto ad un SF7 con BW di 125 kHz
 int txParameter=5;
/*Controllo sulla quantità di pacchetti inviati; considerando i tempi necessari
a sistemare e recuperare il sistema sotto terra, non volevamo inviare pacchetti fino a che le batterie non si fossero drenate;
si è quindi inserito un controllo sul contatore, in modo che quando esso arriva a
2000 la trasmissione si conclude definitivamente.*/
if (Frame_Counter_Tx < 2000)
 {
 LoRa.Send_Data(Data, Data_Length, Frame_Counter_Tx,txParameter);
 }
}

here secconfig.h

unsigned char NwkSkey[16] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
 0x09, 0x10, 0x11, 0x12, 0x13, 0x014, 0x15, 0x16 };
unsigned char AppSkey[16] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
 0x09, 0x10, 0x11, 0x12, 0x13, 0x014, 0x15, 0x16 };
unsigned char DevAddr[4] = { 0x00, 0x00, 0x00, 0x02 };

I'll also post what I get on the server.

alessandro_capresi:
I'll also post what I get on the server.

Valore- 456 ppm, Latitudine : 0.00, prova 1

Wiring diagram?

pylon:
Wiring diagram?

considering vcc as 1:
2 nss of rfm9x, 3 dio of rfm9x, 5 AO of MQ-7 sensor, 6 Tx of the GPS, 7 Rx of the GPS.
considering GND as 14:
13 sck of rfm9x, 12 MISO of rfm9x, 11, MOSI of rfm9x.

I used https://www.youtube.com/watch?v=AL9vK_xMt4E as base for the attiny1604.

maybe it is clear now

alessandro_capresi:
I used "prova" in order to see if the code inside the while cycles works and it doesn't as prova will always be==1.

With the wiring of the last post (I changed GPS's Rx and Tx pins) I get prova==3
and this is the code I changed

static const int Rx = 4, Tx = 5;

Hi.

What do your NMEA sentences look like?

John.

HillmanImp:
Hi.

What do your NMEA sentences look like?

John.

I don't know, I don't know how to read them without the transmission, as I should need 2 software serials.
I know the module and library I'm using work because I tried basic examples with Arduino Uno and they worked.

HillmanImp:
Hi.

What do your NMEA sentences look like?

John.

I mean they were normal sentences, but I don't what I'm getting now, I hoped to debug by reading the values on the server, but all I get is 0.00.

Could it be a problem between the USART of the 1604 and the softwareserial?

It is important to be able to read the NMEA output from the GPS module with a minimum of h/w and s/w. I look at the photo of your breadboard setup and think of all the elements in there that might not be working. I hate breadboards. They introduce voltage drops which can stop the GPS working or communicating correctly.

If I have problems I always make sure that the GPS module is producing legible NMEA sentences. I use a TTL/USB converter to do this. This converts the GPS output to USB protocol and that feeds into the Arduino IDE monitor. Simple.

You can also feed the GPS output (just its TX pin) into the Arduino and use a simple (very simple) sketch to read it and send it to the monitor.

GPS projects can have many problems. I feel I am not in charge unless I can easily see the raw data coming from the GPS module -- that is, the NMEA sentences.

Good luck.

John.

HillmanImp:
It is important to be able to read the NMEA output from the GPS module with a minimum of h/w and s/w. I look at the photo of your breadboard setup and think of all the elements in there that might not be working.

Everything else works fine, I get datas from the sensor and I can send transmissions to the server with the lora module.

HillmanImp:
If I have problems I always make sure that the GPS module is producing legible NMEA sentences. I use a TTL/USB converter to do this. This converts the GPS output to USB protocol and that feeds into the Arduino IDE monitor. Simple.

I can get a converter like that at the lab, but I don't know how to use it, any suggests/tutorials?

Alessandro,

You say everything is working fine but can you show us a screenshot of the NMEA sentences?

The converter has these pins at one end: 5v, TX, RX, GND. You connect these to the GPS module (GPS TX to converter RX). The other end is a USB male connector which plugs into a PC port. The GPS output is converted from TTL to USB protocol and can be viewed in the Arduino IDE serial monitor. The computer provides the power to the GPS.

The first thing to look for is legible sentences. If you do not get these then there is no point in trying to get a navigational fix.

When you get legible sentences take it outside (a laptop?) where you have a good view of the sky. You will see satellite data in the NMEA sentences.

Good luck,
John.

This is the output I get with arduino uno and the module (antenna outside of the window and it's raining):frowning:

arduino uno and adafruit gps library

This is what I get doday