paraFANET

[julesp]

Bonjour a tous les parapentistes

je suis en traine de faire des recherches sur la technologie paraFANET, est ce que vous connaissez des sites ou je peux chopper des infos sur cette techno?

merci pour vos réponses.

[sylvain_p]

Salut, Je connais pas parafanet, tu veux parler de FANET/+?
Si c'est ça je suppose que tu es déjà passé sur ces resources
 - présentation https://naviter.com/fr/2019/09/how-it-works-fanet/
 - description succincte du protocole https://github.com/3s1d/fanet-stm32/blob/master/Src/fanet/radio/protocol.txt (tirée du module utilisé par skytraxx https://github.com/3s1d/fanet-stm32/)

 - un projet autonome : https://github.com/lyusupov/SoftRF
dont quelques explications sur le projet skytraxx https://github.com/lyusupov/SoftRF/wiki/FANET-compatibility

Sinon désolé pour le HS

[julesp]

c'est parfait merci pour ta réponse !

[sylvain_p]

De rien!
J'oubliais GXAirCom https://github.com/gereic/GXAirCom

bonnes expérimentations !

[jcp]

De rien!
J'oubliais GXAirCom https://github.com/gereic/GXAirCom

bonnes expérimentations !

Je m'intéresse à ce projet et je vois que le
LILYGO®TTGO – meshtacstic t-beam V1.1 ESP32 LoRa 915MHz 433MHz 868MHz 923MHz, WiFi, GPS BLE avec écran OLED et support de batterie
est vendu en plusieurs versions qui semblent correspondres aux différentes fréquences LoRa...

En lisant la doc, je vois que l'Europe est 868MHz, je pense donc "choisir" la version 868MHz sur le site de vente en ligne où je trouve ce module.
Mais surement y a-t-il des experts ici pour m'aider à comprendre.
J'imaginais que le même module pouvait utiliser les différentes fréquences. Pourquoi donc le site marchant propose plusieurs versions... ?

Ai-je loupé un truc ?

[sylvain_p]

Je m'étais posé la question et on est pas les seuls :
https://www.paraglidingforum.com/viewtopic.php?t=106252
Depuis ils ont dû avoir la réponse à leur question puisqu'ils commercialisent leurs xctacer dans le monde entier
Si personne ne sait ici peut être qu'ils voudront bien te filer des billes si tu le contactes ? 

[jcp]

Merci pour ta réponse !

[sylvain_p]

Je viens de me rendre compte que j'ai répondu à côté de la plaque. Si j'en crois la page Aliexpress la seule différence physique entre le 868 et le 915 est l'antenne. Le reste doit se faire par la configuration du soft embarqué (par exemple pour softrf : https://github.com/lyusupov/SoftRF/wiki/Settings); le chipset (lora sx1276/8) fonctionne de 133 à 1020 MHz.
Si tu t'y mets tu nous tiendras au courant de tes expérimentations ça m'intéresse !

[sylvain_p]

Correction il est possible que sur la version 433 ils mettent un sx1276 qui lui ne dépasse pas 500 MHz et qques.
https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series

[jcp]

Je viens de me rendre compte que j'ai répondu à côté de la plaque. Si j'en crois la page Aliexpress la seule différence physique entre le 868 et le 915 est l'antenne. Le reste doit se faire par la configuration du soft embarqué (par exemple pour softrf : https://github.com/lyusupov/SoftRF/wiki/Settings); le chipset (lora sx1276/8) fonctionne de 133 à 1020 MHz.
Si tu t'y mets tu nous tiendras au courant de tes expérimentations ça m'intéresse !

Ca y est, j'ai reçu un t-Beam v1.1 avec support pour batterie 16850 et écran oled 0,9 pouce
j'ai suivi la doc gxaircom sur github, et je n'ai eu aucun soucis
Tout à fonctionné du premier coup avec le build 3.5.3 du 25 juin 2023
(je suis presque déçu de n'avoir eu aucune difficulté)

au boot, le t-beam fait point d'accès wifi, avec 12345678 comme mot de passe
la config se fait via une interface web sur 192.168.4.1
j'ai mis mon nom, choisi le bon format de carte t-beam, choisi d'envoyer les données sur OGN via ma box internet (car je suis au sol et je voulais me "voir" sur le livetrack OGN / burnair - j'ai simplement enregistré un device (avec l'ID du t-beam sur https://ddb.glidernet.org))
je pose le t-beam sur le bord de la fenêtre et hop, il met un peu de temps à choper le signal GPS (uniquement au premier fix, maintenant après changement de config et reboot, c'est environ 10 secondes pour rechoper un fix - je suis à l'intérieur, alors je "bouge" un peu)

En fait, je ne vois qu'un seul soucis pour l'instant (et je n'ai pas trop le temps de creuser pour l'instant), c'est le niveau d'indication de batterie. Le logo batterie reste vide, bien que ma batterie soit complètement chargée.
dans la config, le calibrage voltage batterie est un champ vide. Il y a une petite case éditable à côté, mais je ne sais pas comment l'utiliser. Je dois y mettre un voltage ? un pourcentage (genre 100% si je sais que ma batterie est pleine au premier démarage ?)
Bref, pas compris pourquoi ce logo reste vide... lorsque je branche un cable, la lumière bleu du t-beam clignote, mais le logo ne change pas, toujours vide.
Aucune idée de si ca charge ou non...
je regarderai du côté AXP192 quand j'aurai un peu de temps...

[jcp]

Ah, et j'oublie le point important qui a déclanché le début de mon intervention dans ce post:
j'ai chosi le t-beam avec écran oled déjà soudé ! et en version 868MHz (SX1276)
le SX1278 semble être prévu pour 433MHz

[jcp]

Correction il est possible que sur la version 433 ils mettent un sx1276 qui lui ne dépasse pas 500 MHz et qques.
https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series

C'est le 1278 qui ne dépasse pas 525MHz

(source: https://www.semtech.com/products/wireless-rf/lora-connect/sx1278)

[jcp]

Bon, j'ai pris quelques minutes sur ma pause de midi:

float BattVoltOffs; //offset for Battery-multiplier

C'est à ça que sert la petite boîte à côté de "Battery Voltage calib" dans les settings


Quand je lis les logs, je vois ça:
[main.cpp:1607] printSettings(): AXP192=0

Ca voudrait dire qu'il ne voit pas le AXP192 sur la carte T-Beam !?
Plus loin:
[E][main.cpp:1401] setupAXP192(): AXP192 error begin

Cette fois c'est clair, il y a un truc louche de ce côté, mais quoi ?

[sylvain_p]

Merci pour tes retours 
Pour ton problème il faudrait regarder plus précisément avec la carte que tu as ; le truc malheureux avec Lillygo/arduino et tous les clones chinois c'est qu'ils aiment bien changer tous les 4 matins les specs de leurs boards et du coup peut être qu'ils ont changé l'adresse I2C d'un module, ou alors changé carrément de pins pour la communication...

De ce que tu as dû voir dans le code il y'a tout un tas d'aiguillage pour essayer de deviner le type de carte sur lequel est exécuté le soft, dans la fonction checkBoardType : https://github.com/gereic/GXAirCom/blob/master/src/main.cpp#L570
en fonction de ça c'est là qu'il pourra déterminer la pin où lire la tension de la batterie, mais comme il n'a effectivement pas l'air de vouloir communiquer avec le module axp192 (qui doit s'occuper de la charge de la batterie de ce que je vois) ça plantoi.
essaie peut être de commencer avec un scanner I2C de ce genre ? https://raw.githubusercontent.com/RuiSantosdotme/Random-Nerd-Tutorials/master/Projects/LCD_I2C/I2C_Scanner.ino

[jcp]

oui, effectivement, j'ai vu le code pour détecter le type de carte, et j'avoue que je mets un peu de temps à comprendre la logique...
C'est un peu "confusant".
Les "settings" sont lu d'un fichier de conf, mais le AXP192 vient d'une fonction et se retrouve stocké dans une variable "status".
C'est un peu chaud de suivre dans quel ordre s'execute quoi...
J'admire tout le travail fait jusque là, c'est juste dingue et je comprends parfaitement que ce soit codé ainsi, au fil des avancés... mais pfff, c'est pas facile à suivre sans prendre un peu de temps.


au passage, d'après les logs, je rentre la dedans:

Code:

  if (i2cDevices < 10){
    i2cOLED.beginTransmission(AXP192_SLAVE_ADDRESS);
    if (i2cOLED.endTransmission() == 0) {
      //ok we have a T-Beam !! 
      //check, if we have an OLED
      setting.boardType = eBoard::T_BEAM;
      log_i("AXP192 found");
      checkLoraChip();
      setting.displayType = NO_DISPLAY;
      i2cOLED.beginTransmission(OLED_SLAVE_ADDRESS);
      if (i2cOLED.endTransmission() == 0) {
        //we have found also the OLED
        setting.displayType = OLED0_96;
        log_i("OLED found");
      }
      log_i("Board is T-Beam V1.0 or V1.1");
      write_configFile(&setting);
      delay(1000);
      esp_restart(); //we need to restart
    }

Mais checkLoraChip() me fait aussi passer la dedans

Code:

    log_i("Lora-Chip SX1262 found --> Board is a T-Beam with SX1262");

et comme checklorachip() est appellé au milieu de checkBoardType(), la suite de cette function me donne enfin:
Ah, j'ai un OLED, donc...

Code:

      if (i2cOLED.endTransmission() == 0) {
        //we have found also the OLED
        setting.displayType = OLED0_96;
        log_i("OLED found");
      }
      log_i("Board is T-Beam V1.0 or V1.1");

bref, j'ai bien AXP192 (d'après le code exécuté) donc j'ai Board is a T-Beam with SX1262
mais comme j'ai un oled, j'ai finalement Board is T-Beam V1.0 or V1.1

En fin de compte, on s'en fou un peu que ce soit moche, ce qui importe, c'est la fonction

Code:

setupAXP192

qui elle fini par mettre

Code:

      log_e("AXP192 error begin");
      status.bHasAXP192 = false;

Ce qui veut dire que je ne rentre pas la dedans:

Code:

if (!axp.begin(i2cOLED, AXP192_SLAVE_ADDRESS))

A priori, j'ai un SX1276 et non un SX1262, mais en regardant sur la carte à la loupe, je vois AXP2101v1.2 et non AXP192 comme sur la spec de la page web de l'article que j'ai acheté.

Merci pour la suggestion de scan I2C, ca va surement m'aider.
Et aussi, je reprendrai le code à tête reposé, car dans la fonction AXP192.

Mais je pense que j'ai déjà une piste avec cette histoire de AXP192 et AXP2021
dans le fichier axp20x.h lignes 64 et 65

Code:

//! Chip Address
#define AXP202_SLAVE_ADDRESS (0x35)
#define AXP192_SLAVE_ADDRESS (0x34)