Chat freely about anything...

User avatar
By eriksl
asz wrote: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
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:

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: ... ksums.html
And a good online calculator is found here: ... 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)?
User avatar
By asz
#92710 Hi Erik
There is a good amount of lag in this forum that plays some tricks on us. i seems that we get a little "out of sync" in our conversation.

I did get a bit inpatient from all the planning and "designing" on the new functions so I couldn't really stop myself from going ahead and write my own code...sorry.
I use platformio as IDE and with the arduino framework it wasn't so many hours of work.

That said, I would like to use your code anyhow because I will need other type of functionality onboard where you cli approach is much better suited.

As I understand from your answers what I first called a bug is the uart=>cli functions you describe...sorry again. But the "forget everything and reset" is still there and it is easy to trigger...I will describe how you can trigger that.
I also understand that I should be getting the sensor value out on the that so?
I will play some more with the BME280 and leave the "GPS" out of the equation as it constantly spews info. and make it hard to se other data. I'll report back on that to.
User avatar
By eriksl
#92733 I ask again: what version are you using, is it one of the "releases" (which are quite old in the meantime) or from git HEAD and build yourself?
User avatar
By asz
#92764 Hi Eric and sorry for the late answer... a lot of work lately.
I use the very latest master branch #25 release that is flagged as "latest" on the github page.