Hallo, ich nutze das Performance Testprogramm der Atmel MAC Software. Ich übertrage 20000 Pakete bei eingeschalteten Retries und Acks. Bei einer schlechten Verbindung kommt es nun dazu, das manchmal 20005 oder 20001 Pakete emfangen werden, obwohl ja nur 20000 gesendet werden sollen. Was kann dafür die Ursache sein? Auch bei wiederholten Sendungen, sollte es durch die Sequenznummern zu keiner "doppelten" Übertragung kommen. Oder ist der Fehler innerhalb das Prgramms zu suchen? Gruß Daniel
Wie gesagt, das Programm ist aus der Atmel MAC Software. Aber ich habe die Main-Datei angehangen, falls es sich jemand anschauen möchte. Ich meinte eigenlich ob so etwas im Falle einer schlechten Verbindung grundsätzlich entstehen kann. Falls nicht, muss es ja ein Programmfehler sein.
Daniel schrieb: > uch bei wiederholten > Sendungen, sollte es durch die Sequenznummern zu keiner "doppelten" > Übertragung kommen. Die Sequenznummer wird ja bei einer Wiederholung nicht erhöht. Wenn beispielsweise der Rahmen ordnungsgemäß empfangen worden ist, aber der Absender das ACK nicht gesehen hat, muss er ihn trotzdem nochmal übertragen.
Ja so habe ich es mir auch vorgestellt. Also muss ein Fehler im Programm vorhanden sein. Welcher schwer zu finden sein dürfte...
Daniel schrieb: > Ich meinte eigenlich ob so etwas im Falle einer schlechten > Verbindung grundsätzlich entstehen kann. Falls nicht, muss es ja ein > Programmfehler sein. Ja klar, oder denkst du man baut Acks und Retransmits nur zum Spass in ein Protokoll ein? 8) Ich kenn "Atmel MAC" nicht, was ist das für ein Stack bzw. wie sieht die PHY aus?
Ist mir schon klar, ich suche nur erst nach Erklärung bevor ich die Atmel- Softwerker beschuldige :-). Der Atmel MAC-Stack wurde nach dem IEEE 802.15.4 Standard entwickelt. siehe http://www.atmel.com/dyn/products/tools_card_v2.asp?tool_id=4675 Ich habe mir die entscheidenen Stellen im Code nochmal angeschaut. Konnte aber keinen Fehler bei den Zählern finden in den entscheidenen Programmteilen. Theoretisch kann es nicht vorkommen, dass mehr Frames ankommen als gesendet werden. Merkwürdig...
Daniel schrieb: > Also muss ein Fehler im Programm > vorhanden sein. Warum? Du hast einen Callback für jeden empfangenen Rahmen eingerichtet, und in diesem zählst du einfach nur hoch, ohne dir irgendwie die Details des Rahmens anzugucken. Stell dir nun folgendes Szenario vor: Tln A sendet den Rahmen mit der Folgenummer 42. Tln B empfängt ihn, dein Callback wird also aufgerufen und zählt hoch, Tln B bestätigt ihn. Die Bestätigung geht aber verloren, sodass Tln A ihn nochmal sendet. Dein Callback wird wiederum aufgerufen, zählt hoch -- schwups, hast du einen zu viel gezählt.
Achso, ich dachte dass Anhand der gleichen Sequenznummer nur einmal hochgezählt wird. Dann hat der Entwickler wohl an dieser Stelle gefuscht.
@Jörg Ich habe das Programm mal folgendermaßen verändert:
1 | void tal_rx_frame_cb(frame_info_t *mac_frame_info, uint8_t lqi) |
2 | {
|
3 | |
4 | uint8_t Sequence_number = mac_frame_info->seq_num; |
5 | if(Sequence_number!=old_Sequence_number) |
6 | {
|
7 | number_rx_frames++; |
8 | aver_lqi += lqi; |
9 | |
10 | }
|
11 | old_Sequence_number=Sequence_number; |
12 | |
13 | |
14 | |
15 | if (op_mode == PROMISCUOUS_OP_MODE) |
16 | {
|
17 | uint8_t i; |
18 | char ascii[5]; |
19 | |
20 | printf("Rx: 0x%.2X ", mac_frame_info->payload_length + 2); // 2 = FCS |
21 | for (i = 0; i < mac_frame_info->payload_length + 3; i++) /* 3 = FCS + LQI */ |
22 | {
|
23 | sprintf(ascii, "%.2X ", mac_frame_info->payload[i]); |
24 | printf(ascii); |
25 | }
|
26 | printf("\r\n"); |
27 | }
|
28 | |
29 | /* free buffer that was used for frame reception */
|
30 | bmm_buffer_free((buffer_t *)(mac_frame_info->buffer_header)); |
31 | }
|
Der erste Frame wird wahrscheinlich so noch nicht gezählt, da die erste Sequenznummer per Zufall bestimmt wird.
1 | static void configure_frame_sending(void) |
2 | {
|
3 | uint8_t temp_value[2]; |
4 | |
5 | /*
|
6 | * Set TAL PIBs
|
7 | * Use: retval_t tal_pib_set(uint8_t attribute, pib_value_t *value);
|
8 | */
|
9 | temp_value[0] = (uint8_t)SRC_PAN_ID; |
10 | temp_value[1] = (uint8_t)(SRC_PAN_ID >> 8); |
11 | tal_pib_set(macPANId, (pib_value_t *)&temp_value); |
12 | |
13 | temp_value[0] = (uint8_t)OWN_SHORT_ADDR; |
14 | temp_value[1] = (uint8_t)(OWN_SHORT_ADDR >> 8); |
15 | tal_pib_set(macShortAddress, (pib_value_t *)&temp_value); |
16 | |
17 | temp_value[0] = (uint8_t)DEFAULT_CHANNEL; |
18 | tal_pib_set(phyCurrentChannel, (pib_value_t *)&temp_value); |
19 | |
20 | /* Init tx frame info structure value that do not change during program execution */
|
21 | tx_frame_info = (frame_info_t *)storage_buffer; |
22 | tx_frame_info->msg_type = MCPS_MESSAGE; // use data frame type for Performance example |
23 | tx_frame_info->seq_num = (uint8_t)rand(); |
24 | tx_frame_info->dest_panid = DST_PAN_ID; |
25 | tx_frame_info->dest_address = DST_SHORT_ADDR; |
26 | tx_frame_info->src_panid = SRC_PAN_ID; |
27 | tx_frame_info->src_address = OWN_SHORT_ADDR; |
28 | }
|
Wenn ich einen festen wert für die erste Nummer festlege müsste es gehen oder? Nach einem kleinen Test stimmen die nicht erhaltenen Frames mit nicht erhaltenen Acks überein, was natürlich nicht unbedingt heisst dass es 100%tig funzt. Reicht diese Veränderung aus, oder siehst du einen groben Fehler?
Daniel schrieb: > Achso, ich dachte dass Anhand der gleichen Sequenznummer nur einmal > hochgezählt wird. Du hast doch den Code da, du kannst doch einfach nachgucken, was gemacht wird. Die einzige Bedeutung der Folgenummer ist, dass sie im ACK wieder auftaucht. Zur wirklichen Identifizierung eines Rahmens taugt eine einfache 8-bit-Zahl wohl kaum. > Dann hat der Entwickler wohl an dieser Stelle > gefuscht. Du unterstellst einfach viel mehr Funktionalität als hier offenbar das Entwicklungsziel war. Dort steht "received frames", und genau das zählt er auch.
Daniel schrieb: > Reicht diese Veränderung aus Siehe oben: zur wirklichen eindeutigen Identifizierung eines Rahmens reicht das nicht. Du kannst dir mal die kryptografische Authentifi- zierung im 802.15.4 angucken, die muss sich gegen sogenannte replay- Attacken absichern und implementiert daher auch eine Folgenummer, die aber länger ist und die einen Mechanismus implementiert hat, wie sie bei Überlauf zurückgesetzt wird. Für deinen einfachen Fall (dem ich allerdings keine ernsthafte praktische Relevanz zugestehen mag) wird's wohl genügen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.