Creating a serial bridge from 1 esp32 board to another

Which, is almost guaranteed with an asynchronous protocol like serial (unless it's specifically synchronous).

After all that has been said, why are you not framing your data?

Absolutely NOOOO!. Framing is done with embedded symbols in the data stream.

You are thinking, to make an analogy, like a violin maker trying to build a house. You wonder, why is it so hard to make an arched roof, and how to decorate the support post in the middle of the living room. :slight_smile:

Your cumbersome idee fixe of using timing is dragging you down...

That's a completely inadequate protocol for proper framing. The major problem with it, is the lack of end marker.

Does your code check for the end byte, 0x00?

I suspect your code.

So far I have not done any checking for anything, because the time it takes to receive 1 frame of 25 bytes is at best 3-4 times as long as the 9 ms frame time. I have only been trying to receive the data fast enough, then I was going to check the individual bytes. But it looks like reception and checking may be intertwined.

That is a guaranteed failure right there.

Yes, I don't doubt that, but as I mentioned, I didn't have to do anything because a quick check with wired connections didn't cause any issues, the issue only arose when wireless communication was used. So if a problem didn't exist yet, a solution wasn't needed. That's why I posted here, because there was/or obviously is a problem with the code not doing what is intended. I'm not saying the code is perfect, and that's why I posted it here.

To make an analogy, you are saying in effect, "Before I needed to ride a horse, I didn't need a saddle... now that I have a horse, why do I need a saddle?".

The perfection or lack of it is not the issue here, it's whether it can work.

I'm asking you to use a saddle. :slight_smile: The fact that you could walk perfectly well without one, is irrelevant.

The bluetooth communication doesn't care what the start and end bytes are though, only the decoder does. So if the bluetooth protocol is receiving 25 bytes every 9 ms, why is it delaying it up to 27 ms to complete one cycle? As far as the bluetooth is concerned, any of the bytes could be anything, the wireless reception time shouldn't depend on the contents, right?

No I completely understand what you are saying, it's I didn't even know a saddle was needed or "what a horse was" until this happened. I'm not an expert programmer, I just use this as a tool.

Now that I know I need it, I really don't know how to fix the issue yet, I know the logic but not yet how to implement it. That's why I asked for assistance.

Almost. Bluetooth actually communicates in packets. Those packets might contain a single or multiple characters, the transmitter tries to combine characters in a single packet but if the input stream pauses, or if the packet is full, it will be sent, and further characters have to go in the next packet...

You show no signs of understanding the logic. Not in what has become a very verbose thread...
because of the behaviour of the channel that I explained in #46, you have to completely ignore timing and only look at the contents of the received serial stream.

By logic I refer to that I understand what I need to do, as in have a timed frame, I knew that before even posting my first message, I don't know how to code it or fix it, and none of us really know why the bluetooth issue/delay exist.

Regardless of what I know or don't know, I have posted my problem, I'm not sure how what I know or don't know would fix this since I've already stated that I don't know exactly what is causing this or how to solve the problem. I have already presented all the facts. If someone knows how to deal with issue, I'm not sure how it helps regardless of how many times I say that I'm not sure how to fix the issue. If I did, I would implement a working solution.

I do, and I told you how to fix it. :roll_eyes: reply #47...

I'm not 100% sure how the bluetooth packet structure work either. That's why I timed everything and presented thd facts here.

The only thing you really need to know about that from an end user perspective, is that there will be some latency (delay), and that it will vary.

You said to use the incoming symbols in the data stream.

I know how do if (byte == xxxx) then....

But that won't help with the time issue unless I know more about bluetooth or unless someone else sees the exact problem that is being caused.

To use your riding analogy, if someone doesn't know how to ride, simply explaining it to them won't make them an expert rider.

I'm not a programmer, I know a little programming just to get by, but just telling me in word what to do doesn't mean I know how to do it. Just like I put all of the code I used here in full detail, I'd think if someone had a suggestion, they'd put in some part or kind of code example.

Yes, it will. The "time issue" is one that you manufactured, it doesn't really exist.