die Lösung für Lost-Telegramme-Problem mit FT12 Firmware?

[StefanT]

Telegrams need 23 bytes. 8 bytes are header and checksum, and 0-15 bytes data payload.
So no, the 23 bytes are unfortunately required.

We really need 57 bytes (34+23) for buffers.

The problem should not happen for normal apps ... hmm ... of course I might be mistaken. I will have a talk with our lib expert (oldcoolman)

[vannachen]

Telegrams need 23 bytes. 8 bytes are header and checksum, and 0-15 bytes data payload.
So no, the 23 bytes are unfortunately required.

We really need 57 bytes (34+23) for buffers.

The problem should not happen for normal apps ... hmm ... of course I might be mistaken. I will have a talk with our lib expert (oldcoolman)

Hello,

today i test two LPCs with out8-firmware, the result is so sad:

i combine a switch-groupaddress which contains 2x8out-switch objects
i combine 16 status-groupaddresses which related to each output

when i switch on/off the switch-GA and not all the 16-status-GAs back...

that means "Lost"?

[StefanT]

The queue inside the LPC firmware for sending telegrams is not infinitely long. When you send lots of requests to a device it might overflow in some kind. But that happens with commercial devices too, to some extend.

[vannachen]

The queue inside the LPC firmware for sending telegrams is not infinitely long. When you send lots of requests to a device it might overflow in some kind. But that happens with commercial devices too, to some extend.

hallo, du hast Recht

the problem is not the lots of items in the queue, the problem is sending toooo fast.

i met the questions below:

1) when i connect ONE out8 LPC, all the thing goes well, but when i connect TWO or more out8s, the Rück-telegramms are always twice back! I think twice means NO-ACK?

2) the max.transfer-time for sending is 36,354 ms (from http://knx-user-forum.de/lexikon/?s=7a8 ... le=knx-eib)

when i send too fast(we cann't decide the sending from BUS is fast or not!), the commercial devices can be excuted one by one, but the LPCs seems "LOST" sometimes, especially if the bus is busy...

I have also arranged a new telegramm_tx[23] and the telpos_tx (yes, i have disable some functions of OUT to be able to define it), and the situation seems better, but that is just better, not best! that means the "LOST" reduced, but just reduced, not like the commercial "NO-LOST"

I have no idea about that... please help me...

[StefanT]

Repeated telegrams are usually no problem, as they are marked as repeats.

The problem with lost telegrams is due to the implementation of our library. The LPC library uses a ring buffer for sending, the commercial devices have bits for every communication object where send or reply requests are marked and then processed by the core library.

The ring buffer is IMO more efficient, but of course there is the possibility of loosing telegrams when the device is spammed.

The only thing you can do to improve the situation is to send with delays between sending, to give the bus time to do other stuff too.

[vannachen]

Repeated telegrams are usually no problem, as they are marked as repeats.

The problem with lost telegrams is due to the implementation of our library. The LPC library uses a ring buffer for sending, the commercial devices have bits for every communication object where send or reply requests are marked and then processed by the core library.

The ring buffer is IMO more efficient, but of course there is the possibility of loosing telegrams when the device is spammed.

The only thing you can do to improve the situation is to send with delays between sending, to give the bus time to do other stuff too.

The question is if we send with delays between sending, why we use the ring-buffer?
we can easily in our main-loop just send one by one using a special time-delay.

so we must send with delay between sendings in the ring-buffer in our library?

I guess the ring-buffer means that we can send the 8 telegramms onebyone with no delay(in fact it has the delay but just according to the T1-interrupt)?

btw: according my test, when the bus is busy(such as busy pollings), and even the delay-time is 1-second, some telegramms lost also.

mfg

[StefanT]

Hmm .... how can this be reproduced?
Could you please describe how you tested it?

[vannachen]

Hmm .... how can this be reproduced?
Could you please describe how you tested it?

In order to realize Welcome/Dinning-mode in our home, such as some lights on and other lights off, we must use the Scene or the Sequence. I think that should be important in our modern Intelligent-home

Because our OUT has no scene-function, so we should use the sequence from other methods:

1. Using (EIBD+LPC FT12) && three 8outs: Some outputs are not excuted always, the situation is just the thema;

2. Using (EIBD+LPC FT12) && three 8outs with delay: all outputs are excuted but if i use some sensors or gateways such as very busy-pollings, some outputs are not be excuted!

3. Using (EIBD+Commercial USB) && 8outs: all outputs are rightly excuted and very fast(ca. 20ms between send-commands, even the bus is very very busy), but the back-status-GAs lost sometimes.

4. Using Commercial Sequence such as Beker-Taster with scene-module: just as the situation as Point 3.

According to my Test, I am not sure the problem is from the LPC-hardware or the collision is not rightly realized in LPC-core-library. I have read the LPC922.c, and found that if the SEND-Action(state-machine) is not finished, the EX1=0! So the Send-actions should not be effected by the Back-Status-GAs!

btw. I think if we use more 8outs, the situation is more obviously

[StefanT]

3. Using (EIBD+Commercial USB) && 8outs: all outputs are rightly excuted and very fast(ca. 20ms between send-commands, even the bus is very very busy), but the back-status-GAs lost sometimes.

You know, telegrams are only sent three times. If the bus is too busy, telegrams get lost.

Maybe you should group the things you want to switch when coming home, so that there are less GAs to send.

[vannachen]

es gibt einer diskutierter Thema von der http://knx-user-forum.de/knx-eib-forum/ ... bcu-5.html


Die Busimpedanz stellt für den Modulator eine gewisse Belastung dar, er muss also eine gewisse Leistung abgeben und wird dabei wie jeder Verstärker durch die Verlustleistung aufgeheizt. Es gibt Schnittstellenbausteine (ICs), die überhitzen bis zur Zerstörung wenn man mit ihnen dauerhaft Telegramme sendet. Sie sind nicht "vollgasfest", weil die meisten Geräte normalerweise nicht ununterbrochen senden und daher auch keine thermischen Probleme bekommen. Ein zentraler Steuerrechner könnte aber schon mal eine Weile lang sehr viele Telegramme hintereinander versenden wollen, wenn komplexere Aufgaben anstehen. Da sollte die Schnittstelle dann "vollgasfest" sein, also dauerhaft mit der maximal möglichen Telegrammrate senden können ohne zu überhitzen.

Das Ding zieht den Bus halt um ca. 8V runter um ne Null zu senden und die Drossel verhindert (aufgrund ihrer Impedanz), dass das Netzteil "zu schnell" nachliefert. Trotzdem wird die Stromsinke (der ASIC) natürlich bei Dauersenden warm, aber alle ASICs (FZE1066, TPUART(2), NCN5120 etc...) haben selber eine Überwachung und stellen das Senden ein. Kaputt geht da definitiv nix (oder gibts für diese Behauptung Belege). Lediglich die diskrete Freebus-Schaltung könnte man tatsächlich auf diese Weise kaputt bekommen. Bitte nicht die Leute kirre machen...