RF Channels

[billy0xff]

Ich denke das Problem des Pinouts ist bei meinem Aufbau erledigt, hier sieht man die Antwort des Inverters im HF-Spektrum. Der Inverter - betrieben am Labornetzgerät auf der DC-Seite und nicht ans Netz angeschlossen - wird trotzdem nicht erkannt:

Receive success: 0 Receive fail: 313 Frames received: 0 Send Cnt: 937 Inverter 'HM400' is not available and is not producing

Vorbereitung: Version 0.4.25 , sowie

define CHANNEL_HOP

(statt auskommentiert)

mTxChLst[0] = 3; (statt 40)

Screenshots:

1_ahoy_aktiv__inverter_aus.png

2_ahoy_aktiv__inverter_ein.png

3_CW_ahoy_ausinverter_aus.png 

4_ahoy_aus__inverter_ein.png

5_ahoy_ein__inverter_ein.png

Man sieht, dass der Inverter (M2) ein Signal abgibt, nachdem die DTU (M1) aktiv ist.

Der Hintergrund ändert sich etwas, abhängig ob das ESP-WLAN aktiv ist oder nicht, der Rest sind WLANs oder Bluetooths, etc.

So nun die große Frage wie denn korrekt konfiguriert werden muss (Channel hop? Channel-Nomenklatur?) um die Antwort vom Inverter auch empfangen zu können. Besten Dank schon einmal.

[stefan123t]

@billy0xff vielen dank für die Screenshots. Die Frequenz M2 2.461 GHz entspricht m.E. Kanal 2461 bzw. 61. Die sollte also auch in der mRxChLst eingetragen sein. Vielleicht kann man die Reihenfolge der Rx Kanäle anders angehen, d.h. dass er ab und an auch mal mit Channel 61 beginnt bzw. so lange dort horcht, bis die Antwort da ist.

[billy0xff]

wäre auch vorteilhaft, wenn man dies auch im Setup entsprechend konfigurieren könnte.

[stefan123t]

Hallo @billy0xff kann man indirekt konfigurieren. Aktuell haben wir 5 Retransmits als Default konfiguriert und unsere Liste mRxChList[] hat ebenfalls fünf Elemente.

https://github.com/grindylow/ahoy/blob/c35c86210f8507be7352ead73c02e5855f3f9d63/tools/esp8266/hmRadio.h#L62-L70

Das heißt nach jeder „Runde“ an fehlgeschlagenen Versuchen die Pakete vom WR zu empfangen, fängt er wieder an der selben Stelle im Spektrum an zu lauschen.

Mit diesem deterministischen Verhalten scheint er die Antworten offenbar nie zu bekommen ?

getRxNxtChannel müsste man also entweder immer einen zufälligen Kanal auswählen lassen oder zumindest bei jedem neuen Sendeversuch auch den mRxChIdx zufällig initialisieren.

https://github.com/grindylow/ahoy/blob/c35c86210f8507be7352ead73c02e5855f3f9d63/tools/esp8266/hmRadio.h#L293-L298

https://github.com/grindylow/ahoy/blob/c35c86210f8507be7352ead73c02e5855f3f9d63/tools/esp8266/hmRadio.h#L222

[billy0xff]

Hallo Stefan, das allereinzige was ich selber noch machen kann ist: mRxChLst[0] = 61; // ex 03;

Schade dass die Kanalzuweisungen nicht so wie die Pinzuweisungen im Webinterface geändert werden können, dann könnte man nämlich viele Kombinationen schneller durchtesten. Der TX-Channel ist aber immer fix wie es scheint.

[billy0xff]

CHANNEL_HOP wieder auskommentiert und mRxChLst[0] = 61; // ex 03; mRxChLst[3] = 03; // ex 61;

ergibt keinerlei Verbesserung: Spektrum hat den gleich Verlauf mit M1 auf 2403 und M2 (Inverter) audf 2461. Weiterhin "Inverter 'HM400' is not available and is not producing"

[billy0xff]

Inverter gegen einen anderen HM400 mit s/n 112174xxxxxx getauscht ergibt das gleiche Ergebnis: HF-Antwort im Spektrum sichtbar aber kein "Receive success".

[stefan123t]

@billy0xff #CHANNEL_HOP wird nirgends verwendet, das ist vermutlich ein Überbleibsel aus alten Zeiten (Hubi's Code). Man kann die Zeile m.E. löschen. Das TX Channel Hopping sollte man m.E. ebenfalls wie mRxChLst[4] und mRxIdx implementieren.

Ich habe noch eine Vermutung, daß der WR eventuell zu viele Alarm Events gesammelt hat und einmal einen Reset seines Fehlerspeichers braucht.

Hat schon jemand das Type_CleanState_LockAndAlarm ;// Lock alarm cleared // 0x14 implementiert ?

7E 51 81101507 81101507 81 14 00 B00E 73 7F Type_CleanState_LockAndAlarm 0x14
^^------------------------------------------ SOF Start of Frame 0x7E
   ^^--------------------------------------- MainCmd 0x51 DEVCONTROL_ALL
      ^^^^^^^^------------------------------ WR Serial ID
               ^^^^^^^^--------------------- DTU Serial ID wird vom NRF24 überschrieben, da initial vom Treiber gesetzt
                        ^^------------------ Single Frame ID
                           ^^--------------- SubCmd siehe oben
                           ^^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll
                                 ^^^^------- CRC16 / CRC-Modbus über die Daten, nach und excl. Frame ID!
                                      ^^---- CRC8
                                         ^^- EOF End of Frame 0x7F

[stefan123t]

Channel Hopping mit mTxIdx scheint soweit zu funktionieren. Habe positive Rückmeldungen aus dem Chat bekommen.