uracoli, lwmesh, broadcast

[Michael S (Gast)]

Kürzlich hab ich mir mal wider uracoli angeschaut und da gibt es sang 
und klanglos eine kompatible Implementierung zu Atmels Lightweight Mesh. 
Funktioniert auch einwandfrei.
Ich hab bisher allerdings noch keine Broadcasts empfangen können. Daten 
die an die Networkadresse 0xFFFF verschickt werden, sollen ja wohl 
Broadcast sein ? Wenn ich in den Sourcecode schaue, scheinen solche 
Pakete auch weitergesendet zu werden, aber sie kommen bei mir nicht am 
lokalen Endpoint an. Hat einer schon mal erfolgreich Broadcasts 
empfangen ?

Danke

Michael

[A. W. (uracolix)]

Hallo Michael,

im Repo ist es noch drin, wird aber derzeit nicht weiter unterstuetzt, 
da  die lizenzlichen Konsequenzen hinsichtlich der EULA bisher noch 
nicht geklaert sind. Es war einfach (m)eine dumme Idee, das 
reimplementieren zu lassen, deshalb ist diesbezueglich auch Funkstille. 
Um die FreeBSD-Lizenz fuer uracoli uneingeschraenkt aufrecht erhalten zu 
koennen, werden wir uns von dem Protokoll in Kuerze ganz trennen.

Im Team sind wir bemueht eine neue Alternative zu schaffen um einfaches 
Routing bereitzustellen. Wenn du dazu Ideen hast, bist du und jeder 
andere gern als Entwickler eingeladen.

Axel.

[Michael S (Gast)]

Ah ,das ist schade. Hab ne weile mit Contiki experimentiert, aber des 
war ein ziemlicher Alptraum und meine alten Module mit rf230 rev.a. 
werden da nur schlecht unterstützt. Da fand ich es toll daß ich mit 
uracoli in nur 20 Minuten 4 Module hatte die miteinanader Daten 
ausgetauscht hatten. Hab das Routing von lwmesh zwar noch nicht 
ausprobiert, weil die alle nah beinander standen.

In den Beispielen hab ich noch nichts konkretes gefunden. Wie 
funktioniert denn ein Broadcast unter uracoli ohne lwmesh ?

Danke

Michael

[A. W. (uracolix)]

Broadcast funktioniert quasi inherent, wenn du kein RX_AACK nutzt. Im 
normalen RX werden alle Rahmen an die Applikation weitergeleitet.

Wenn du RX_AACK nutzt und im Adressfilter deines Devices die 
Shortadresse auf 0xcafe setzt und die PAN-ID auf 0xbabe, dann werden 
alle Frames mit
Destination Adresse 0xffff oder 0xcafe und PAN-ID 0xbabe per Interrupt
signalisiert (man nutzt dabei den in der Transceiver Hardware 
inmplementierte IEEE-802.15.4 Technik).

So wird die RX-Seite aufgesetzt:

    uint8_t RxFrame[127];

    radio_init(RxFrame, sizeof(RxFrame));
    radio_set_state(STATE_OFF);
    radio_set_param(RP_CHANNEL(CHANNEL));
    radio_set_param(RP_IDLESTATE(STATE_RXAUTO));
    radio_set_param(RP_SHORTADDR(0xcafe));
    radio_set_param(RP_PANID(0xbabe));

Auf der TX Seite ist folgendes von Noeten:

typedef struct
{
    uint16_t fctl;
    uint8_t  seq;
    uint16_t pan;
    uint16_t dst;
    uint16_t src;
    /* frame payload */
    uint8_t  keycnt;
    uint8_t  data[8];
    uint16_t crc;
} my_frame_t;

my_frame_t TxFrame = {
        .fctl = 0x8841,
        .pan = 0xbabe,
        .dst = 0xffff, // broadcast frame
        .src = 0xbeef
};

    // senden eines Frames:
    radio_set_state(STATE_TXAUTO);
    TxFrame.keycnt = keycnt;
    radio_send_frame(sizeof(TxFrame) , (uint8_t *)&TxFrame, 0);
    LED_TOGGLE(0);
    return 0;

Ein ausformuliertes compilierfaehiges Beispiel gibt es hier:
http://uracoli.nongnu.org/manual/pgXmplRadioRange.html

[Michael S (Gast)]

Danke ! Dann werd ich des mal ausprobieren..


Michael