RF Modul Packet Error Test, Packet Error Rate(PER) mit Hilfe von Signalgenerator bestimmen

[Andi M. (Gast)]

Hallo Leute,
ich brauche dringend eure Hilfe! Und zwar muss ich für mein Praktikum 
die PER eines RF-SoC mit Hilfe von dem Signal Generator Rohde&Schwarz 
SMIQ bestimmen.

Den Aufbau habe ich mir folgendermaßen gedacht.
Ich generiere in LabView eine zu IEEE 802.15.4 kompatible Datenliste 
schicke sie zum Signal Generator über GPIB und der soll diese dann auf 
2,45Ghz mit OQPSK modulieren. Das RF Modul empfängt das Signal und 
demoduliert es, falls es richtig angekommen ist. Das wird wiederum über 
SPI ausgelesen.

Was haltet Ihr soweit von der Idee??

Also zunächst habe ich einen fertiges Packet Sniffer, welcher über das 
Debug Interface, alle RX Signale auf IEEE 802.15.4 des RF moduls 
empfängt. Also deswegen kann ich hierbei Fehler ausschließen.

Nun zu meinen Problemen:
Ich weiß nicht genau, wie ich den Signal Generator richtig konfiguriere.
Ich habe ihn im Moment auf
Modulation GMSK
Symbol rate 2 Msym/s
Filter Gauss/2.0
Source: Datalist
Clock: Coupled/Symbol

Muss ich noch einen Trigger einstellen? oder ein Coding?
Kennst sich von euch jemand mit der Thematik aus? Im Praktikum kann mir 
dazu leider keiner weiterhelfen.

Vielen Dank!!
Viele Grüße

Andi M.

[Andi M. (vivaultra)]

sorry war gerade nicht angemeldet:
Also eine weitere Sache ist das erstellen der Datenliste. Vorallem die 
Softwareimplementierung der FCS/Frame Check Sequence, welche 
"normalerweiße" immer via Hardwarechip erstellt wird.
Hat das schoneinmal jemand gemacht? Hat jemand ein Beispiel? Gerne auch 
eine andere Programmiersprache!

Danke

[Jörg W. (dl8dtl) (Moderator)]

Andi M. schrieb:
> Vorallem die
> Softwareimplementierung der FCS/Frame Check Sequence, welche
> "normalerweiße" immer via Hardwarechip erstellt wird.

Dafür gibt's doch ein Beispiel im IEEE-802.15.4-Standard.

Hier ein Progrämmchen, das ich vor Jahren mal zusammengehackt habe:

/*
 * ----------------------------------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 * Joerg Wunsch wrote this file.  As long as you retain this notice you
 * can do whatever you want with this stuff. If we meet some day, and you think
 * this stuff is worth it, you can buy me a beer in return.        Joerg Wunsch
 * ----------------------------------------------------------------------------
 */
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static uint16_t crc_ccitt_update (uint16_t crc, uint8_t data)
{
    data ^= crc & 0xff;
    data ^= data << 4;

    return ((((uint16_t)data << 8) | ((crc & 0xff00) >> 8))
            ^ (uint8_t)(data >> 4)
            ^ ((uint16_t)data << 3));
}

static void
usage(void)
{
    fprintf(stderr, "usage: gencrc [-b base] number...\n");
    exit(64);
}

int
main(int argc, char **argv)
{
    long i;
    int c, base;
    uint16_t crc = 0;
    uint8_t byte;

    base = 0;
    while ((c = getopt(argc, argv, "b:")) != -1)
        switch (c)
        {
        case 'b':
            base = strtol(optarg, 0, 0);
            break;

        default:
            usage();
        }
    argc -= optind;
    argv += optind;

    while (argc-- > 0) {
        i = strtol(argv[0], 0, base);
        byte = (uint8_t)i;
        crc = crc_ccitt_update(crc, byte);
        argv++;
    }
    printf("CRC = 0x%04x\n", crc);
    return 0;
}

[Andi M. (vivaultra)]

vielen Dank fuer die Antwort! Werde es die Tage testen. Hab im Moment 
was anderes zu tun bekommen, aber sobald das fertig ist, werde ich mal 
testen.

Danke! :)

[Andi M. (vivaultra)]

Ahh jetzt bin ich unerwartet schnell fertig geworden, sodass ich mich 
jetzt doch schon wieder daran machen werde. In den 15 Minuten, wo der 
alte Beitrag editiert werden kann, hab ichs leider nicht mehr geschafft 
;)

Also mein erstes Hindernis ist erstmal eine Datenliste auf dem 
Signalgenerator zu erstellen und rueberzuschicken, sodass diese von dem 
SoC RF-Modul erkannt wird.

Ich habe ein Programm runtergeladen, in welchem ein/1 MAC/PHY Beispiel 
command frame angezeigt wird:
0x 00 00 00 00 A7    0A     03 00 10    01 01 42 0C 39       B3 69
        SHR          PHR      MHR        MAC Payload          FCS


Also theorethisch sollte das frame stimmen.
Nun muss man ja diese Symbole(4Bit) zu einer 32bit chip folge nach 
folgender Tabelle konvertieren: Quelle: Agilent.com

http://edocs.soco.agilent.com/download/attachments/100337712/ZigBee_Introduction-4.gif?version=1&modificationDate=1260242976000

und danach dann modulieren oder?

Danke!

[Jörg W. (dl8dtl) (Moderator)]

Andi M. schrieb:

> Ich habe ein Programm runtergeladen, in welchem ein/1 MAC/PHY Beispiel
> command frame angezeigt wird:
> 0x 00 00 00 00 A7    0A     03 00 10    01 01 42 0C 39       B3 69
>         SHR          PHR      MHR        MAC Payload          FCS
>
>
> Also theorethisch sollte das frame stimmen.

Ja:

./gencrc -b16  03 00 10 01 01 42 0C 39 B3 69
CRC = 0x0000

(Präambel, SFD und PHR zählen nicht mit in die CRC-Generierung.)

Wobei 03 00 10 kein sinnvoller MHR ist; das wäre ein MAC command,
aber ohne jegliche Adressierungsfelder.

> Nun muss man ja diese Symbole(4Bit) zu einer 32bit chip folge nach
> folgender Tabelle konvertieren:

Davon habe ich leider keine Ahnung, mit einem Signalgenerator musste
ich sowas bislang noch nicht selbst tun.

[Andi M. (vivaultra)]

Ahhhh merci!!!
Klappt aber leider immer noch nicht. Ich habe gerade mal mit einem 
zweitem Modul etwas rübergesendet und mit dem Packet Sniffer 
aufgefangen. Ich habe das Bild angehängt.

Kann man aus den Daten dort das komplette gesendete Frame 
rekonstruieren?
Auch wenn ich c++ (noch) nicht kann, müsste man dein programm ja so 
verändern können, dass die FCS direkt ausgegeben wird und nicht nur das 
ganze auf richtigkeit überprüft wird, oder?

Im IEEE Datenblatt gibts dazu in 7.2.1.8 FCS field den entsprechenden 
Algorithmus, den ich aber nicht so ganz verstehe...

Hab dazu leider überhaupt nichts im Internet gefunden und wüsste auch 
sonst nicht, an wen ich mich damit wenden kann.
Vielen Dank für dein Unterstützung!

[Jörg W. (dl8dtl) (Moderator)]

Andi M. schrieb:

> Kann man aus den Daten dort das komplette gesendete Frame
> rekonstruieren?

Der Frame steht doch direkt drunter, wobei die CRC nicht mit dabei
steht.  Den kann der hier vermutlich benutzte CC2420 nämlich nicht
mit liefern, wenn er ihn zugleich überprüfen soll: stattdessen
liefert er dann ein "CRC OK"-Flag und den LQI-Wert.

Allerdings ist der Frame auch wieder Nonsense.  Das sieht man
beginnend am frame type 4 ("R100"), der ein "reserved frame type"
im Standard ist.  Weiterhin wird behauptet, dass er verschlüsselt
sei, was deinen Sniffer dann dazu bewegt, alle möglichen Annahmen
über den benutzten Schlüssel zu implizieren und diese in die
dekodierte Ausgabe einzubauen.  Dadurch enthält die dekodierte
Ausgabe deutlich mehr Informationen als die 3 abschließenden Bytes
MAC Payload, die da eigentlich drin sind. ;-)

> Auch wenn ich c++ (noch) nicht kann, müsste man dein programm ja so
> verändern können, dass die FCS direkt ausgegeben wird und nicht nur das
> ganze auf richtigkeit überprüft wird, oder?

Das macht es schon jetzt. ;-)

./gencrc -b16 03 00 10 01 01 42 0C 39 
CRC = 0x69b3

Wenn du die CRC weglässt, wird sie berechnet; gibst du sie mit an, so
muss das Ergebnis 0 sein.  Das ist genau die Funktionsweise einer CRC
...

> Im IEEE Datenblatt gibts dazu in 7.2.1.8 FCS field den entsprechenden
> Algorithmus, den ich aber nicht so ganz verstehe...

Den muss man auch nicht verstehen, um ihn benutzen zu können.  Es
genügt völlig, dass Mathematiker und Informationstheoretiker diese
Algorithmen verstehen können. ;-)  Die Umsetzung in C hast du ja
weiter oben stehen.