ESP8266 Community Forum

- Sat Oct 23, 2021 7:31 am #92698

Hi again Erik
Maybe I have found you a bug

When I activate uart without connecting to a wlan first, the bridge will pipe the received data into the cli... no matter what I set the bp to, the received characters end up in "bp 0 24".

I agree, this is a special case...but it is actually not necessary to associate to a wifi it you want to have an "AP bridge" which I think is a cool feature .

Kind regards.
/Andreas Schütz

I am not exacty sure because I don't understand what exactly happens, but it could be you're running into something that's actually a feature. If you don't have any config active, a default, minimal config will be installed, in which flags/features "log-to-uart" and "cmd-from-uart" are enabled. That means that everything you type to the UART is interpreted as commands and everything the system replies is also echoed to the UART. If you don't want that, disable these features:
- fu log-to-uart
- fu cmd-from-uart

Hope that helps. Otherwise I'll try fix it.

- Sat Oct 23, 2021 7:36 am #92699

I think that I have found another bug...

1) I set the wifi parameters and connect to wifi... No Problem.
2) I set the uart parameters and start fetching characters from uart on port 23.... No problem.
3) I set the i2c pins (im 0 5 i2c scl 5) and when pressing enter, my wemos d1 forget all config and restarts without config.

That's bad, really bad. I am not really using the UART bridge feature anymore myself, so there could be bugs lurking there. But the other stuff should be working really.

Is this reproducable? Please note that many config changes need a reset to become (fully) active, especially the I2C subsystem.

Interesting syntax though, is that a typo? The command should read "im 0 5 i2c scl" without the '5'.

If this is reproducable, can you do an "s" (stat) immediately after the crash? It would tell the "reason" for crashing and some addresses. Did you also capture the UART output?

- Sat Oct 23, 2021 7:40 am #92700

Hi again.
So I have connected all my modules together and tested the various buses and it works just fine (with some quirks to avoid the "reset and forget everything bug").
I can see three sensors (51, 52 & 53) and the values they measure when i surf to the webpage or do a isd on the cli. Great!
On port 23 I can see everything received on the RX pin but no values from BME280 sensors.... how do they get visible in the port 23 stream?
/Andreas Schütz

Are you also using UART bridging?

So you're issueing an "isd" from wifi/ip and then it works and from the UART (with "cmd-from-uart" and "log-to-uart" features active) it doesn't? Or the other way around? It may be the output is too long for the very limited amount of buffering I can use. Does it show anything at all?

- Sat Oct 23, 2021 7:45 am #92701

Hi Eriksl

Maybe I am out in the blue now...but a way to get the values that one can read from the sensors out on the bridge port would be to build an "bw" (bridge write) command so that one can create a sequencer that reads the sensor value and then puts the value out on the bridge stream (like it was received on the tx pin). The bw command would need to have some data variables... or be able to take a secondary command that reads the value for it....like:
bw "first string" [51] "second string" cs <CR><LF>

or even better if one could stack more values like:
bw "first string" [51] "second string" [52] "third string" [53] ... [nn] "last string*" cs

- Where bw is the command
- "first string" is part of the NMEA format and is static for a given sensor
- [51] is the value that gets read from the sensor number . Same that is presented inside brackets when you do a "isr 51"
- "second string" is the rest of the NMEA static format string...and so on.
- cs is a calculated checksum that needs to be done on the fly. It does not need to have a parameter but can be understood to be there after the asterisk. But maybe the bw command gets more universal with the parameter. The complete message must end with <CR><LF> which also can be understood or implemented as a parameter.

This would give an example command like this:
bw "$IIXDR,C," [51] ",C,UIObridge*" cs
And would send the string:
$IIXDR,C,23.7,C,UIObridge*1A

Of course the bw command could be used to send a lot of other things out on the X.X.X.X:bp
Would it be possible for you to build something like this? (crossing my fingers, saying pleeeeese) It would save me a ton of work since I haven't got the build environment. A pretty good description of how to calculate the checksum is found here:
https://doschman.blogspot.com/2013/01/c ... ksums.html
And a good online calculator is found here:
https://alekunderwater.github.io/nmea01 ... lator.html

So what you actually want is a macro-formatted output function to the UART? There is already a command to write to the UART(s), it's called uw (uart-write) but, of course, it doesn't fill in values. I think it will be a bit tricky to implement due to the very limited amount of memory available. I think the start point would be a parser that would be interpreting "special" sequences of characters and replace them with values. I think any kind of dynamic calculation is impossible, it would be a 1:1 replacement, but a CRC could be offered as a static calculation.

Wouldn't it be far easier to just build an NMEA emulator (either standalone or in this code)?