AskSin Analyzer XS - Der Analyzer als Desktop-App ohne ESP

[jp112sdl]

Die FW Übertragung erfolgt (zumindest bei BidCos) im 100k Fast Mode.
Das wird vom Analyzer nicht erfasst

[Stefan0815]

Die FW Übertragung erfolgt (zumindest bei BidCos) im 100k Fast Mode.
Das wird vom Analyzer nicht erfasst

...und bei HmIP-RF? Ich habe ausschließlich IP-Geräte.
Sollte die Übertragung nicht trotzdem die Frequenz belasten?

[Wombater]

Moor, ich bins nochmal mit meinem Darstellungsproblem:

Habe nun auf dem neu eingerichteten Windows 10 pro (64 Bit, alle Updates geladen) den Askin-Analyser XS mit --enable-logging gestartet und folgende Ausgabe erhalten:

Code: Alles auswählen

Data-Path: C:\Users\<Mein name>\AppData\Roaming\asksin-analyzer-xs
Detected SerialPort: COM4 (FTDI)
Server started on port 52336
Serving UI from C:\ASK\resources\htdocs
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check https://github.com/electron/electron/issues/18397
Fetched Device List from http://RaspberryMatic:8181/a.exe?ret=dom.GetObject(ID_SYSTEM_VARIABLES).Get(%22AskSinAnalyzerDevList%22).Value()
Connected to COM4
I: AskSin++ V4.1.6 (Sep 24 2020 21:38:48)
I: CC init1
I: CC Version: 14
I:  - ready
I: :00;
I: :62;
I: :62;
I: :64;
I: :64;
I: :64;
I: :63;
I: :63;
I: :64;
I: :3B1810008E682DC132E8E0119137B950305FE056A09FC0A2DDDB;
I: :63;
I: :65;
I: :63;
I: :62;
I: :62;
I: :64;
I: :63;
I: :562710008E4BE2F8BA4BEB0012E409F8E420FCD132540B35CABB956E9136C9F1D7AFB109522245A18C;
I: :56;

Das sieht mir (als AskSin-Laie) ganz gut aus. Keine groben Fehlermeldungen und die seriellen Daten kommen. Auch die RAspbberrymatic wird abgefragt.

Dennoch bleiben die Anzeigen im AskSin Analyzer Programm leer, da tut sich nichts.

Hat vielleicht jemand noch eine Idee? Langsam weiß ich nichts mehr auszuprobieren. Das wäre zwar ein schöner Grund sich in Electron und Javascript einzuarbeiten aber das würde dann doch recht lange dauern mit der Lösung des DC Problems.

Könnte es irgendwie an Firewall Einstellungen etc. liegen. Irgendwie läuft ja die ganze Kommunikation über TCPIP (schätze ich mal).

Wenn jemand noch einen Tipp hat wäre das super.

[jp112sdl]

Die FW Übertragung erfolgt (zumindest bei BidCos) im 100k Fast Mode.
Das wird vom Analyzer nicht erfasst

...und bei HmIP-RF? Ich habe ausschließlich IP-Geräte.
Sollte die Übertragung nicht trotzdem die Frequenz belasten?

Ja natürlich belastet es "die Frequenz". Der Analyzer berechnet den DC nur anhand der Länge von empfangenen Paketen.
Da bei der FW Übertragung keine Pakete ausgewertet werden (können), passiert da auch nix am DC

[Ron24]

Hallo Wombater, wir scheinen das gleiche Problem zu haben, leider zeigt der Analysator hier auch noch keine Daten an, deshalb nur mal als eine Idee für die Fehlersuche:
Es müsste doch möglich sein, eine Art Test-Scetch zu machen, der nichts anderes macht, als gültige Telegramme auf der seriellen Schnittstelle zu erzeugen, die dann in der Software angezeigt werden. Mit so einem Scetch könnte man zumindest die Fehlerquelle besser einschränken und sehen, ob prinzipiell der Datenfluss über die serielle Schnittstelle funktioniert.
Der Fehler liegt wohl entweder an falschen Telgrammen (Formatierung/Datenaufbereitung des CC1101/Arduino), am durchreichen der Telegramme an die seriellen Schnittstelle (FTDI, Treiber etc), oder irgendwelche Einstellungen in der Software.
Um so ein Test-Scetch zu machen, müsste man einige verlässlich, richtige Telegramme haben, die man einfach über die serielle Schnittstelle zyklisch senden könnte.

Lg Ron

[TomMajor]

Hallo Wombater und Ron24,
ich habe mal schnell meinen angeworfen. Der Log sieht in etwa so aus wie von Wombater gepostet, bei mir hört er aber so auf:

Code: Alles auswählen

I: AskSin++ V4.1.3 (May  8 2020 19:00:05)
I: CC init1
I: CC Version: 14
I:  - ready
I: Config Freq: 0x21652A

Danach ist Ruhe im Log und die Anzeige im Analyzer geht los, keine "I: xx" messages mehr.

Schaut euch noch mal den Sniffer an, Fuses richtig, für 8/16MHz richtig geflasht, HW prüfen usw., ich vermute das Problem im Sniffer bei euch.

[jp112sdl]

Dennoch bleiben die Anzeigen im AskSin Analyzer Programm leer, da tut sich nichts.

Wird auch keine rote Linie gezeichnet, wie bei TomMajor im Screenshot?

[Ron24]

Hallo
Danke für die Hilfestellung von euch.
Gemäss Anleitung habe ich eigentlich alles so gemacht wie es sein soll, jedoch zeigt es wirklich nichts im Programm an. Auch keine rote Linie.
Dürfte ich vielleicht noch jemand bitten, mir 2,3 Telegramme von dem seriellen Monitor zu posten, die einen gültigen Wert im Analysator anzeigen, nur dass ich hier mal versuchen kann, diese Situation zu simulieren.

Vielen Dank
LG, Ron

[TomMajor]

Du könntest testweise einen Uno oder Nano nehmen und einfach jede Sekunde diesen String mit 57600 Baud senden:

Code: Alles auswählen

:64;\n

Damit müsstest du die RSSI Linie konstant bei 100 sehen wenn ich den Sniffer code richtig deute:
https://github.com/psi-4ward/AskSinAnal ... 8P.ino#L74

Das wär ein einfacher Test ob es an der PC App liegt oder davor.

[Wombater]

Hallo jp112sdl und TomMajor und Ron24,

danke für Eure Tipps. Es wird auch bei mir keine rote Linie angezeigt, einfach gar nichts.

Hier der Sniffer-code den ich verwende:

Code: Alles auswählen

//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2019-05-24 jp112sdl Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------

// Enable th 0.91" 128x32 OLED display
// #define USE_OLED


#include <SPI.h>
#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <Device.h>
#include <Register.h>

#ifdef USE_OLED
#include "Ssd1306.h"
#endif

#ifndef LED_PIN
#define LED_PIN 8
// Arduino Nano has LED on PIN 8
#endif

#ifdef SSD1306_H_
#define PEAK_THRESHOLD 5 // count the RSSI Polls for the peak threshold
#endif

#define RSSI_POLL_INTERVAL 200 // poll every x milliseconds
#define RSSI_SERIAL_FACTOR 5   // sends all RSSI_POLL_INTERVAL * RSSI_SERIAL_FACTOR the lowest RSSI to Serial

// all library classes are placed in the namespace 'as'
using namespace as;

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
  {0xFF, 0xFF, 0xFF},     // Device ID
  "..........",           // Device Serial
  {0x00, 0x00},           // Device Model
  0x10,                   // Firmware Version
  as::DeviceType::Remote, // Device Type
  {0x00, 0x00}            // Info Bytes
};

typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<LibSPI<10>, 3>> HalType;

class SnifferDevice : public Device<HalType, DefList0>, Alarm {
  DefList0 l0;
  
  private: 
    uint8_t cnt;
    uint8_t rssi_peak;
    uint8_t rssi_act; 
  public:
    typedef Device<HalType, DefList0> BaseDevice;
#ifdef SSD1306_H_
    DisplayType<PEAK_THRESHOLD, 0x3C> display;
#endif
    SnifferDevice (const DeviceInfo& i, uint16_t addr) : BaseDevice(i, addr, l0, 0), Alarm(0), l0(addr)  {}
    virtual ~SnifferDevice () {}

    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      set(millis2ticks(RSSI_POLL_INTERVAL));
      clock.add(*this);
      this->radio().pollRSSI();
      cnt++;
      rssi_act = this->radio().rssi();
      if (rssi_act < rssi_peak) {
        rssi_peak = rssi_act;
      }
      if (cnt >= RSSI_SERIAL_FACTOR) {
        DPRINT(":");DHEX(rssi_peak);DPRINTLN(";"); 
        cnt = 0;
        rssi_act = 0;
        rssi_peak = 199;
      }
#ifdef SSD1306_H_
      display.printFull(this->radio().rssi());
#endif
    }

    virtual bool process(Message& msg) {
      DPRINT(F(":"));
      DHEX(radio().rssi());
      DHEX(msg.length());
      DHEX(msg.count());
      DHEX(msg.flags());
      DHEX(msg.type());
      msg.from().dump();
      msg.to().dump();
      for (uint8_t l = 0; l < msg.length() - 9; l++) DHEX(msg.buffer()[l + 9]);
      DPRINTLN(";");
      this->led().ledOn(millis2ticks(100));
      return true;
    }

    bool init (HalType& hal) {
      HMID id;
      this->setHal(hal);
      this->getDeviceID(id);
      hal.init(id);
      hal.config(this->getConfigArea());
      sysclock.add(*this);
      return false;
    }
};

HalType hal;
SnifferDevice sdev(devinfo, 0x20);

void setup () {
  DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
#ifdef SSD1306_H_
  sdev.display.init();
#endif
  sdev.init(hal);
}

void loop() {
  hal.runready();
  sdev.pollRadio();
}

Habe folgendes zum Original geändert:
#define LED_PIN 8 (statt 4)

und
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<LibSPI<10>, 3>> HalType;
statt
typedef AskSin<StatusLed<LED_PIN>, NoBattery, Radio<LibSPI<10>, 2>> HalType;

Bibliotheken:
Low-Power (Master)
EnableInterrupt 1.1.0
Askin PP (Master)

Ansonsten nichts geändert. Vielleicht fällt jemand ja noch etwas dazu ein.

Ich vermute wie tomMajor nun auch den Fehler im Sketch. Es sollen ja auch nicht alle Nachbau nano boards mit dem Arduino original board identisch sein. Eventuell liegt es auch daran. Oder an den Fuses etc.. Bisher habe ich gar nichts mit dem Arduino gemacht, daher muss ich mich erst mal einlesen und probieren.
Ganz falsch kann es ja nicht sein, da ja immerhin Daten kommen, aber der Analyzer nimmt sie nicht entgegen. Es scheint so, dass auf etwas gewartet wird was dann nicht kommt.
Das "Config Freq: ..." bei TomMajor kommt ja bei mir auch nicht in der Ausgabe.

Ich werde jetzt mal das Frequenztest Sketch probieren und sehen ob das läuft.

Ich kann leider nicht kontinuierlich dran bleiben aber ich werde auf jeden Fall berichten wenn ich etwas rausbekomme und auch hier das Forum verfolgen.

Nochmals Danke für Eure Unterstützung.

P.S.: Habe mal bei Lieferanten des nanoculs nachgefragt. Hat sehr schnell geantwortet, konnte mir aber auch keinen Sketch für AskSin Analyzer XS (der auf dem gelieferten nanocul läuft anbieten. Sei Fokus liegt eher auf der culfw.