ich mein, dev eui, app key beim device eintragen und bei der application die app eui dazufügen (oder eigene application anlegen), mehr ist es ja nicht … oder habe ich was wichtiges vergessen??
dzt. läuft das übers raspi+ic880-gateway bei mir am tisch, ein original ttn-node funktioniert übers selbe gateway problemlos.
bitte um hilfe. wenn noch infos für die fehlereingrenzung notwendig sind =>info
im trafficmonitor am gateway sehe ich einen joinrequest mit dev eui und app eui, die sind richtig (zumindest laut pickerl auf der box. am tracker steht nur die frq 868 und die dev eui drauf)
also das packet kommt scheinbar mal über mein gateway rein, der joinrequest wird aber nicht behandelt … hmm
ja, ein paar Details brauchen wir noch - zB. welchen Code versuchst du auszuführen?
Du beachtest eh, dass du nicht das Gateway mit zu starkem RSSI belastet (weil du schreibst, dass es am Tisch steht), wie im Workshop erwähnt sind da schon einige IMST Board taub geworden? (max. -35dB)
Wenn der Join Request nicht beantwortet wird, war was mit den Angaben (DEVEUI, usw.) falsch. Hast du in der Console alles auf OTAA konfiguriert?
Hast du MSB/LSB bei den Werten beachtet? (kann man leicht verwechseln: https://www.thethingsnetwork.org/forum/t/hex-lsb-or-msb/2809/2)
Falls du ein Hakerl beim Frame Check Counter gesetzt hast, nimm das weg. (In der TTN Console beim Device)
welchen code? verstehe ich nicht. ich versuche mal „irgendein“ payload dorthinzubekommen, die vb-script-artige auseinanderpfrimmlerei mach ich später ;-))
mutters stahltopf leistet gute (abschirm-)dienste! ;-)) -60dBm oder so sollte das ding aber verkraften …
OTAA ist eingestellt. ABP ginge auch (weil auf der packung appskey und netskey aufgedruckt sind), aber dzt ist alles auf OTAA
msb/lsb: keine ahnung, ich habe einfach mal das eingetragen was auf der schachtel aufgedruckt ist
und da ich da nicht reinschauen kann (brauche noch einen usb-ttl-umsetzer um mittels at befehlen zu sehen, ob das vom karton überhaupt stimmt )
die dev eui ist ja sowas wie eine mac-adresse, dragino-zeugs beginnt (offenbar) immer mit A8404100… daher habe ich das mal so wie es ist, hier msb, eingetragen
ebenso die app eui
nun, in einem anderen post steht „using LMIC“ dann
dev eui => lsb
app eui => lsb
app key => msb
hmm, mal probieren
frame check counter ist weg, hab ich schon in vielen postings gelesen. wenn man alles up+running hat, kann man das ja wieder aktivieren …
nur für mein verständnis: man kann eine „app eui“ zu einer application „dazubuchen“, damit ich dann beim anlegen vom device selbige auswählen kann - richtig? also quasi eine „gruppierung“
entweder ttn gibt eine app eui vor, dann muss diese in alle devices reinschreiben oder ich nehme (mal ohne programmieren) die angaben vom karton. damit muss ich diese app eui der application bekanntmachen. richtig?
hast du die Anleitung für das Einbinden zu TTN (Kapitel 2.2) aus der Anleitung befolgt?
LMIC ist nur relevant, wenn du eigene SW (Code) drauftust.
Ja, irgendwie kann man eine eigene AppEUI wählen. Dann kann man je Device über eine Dropdown-Liste wählen, welche AppEUI dieses Device nutzen soll.
Meist wird sie von TTN vorgegeben, manchmal liefert es der Hersteller mit (womit streng genommen die Verschlüsselungskeys dem Hersteller „bekannt“ (= er hat sie vergeben) sind, was oft nicht als ideal gesehen wird).
wobei der aufgedruckte app eui „komisch“ ausschaut. viele nuller … schaut aus wie fortlaufend nummeriert … sollte aber eh wurscht sein, hauptsache gleich im device und in der application…
habe zum testen noch ein dragino LT33222-L, ein modul mit 3x DO, 3x DI, 2x relay, 2x AI, 2x VI,
das funktioniert tadellos. auch der downlink funktioniert. muss nur mehr die transmit interval time runter drehen (dzt 0x000258, also 600s), dann kann man auch ordentlich testen.
nach einer amazonbedingten pause hab ich gestern mal versucht mit dem tracker zu „reden“. ging überraschend einfach, das ding beantwortet meine AT-anfragen, im manual gibts die liste der AT-befehle und auch ein beispiel wie was zu setzen ist.
habe dann den tracker als neues device angelegt und versucht ABP zu machen. da ttn dann eine device address (4 byte) generiert, habe ich diese im tracker reinge-AT-t. im gateway-paket-monitor habe ich auch die neuerlichen anfragen gesehen (gelber blitz, join request) und konnte auch den gpstracker fragen ob er meint, dass er joined ist - er meinte er ist joined … ttn meint was anderes, offenbar
weiters war dann noch SF12 gesetzt, was ~1500ms airtime bei 25bytes payload entspricht (also lt gateway), das hab ich auf SF7 reduziert, damit brauchen die 25bytes ~61ms airtime. rssi mit -75dBm ist auch im rahmen.
die ttn-webseite meint beim device: grüner punkt, aber dennoch beharrlich „never seen“
ich habe einen zombie erschaffen … grmpf :-((
habe dann noch das interval von 300s auf 30s runtergedreht und das ding bissl rausgelegt,
damit es einen gpsfix hat/bekommt. auch das ist soweit in ordnung…
gibts von euch nerds noch ideen?? … irgendwie stehe ich an
Hast du mit diesem Teil die Steps, die ich vor einigen Tagen vorgeschlagen habe (Frame Counter Check, etc.) auch beachtet?
Du hast mir ja deine Applikationen & Devices in der Console freigeschaltet. Von welchem Teil reden wir da earlgrey_testnet/dragino-blauesding-rbk war zum Beispiel schon erfolgreich verbunden!?
Du nutzt eh einen vollwertigen LoRaWAN Gateway (zB. den Raspi von uns), der dann auch antworten kann?
jaja, alles so, mehrmals, als otaa angelegt, alles gecheckt, framecounter abgewählt etc… dann auf abp umgedreht, die jeweils anderen beiden keys reingetan, die ttn-device-addr in den tracker reingetan.
komme nicht über den joinrequest hinaus, auch wenn der tracker inzwischen meint, er ist joined.
inzwischen verstehe ich das generelle konzept dahinter auch besser - wie da die fastilliarden an keys zusammenspielen.
das blaue ding ist super, hat gefühlt 5 femtosekunden gedauert das anzulegen. auch downlinks (relais schalten) funktionieren tadellos.
ich habe (wegen anderem payloadformat) eine neue app angelegt und den tracker dort reingetan und dich freigeschalten.
ja, dzt ist der raspi aktiv, der dem ttn_node und dem blauen ding tadellos antwortet. sicherheitsabstand ist auch da, dass rssi unter -60dBm ist :-))
falls dir noch was einfällt, was ich am tracker selber ändern soll (mit AT+ etc.), dann bitte gerne her damit …
Ich wäre dir weiterhin dankbar, wenn du Applikations-Name und Device-Name dazuschreibst. Mir sharen viele Leute ihre Anwendungen ich hab’ da -zig-Einträge und muss dann raten, wovon du redest.
Ich denke du redest von earlgrey_mobile/gpstracker ? Dieses Gerät ist aktuell für ABP in der Console konfiguriert (sollte deinen Schilderungen nach aber OTAA sein?).
ja, es geht um diesen tracker. ich habe das DERZEIT auf ABP, kann das ding aber sofort rausschmeissen und als OTAA neu anlegen - hatte bis jetzt immer den gleichen erfolg - keinen.
was wäre zu empfehlen? kenne die unterschiede/pros/cons von den beiden methoden (noch) nicht, muss erst nachlesen.
Beachte, dass sich die Keys bei den beiden Varianten unterscheiden. Wenn du also umstellst, musst du die Keys neu eintragen bzw. bekommst andere Keys in der Console.
Aber scheinbar stehen die LGT-92 unter keinem guten Stern im Moment…
Ich hab’ übrigens auch eines, das hat problemlos funktioniert. Nur vom Batterieverbrauch hätte ich mir mehr erwartet, nach 10 Tagen war er leer - aber immerhin.
Wie schaut’s bei dir aus? Hats mit neuer Einstellung + neuen Keys funktioniert?
noch keine neuigkeiten, am donnerstag werde ich ein forumsmitglied belästigen dürfen um zu testen, ob es sich um ein hardware oder layer8/layer9 problem handelt :-))
1:0 für layer8
der tracker hat irgendwie ein problem, layer1 geht noch alles, also SF7, BW, frq, und und und und, gateway empfängt was und schickts weiter, ttncloud zeigt die kalte schulter … naja …
[2122]***** UpLinkCounter= 0 *****
[2521]TX on freq 868500000 Hz at DR 5
[2587]txDone
[7577]RX on freq 868500000 Hz at DR 5
[7604]rxTimeOut
[8583]RX on freq 869525000 Hz at DR 3
[8623]rxTimeOut
[9557]***** UpLinkCounter= 0 *****
[9957]TX on freq 868300000 Hz at DR 5
[10023]txDone
[15012]RX on freq 868300000 Hz at DR 5
[15041]rxTimeOut
[16018]RX on freq 869525000 Hz at DR 3
[16058]rxTimeOut
[16995]***** UpLinkCounter= 0 *****
[17394]TX on freq 868300000 Hz at DR 5
[17460]txDone
[22450]RX on freq 868300000 Hz at DR 5
[22478]rxTimeOut
[23456]RX on freq 869525000 Hz at DR 3
[23496]rxTimeOut
[24432]***** UpLinkCounter= 0 *****
[24832]TX on freq 868500000 Hz at DR 5
[24898]txDone
[29887]RX on freq 868500000 Hz at DR 5
[29916]rxTimeOut
[30893]RX on freq 869525000 Hz at DR 3
[30933]rxTimeOut
[31870]***** UpLinkCounter= 0 *****
[32199]TX on freq 868500000 Hz at DR 5
[32265]txDone
[37254]RX on freq 868500000 Hz at DR 5
[37283]rxTimeOut
[38260]RX on freq 869525000 Hz at DR 3
[38300]rxTimeOut
Hab das Teil im ThingsNetwork registriert, mehrfach die Angaben vom Aufkleber überprüft, die Angaben aus dem Tracker selber mit den entsprechenden AT Befehlen ausgelesen, quergechecked, das Teil stundenlang draussen liegen gelassen, mit dem Teil umhergefahren (Venlo, Grefrath, Düsseldorf und noch so verschiedene Gegenden - wobei in Grefrath, nicht weit unserer Heimat, ein Knode ist).