(SparkFun GPS Breakout - Chip Antenna, SAM-M8Q (Qwiic) + Arduino Due ) en I2C connexion aléatoire

bonjour a tous
voila ,j'ai un petit soucis que je ne comprend pas.
j'ai connecter un Arduino DUE a un SparkFun GPS Breakout - Chip Antenna, SAM-M8Q (Qwiic) sur les les ports 20-21 (SCL et SDA) de l'arduino due ,et soudé directement sur la platine du SAM-M8Q au emplacement SCL et SDA ainsi que alimentation est fait par l'arduino due en 3v3.

voici le code utiliser pour les tests:

/*
  Reading lat and long via UBX binary commands - no more NMEA parsing!
  By: Nathan Seidle
  SparkFun Electronics
  Date: January 3rd, 2019
  License: MIT. See license file for more information but you can
  basically do whatever you want with this code.

  This example shows how to query a u-blox module for its lat/long/altitude. We also
  turn off the NMEA output on the I2C port. This decreases the amount of I2C traffic 
  dramatically.

  Note: Long/lat are large numbers because they are * 10^7. To convert lat/long
  to something google maps understands simply divide the numbers by 10,000,000. We 
  do this so that we don't have to use floating point numbers.

  Leave NMEA parsing behind. Now you can simply ask the module for the datums you want!

  Feel like supporting open source hardware?
  Buy a board from SparkFun!
  ZED-F9P RTK2: https://www.sparkfun.com/products/15136
  NEO-M8P RTK: https://www.sparkfun.com/products/15005
  SAM-M8Q: https://www.sparkfun.com/products/15106

  Hardware Connections:
  Plug a Qwiic cable into the GNSS and a BlackBoard
  If you don't have a platform with a Qwiic connection use the SparkFun Qwiic Breadboard Jumper (https://www.sparkfun.com/products/14425)
  Open the serial monitor at 115200 baud to see the output
*/

#include <Wire.h> //Needed for I2C to GNSS

#include <SparkFun_u-blox_GNSS_Arduino_Library.h> //http://librarymanager/All#SparkFun_u-blox_GNSS
SFE_UBLOX_GNSS myGNSS;

long lastTime = 0; //Simple local timer. Limits amount if I2C traffic to u-blox module.

void setup()
{
  Serial.begin(115200);
  while (!Serial); //Wait for user to open terminal
  Serial.println("SparkFun u-blox Example");

  Wire.begin();

  //myGNSS.enableDebugging(); // Uncomment this line to enable helpful debug messages on Serial

  if (myGNSS.begin(Wire, 0x42) == false) //Connect to the u-blox module using Wire port
  {
    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));
    while (1);
  }

  myGNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
  myGNSS.saveConfigSelective(VAL_CFG_SUBSEC_IOPORT); //Save (only) the communications port settings to flash and BBR
}

void loop()
{
  //Query module only every second. Doing it more often will just cause I2C traffic.
  //The module only responds when a new position is available
  if (millis() - lastTime > 1000)
  {
    lastTime = millis(); //Update the timer
    
    long latitude = myGNSS.getLatitude();
    Serial.print(F("Lat: "));
    Serial.print(latitude);

    long longitude = myGNSS.getLongitude();
    Serial.print(F(" Long: "));
    Serial.print(longitude);
    Serial.print(F(" (degrees * 10^-7)"));

    long altitude = myGNSS.getAltitude();
    Serial.print(F(" Alt: "));
    Serial.print(altitude);
    Serial.print(F(" (mm)"));

    byte SIV = myGNSS.getSIV();
    Serial.print(F(" SIV: "));
    Serial.print(SIV);

    Serial.println();
  }
}

le soucis est que il faut que je fasse plusieurs reset de l'Arduino due pour qu'il trouve le SAM-M8Q et qu'enfin arrive les données.
ma question est pourquoi il faut que je reset plusieurs fois pour qu'il le trouve, faut 'il lui mettre une pause avant l'envoie de la commande if (myGNSS.begin(Wire, 0x42) == false)
le due est t'il trop rapide pour attendre la réponse du GPS ?

Je ne connais pas ce module mais quand vous faites un reset de l'arduino, ça ne fait pas de reset du module SAM-M8Q. Peut-être prend-il simplement plus de temps à démarrer que vous n'anticipez... vous faites bien un while (!Serial); , il faut peut-être faire pareil..

➜ si vous faisiez un truc comme cela

void setup()
{
  Serial.begin(115200);
  while (!Serial); //Wait for user to open terminal
  Serial.println("SparkFun u-blox Example");

  Wire.begin();
  Serial.println(F("connecting to u-blox GNSS"));
  while (myGNSS.begin(Wire, 0x42) == false)  {
    Serial.write('.');
    delay(500);
  }
  Serial.println("\nGNSS OK");

...

bonjour , j'ai bien tenter le delay mais cela n'a rien changer, j'ai même fait une réinitialisation du port avant de wire.begin(); avec : ( car sda et scl sont sur port 21 et 20)

 //verification de la presence du module gps
 pinMode(21, OUTPUT);
 for (int i = 0; i < 8; i++) {
 digitalWrite(21, HIGH);
 delayMicroseconds(3);
 digitalWrite(21, LOW);
 delayMicroseconds(3);
  }
 pinMode(21, INPUT);
 

mais cela n'a rien changer.( j'ai ouïe dire que le DUE aurai des soucis avec le I2C, j'espère pas car j'ai deux module a y brancher)

rajoutez 2 résistances de pullup externe.

Votre SAM-M8Q est bien en 3.3V ?

oui oui ,le due est en 3.3v et le sam-m8q est aussi en 3.3v d'où mon choix pour éviter un composant encore en plus pour utiliser du 5v.

OK essayez de mettre une résistance de pullup de 4.7KΩ sur SCL et SDA

                3.3V
                 |
                 |
              R 4.7KΩ
                 |
                 |
LEONARDO SCL ----|----- SCL SAM-M8Q

ET

                3.3V
                 |
                 |
              R 4.7KΩ
                 |
                 |
LEONARDO SDA ----|----- SDA SAM-M8Q

je viens de regarde la doc du SAM-M8Q et il a déjà 2 résistance de 2.2kohm en pullup dessus.
je me pose la question justement de les enlever car c'est faisable si trop de périphérique dessus.


je cite"Il y a trois cavaliers sur le dessus du produit, chacun étiqueté avec sa fonction. En bas à droite de l'image se trouve un cavalier à trois voies étiqueté I²C qui connecte deux résistances pull-up aux lignes de données I2C. Si vous avez beaucoup d'appareils sur vos lignes de données I2C, vous pouvez envisager de couper ces résistances. Juste au-dessus de ce cavalier se trouve le cavalier JP2. Si vous coupez cette trace, vous déconnecterez la LED d'alimentation juste au-dessus du connecteur Qwiic. Enfin, sur le côté gauche du produit se trouve le cavalier JP1 qui, lorsqu'il est coupé, déconnecte la LED PPS."

Tu as d'autres périphériques sur le bus I2C?

C'est peut-être une bonne idée car si j'en crois le schéma de la DUE il y a déjà des résistances de 1.5kΩ sur la carte.

non pas encore, mais j'y prévois un ecran nextion dessus donc aussi en sda scl.
une chose a la fois ^^

bonsoir pullup sur le sam-m8q couper et toujours pareil.

Tu es certain qu'il n'y aurait pas une soudure défectueuse quelque part?

bonsoir, je viens de revérifier mes soudures avec un testeur. fils sda et scl vers port Qwiic fonctionne, pas de court circuit entre les files.
je comprend pas qu'on face un arduino due avec autant de soucis en I2C ou autre, dés qu'on lui met des périphériques c'est la galère.
y'a toujours un truc qui ne fonctionne pas, les uno sont pas a vrai virgule flottante et pas assez puissant pour ce que je veut en faire.(calcul astronomique).
le uno r4 est trop récent donc pas assez de bibliothèque compatible.
franchement les arduino commence a me sortir les yeux de la tête.
je vais brancher mon DUE en TX RX avec le SAM-M8Q bien que le SAM-M8q est Prévu de fonctionner majoritairement en I2C.
du coup je suis perdu entre ce que je doit prendre ou pas, ce qui est compatible ou pas.

bonsoir,
branchement en RX et TX fonctionnel et communication bonne.
je ne comprend pas le soucis de I2C, il va falloir que je trouve une solution pour mon Nextion car il ne communique qu'en I2C.
voilà le code que j'ai adapter et qui fonctionne sur un Arduino DUE et un SAM-M8Q mais en Serial1 et non en I2C

/*
  Reading lat and long via UBX binary commands using UART @38400 baud - free from I2C
  By: Nathan Seidle, Adapted from Example3_GetPosition by Thorsten von Eicken
  SparkFun Electronics
  Date: January 28rd, 2019
  License: MIT. See license file for more information but you can
  basically do whatever you want with this code.

  This example shows how to configure the library and U-Blox for serial port use as well as
  switching the module from the default 9600 baud to 38400.

  Note: Long/lat are large numbers because they are * 10^7. To convert lat/long
  to something google maps understands simply divide the numbers by 10,000,000. We 
  do this so that we don't have to use floating point numbers.

  Leave NMEA parsing behind. Now you can simply ask the module for the datums you want!

  Feel like supporting open source hardware?
  Buy a board from SparkFun!
  ZED-F9P RTK2: https://www.sparkfun.com/products/15136
  NEO-M8P RTK: https://www.sparkfun.com/products/15005
  SAM-M8Q: https://www.sparkfun.com/products/15106


  Open the serial monitor at 115200 baud to see the output
*/

#include <SparkFun_u-blox_GNSS_Arduino_Library.h> //http://librarymanager/All#SparkFun_u-blox_GNSS
SFE_UBLOX_GNSS myGNSS;

long lastTime = 0; //Simple local timer. Limits amount of I2C traffic to u-blox module.

void setup()
{
  Serial.begin(115200);
  while (!Serial); //Wait for user to open terminal
  Serial.println("SparkFun u-blox Example");

  //Assume that the U-Blox GNSS is running at 9600 baud (the default) or at 38400 baud.
  //Loop until we're in sync and then ensure it's at 38400 baud.
  do {
    Serial.println("GNSS: trying 38400 baud");
    Serial1.begin(38400);
    if (myGNSS.begin(Serial1) == true) break;

    delay(100);
    Serial.println("GNSS: trying 9600 baud");
    Serial1.begin(9600);
    if (myGNSS.begin(Serial1) == true) {
        Serial.println("GNSS: connected at 9600 baud, switching to 38400");
        myGNSS.setSerialRate(38400);
        delay(100);
    } else {
        //myGNSS.factoryReset();
        delay(2000); //Wait a bit before trying again to limit the Serial output
    }
  } while(1);
  Serial.println("GNSS serial connected");

  myGNSS.setUART1Output(COM_TYPE_UBX); //Set the UART port to output UBX only
  myGNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
  myGNSS.saveConfiguration(); //Save the current settings to flash and BBR
}

void loop() {
  // Query module only every second. Doing it more often will just cause traffic.
  // The module only responds when a new position is available
  if (millis() - lastTime > 1000) {
    lastTime = millis(); // Update the timer
    
    long latitude = myGNSS.getLatitude();
    long longitude = myGNSS.getLongitude();
    long altitude = myGNSS.getAltitude();
    byte SIV = myGNSS.getSIV();

    // Convert latitude to DMS
    char latHemisphere = (latitude < 0) ? 'S' : 'N';
    latitude = abs(latitude);
    int latDegrees = latitude / 10000000;
    int latMinutes = (latitude % 10000000) * 60 / 10000000;
    int latSeconds = ((latitude % 10000000) * 60 % 10000000) * 60 / 10000000;

    // Convert longitude to DMS
    char lonHemisphere = (longitude < 0) ? 'W' : 'E';
    longitude = abs(longitude);
    int lonDegrees = longitude / 10000000;
    int lonMinutes = (longitude % 10000000) * 60 / 10000000;
    int lonSeconds = ((longitude % 10000000) * 60 % 10000000) * 60 / 10000000;

    // Print results
    Serial.print(F("Lat: "));
    Serial.print(latDegrees);
    Serial.print(F("° "));
    Serial.print(latMinutes);
    Serial.print(F("' "));
    Serial.print(latSeconds);
    Serial.print(F("\" "));
    Serial.print(latHemisphere);

    Serial.print(F(" Long: "));
    Serial.print(lonDegrees);
    Serial.print(F("° "));
    Serial.print(lonMinutes);
    Serial.print(F("' "));
    Serial.print(lonSeconds);
    Serial.print(F("\" "));
    Serial.print(lonHemisphere);

    Serial.print(F(" Alt: "));
    Serial.print(altitude);
    Serial.print(F(" mm"));

    Serial.print(F(" SIV: "));
    Serial.print(SIV);

    Serial.println();
  }
}

Sur le Leonardo, la gestion native de l’USB ou d’autres bibliothèques dépendant beaucoup des interruptions peut créer des conflits de timing avec les interruptions utilisées par l’I2C.

Une communication série sera plus lente et il y a un buffer, ça pourrait faire la différence…

bonsoir,
je viens de regarder pour le Leonardo et il n'est pas en vrai virgule flottante 32bits et n'aura pas la précision et la vitesse de calcul dont j'ai besoin.
gestion lumineuse suivant lumière calculer, température ambiante ainsi que calcul astronomique pour la position lunaire/ solaire suivant la position géolocaliser de l'appareil avec une gestion de l'heure suivant aussi la position geo.
pour l'instant je vais rester sur du Serial1 et mes 2 autre serial pour gérer les périphériques.
si j'ai encore un soucis de puissance, je vais regarder du coter du teensy 4.1 qui m'a l'air pas mal pour des calculs astro et a plusieurs serial aussi et peut être un I2C fonctionnel ^^

CoreMark Benchmark

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.