• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

für xorg1990

tsseh schrieb:
welcher ist es denn? vielleicht kommt man ja gut ran? ich kann das zwar nicht löten, aber meine frau hat bessere augen, die macht das immer für mich.
Wo der i2s Pin ist weiß ich auch nicht, das steht nicht mal beim esp-12(nodemcu) geschrieben. Auf dem 01er rum zu Löten war eingleich nicht mein Plan.

Wie seit ihr eigentlich zwischen esp und flash gekommen mit dem Lötkolben, hat deine Frau eine Stecknadel erhitzt, da ist gerade mal 1mm Platz^^
esp_klein_groß.JPG

Für eine vernünftige Voll-duplex Lösung braucht es den esp-03 und SPI, aber was ich mich frage was passiert mit den Flash Speicher wenn der ESP als SPI Slave läuft und der avr als Master.

Überschreibe ich den Flash? Es gibt ja auch mehrer Slaves bei SPI aber der Flash speicher hat gar kein cs/ss Pin. Datenblatt im Anhang. ESP8266 Register Table's habe ich auch noch im Anhang. Theoretisch kann es nicht viel anders sein als beim lesen/schreiben einer sd Karte, aber das macht auch kaum einer, und das wird auch seien Grund haben.

Auf die Reverenz Spannung kann ich verzichten beim avr. SS Pin kann ach auch hart auf GND ziehen, dann spare ich zumindest beim avr einen Pin ein.
 

Anhänge

  • 25017A.pdf
    370,1 KB · Aufrufe: 1
  • esp8266_registerTable.zip
    86,2 KB · Aufrufe: 0
Ein paar Dinge konnte ich noch Herausfinden.
Der avr kann nur mit 8Mhz getaktet werden wenn man die PLL für PWM nutzen möchte.

Die ADC Clock Frequenz hat nichts mit der Sample Rate zu tun.
Wenn avr 8Mhz und adc Vorteiler auf 8 steht ergibt das 1Mhz Clock Frequenz also das Maximum was Atmel verspricht.
Im Free Runnging Modus braucht es 13 Clock Zyklen bis ein wert erfasst wird.
Also 1mhz/13 = 76.92kHz
76.92kHz ist also mein Sample rate sehe ich das richtig so??

• Bit 6 – ADSC: ADC Start Conversion
In Single Conversion mode, write this bit to one to start each conversion. In Free Running mode, write this bit to
one to start the first conversion. The first conversion after ADSC has been written after the ADC has been enabled,
or if ADSC is written at the same time as the ADC is enabled, will take 25 ADC clock cycles instead of the normal
13. This first conversion performs initialization of the ADC.

Da ist schon die Frage schaft der das spi Protokoll überhaut die 76khz a 8Bit das Sample überhaupt?

Auch nicht zu verstehen ist folgende aussage:
###transfer() #####Description Transfers one byte over the SPI bus, both sending and receiving. Interrupts are inhibited during each byte transfer to ensure a consistent bit clock period. #####Syntax SPI.transfer(val); #####Parameters val: the byte to send over the bus (byte) #####Returns the byte read from the bus (byte)
https://github.com/JChristensen/tinySPI
Interrupts are inhibited .... Das würde mein vorhaben unbrauchbar machen :mad:

Was mit den Flash speicher passiert wenn ich die Daten vom avr zum esp sende weiß auch keiner so richtig.

Die out SampleRate also die aufs PWM moduliert wird sollte ~32kHz betragen, da die ELISE Sender das machen.
https://www.aatis.de/content/bausatz/AS802_Einfacher_Licht-Sende-Empfänger


Was ich auch noch nicht verstanden habe ist die "wie schell muss den mein adc auf dem avr nun wirklich den laufen". Druch die PLL erreiche ich eine PWM Frequenz von 64Mhz/256 = 250kHz. auf die 250Khz moduliere ich eine Sample rate von 32Khz auf, sprich das was vom Browser kommt. In den 32Khz stecken aber alla nyquist/2 Frequenzen also 16kHz die wirklich hörbar wären. Dann würde es ja reichen wenn der adc auf dem auch nur 32kHz macht oder doch 64+ ???
 
Zuletzt bearbeitet:
Wo der i2s Pin ist weiß ich auch nicht
scheint gpio3 (rx) zu sein

Wie seit ihr eigentlich zwischen esp und flash gekommen
ging, war der ganz am rand

Für eine vernünftige Voll-duplex Lösung braucht es den esp-03 und SPI, aber was ich mich frage was passiert mit den Flash Speicher wenn der ESP als SPI Slave läuft und der avr als Master.
gute frage, hab ich mich auch schon gefragt bei deinem i2s beispiel mit dem ram, der muss also irgendwie über cs gesteuert werden

Es gibt ja auch mehrer Slaves bei SPI aber der Flash speicher hat gar kein cs/ss Pin. Datenblatt im Anhang.
pin1

76.92kHz ist also mein Sample rate sehe ich das richtig so??
wenn das alles so ist, dann ja, dann ist das deine max. sample rate

Da ist schon die Frage schaft der das spi Protokoll überhaut die 76khz a 8Bit das Sample überhaupt?
sw oder hw lösung? aber egal, du musst ja nicht mit 76khz messen, machst du eben langsammer, würde ich sowieso

Auch nicht zu verstehen ist folgende aussage:

https://github.com/JChristensen/tinySPI
Interrupts are inhibited .... Das würde mein vorhaben unbrauchbar machen :mad:
nee, das ist ja klar, damit würdest du ja das timing durcheinanderbringen. das ist ja aber nur für die laufzeit von transfer() so. du musst deine zeiten ja sowieso so wählen, dass du in einem zyklus messen und übertragen kannst. erst dann (mit reserve) darf ein neuer zyklus beginnen.

Dann würde es ja reichen wenn der adc auf dem auch nur 32kHz macht oder doch 64+ ???
wenn das
Die out SampleRate also die aufs PWM moduliert wird sollte ~32kHz betragen, da die ELISE Sender das machen.
gilt, dann 32kHz
 
Laut Verdrahtung sollte es keinen Kontakt zwischen GPIO Pins und Flash speicher geben.
esp03-boardtop.jpg
GPIO14,12 und 13 werden benötigt für spi, der Flash hängt an ganz anderen Pins am ESP.
esp-03.png

tsseh schrieb:
sw oder hw lösung? aber egal, du musst ja nicht mit 76khz messen, machst du eben langsammer, würde ich sowieso
ESP, ist denke ich Hardware SPI und avr USI also auch Hardware.

Beim avr ist die SPi Bandbreite Cpu Clock/2 also 4Mhz == 4Mbit/sec, mehr als ausreichend. Den ADC lasse ich langsamer laufen.

tsseh schrieb:
nee, das ist ja klar, damit würdest du ja das timing durcheinanderbringen. das ist ja aber nur für die laufzeit von transfer() so. du musst deine zeiten ja sowieso so wählen, dass du in einem zyklus messen und übertragen kannst. erst dann (mit reserve) darf ein neuer zyklus beginnen.
Wie soll ich das den Timen, das erst gemessen und dann erst gesendet wird? Gut ich könnte den Transfer in den ISR vom ADC Packen.
Wäre den das Interrupt Proben noch wenn der avr als SPi Slave läuft und der ESP als Master? Das wäre vielleicht günstiger, dann laufe ich nicht Gefahr das der avr den flash überschreibt.

Ich habe das ohnehin nicht verstandene die tynySPi Master Klasse sendet und empfängt ein byte gleichzeitig:
https://github.com/JChristensen/tinySPI/blob/master/examples/spi_85/spi_85.ino#L58
wärend die ESP Salve klasse einen Puffer überträgt:
https://github.com/esp8266/Arduino/.../examples/SPISlave_Test/SPISlave_Test.ino#L31

Wie soll das bitte zusammen passen?
 
Laut Verdrahtung sollte es keinen Kontakt zwischen GPIO Pins und Flash speicher geben.
nicht an den nach außen geführten gpios

GPIO14,12 und 13 werden benötigt für spi, der Flash hängt an ganz anderen Pins am ESP.
ok, der esp scheint 2 spi schnittstellen zu haben
esp8266_gpio_pin_allocations [ESP8266 Support WIKI]
der flash hängt an einem multi io interface (sqi - gpio 6-11)
und auf gpio 12-15 hast du ein weiteres spi

Wie soll ich das den Timen,
timer isr alle 32khz -> flag setzen
in loop() wenn flag sitzt adc wert lesen dann über spi an esp senden
so einfach
das einzige was zu beachten ist, der code in loop muss definiert fertig sein ehe der timer isr wieder kommt

Ich habe das ohnehin nicht verstandene die tynySPi Master Klasse sendet und empfängt ein byte gleichzeitig:
https://github.com/JChristensen/tinySPI/blob/master/examples/spi_85/spi_85.ino#L58
wärend die ESP Salve klasse einen Puffer überträgt:
https://github.com/esp8266/Arduino/.../examples/SPISlave_Test/SPISlave_Test.ino#L31
ja gut, die esp schnittstelle ist komfortabler als die beim tiny (dafür vermutlich mit overhead)

Wie soll das bitte zusammen passen?
wie? warum nicht, ob du jedes byte einzeln schickst und dann als puffer empfängst und umgekehrt ist ja egal?!
 
tsseh schrieb:
timer isr alle 32khz -> flag setzen
in loop() wenn flag sitzt adc wert lesen dann über spi an esp senden
so einfach

Ja ginge auch, fürs erste lasse ich erst mal den Attiny als Slave laufen.
Aktuell warte ich nur noch auf die Logic level shifter, dann kann es los gehen.

tsseh schrieb:
wie? warum nicht, ob du jedes byte einzeln schickst und dann als puffer empfängst und umgekehrt ist ja egal?!
Nicht ganz, die Attiny Spi klasse kann nur ein byte pro Event senden und empfangen, wiederum die esp klasse nur einen Puffer.
Der avr kann nicht eine byte zum esp senden ein Hunderte kommen zurück, dann kommt "garbage" raus.
 
Nicht ganz, die Attiny Spi klasse kann nur ein byte pro Event senden und empfangen, wiederum die esp klasse nur einen Puffer.
ja gut und?
beim tiny musst du
transfer('h');transfer('a');transfer('l');transfer('l');transfer('h');transfer('o'); aufrufen um beim esp "hallo" zu empfangen.
anders herum sendest du beim esp setData("hallo"); und musst auf dem tiny buffer[idx++] = transfer();buffer[idx++] = transfer();buffer[idx++] = transfer();buffer[idx++] = transfer();buffer[idx++] = transfer();buffer[idx++] = transfer(); zum empfang aufrufen.

Der avr kann nicht eine byte zum esp senden ein Hunderte kommen zurück, dann kommt "garbage" raus.
ähhh was? ich versuch das mal zu deuten
Der avr kann nicht eine byte zum esp senden
doch: transfer('X');
Hunderte kommen zurück
wenn Hunderte zurück kommen, kann aber der tiny in der zwischenzeit nichts anderes machen als ein buffer[idx++] = transfer(); nach dem nächsten. das dürfte ungünstig sein.
was willst du denn überhaupt machen?

- - - Aktualisiert - - -

die passende master-implementierung liegt gleich daneben
https://github.com/esp8266/Arduino/tree/master/libraries/SPISlave/examples/SPISlave_Master
die mit der arduino-kompatiblen SPI-klasse https://github.com/esp8266/Arduino/blob/master/libraries/SPI/SPI.h

https://github.com/esp8266/Arduino/blob/master/libraries/SPISlave/examples/SPISlave_Master/SPISlave_Master.ino#L111
ruft
https://github.com/esp8266/Arduino/blob/master/libraries/SPISlave/examples/SPISlave_Master/SPISlave_Master.ino#L98
ruft
https://github.com/esp8266/Arduino/blob/master/libraries/SPISlave/examples/SPISlave_Master/SPISlave_Master.ino#L88
ruft
https://github.com/esp8266/Arduino/blob/master/libraries/SPISlave/examples/SPISlave_Master/SPISlave_Master.ino#L69

nebenbei: dort sieht man dass die slave-klasse immer 32 byte erwartet, du musst also immer 32 byte mit padding 0 übertragen und deine "hunterten bytes" auf 32-byte-blöcke aufteilen
 
tsseh schrieb:
was willst du denn überhaupt machen?
Praktisch das gleiche wie bei den WIFI Speakern nur als voll-duplex Lösung.

Ich lasse aber den avr nun doch als SPi Client laufen, ich habe nur gerätselt wie das mit den CS Pin gehen soll beim Attiny85. Es gibt da ein 3-Wire Mode.

Problem, ich kann meine Code nicht kompilieren:
<built-in>: fatal error: when writing output to /tmp/arduino_build_169954/preproc/ctags_target_for_gcc_minus_e.cpp: No space left on device
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board ATtiny25/45/85.
Also meine Festplatte ich definitiv nicht voll!

Oder meint Arduino den Code:
Code:
#define F_CPU 8000000UL
#include "pins_arduino.h"


#define bufferSize 128
#define BUFFER_MASK (bufferSize-1)
/*
  Pinmodes
  PB0 MOSI
  PB1 MISO
  PB2 Clock
  PB3 ADC Input
  PB4 PWM Out
*/
static struct adc_FIFO {//ringBuffer als struct für pcm saples
  byte data[bufferSize];
  volatile byte read_ptr; // zeigt auf das Feld mit dem ältesten Inhalt
  volatile byte write_ptr; // zeigt immer auf leeres Feld
} adc_buffer = {{}, 8000, 0};

static struct pcm_samples_buffer {//ringBuffer als struct für pcm saples
  byte data[bufferSize];
  volatile byte read_ptr; // zeigt auf das Feld mit dem ältesten Inhalt
  volatile byte write_ptr; // zeigt immer auf leeres Feld
} pcm_buffer = {{}, 0, 0};

void setup() {
  cli();
  // Enable 64 MHz PLL and use as source for Timer1
  PLLCSR = 1 << PCKE | 1 << PLLE;
  // Set up Timer/Counter1 for PWM output
  TIMSK = 0;                              // Timer interrupts OFF
  TCCR1 = 1 << CS10; //1<<PWM1A | 2<<COM1A0 | 1<<CS10; // PWM A, clear on match, 1:1 prescale
  GTCCR = 1 << PWM1B | 2 << COM1B0;       // PWM B, clear on match
  OCR1B = 128;               // 50% duty at start on pin PB4
  // Set up Timer/Counter0 for 44.1kHz interrupt to output samples.
  TCCR0A = 3 << WGM00;                    // Fast PWM sets bits WGM00 and WGM01, which (when combined with WGM02 from TCCR0B below) enables Fast PWM mode
  TCCR0B = 1 << WGM02 | 2 << CS00;        // 1/8 prescale
  TIMSK = 1 << OCIE0A;                    // Enable compare match
  OCR0A = 22;                            // 22us = 44100HZ
  //pinModes
   pinMode(MOSI, INPUT);// initialize the MOSI Port (PIN 0) 
 pinMode(MISO, OUTPUT);// initialize the MISO Port (PIN 1) 
 pinMode(SCK, INPUT);// initialize the SCK Port (PIN 2) 
  pinMode(4, OUTPUT);
  pinMode(3, INPUT);

 USICR = (1<<USIWM0)  // SPI mode; Uses DO, DI, and USCK pins.
         |(1<<USIOIE)  // Enable interrupt
         |(1<<USICS1) // Clock is external
         |(0<<USICS0); // SPI Mode 0
  
  //ADC settings 8bit value
  ADMUX =   3 | //channel 3
            (1 << ADLAR) |     // left shift result
            (0 << REFS1) |     // Sets ref. voltage to VCC, bit 1
            (0 << REFS0);    // Sets ref. voltage to VCC, bit 0

  ADCSRA =
    (1 << ADEN)  |     // Enable ADC at 38,46 kHz Samplerate
    (1 << ADSC)    | // start conversion
    (1 << ADATE)   | // free running
    (1 << ADPS2) |     // set prescaler to 8, bit 2
    (0 << ADPS1) |     // set prescaler to 8, bit 1
    (0 << ADPS0);      // set prescaler to 8, bit 0
  sei();  // enable interrupts
}


ISR(ADC_vect)// interuppt each 38kHz
{
  byte adcValue = ADCH;
  register byte next = ((adc_buffer.write_ptr + 1) & BUFFER_MASK);
  if (adc_buffer.read_ptr != next) {
    adc_buffer.data[adc_buffer.write_ptr] = adcValue;
    //buffer.data[buffer.write_ptr & BUFFER_MASK] = byte;
    adc_buffer.write_ptr = next;
  }
}

// Sample interrupt 44.1khz
ISR(TIMER0_COMPA_vect) {
  if (pcm_buffer.read_ptr != pcm_buffer.write_ptr) {
    byte sample  =  pcm_buffer.data[pcm_buffer.read_ptr];
    pcm_buffer.data[pcm_buffer.read_ptr] = 0;
    OCR1B = sample;
    pcm_buffer.read_ptr = (pcm_buffer.read_ptr + 1) & BUFFER_MASK;
  }
}

ISR(USI_OVF_vect){
  byte incommingByte = 0;
  // Wait for complete byte to arrive
 while ((USISR & (1<<USIOIF))==0) {
 }
 // Clear counter overflow flag so next byte can begin arriving
 // While we're processing this one
 USISR = (1<<USIOIF);
 incommingByte = USIDR;
}

void loop() {
}
 
Praktisch das gleiche wie bei den WIFI Speakern nur als voll-duplex Lösung.
ich habs immer noch nicht verstanden, egal
aber warum voll-duplex? das würde ich ja auf keinen fall so machen

Problem, ich kann meine Code nicht kompilieren:
gnu fehlermeldungen - manchmal recht "gewöhnungsbedürftig"
das ist alles an code? dann kann es nicht die größe sein. hast du schreibrechte?
 
tsseh schrieb:
aber warum voll-duplex? das würde ich ja auf keinen fall so machen.
Ich auch nicht aber man muss ja Wettbewerbsfähig bleiben.
Die einfachen Licht-Sende-Empfänger sind voll Dupelx Fähig, da das muss man ja Toppen.
ELiSE steht für „Einfacher Licht-Sender-Empfänger“, wobei mit zwei Bausätzen sogar Gegensprechen möglich ist!
https://www.aatis.de/content/amateurfunk-über-licht

Der nachteil ist aber die Modulieren AM, das ist nicht so effizient wie PWM. Die Idee war über den ESP die Daten über Wlan rüber zu schaffen. Weil, a habe ich keine bock neben ein Laser zu stehen und b einmal an das Stativ kommen und die Laser sind nicht mehr justiert.

tsseh schrieb:
das ist alles an code? dann kann es nicht die größe sein. hast du schreibrechte?
Hab's gefunden mein /tmp Verzeichnis ist voll. ich wusste gar nicht das das voll werden kann.

Wie dem auch sei ich komme aktuell nicht weiter, da die Pegelwandler noch nicht gekommen sind. Außerdem platzt mir bald der Schädel.

Vater hat Hodenkrebs, Muttern kann nicht mehr laufen weil was mit dem Knie und von meiner Freundin, deren Beste Freundin liegt im Streben.
Frag nicht was hier los ist... ein Geweine.

Die Umstände sind mehr als scheiße, da sie Ursprünglich aus Venezuela kommt und hier niemanden hat. Und Krebs ist ein scheiß, sie hat eine Gehirnblutung am Stammhirn/Hirnstamm. Ich war gestern im KH, habe bald gekotzt und ich habe schon viel erlebt. Das letzt war vor 2 Jahren auf Arbeit, da ist eine Kette beim Spunden gerissen und auf meine Kollegen drauf, das sind Bilder... ach seiß auf die Bilder das Geräusch.
https://www.youtube.com/watch?v=xk2rvgONzYQ

Hier hilft nur noch gute Musik.
https://www.youtube.com/watch?v=rAsgIwkGAwY
oder:
https://www.youtube.com/watch?v=5-NsrOP_dqg
 
Zuletzt bearbeitet:
Hi tsseh, nachdem sich alles soweit Familiär wider eingependelt hat möchte ich dich auf den aktuellen stand bringen.

Was nicht geht:
Das gegensprechen wird leider nichts, da die WLAN Verbindung nicht Voll-Duplex fähig ist. Ich hatte gedacht immer eine Buffer zu empfangen und einen zu senden. Im Browser habe ich immer gewartet bis ein Buffer ankommen ist, dann erst habe ich den Nächsten abgeschickt.
Aber aus irgendwelchen gründen dauert das Umschalten zwischen empfangen und senden zu lange im ESP, bei einer Puffergroße von 128 bytes jeweils 3ms. Irgendwann läuft mir im Broser der Puffer über, selbest bei einer Samplerate von 8000Hz.

Lasse ich das senden/empfangen weg kann ich bis zu einer SR von 44100Hz zu esp senden, allerdings mit 1sec delay.

Es gibt im Netzt auch keine Hinweiße dadrauf wie schnell die WIFI Verbindung im esp ist und ob es ein unterschied macht zwischen Station und Access Point.

Bei mir läuft der ESP als AP im 802.11g Protokoll was 54Mbit/s sein sollen. 802.11n funzt nur im STA modus.


Die Übertagung vom ESP zum avr via SPI geht auch mit 44100Hz. Der avr kann PCM bis zu 48Khz wiedergeben nur die SPI Schnittstelle macht da nicht mehr mit oder einer der Prozessoren.
44100Hz geht einwandfrei, wie gesagt mit delay.

Die PWM Audio Qualität ist im übrigen sehr sehr gut.

Mir fällt gerade ein das das Logitech Z-5450 Wlan Rear boxen hatte. Mal schauen ob es was gibt im Netz wie die das gelöst haben.

Wenn du noch eine Idee hast das WLAN zu Beschleunigenen melde dich doch mal.
 
Das gegensprechen wird leider nichts, da die WLAN Verbindung nicht Voll-Duplex fähig ist. Ich hatte gedacht immer eine Buffer zu empfangen und einen zu senden. Im Browser habe ich immer gewartet bis ein Buffer ankommen ist, dann erst habe ich den Nächsten abgeschickt.
Aber aus irgendwelchen gründen dauert das Umschalten zwischen empfangen und senden zu lange im ESP, bei einer Puffergroße von 128 bytes jeweils 3ms. Irgendwann läuft mir im Broser der Puffer über, selbest bei einer Samplerate von 8000Hz.
das verstehe ich alles nicht
Das gegensprechen wird leider nichts, da die WLAN Verbindung nicht Voll-Duplex fähig ist. Ich hatte gedacht immer eine Buffer zu empfangen und einen zu senden. Im Browser habe ich immer gewartet bis ein Buffer ankommen ist, dann erst habe ich den Nächsten abgeschickt.
das ist ja gerade nicht voll duplex
Aber aus irgendwelchen gründen dauert das Umschalten zwischen empfangen und senden zu lange im ESP, bei einer Puffergroße von 128 bytes jeweils 3ms.
welches umschalten?
Irgendwann läuft mir im Broser der Puffer über, selbest bei einer Samplerate von 8000Hz.
wenn ein puffer überläuft musst du den schneller leeren
 
tsseh schrieb:
das ist ja gerade nicht voll duplex
Nee ist es ja auch nicht, aber da das Wlan ja bedeutend schneller ist (sein sollte) als ich Daten sende, könnte ich ja einen Buffer senden im ESP verarbeiten und danach vom ESP zurück zum Browser senden. So als wenn es den eindruck von voll-duplex vermittelt.

Angenommen ich sende in der Sekunde 8000bytes zum esp und das wlan geht bis 54Mbit/s dann sind die 8000bytes ja im nu durch, es sollte genügend Zeit sein um 8000bytes auch wider zum Browser zurück zu senden. Der esp läuft wahlweise mit 80 oder 160Mhz. Alles was das zwischen ist, ist eine Schleife und der SPI Transfer. Selbst wenn ich die schleife und den SPi Transfer weglassen ist der ESP nicht in der Lage 8000bytes zu empfange und anschließend zu senden.


Im Browser vergehen zwichen send() Event und onmessage event immer 3ms. Selbst wenn ich die 8000bytes in 128byte große cuncks unterteile.

Meine Vermutung ist, das das "umschalten" zwischen empfangen und senden zu lange dauert. Keine Ahnung wie das im ESP funktioniert WLAN ist OFDM Moduliert und irgendwo muss noch ein Tuner sein. Die OFDM Modulation ist sehr sehr sehr Rechen aufwendig wenn das nicht in Hardware gelöst wird das ist das das Problem.

Digitalradio, DVB-T und Satellit Übertagung ist alles OFDM:
https://www.csie.ntu.edu.tw/~hsinmu/courses/_media/wn_11fall/ofdm_new.pdf
 
Zuletzt bearbeitet:
Im Browser vergehen zwichen send() Event und onmessage event immer 3ms. Selbst wenn ich die 8000bytes in 128byte große cuncks unterteile.
find ich jetzt sehr wenig. die verbindung muss ja auch erst aufgebaut werden oder geht das über eine stehende verbindung? websocket? aber selbst wenn, find ich 3ms wahnsinnig schnell. onmessage läuft ja in einem anderen js-abarbeitungspfad als send. da hätte ich locker mit 20-30ms gerechnet.
 
Naja wenn du die 8000byte in rund 64 a 128bytes große Teile unterteilst, hast du 192ms Verzögerung.

Außerdem ist das mit den 3 ms etwas geflunkert, weil ab und zu mal verausgabt sich der esp total dann hast man mal 700 oder 600ms delay.

Ich möchte mal prüfen ob auch so ist wenn der esp als Station läuft. Nicht das er als AP noch andere dinge zu elendigen hat wie z.b Kanäle ausortieren oder eine art Fehlerkorrekturverfahren, die ich nicht brauche da ja das TCP Protokoll sowas schon beinhaltet.

Ach ja und ich verwende eine Werbsocket Verbindung:
https://github.com/Links2004/arduinoWebSockets

- - - Aktualisiert - - -

Schau mal:
http://zonerobotics.com/throughput-testing-of-esp8266-module-size-matters/
oder
http://bbs.espressif.com/viewtopic.php?t=2187

Klärt aber nicht warum das senden/empfangen toggeln so lange dauert.
 
Naja wenn du die 8000byte in rund 64 a 128bytes große Teile unterteilst, hast du 192ms Verzögerung.
wie gesagt, 3ms zw. 2 events im browser finde ich schnell (für js verhältnisse)
auf dauer wirst du den browser das (vermutlich) auch nicht abverlangen können

Außerdem ist das mit den 3 ms etwas geflunkert, weil ab und zu mal verausgabt sich der esp total dann hast man mal 700 oder 600ms delay.
600 sind zuviel, das dürfte dann tatsächlich am esp liegen, der dann mit anderen dingen beschäftigt sein wird

Ich möchte mal prüfen ob auch so ist wenn der esp als Station läuft. Nicht das er als AP noch andere dinge zu elendigen hat wie z.b Kanäle ausortieren oder eine art Fehlerkorrekturverfahren, die ich nicht brauche da ja das TCP Protokoll sowas schon beinhaltet.
selbst wenn, das sind alles keine 600ms. außerdem werden sie genau das machen was notwendig ist


das ist aber wieder was anderes.
1. dass du die 54 Mbit nicht als reine nutzdatenrate hast ist ja klar
2. mit der antenne wirst du überhaupt nicht in die nähe der 54 Mbit kommen
3. ist das die übertragung über das serielle at-protokoll. du sendest alles an den esp über die serielle schnittstelle(die hatten eine baudrate von 400k glaube ich, schneller geht es damit schon mal nicht). den at-befehl musst du dann noch parsen. und dann erst wird das über wlan gesendet. die nächste frage ist, wieviel daten senden sie immer. auf 2k blöcke muss das sowieso aufgeteilt werden, sprich das ganze prozedere muss für mindestens jeden 2k block laufen. nehmen sie kleinere blöcke, dann entsprechend öfter.


Klärt aber nicht warum das senden/empfangen toggeln so lange dauert.
genau!
von welchem fall sprechen wir hier? die 3ms sind erklärbar, die 600ms nicht

- - - Aktualisiert - - -

von welchem fall sprechen wir hier? die 3ms sind erklärbar, die 600ms nicht
vielleicht doch nicht unbedingt, hier mal ein testUnbenannt.png
von regelmäßigen ausrutschern mal abgesehen um die 0-1 ms bei lokalem php-websocket-server
 
Habe heute auch noch mal getestet es dauert nämlich bedeutend länger. Habe mit diesmal mit den ESP 03 gemessen und mit SPi Übertagung an den AVR. so wie es ja am Ende sein soll.

Zwichen request und responce liegen total willkürliche Zeiten:
80Mhz...8kHz.jpg

gemessen wurde mit performance.now();

Habe alle WLAN Protokolle druck CPU Frequenz 160/80Mhz Station/AP... keine Änderung.

Alle 3ms wird ein onmessage event gefeuert wenn ich vom esp zum browser sende only.

Ebenfalls festgestellt habe ich, dass gar kein onmessege event gefeuert wird wen der zu sendende Puffer großer ist als 1024bytes.
Selbst wenn ich via undef das WEBSOCKETS_USE_BIG_MEM herausnehme https://github.com/Links2004/arduinoWebSockets/blob/master/src/WebSockets.h#L50

Andersrum vom Browser zum esp kann ich bis 16384 und mehr bytes.

Also half duplex only oder hast du noch eine idee?? AJAX vielleicht?
 
Zwichen request und responce liegen total willkürliche Zeiten:
naja, ganz so willkürliche sind die ja nicht, mit 100ms würde ich aber rechnen

Alle 3ms wird ein onmessage event gefeuert wenn ich vom esp zum browser sende only.
wenn du zusätzlich was machst, ist es ja klar, dass du für kommunikation und verarbeitung von daten über wlan weniger zeit hast

Ebenfalls festgestellt habe ich, dass gar kein onmessege event gefeuert wird wen der zu sendende Puffer großer ist als 1024bytes.
ohne jetzt wirklich nachgesehen zu haben sollten es 15*1024 für den empfangspuffer sein und beim senden ohne limitierung, aber selbst mit 1024 und 100ms sollte es doch gerade so gehen deine 8000 byte zu übertragen. zur sicherheit solltest du doppelt soviel puffern, falls die 100ms mal mehrfach überschritten werden.

das hat damit nichts zu tun, das sorgt nur dafür das die daten nicht gestückelt werden, wenn sie in ein tcp-paket passen

Also half duplex only oder hast du noch eine idee?? AJAX vielleicht?
versuchs mit ajax, prinzipiell sollte das eher langsammer sein
 
tsseh schrieb:
ohne jetzt wirklich nachgesehen zu haben sollten es 15*1024 für den empfangspuffer sein und beim senden ohne limitierung, aber selbst mit 1024 und 100ms sollte es doch gerade so gehen deine 8000 byte zu übertragen. zur sicherheit solltest du doppelt soviel puffern, falls die 100ms mal mehrfach überschritten werden.
Nee 100ms ist zu langsam selbst mit 6000byte läuft der Puffer über. Der Puffer hat schon die 4 Fache größe.

Du Musst ja auch damit rechen das das Schreiben in den Puffer an den Event vom ScriptProcessor hängt wenn die Samplerate im Browser 44100Hz ist und die Puffergröße des SP 16384, dann schreibe ich aller 1/44100*16384 = 0,371519274 Sekunden rund 5000 bytes in den Ringpuffer.
5000byte daher weil down gesampled auf 8000Hz.

Oder wie hast du gedacht?

Senden und Empfangen tue ich aber jeweils nur 128byte große chunks, da der Ringpuffer auf dem avr nicht größer ist.

Aber avr hin oder her selbst wenn ich keine SPI Übertagung mache und nur die Websocket Klasse auf den ESP läuft geht es nicht!
Selbst wenn ich 1024byte große chunks mache.

tsseh schrieb:
versuchs mit ajax, prinzipiell sollte das eher langsammer sein
Ja eigentlich kann es nicht schneller sein. Wenn es aber geht spare ich immerhin eine Klasse ein.
Einfach ausprobieren.
 
Zuletzt bearbeitet:
Du Musst ja auch damit rechen das das Schreiben in den Puffer an den Event vom ScriptProcessor hängt wenn die Samplerate im Browser 44100Hz ist und die Puffergröße des SP 16384, dann schreibe ich aller 1/44100*16384 = 0,371519274 Sekunden
das sind aber fast 400 ms

rund 5000 bytes in den Ringpuffer.
3000

Oder wie hast du gedacht?
ich habe gedacht, daß 3000 byte aller 400ms drinn sein sollten

Senden und Empfangen tue ich aber jeweils nur 128byte große chunks, da der Ringpuffer auf dem avr nicht größer ist.
ach daran liegts? ist ja aber für die übertragung zum esp über wlan erst mal egal. wenn du die 3000 byte immer im block zum esp sendest und dann diesen block auf dem esp nochmal in 128 byte blöcke unterteilst und zum avr sendest sollte das doch gehen. hast halt ne halbe sekunde verzögerung drinn

Aber avr hin oder her selbst wenn ich keine SPI Übertagung mache und nur die Websocket Klasse auf den ESP läuft geht es nicht!
Selbst wenn ich 1024byte große chunks mache.
weil? wie sind denn die zeiten? mit 3000, 1024 und 128byte? die ~100 ms waren für die 128byte blöcke? wächst das in etwa linear an wenn du 1024 byte blöcke nimmst? ich hätte jetzt erwartet dass das nicht passiert, wenn du für 1024 byte blöcke dann aber fast ne sekunde brauchst liegt es wohl wirklich an der wlan übertragungsrate, das glaube ich aber nicht wirklich.
 
Zurück
Oben