SPI Verbinung zwischen Teensy3.6 und ESP8266 zerlegt PCM Daten komplett

Hallo Leeutz, ich habe seit mehreren Tagen das Problem das allen Anschein nach die SPI Verbindung zwischen Teensy und ESP mir meine Audio PCM Daten (im wahrsten sinne) zersägt.

Zum vorhaben:
Ich würden gerne Audio Daten die der Teensy empfängt via SPI zum ESP und auch zurück schaffen. Dann die Daten via WebSocket zum Browser schicken kann, damit ich diese dann dort Visualisieren und ausgeben kann.

Das verwendetet ESP Modul. ist der ESP-M1 Modul, darauf befindet sich ein ESP8285, das sollte aber keinen unterschied machen zum ESP8266.

Es ist nun so, das der Weg vom Browser zum Teensy hin perfekt funktioniert, da kommt ein schöner Sinus am DAC heraus.

Aber der Weg vom Teensy zum Browser ist nur noch ein gerausche und Getöse. Wie bei einem Schlecht eingestellten Radio Sender. Siehe Bild:


Das Bild soll einen 400Hz Sinus Darstellen.

PCM Daten sind ja nur Messwerte zum Zeitpunkt x mit der Amplitude x.
Die einzige stelle wo die PCM Daten derartig durcheinander geraten können ist die SPI Verbindung.

Weil das ganze nun etwas umfangreicher ist habe ich den Code bis auf ein Minimum heruntergeschraubt.

Der Teensy ist in in meinen Fall das Slave Device. Als Transfer Methode habe ich 16bit wide transfers.
Die verwendete Lib ist diese:

Mehr infos dazu finde ich auch nicht außer diesen Foren Eintag.

Für den Test habe ich am Teensy eine (SPI Schleife) gemacht. Sprich: der Teensy Kopiert den Empfangen Wert und sendet diesen zurück.

#include <SPI.h>
#include "TSPISlave.h"

#define ESP_READY_PIN 39
#define SPI_READY_PIN 35

#define MISO_PIN 1
#define MOSI_PIN 0
#define SCK_PIN 32
#define CS_PIN 31

TSPISlave mySPI = TSPISlave(SPI1, MISO_PIN, MOSI_PIN, SCK_PIN, CS_PIN, 16);

bool showcnt = false;
bool receiveSPIaudio = false;
unsigned long previousMillis  = 0;
volatile uint16_t wert = 0;
volatile uint16_t cnt = 0;
unsigned long endTime = 0;
bool isSDCardReady = false;

void setup() {
  Serial.begin(9600);
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(ESP_READY_PIN, INPUT);
  pinMode(SPI_READY_PIN, INPUT);


  mySPI.onReceive(mySPIFunc);
  attachInterrupt(digitalPinToInterrupt(SPI_READY_PIN), toggleSPIInput, CHANGE);
}

void loop() {
  unsigned long currentMillis  = millis();
  if (currentMillis - previousMillis  >= 700) {
    previousMillis = currentMillis;
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    Serial.println(wert, DEC);
  }

  if (showcnt) {
    Serial.print("Zähler: ");
    Serial.println(cnt, DEC);
    Serial.print("Zeit: ");
    Serial.println(endTime);
    Serial.println();
    cnt = 0;
    endTime = 0;
    showcnt = false;
  }
}

void toggleSPIInput() {

  if (digitalReadFast(SPI_READY_PIN) == LOW)//WiFi Modul verbunden
  {
    wert = 0;
    receiveSPIaudio = true;
  } else {//SPI verbindung beendet
    wert = 0;
    receiveSPIaudio = false;
  }

}


//wird aufgerufen wenn SPI cs pin == LOW
FASTRUN void mySPIFunc() {
  unsigned long startTime = micros();
  while (mySPI.active() ) {
    if (mySPI.available()) {
      cnt++;
      wert = mySPI.popr();
      mySPI.pushr(wert);
    }
  }
  endTime = micros() - startTime;
  showcnt = true;
}

Die Ausgabe am teensy ist dann wie Folgt:

64624
Zähler: 131
Zeit: 794

16270
Zähler: 130
Zeit: 793

59384
Zähler: 129
Zeit: 795

51040
Zähler: 131
Zeit: 794

65310
Zähler: 130
Zeit: 794

63738
Zähler: 130
Zeit: 800

16128
Zähler: 131
Zeit: 794

58352
Zähler: 131
Zeit: 795

63744
Zähler: 131
Zeit: 794

61960
Zähler: 129
Zeit: 793

32664
Zähler: 130
Zeit: 794

3065
Zähler: 128
Zeit: 794

37248
Zähler: 131
Zeit: 795


Der Zähler wert ist hier schon falsch, ich tätige jeweils nur 128 Übertragungen.

Der ESp, als SPI Master hat diesen code:

#include <ESP8266WiFi.h>
#include "SPI.h"

extern "C" {
#include "osapi.h"
#include "ets_sys.h"
#include "user_interface.h"
}

#define WEBSOCKETS_SERVER_CLIENT_MAX (1)
#define ESP_READY_PIN 0
#define SPI_READY_PIN 2
#define ESP_READY_PIN_LED 4
#define WiFi_LED_PIN 5
#define SPI_SPEED 1000000

#define HTTP_PORT 80
#define SOCKET_PORT 81
#define DNS_PORT 53

#define AUDIO_BLOCK_SAMPLES 128
#define INTERVAL 700*1000

const uint8_t wifiChannels[6] = {1, 5, 6, 7, 9, 13};

SPISettings settingsSPI(1000000, MSBFIRST, SPI_MODE0);

unsigned long previousMillis = 0;
uint8_t client_id = NULL;
bool wifiLED_Status = false;
uint8_t displayData[9] = {0};
unsigned long previousMicros = 0;
uint16_t xy = 0;
uint16_t wert = 0;
uint16_t inWert = 0;




void IRAM_ATTR spi_audio() {
  unsigned long currentMicros = micros();
  if (currentMicros - previousMicros >= INTERVAL) {
    previousMicros = currentMicros;
    SPI.beginTransaction(settingsSPI);
    digitalWrite(SS, LOW); // enable Slave Select
    for (byte i = 0; i < AUDIO_BLOCK_SAMPLES; i++) {
      wert += 1;
      inWert =  SPI.transfer16(wert);
      if (inWert != wert - 2) {
        xy++;
      }
    }
    digitalWrite(SS, HIGH); // disable Slave Select
    SPI.endTransaction();
    if (xy > 0) {
      Serial.print("SPI Fehler: ");
      Serial.println(xy);
      Serial.print("Wert: ");
      Serial.println(inWert);
      xy = 0;
    }
  }
}

void setup() {
  //SYS_CPU_160MHZ  160MHz
  system_update_cpu_freq(SYS_CPU_160MHZ);
  system_timer_reinit();
  delay(6000);
  pinMode(SPI_READY_PIN, OUTPUT);
  pinMode(ESP_READY_PIN, OUTPUT);

  pinMode(ESP_READY_PIN_LED, OUTPUT);
  pinMode(WiFi_LED_PIN, OUTPUT);
  digitalWrite(ESP_READY_PIN_LED, HIGH);
  digitalWrite(WiFi_LED_PIN, LOW);
  Serial.begin(115200);//or 115200

  SPI.pins(14, 12, 13, 15);
  SPI.setHwCs(false);
  SPI.begin();
  SPI.setFrequency(SPI_SPEED);
  pinMode(SS, OUTPUT);
  digitalWrite(SS, HIGH); // disable Slave Select
  ESP.eraseConfig(); // Alte WiFi Konfiguration löschen
  WiFi.persistent(false);
  WiFi.disconnect(true);
  WiFi.softAPdisconnect();
  WiFi.mode(WIFI_OFF);
  wifi_set_sleep_type(NONE_SLEEP_T);//maximale sendleistung

  bool writeIncommingData = false;
  byte line = 0;
  String _SSID = "abcdef";
  String _PASSWD = "0123456789";

  digitalWrite(SPI_READY_PIN, HIGH);
  digitalWrite(ESP_READY_PIN, LOW);

  const int randNr = random(0, 5);
  const byte WiFi_ChannelNr = wifiChannels[randNr];

  WiFi.mode( WIFI_AP);
  WiFi.setOutputPower(10.0);
  WiFi.setPhyMode(WIFI_PHY_MODE_11G);

  _SSID.trim();
  _PASSWD.trim();

  // ss->println(_SSID);
  // ss->println(_PASSWD);

  if (_SSID.length() > 32 || _SSID.length() < 4) {
    while (1) {
      delay(100);
    }
  }
  if (_PASSWD.length() > 64) {
    while (1) {
      delay(100);
    }
  }

  if (_PASSWD.length() >= 8) {
    WiFi.softAP(_SSID, _PASSWD, WiFi_ChannelNr, false, 1);
  } else {
    WiFi.softAP(_SSID, "", WiFi_ChannelNr, false, 1);
  }
  WiFi.setAutoReconnect(true);
  WiFi.setAutoConnect(false);

  IPAddress IP = WiFi.softAPIP();
}

void loop() {
  spi_audio();
}

Die Ausgabe ist dann wie Folgt:


Wert: 29948
SPI Fehler: 91
Wert: 30462
SPI Fehler: 76
Wert: 15230
SPI Fehler: 78
Wert: 15358
SPI Fehler: 73
Wert: 15486
SPI Fehler: 66
Wert: 31228
SPI Fehler: 93
Wert: 32126
SPI Fehler: 96
Wert: 31740
SPI Fehler: 89
Wert: 31998
SPI Fehler: 51
Wert: 16126
SPI Fehler: 106
Wert: 32510
SPI Fehler: 78
Wert: 16382
SPI Fehler: 56
Wert: 16510
SPI Fehler: 42
Wert: 16638
SPI Fehler: 111
Wert: 33532
SPI Fehler: 50
Wert: 16894
SPI Fehler: 91
Wert: 34430
SPI Fehler: 65
Wert: 17150
SPI Fehler: 92
Wert: 34558
SPI Fehler: 81
Wert: 17406
SPI Fehler: 79
Wert: 17534
SPI Fehler: 94

Von der Sache her ist ja MiSO und MOSI syncron je nach Data Mode.
Wie so muss ich den aber dann zwei Inkrementirungen abzihen?
if (inWert != wert - 2) {
Sollte es nicht -1 sein?

Gut ok, sind eben 16 Bit transfers also 2* 8Bit

Übertrrage ich eien Statischen wert z.B 1234 habeich keinen SPi Fehler. Nur den Ersten der allerersten Aussendung. Auch Komisch.

Setze ich den transfer auf 8 Bit. Dann habe ich nur noch einen SPI Fehler in jedem Schleifendurchgang und muss aber trotzdem noch 2 vom wert Subtrahieren. Bei 8 Bit stimmt dann der auch der Zählerwert am teensy.

Micht Stört jezt hier dieser versatz von zwei schleifendurchgängen / aussendung. Sowohl bei 8 Bit also auch bei 16 bit.
Und weshalb geht die Übetragung in richtung teensy?

Teensy und ESP sind auf eiener PCB Platien verlötet, also eine Fehlerahfte Masse odder Verbindung ist ausgeschlossen.

in der ESP SPi Lib wird der 16 bit wert in zwei 8 Bit werte Zerlegt:

Der Teensy Möchte aber mit eienr Sendung einen 16bit wert loswerden. Ich glaube das ist das Problem.
....
Ich weis mir ist nicht mehr zu helfen, aber villeicht hat wenigstens einer eine Idee :innocent:

Jaaaaa, also da das Problem für die Meisten hier nicht nachzuvollziehen ist habe ich das Problem selbst gelöst.

Ich habe es im Prinzip bei Schreiben des Beitrags schon erwähnt.

Nach ein ein wenig googel'n habe ich das hier gefunden:

Ich habe den Trasnfer 16 angepasst und jetzt ist die Ausgabe einwandfrei:


*Naja gut. Einwandfrei ist übertrieben aber man kann wenigsten Sprache verstehen.
Phonie, also Sprache reicht mir aus.

PS.:
Falls jemand fragen hat wie man Audio vom Browser zum ESP Schafft und auch andersherum, der kann sich gerne an mich wenden.

Hallo,

nachvollziehen kann ich es ehrlich gesagt auch nicht. Die Lösung läuft aber bestimmt auf eine Vertauschung bzw. Korrektur der Sende- bzw. Empfangsreihenfolge hinaus. Dein Testprogramm mit Wert, Zähler und Zeit ist da etwas unpassend. Man hätte nur einen 16 Bit Wert hin- und her übertragen müssen. Wenn der auf beiden Seiten nicht passt schaut man sich den 16Bit Wert und die 2 Byte Werte binär an und kann feststellen welche Reihenfolge vertauscht ist. Entweder die Bitfolge der Byte Werte und/oder die Reihenfolge LSB - MSB. Das wird dein Fix vermutlich korrigiert haben. Und weil der ESP und Teensy verschiedene CPUs sind hätte das auch noch verrückter werden können. Wenn jetzt läuft ist alles okay. :grinning:

Das habe ich im vornherein so auch gemacht. Ich habe sogar die SPi Übertragung mit einer Gleichspannung getestet und mir dann die übermittelten Werte angesehen.
Bis auf 3 Ausrutscher aller 10 Übertragungen war das Ok. Also 10 Übertragungen von 128 Samples.

Es klingt auch jetzt noch nicht besonders gut. Eventuell muss man im Browser mittels Moving average FIR Filter das Signal noch etwas glatt ziehen. Das macht sich aber bei Sprache blöd.
Ich vermute das der Teensy nicht synchron zum Takt antwortet und einige Samples gehen verloren dann ist das Singal einfach kaputt.

Ich habe mich auch ein wenig vertan mit der Wahl des ESP8266. Der ist für 5Khz audio in 16bit via TCP einfach zu langsam. Beachte: 5kHz entspricht laut Abtasttheorem 10kHz zu übertragende Bandbreite. Ich musste die Daten zusätzlich noch Komprimieren.

Bei Audio via TCP und über WiFi, gehen keine Daten verloren das funktioniert immer. Aber die Pufferung ist unendlich kompliziert für Audio um zu setzen.
Im empfangen von Audio Daten ist der ESP8266 recht gut. Ich habe mal WiFi speaker gebaut mit 8 Bit und 44100Hz via TCP. Das geht ganz gut. Aber im Senden ist der ESP unendlich langsam.
Bzw langsam kann man nicht sagen. Es gibt überhaupt keine zyklischen Sende Intervalle.
Wenn ich aller 11Milliskeunden 128 Samples übertragen will, dann kommt alles willkürlich im Browser an.

Sprache_RX_OUT_Browser.zip (1.6 MB)
Sinus400Hz_1000Hz_RX_Browser_OUT.zip (1.5 MB)
Die Dateien sind Klangbeispiele wie sich das Ergebnis Anhört im Browser.
Weshalb bei Sprachpausen das Rauschen verstärkt wird, habe ich auch noch nicht verstandenen. Das klingt nach einer schnell tastenden AGC im Browser. Es gibt in der Web Audio APi keine AGC am Sound Ausgang.

Hallo,

hmmm stimmt, die Sprachqualität wäre für mich noch nicht akzeptabel.
Helfen kann ich dir dabei leider nicht. Teensy habe ich nicht und mit ESP kenne ich mich nicht wirklich aus. Ich weiß nicht ob man dem WLAN Audio eine Priorität mitgeben kann. Oder mit einem ESP32 oder mit einem Raspi probieren. "Problem" beim Raspi ist, dass Programm "Sketch" läuft auf dem OS "nur" nebenbei. Auf einem AVR oder ESP läuft wenigstens der Sketch direkt auf der Hardware. Gut möglich das das WLAN Netz bzw. der Router verantwortlich ist. Eigentlich regelt doch der Router die Prioritäten? Das ist bei mir gefährliches Halbwissen. Wenn hier niemand weiterhelfen kann könntest du dich mit dem konkreten WLAN Problem vielleicht ans mikrocontroller Forum wenden. Mehr fällt mir dazu leider nicht ein. Aber Danke für den Bericht.

Schade, das ist so eine Geniale Plattform. Könnte nicht mehr ohne arbeiten.
Leider Stark vom Chipmangel betroffen.

Also am WLan selbst kann man nichts ändern. das ist wie es ist.
Man kann ein wenig Performance gewinnen indem man das WLAN offen betreibt. Quantensprünge macht man dann aber auch nicht.
Senden zwei ESP's auf der Selben Frequenz oder sind Andre WLAN's der selben Frequenz in der nähe wird es auch langsamer.

Nee, Raspberry ist keine Option. Ursprünglich ging es nur um eine Ferngensteuerung eines Selbstbau Transceiver's. Das mit dem Audio ist mir dann erst später eingefallen. Wenn ich die I2S Pins noch am Teensy frei hätte, hätte ich diesen BUS genutzt.

Ja nee, der ESP läuft bei mir als Access Point. Über einen Router bist du schneller, weil da der ESP IEEE 802.11n als Protokoll versteht.
Ich denke mir mal das hat was mit Zeitfenstern zu tun. Es können ja nun nicht Client und Station gleichzeitig senden. Es muss also irgendwie Gestaffelt werden, wer wann was senden und empfangen darf. Bei IEEE 802.11n legt der Router die Zeitfenster fest und das macht die etwas höhere Bandbreite aus. Und zudem ist die Sende Bandbreite auch noch höher.

Weshlab der ESP das aber nun nicht als Access Point kann weis ich auch nicht genau.

Ich weis nur das WLAN eine OFDM Modulation ist. Im Amatrufunk nutzen wir OFDM teilweise für schlechte Verbindungen. Wenn man das Reguläre SSB Signal nicht mehr versteht, kann OFDM da schon was bewirken. Nachteil ist aber für Sprache reicht eine Bandbreite von 300-3000Hz aus. Digital Voice(OFDM) benötigt aber 5kHz.

Die Amerikaner modulieren OFDM und FT-8 auf' eine LED auf und mache so "Funkverbindung" von bis zu 200kM. Theoretisch geht das auch mit WLAN. Das wäre dann Licht-LAN :crazy_face:

Am ende ist es So, du siehst das Licht nicht mehr aber es wird Trotzdem noch Empfangen demoduliert.

Aber OFDM-Amaturfunk und OFDM_WLAN sind auch noch zwei unterschiedliche Schuhe.

Hallo,

aha Danke, ist informativ.
Zur Led, positiv Verrückte. :joy:

Leider verstehe ich nur unter 10 % von dem, was Du schreibst, könnte aber Teensy 3.2 und ESP32 DevKitC V4 in die Waagschale werfen.

Der ESP32 weicht in manchen Punkten vom ESP8266 ab. Beispielsweise soll er RGB-LED mit Controller (WS2812/WS2815 usw.) mittels DMA mit Daten versorgen können, weshalb ich diesen Typ gewählt habe. Bei Audio habe ich mal mit einer Zeitansage experimentiert und Audio-Dateien aus dem SPIFFS abgespielt, ohne aber in die Tiefe der Materie einzutauchen.

Wenn Du nachvollziehbar beschreibst, was ich machen soll, könnte ich was probieren.

Nächstes Monat die Funkamateur kaufen und nachbauen. Wobei ich glaube ich hab im letzten gelesen, dass sie den Verkauf über Trafiken einstellen...

Welchen Funkamateur soll ich bestechen? Und was bedeutet "Verkauf über Trafiken"?

Bin ich mit dem falschen Fuß aufgestanden?

https://www.funkamateur.de/

eine Zeitschrift.
Der Hinweis auf den fehlenden Gassenverkauf:

# Editorial FUNKAMATEUR 1/2023

---

## Das letzte Heft

Mit dieser Ausgabe verabschiedet sich der FUNKAMATEUR aus dem Angebot des Zeitschriftenhandels. Dies geschieht nicht – wie man vielleicht vermuten könnte – aus wirtschaftlichen Erwägungen, denn der Verkauf über etwa 1700 Verkaufsstellen in acht Ländern – von der großen Bahnhofsbuchhandlung bis zum kleinen Lottoladen – ist nach wie vor profitabel.


dann im "Geile Projekte" Thread ein paar posts zurück lesen, dann kommt der Zusammenhang.

Eine Zeitschrift, aha :blush:

Habe ich hier im Zeitschriftenhandel noch nicht gesehen, aber das hat sich ja nun auch erledigt. Eine Lektüre hätte aber vermutlich nur mein mangelndes Wissen bestätigt.

Was kann man denn bei "...vom Chipmangel betroffen" nur 10% verstehen.
Oder meinst du im allgemein?

Was ist den nun wider bei dir die Waagenschale?? Kaufen? ...Ich dachte ich habe ein komische Eloquenz.
Ja also ich arbeite 90% mit dem Teensy 3.5 oder besser mit dem 3.6. Beruflich habe ich auch überwiegend nur mit den NXP k66 zu tun. Tja aber aktuell ist nichts mit Entwicklung von Steuergräten mit Chips von NXP. Tja und Hobby mit Teensy's und Beruf muss sich noch gedulden.

Ja, der ESP32 ist definitiv die bessere Wahl. Es gibt ja auch eine Kamera dafür, also muss er eine Höhere Bandbreite haben. Obwohl Bild und Audio ist auch zwei verschiedene Paar Schuhe.
Bei einem Bild kann die Framerate von 60 auf 20 FPS Runter gehen. Es wird aber immer noch ein Bewegtes Bild sein. Bei Audio wird das Nix. Verlagsamt du das Audio hast du eine Pitch-Shift Effekt oder aber es setzt aus, da reichen einige Millisekunden das Gehör nimmt alles war.

Man bekommt beim ESP einfach auch nicht heraus wie die Datenpackte Versendet werden.
Ich könnte eventuell etwas Performance gewinnen wenn ich die Websocket Packete selber Schnüre.
und dann in den TX Buffer Schrieb. Aber WO ist der WiFI TX Buffer. Sicherlich nur ein Zeiger oder Register wo man seien Daten hinein schiebt aber WO??

Kiosk Verkauf.

Aja, da war ja was. Den Muss man jetzt abonnieren.

Wenn der Nächste Licht Funk Praxistest durch ist schrieb ich noch einen ein Beitrag dazu ist hier ins Forum, der dann angepinnt werden kann (Wenn das möglich ist). Eventuell auch im teesny Forum unter: Blog Project Submission | Teensy Forum

Oder halt auf unsere Website.

Die Website wird aber demnächst platt gemacht wir ziehen auf eine andren Server um.
Die Veröffentlichung des Teens Licht TRX auf der Webseite erfolgt erst nach dem Release des Funkamateur-Zeitschrift Beitrages.

Nachbauen nicht zwingend nötig. Die Platine gibt es Fertig bestückt auf Wunsch. Für den Teensy und ESP gibt es eine Sockel. Das rechtliche Hühnerfutter ist Fertig bestückt.

Du verwendest in Deinem Text neben regional typischen Begriffen in #6 auch eine Menge technischer Ausdrücke, die ich bisher noch nie gelesen habe. Da kann ich Dir also inhaltlich nicht folgen. Ungefähr ab "OFDM" steige ich aus und bewundere bunte Bilder.

"Etwas in die Waagschale werfen" ist eine Redewendung.

Ich wollte Dir meine Hardware, bestehend aus Teensy 3.2 und ESP32 DevKitC V4 zum Testen anbieten. Du gibst mir zwei Programme, die ich aufspiele und Dir vom Ergebnis berichte. Es sollte ein freundlich gemeintes Unterstützungsangebot sein.

In den drei Jahren, in denen ich mich mit dem ESP32 beschäftige, habe ich mich das noch nie gefragt. Daher bin ich da leider kein adäquater Gesprächspartner. Da landet nichts in der Schale.

Als Funkamateur hier im Forum fällt mir @RudiDL5 ein, der Dich eventuell besser versteht.

OFDM ist ja nun auch das härtste Hardcore Modulation verfahren was es gibt.
Wenn man sich dazu beliehst, verlauft man sich im Labyrinth der Formeln.
OFDM ist auch wiederum nur eine Oberhebegriff für diverse Bekannte Modulationen (AM, PSK).
Der englische wiki ist dazu ganz hilfreich:

Ook, nie gehört.

ja ok. ich werde auf dich zurück kommen, wenn ich mit dem Programmiren am Licht-TRX weiter mache.
Aktuell ist da Pause. Das Gerät muss an die Leute gebracht werden und wir warten erst einmal ab wie die Leute die "neu Entwicklung" annehmen.

Der Otto-normale Arduino Nutzer fragt sich hauch nicht wie der ESP Sendet. Ein Otto-normal Funkamateur ebenfalls nicht.
Ich wollte mal DIGITAL SSTV aufm ESP Modulieren
Ich bin nur bis hierher gekommen (Ab Zeile 959):

Das ist aber nur die Halbe Wahrheit. Da muss es noch andere Funktionen geben.

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