proddy commented 4 years ago

We can merge later. My system is also EMS 1.0 and all modes working. Maybe it is uncritical because all components are on the boiler and the ems-bus lines are less than 1m (no roomcontroler, only weather controlled), No emc problems, no reflections, etc. Can you check with less delay, set emsTxWait = 5 * EMSUART_BIT_TIME * 11; for 11 bittimes. Also you can check with break ended by timer in the isr uncommend the last lines but set the timer to timer1_write(5 * EMSUART_TX_BRK_WAIT.

Originally posted by @MichaelDvP in https://github.com/proddy/EMS-ESP/issues/397#issuecomment-643620901

proddy commented 4 years ago

@MichaelDvP With the latest version 2.0.0a18 with your UART changes I can only get tx_mode 1 working. tx_mode 2 gives me:

[telegram] Sending read Tx [#12], telegram: 0B 97 02 00 20 44
[telegram] [DEBUG] New Tx [#25] telegram, length 1
[emsesp] [DEBUG] Last Tx operation failed. Retry #1. Sent: 0B 97 02 00 20, received: 09
[telegram] Sending read Tx [#25], telegram: 0B 97 02 00 20 44
[telegram] [DEBUG] New Tx [#26] telegram, length 1
[emsesp] [DEBUG] Last Tx operation failed. Retry #2. Sent: 0B 97 02 00 20, received: 09
[telegram] Sending read Tx [#26], telegram: 0B 97 02 00 20 44
[emsesp] [DEBUG] Last Tx operation failed. Retry #0. Sent: 0B 97 02 00 20, received: 09
[emsesp] Last Tx operation failed after 3 retries. Ignoring request.

EMS Bus info:
  Bus protocol: Buderus
  #telegrams received: 41
  #read requests sent: 0
  #write requests sent: 0
  #incomplete telegrams: 0 (0%)
  #tx fails (after 3 retries): 9

I noticed there is also no echo. With tx_mode 1 I would get the echo after the send, like

[telegram] Sending read Tx [#64], telegram: 0B 97 06 00 20 54
[emsesp] [DEBUG] Echo: 0B 97 06 00 20 54
[emsesp] Last Tx read successful

proddy commented 4 years ago

Michael, are you also using the same platformio.ini file with the ESP8266 running at 160Mhz instead of 80Mhz (board_build.f_cpu = 160000000L). Was thinking this could perhaps interfere with the timing?

MichaelDvP commented 4 years ago

Yes i'm running 160 MHz, but i tested the timer before with dummy counts, Have you tried mode 2 or 3? 3 gives no echo, since it clears the fifos before sending break. The timer controlled mode 2 should echo. With mode 3 i see a strange thing, the device answers, but ems-esp says no response. But it's only in mode 3. ems:/ems# 000+00:10:01.547 D 653: [telegram] Sending read Tx [#101], telegram: 0B 88 33 00 20 78 ems:/ems# 000+00:10:01.670 D 654: [telegram] New Rx [#166] telegram, length 11 ems:/ems# 000+00:10:01.670 T 655: [emsesp] Boiler(0x08) -> Me(0x0B), UBAParameterWW(0x33), data: 08 FF 30 FB FF 28 FF 07 46 00 00 ems:/ems# 000+00:10:01.670 D 656: [emsdevice] Processing UBAParameterWW... ems:/ems# 000+00:10:02.087 D 657: [telegram] Sending read Tx [#110], telegram: 0B 88 33 00 20 78 ems:/ems# 000+00:10:02.170 D 658: [telegram] New Rx [#167] telegram, length 11 ems:/ems# 000+00:10:02.170 T 659: [emsesp] Boiler(0x08) -> Me(0x0B), UBAParameterWW(0x33), data: 08 FF 30 FB FF 28 FF 07 46 00 00 ems:/ems# 000+00:10:02.170 D 660: [emsdevice] Processing UBAParameterWW... ems:/ems# 000+00:10:02.182 D 661: [mqtt] Publishing topic stat/ems/boiler_data (#102, attempt #1, pid 1) ems:/ems# 000+00:10:02.566 D 662: [telegram] Sending read Tx [#111], telegram: 0B 88 33 00 20 78 ems:/ems# 000+00:10:02.575 E 663: [emsesp] Last Tx operation failed after 3 retries. Ignoring request. ems:/ems# 000+00:10:02.667 D 664: [telegram] New Rx [#168] telegram, length 11 ems:/ems# 000+00:10:02.667 T 665: [emsesp] Boiler(0x08) -> Me(0x0B), UBAParameterWW(0x33), data: 08 FF 30 FB FF 28 FF 07 46 00 00

proddy commented 4 years ago

only tx_mode 1 is working. 2,3 4 give failures. not even a single Tx makes it through. I think I just need to bring out the scope and see what is actually happening on the line.

For tx_mode 3 this was a special modification I worked with @philrich on last year. See https://github.com/proddy/EMS-ESP/issues/103#issuecomment-493368592. The timings are slightly different for Junkers/HT3.

MichaelDvP commented 4 years ago

In this comment he wrote:

For me this patch works and i get close to none Corrupted Telegrams when i set EMS_TX_WAIT_GAP to 7 Bits (728us). (3, 4, 5, 6 Bits also works, when setting this to 10 or more Bits i get many Corrupted Telegrams)

So we need a gap of 3-9 bittimes for HT3, 10 for EMS+, and a low value for EMS1.0? I do this to the uart, revert the mode 2, it's never good to change a working mode. Now there are:

mode 1..3 as before, exept i do not clear buffers on break to get the echo in rx.
mode 4 as before, only hardwarecontroled
mode 5, same as mode 4, but 1,5 stopbits, I see in #103 that the time between master-poll and master-break is 1,5 bittimes.
mode 11..30: timer controlled modes with number of bittimes, ems+ should work with mode 20, ht3 with mode 17
mode 6..10 same as modes 12, 14, 16, 18, 20, but timer controlled clearing of break-flag.
for esp32 i have also implemented timermodes, 4, 6..30 works the same way, 1..3 is also timermode and 5 is the same as 4. I have to look how to change the stopbits.

All modes can be changed without reboot. You know, i don't like the modes 1-3, where the processor making millions of nop-loops to wait for tx done, There are other usefull things to do.

I've also merged your latest commit. Should i make a pr, or wait for feedback from hans?

In my system all modes work. Mode 1 has very few rx-crc-errors only if roomcontrol is activated and a roomcontrol poll-ack is right before a incoming telegram (it's always the UBAMonitorFast to all) . Then i get a 19 as additional first value in this telegram.

proddy commented 4 years ago

I like the approach. Plenty of modes to test with, and we can ask some of the Junkers users to also test. I'd say push the PR with the changes you made for Hans as you also fixed a lot of silly mistakes I made so thanks again for that. I agree the original rx/tx code is not efficient and blocking other important cycles and your approach is cleaner and makes use of the hardware interrupts.

MichaelDvP commented 4 years ago

As long as you never need a timer, 8266 have only 2 timers and one is used by wifi, the other here. Esp32 has more resources.

proddy commented 4 years ago

did a quick test, still only tx_mode 1 works on my system. I'll try all the other combinations later tonight.

MichaelDvP commented 4 years ago

something strange, seems the timer is now used, blocked, or reconfigured by logger for debug and trace. In both log modes tx fails in all timer-controlled modes, with log info the timer works, also if watch is on. As soon i switch log to info or lower tx works again and show emsbus counts no more errors, also i can see the reply to me in watch on/raw.

This log shows only the relevant lines. 20200614_163200.log

I checked the logs from before merging your latest changes, all modes works in debug/trace modes.

proddy commented 4 years ago

Hmm, can’t think of what that could be. And Log Level INFO with ‘watch on’ works you say? I’ll check the code when I’m back home.

proddy commented 4 years ago

did some more testing with ranges 4, 5, 6-10, 11-30 and only tx_mode 1 and tx_mode 5 work in my environment. See screenshots:

Capture_1

Capture_5

I can't see how the debug would affect the timings. It's best not to include any logger objects in the uart code is it may be blocking.

MichaelDvP commented 4 years ago

Oh, good, mode 5 working.

My issues with mode 1 come from the poll. Poll uses tx_brk also for mode 1, but here is no delay for mode 1. Found also a issue with HT3.

I deleted logging from emsuart, but that doesn't help. It is the LOG_DEBUG(F("Sending.. near the transmit() call, if i delete these loggings, all works. Seems the logger uses the timer for output. ESP32 has more timers and no conflict. I'll push + pr the changes after testing. I've also adapted esp32 uart completly, but not tested yet.

proddy commented 4 years ago

tx_mode 5 uses the same code as tx_mode 1 (the legacy stuff) but with 1.5 bitstops?

I can't see why the logs would affect the timings, the LOG_DEBUG just appends the message to a message queue. I think these messages are important (for debugging!) so does it work if you move them after the transmit() ?

MichaelDvP commented 4 years ago

No, mode 5 uses the same code as mode 4, but with 1,5 stopbits: Pushing all in the fifo and the hardware sends it out and appends the break. The transmit-function doesn't have to wait and returns instantly. I think it is the best mode for ems1.0. Putting the sending.. after transmit-call doesn't help (done that), because the timer-mode sending in the background aren't finished. There are other debug-messages if tx fails and on receive Last Tx read successful which doesn't conflict, since the tx is finished then. So there is a debug feedback in any way.

proddy commented 4 years ago

ah, I see what I did wrong now. I modified some of the esp8266 uart code, let me revert and test again. I don't expect tx_mode 5 will work sadly.

proddy commented 4 years ago

ok, tx_mode 5 doesn't work. Only tx_mode 1 on my setup.

MichaelDvP commented 4 years ago

I have tested a bit more and think i understannd better. I tried to measure the time from start sending to complete echo received, but with confusion results. I realize, that you havve modified the get_uptime() and the time is only updated in set_uptime once per loop-cycle, so all in one loop gives the same time (tx-modes 1-3 executes in 0 ms ;-)). Is there a special reason for this modification? I used ::millis() instead and can see the time. The esp uart seems to have a lag of 1 bytelength when receiving a byte, maybe there is a shiftregister for rx and after stopbit it is shifted to fifo in the next cycle, tx_mode 1 needs 16 ms for 6 bytes+break, same as tx_mode 2 or tx_mode 21. tx_mode 4 executes in 9 ms. so it's 1dummy+6+break for mode 4, 6dummy+6+break for mode 1. Your ems1.0 seems to be more ems+ than mine. Try with tx_mode 21 or 22 if it works for you.

Therefore i changed the modes once again, leaving 1..4, but set from 5 on timer as number of delay between bytes: mode 5 is 1bytetime+5bittimes until next byte, If there is no delay needed, mode 4 will do, HT3 will work with 5,6,7, ems+ 20, 21, 22. My system resposes to all modes, also 50 works. In mode 1 i added back the timeout, if there is no loopback from the bus, it will hang forever.

With esp32 i can't get the modes with delayMicroseconds working, but 4..50 without any collision with logger.

proddy commented 4 years ago

The reason for implementing get_uptime() is because I thought millis() was quite expensive and used many times in the code. I decided to control the timestamp once in the loop() cycle.

https://github.com/esp8266/Arduino/blob/1bfb29395f71da2caa5d14cbc6bdf8cf9c092d7a/cores/esp8266/core_esp8266_wiring.cpp#L166

I'll test your changes, thanks

proddy commented 4 years ago

quickly tested. I couldn't get any of the modes to work. tx_mode 1 also now shows errors so I need to check what was changed

[telegram] Sending read Tx [#29], telegram: 0B 97 06 00 20 54
[emsesp] [DEBUG] Echo after 11 ms: 0B 99 F0 C0
[telegram] [DEBUG] New Tx [#62] telegram, length 1
[emsesp] [DEBUG] Last Tx operation failed. Retry #1. Sent: 0B 97 06 00 20, received: 89
[telegram] [DEBUG] New Rx [#80] telegram, message length 25
[emsdevice] Processing UBAMonitorFast...
[telegram] [DEBUG] New Rx [#81] telegram, message length 21
[emsdevice] Processing MC10Status...
[telegram] [DEBUG] New Rx [#82] telegram, message length 19
[emsdevice] Processing UBAMonitorWW...
[telegram] [DEBUG] New Rx [#83] telegram, message length 13
[mqtt] Publishing topic homeassistant/climate/ems-esp/state (#45, attempt #1, pid 1)
[telegram] Sending read Tx [#62], telegram: 0B 97 06 00 20 54
[emsesp] [DEBUG] Echo after 33 ms: 0B 9F F0 C8 D4 FC
[telegram] [DEBUG] New Tx [#63] telegram, length 1
[emsesp] [DEBUG] Last Tx operation failed. Retry #2. Sent: 0B 97 06 00 20, received: 89
[telegram] Sending read Tx [#63], telegram: 0B 97 06 00 20 54
[emsesp] [DEBUG] Echo after 12 ms: 0B 99 F0 C0
[emsesp] [DEBUG] Last Tx operation failed. Retry #0. Sent: 0B 97 06 00 20, received: 89
[emsesp] Last Tx operation failed after 3 retries. Ignoring request.

EMS Bus info:
  Tx mode: 1
  Bus protocol: Buderus
  #telegrams received: 257
  #read requests sent: 39
  #write requests sent: 0
  #corrupted telegrams: 0 (0%)
  #tx fails (after 3 retries): 23

Also I think it's time we have other people test to rule out something strange in my environment.

MichaelDvP commented 4 years ago

Change in tx mode 1 since a19 is the old timeout (22 bittimes) back and change the poll-ack to the same logic, before poll uses tx_brk, but tx_brk has not wait defined for mode 1, causing some crc errors for me. Strange that the echo is corrupted in that way, thats not a timing-issue, the bits aren't shifted, they are puzzled. Bad contacts? Cold solderings?

MichaelDvP commented 4 years ago

Here is a log with nearly all modes on my system, you can see the different timings. The roomcontroller simulation is on, the 0xAF from 0x19 is from that function, so ems-esp answers all polls to 0x0B and 0x19. 20200616_165225_EMS.log I'm surprised that the master does not interrupt the very long modes.

proddy commented 4 years ago

nice can clean. You know, perhaps its my circuit. I have a few older and newer ones which bbqkees gives me to try. I'll go back to an earlier board and try the jack interface with a shorter cable and see if it makes any difference.

proddy commented 4 years ago

@bbqkees we have a similar setup. When you find time could you grab the latest v2 and test tx_mode 1, 4 and 5? Instructions are in https://github.com/proddy/EMS-ESP/tree/v2#uploading-the-firmware

bbqkees commented 4 years ago

I'm already running v2 with tx_mode 1 on a Premium II Gateway with a Lolin ESP8266.

This is from about 12 hours or so: `EMS Bus info: Tx mode: 1 Bus protocol: Buderus

telegrams received: 24713

read requests sent: 4522

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 0`

Will do some logging when I'm at home.

proddy commented 4 years ago

I'm already running v2 with tx_mode 1 on a Premium II Gateway with a Lolin ESP8266.

is this using the latest a21 version with Michael's new tx modes?

bbqkees commented 4 years ago

No you're too fast for me :-). Its on a19 from yesterday morning. Will update it tonight.

bbqkees commented 4 years ago

on a21 all modes give TX errors. log-mode-1-4-5-bbqkees-17062020.log

MichaelDvP commented 4 years ago

Oh, i'll look what is the change in mode 1, i thought nothing was changed, can please also try mode 10, or 12 with longer timer delays?

bbqkees commented 4 years ago

I'm not seeing any real difference between modes.

EMS Bus info: Tx mode: 12 Bus protocol: Buderus

telegrams received: 202

read requests sent: 4

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 38

Rx Queue is empty

Tx Queue (7 telegrams): [104] READ Me(0x0B) -> Thermostat(0x10), RC30Set(0xA7), data: 20 (offset 0) [115] READ Me(0x0B) -> Boiler(0x08), UBAMonitorSlow(0x19), data: 20 (offset 0) [116] READ Me(0x0B) -> Boiler(0x08), UBAParameterWW(0x33), data: 20 (offset 0) [117] READ Me(0x0B) -> Boiler(0x08), UBAParameters(0x16), data: 20 (offset 0) [118] READ Me(0x0B) -> Thermostat(0x10), RCTime(0x06), data: 20 (offset 0) [119] READ Me(0x0B) -> Thermostat(0x10), RC30Monitor(0x41), data: 20 (offset 0) [120] READ Me(0x0B) -> Thermostat(0x10), RC30Set(0xA7), data: 20 (offset 0)

EMS Bus info: Tx mode: 10 Bus protocol: Buderus

telegrams received: 384

read requests sent: 16

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 58

Rx Queue is empty

Tx Queue (17 telegrams): [240] RAW Me(0x0B) -> Boiler(0x08), UBAParameterWW(0x33), data: 20 (offset 0) [194] READ Me(0x0B) -> Boiler(0x08), UBAParameters(0x16), data: 20 (offset 0) [195] READ Me(0x0B) -> Thermostat(0x10), RCTime(0x06), data: 20 (offset 0) [196] READ Me(0x0B) -> Thermostat(0x10), RC30Monitor(0x41), data: 20 (offset 0) [197] READ Me(0x0B) -> Thermostat(0x10), RC30Set(0xA7), data: 20 (offset 0) [208] READ Me(0x0B) -> Boiler(0x08), UBAMonitorSlow(0x19), data: 20 (offset 0) [209] READ Me(0x0B) -> Boiler(0x08), UBAParameterWW(0x33), data: 20 (offset 0) [210] READ Me(0x0B) -> Boiler(0x08), UBAParameters(0x16), data: 20 (offset 0) [211] READ Me(0x0B) -> Thermostat(0x10), RCTime(0x06), data: 20 (offset 0) [212] READ Me(0x0B) -> Thermostat(0x10), RC30Monitor(0x41), data: 20 (offset 0) [213] READ Me(0x0B) -> Thermostat(0x10), RC30Set(0xA7), data: 20 (offset 0) [234] READ Me(0x0B) -> Boiler(0x08), UBAMonitorSlow(0x19), data: 20 (offset 0) [235] READ Me(0x0B) -> Boiler(0x08), UBAParameterWW(0x33), data: 20 (offset 0) [236] READ Me(0x0B) -> Boiler(0x08), UBAParameters(0x16), data: 20 (offset 0) [237] READ Me(0x0B) -> Thermostat(0x10), RCTime(0x06), data: 20 (offset 0) [238] READ Me(0x0B) -> Thermostat(0x10), RC30Monitor(0x41), data: 20 (offset 0) [239] READ Me(0x0B) -> Thermostat(0x10), RC30Set(0xA7), data: 20 (offset 0)

proddy commented 4 years ago

@MichaelDvP could it be the circuit? are you using one of bbqkees' gateway boards or a home grown circuit board?

MichaelDvP commented 4 years ago

I'm using BBQKees Premium 2 Gateway with the original Wemos (purcased december 2019), but it's not buspowered, im using the service jack. I have also a second noname wemos with encapsulated modul, and a wemos D1 mini 32. All working with the gateway. System is Buderus GB125 with BC10, MC10, RC35 and MM10, all pure EMS1.0 from 2011.

The difference from a19 to a21 in mode 1 is

the timeout, with a value as in earlier versions The timeout is now uint8_t, maybe the preprocessor calculated wrong: (22 * EMSUART_TX_BIT_TIME / EMSUART_TX_BUSY_WAIT) should be 176, but if (22 * EMSUART_TX_BIT_TIME) is skipt to 8 bit before the division we alway get a timeout. @proddy I can't test, since all modes working on my system, can you test with (22*8) for EMSUART_TX_TIMEOUT.
the poll handling: I use the same logic for poll, in a19 it was a simple wait:
USF(EMSUART_UART) = data; delayMicroseconds(EMSUART_TX_BRK_WAIT); tx_brk(); // send <BRK> but i'm astonished that a wait doesn't work for sending in your system, but should work for a poll.

bbqkees commented 4 years ago

@MichaelDvP Can you try bus powered? Just put the buck on the upper row then its bus powered even when connected to the service jack.

I and Proddy have the exact same boiler.

MichaelDvP commented 4 years ago

I was a bit to fast, Seems the big capacitor has a lot of load also after disconnecting and burned something on the board or wemos when changing the buck. Have to check first.

bbqkees commented 4 years ago

Could also be that you need to reinsert the jack cable. I have that sometimes when testing new Gateways when you change the buck position the Wemos does not boot. Only after unplugging it from the boiler and plugging it back it in boots. If you fried the Gateway let me know I'll send you a new one.

proddy commented 4 years ago

I just tested with the jack and it behaves the same as bus-powered, so rules that out.

Changing EMSUART_TX_TIMEOUT to (32*8) works. Anything lower than 256 gives the error. I don't think you need the timeoutcnt in there at all?

proddy commented 4 years ago

I changed EMSUART_TX_TIMEOUT so v2 works for us folks still using the legacy tx_mode 1, while we work out why tx_mode 4 and higher with hardware timings don't work on my setup

MichaelDvP commented 4 years ago

@bbqkees Thank you for the offer, but it seems only the 3.3V regulator on the wemos died and is now shortend in/out, the processor is now on 5V heating up very fast. With the other Wemos the gateway works. I've ordered a new wemos-clone to have one in spare. I think i'll wait for the delivery before testing again to switch to buspower. I've disconnected the jack before changing the buck position, but when plugging the buck to the upper pos. there was a very bright flash from the Wemos-LED due to the charge of the capacitor.

@proddy 256 is a bit special for a uint8_t, but works since it counts --timeoutcnt. Better to change to uint16_t. The timeout is not needed if connected to ems with continous receiving data. But when there is no rx, the sending waits forever (watchdog). Not good if you want to test something (wifi, mqtt) on a standalone wemos. But for this cases also a very large timeout will give the chance to telnet and change the tx_mode. If you really need this time for sending, then timer-mode tx_mode 22 will give the same timing without waiting for finish.

proddy commented 4 years ago

@proddy 256 is a bit special for a uint8_t, but works since it counts --timeoutcnt. Better to change to uint16_t.

Yes, I had already changed that.

If you really need this time for sending, then timer-mode tx_mode 22 will give the same timing without waiting for finish.

tx_mode 22 works, which is frigging awesome because it uses the h/w timers and we can finally remove all the hogging legacy code with the delays(). Nice! Why not just make this is default?

For EMS+ and HT3, do you expect differences in the timings too? We can start asking others to run some tests.

proddy commented 4 years ago

@MichaelDvP I'm sure Kees and myself can ship you a few Wemos' and Gateway boards to try out via DHL. I'll cover the costs. If you're interested I'll email you.

MichaelDvP commented 4 years ago

Good that timer mode is working. We should ask people with ems, ems+ and ht3 to check their timings. For instance start with 22, go down until it gives errors, go up till error. Than we have a working range for each system, maybe one value fits all, or make different defaults for the systems with enough distance to critical timings. If i get problems with myy gateway, i'll come back to your offer, for now one gateway is enough. For the wemos: i think dhl within europe is more expensive than ordering a hand full of wemos in china. I've allready ordered.

bbqkees commented 4 years ago

@MichaelDvP its better to use only original Lolin Wemos D1 Mini's and not those clones. Most clones have an under-powered voltage regulator. All Gateways have an additional capacitor on the 3V3 rail as a mini buffer but still. Also some clones like from Do-It.AM have manufacturing issues and behave erratically.

proddy commented 4 years ago

@MichaelDvP tested also with ESP32 and tx_mode 22. Get about a 75% success rate.

MichaelDvP commented 4 years ago

@proddy: Have you tried to increase/decrease mode? @bbqkees: good to know. I've used some 4-5 clones before, nodemcu and wemos, only one making some problems. I always thought i've killed it by ESD, i grabed it from thresh to see if i can desolder his regulator, but it's a Do-It and LDO is marked 4A2D. A short google shows that this is the underpowered LDO.

bbqkees commented 4 years ago

You can get the original D1 Mini's from Lolin on AliExpress The underpowered LDO on the clones does not have to be problematic. Its just if your application is more demanding or you are powering external devices from the 3V3 rail of the Wemos then random problems start to arise.

MichaelDvP commented 4 years ago

@bbqkees thanks for the link, next wemos will be ordered there. I've taken the LDO from the dead Do-It and put it on the Lolin, works. Seems the 8266 survives a few minutes on 5V.

MichaelDvP commented 4 years ago

I have tested a bitmore with the timings and checked with a oszi. I see that the Buderus devices do not have delays between the bytes, but always they start sending 3-4 ms after the poll. Some long messages have delay inbetween, but i can't see a system, i think it depends on internal calculation power of the devices.

I have added modes with delay before sending. tx_mode 5 with a simple fixed delayMicroseconds(3000), modes over 50 have only a starttimer with 100µs per unit, eg. 55 is 0,5 ms delay, 80 has 3 ms. Modes 5..50 have delay between the bytes, but now also before sending first byte.

For me all modes working, so we need other testers with EMS1.0, EMS+ and HT3. I suggest first test with tx_mode 90 (4ms)

proddy commented 4 years ago

tested a31 (and b1 on v2_web) with the latest uart code on an ESP32. With tx_mode 5, 22 and 90 I still get a few misses, around 10-20% but it has improved a lot.

With tx_mode 22 for example:

Capture

MichaelDvP commented 4 years ago

The esp32 timer does not work as described, the timing of all modes >5 is nearly identical with mode4, i.e. the timer fires without waiting. On esp8266 the timer works, better to test these modes with 8266. What about mode5? It's only a delay before sending, but my oszi says that the buderus-ems-bus clients do exactly this when sending. You can try to increase this delay a bit to 5 ms. I'm waiting for delivery of a analyser to check the timings.

proddy commented 4 years ago

I'm back to testing on the ESP8266 with v2_web and trying out the different tx_modes. What used to work before, with no errors was tx_mode 22. Now I'm getting 50% miss. Same with 1, 4, 5 and 90. Is this expected? I haven't compared your changes in the UART code but something is definitely different. Or it's something in my new code. dunno.

MichaelDvP commented 4 years ago

1 to 4 has no change, 5 was before a test to use the mode-1 logic, but in the rx-interrupt. But this does not work for you, so i changed this mode to a logic as mode-4, but delayMicrosecond(3000) before sending. Timer-modes 6-50 are changed in that way: before the first byte was send immediatly, now it starts with a delay. Modes >50 are new and same as 4/5 but the startdelay is controlled by timer.

emsesp / EMS-ESP

(v2) ESP8266 & ESP32 UART optimizations #398

telegrams received: 24713

read requests sent: 4522

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 0`

telegrams received: 202

read requests sent: 4

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 38

telegrams received: 384

read requests sent: 16

write requests sent: 0

corrupted telegrams: 0 (0%)

tx fails (after 3 retries): 58