Aha, so you want a cut and dried solution for free. Okay. I didn't and won't read your code because it's completely off track.
The "serial input basics" tutorial and example does what you ask. It's in the reference threads at the top of the forum.
The protocol you posted in reply #37 would be incredibly easy to decode using that.
You just said that bluetooth has a certain latency. Neither you nor I know that exact latency. No one has said specifically that it's xxxx amount of time. You or I don't know if I "manufactured" anything. It might have been caused by my code, or it might not have been.
The bluetooth spec says it is capable of data rates up to 1 Mbps at least. That being the case, if I send a steady stream of data, 300 bits should not take 27 ms, regardless of the contents.
For me to "check" or evaluate the contents, I need a full 25 bytes. I don't know yet what causes that excessive latency, but I can't evaluate the contents and produce 9 ms frames when each frame takes 27 ms. Continuously telling me that I "manufactured" the delay, doesn't really tell me how to avoid it when I'm trying to fix that exact issue. If you see the solution and know it will fix the time delay, then why not tell me exactly how to avoid it? I won't become a skilled programmer in 1 day, that's why people that have expertise in different fields ask for help from people with expertise in that specific field. Having a philosophical discussion about the problem won't help me fix it, exact details will.
I gave you the technical details and a link (well, directed you) to a solution. This has become tiresome. Good luck with your project.
I don't want anything for free. Obviously I tried for at least over a week to solve the problem myself. My knowledge of dynamic memory, functions and bluetooth at this point prevent me from getting anywhere. I posted here to see if anyone knew right off hand what was happening, or if anyone had come across this issue with bluetooth. I have cone across a hurdle that I don't think I can figure out alone or just by reading.
Repeatedly telling that I don't know what is going on isn't going to fix it because I have already stated that I don't know exactly what is going on. You don't really know me or know what knowledge I have, however I don't usually ask for help if I can figure something out for myself, and I always help others if they're stuck and I have knowledge in the field in which they are stuck. So to say I want something for free is inaccurate. I have tried solving this by reading, but some of what I'm trying to do requires extensive knowledge in CS, and no one is going to become an expert in that by reading for a few days.
Exchanging comments about other people's personality isn't going to solve any problems. This subject should be kept to the specifics of the problem at hand. That's what I'm trying to solve.
You need to forget completely about timing. You're still "at it" in post #55. You need to accept frames. For that, use "serial input basics" technique. All you have to do is look it up.
It will make your program work, after that you don't have to understand why your initial approach didn't work. Until the next time you have to do it, maybe...
Don't accuse me of not helping. That is really untrue and insulting.
I have stopped thinking about framing, if that puts your mind at ease. I completely understand that you are saying to use the symbols and stream content to do what is needed. Believe it or not, that's what I tried obviously because I have no timing related stuff in my code, other than just to measure how long each task takes. When it was on the single board only, all I used was the signal contents alone to do the read/write at the correct time, because nothing delayed the data.
I will use the byte contents to synchronize (if that's the right word) my reception. However, it's not a serial basics only problem since race-related bluetooth is involved. If data is cut up in packets, and the wireless packets tend to have delay, then time is also an issue, which is not intended by me. I need to understand more about the bluetooth spp (serial port profile) packet delivery specs. Do you know if there is any reference material for that? I need that because in order to use stream data I need to have a full cycle of the stream in less time than 1 period. Right now it takes 3 periods to get that data.
If you can't accept latency (delays) then you can't use Bluetooth at all.
I can accept latency, but based on what bluetooth is capable of, and its specification, it shouldn't have this kind of latency for this small amount of data.
Besides, I know bluetooth is capable of doing what I need, because some newer rc radios have internal bt modules that allow them to do exactly what I want to do, but they use the firmware in the radio to accomplish this.
I'm just trying to resolve an unusually high latency for what is being transmitted.
If bluetooth is capable of 1 Mbps, then 1 bit should take 1 microsecond. Even at half that, it would take 2 micros. If I send 300 bits (25 bytes including the overhead), it should take 600 microseconds. Even if it took 5 times longer (that's a total of 10 times slower than in the spec), it should only take 3 ms, so you see why I'm trying to figure out the excessive delay or latency. Otherwise I'm ok with latency in general.
What you are describing there is throughput (bandwidth), not latency. You can not "resolve" unwanted aspects of the channel that are dictated by the hardware and communications medium.
I completely explained why there is latency. It's a necessity of the packetization.
If bluetooth is capable of 1 Mbps, then 1 bit should take 1 microsecond.
Tells me once again, you absolutely do not understand latency. The best performance you can obtain from this system, is whatever latency is introduced by the Bluetooth firmware. You are stuck with that. No user code can influence that.
What you can do, in fact the best you can do, is ensure the end to end integrity of your data by recognizing packets, and accepting any delays in receiving a given packet. If you can't, you have to consider a different method of communication.
I told you where to look for code to parse packets in real time.
Is there any reference material that describes the packet size for the bluetooth protocol? These esp32 boards must use the same classic bluetooth protocol as any other hardware that uses classic bluetooth.
Is there anything I can read to understand more about bluetooth packetization, what causes extra delays and latency? What the packet size is, etc? For now I would like to understand more about how bluetooth works rather than the serial protocol.
If latency is an issue, then buffering should help with that, right? Does the "basics" you pointed me to, have details about the bluetooth protocol as well?
Absolutely not.
If you are concerned about the nominal and maximum delays why not just test it with the hardware you have?
Of course, the "serial input basics" doesn't concern itself with Bluetooth, that is because, as I am kind of finding extremely frustrating trying to make you understand, serial data is in general asynchronous, which means almost by definition, latency is unspecified.
Instead of asking me about it, why don't you go find it, read it, and try it?
Also if you want to learn about Bluetooth, why not just Google up some information? It's bound to be out there, in abundance.
Just realize, you won't be able to change it. So at your level of understanding, it would really be more productive to just learn how to accommodate it.
You have been insulting me from the first post, if you want to help, change your attitude, if not, get out of this thread and stop wasting my time.
Instead constantly insulting me, as in "at your level of understanding", why don't you either answer my specific question, or stop wasting your breath.....
Forget about serial, forget trying to push your own bad experience with something else or agenda on this. I WANT to understand more about bluetooth. Obviously I know about google, I've tried it, but I thought I'd ask someone with more experience than myself where to lead me specifically instead of just googling stuff as I have for weaks. That's like saying "forget going to the library, just ask people on the street". Google being the equivalent of asking people on the street.
So unless you have specific information to provide, like others have so far in this thread, anyone ither than you, go back to wherever you were before you found someone new to bother. I really don't understand people like you, what the necessity is for you to insult others. If that makes you forget about how miserable you are, then I guess it makes sense. But for now I am trying to get help with something specific, answers to my questions, not your smug remarks, so be kind enough and go bother someone else.
I think many people here will see that I've made considerable effort to help you and answer your questions directly, and will therefore be reluctant to help you.
If you have specific examples of abuse, please highlight them and forward them to a moderator.
Saying don't worry learning about bluetooth or about it being slow in this specific case, is like having told people 20 years ago "don't worry about slow modems, if you can't access a 57.6 kbps modem being slow, don't use the internet". If you don't question things that don't work as expected or well enough, then no one would ever make any progress. For being a technical issue, I don't see how you continuously say "don't worry about this or that"....
I didn't say, "don't worry". I specifically warned you that you need to take the Bluetooth delays into account, and I told you very specifically how to do that.
My goal here isn't to pick a beef with you. It's to seek a solution to my technical problem.
I think anyone reading this exchange will see i have been trying to be as polite as possible with you but you constantly have a fairly rough tone, borderline insulting. I really don't care. Maybe you don't notice it yourself, but from the getgo you've been trying to lead me like a herding dog. I'm not here to to argue, I'm here to get an answer to my question. Yes, maybe I can figure it out by months of googling, but then why would anyone ask someone knowledgeable about anything?
You seem to have some issue with my lack of programming knowledge. However, I made that clear very early, that I don't really know a lot about programming.
What you are doing is like if a cab driver would beat up a passenger who says they don't know how to drive, or keep referring them to a book that teaches you how to drive, when the person states they got a cab because they don't know how to drive.
If you can't specifically answer the question I asked in the 1st post, stop trying to teavh me philosophical lessons. If anyone else wants to help or not, leavd it to them. If you can't see how your remarks are insulting, then it's not for me to tell you what's insulting or not, then maybe you should read about how to address other people without coming off as rude.
What is more important to you, critiquing my instructional style, or fixing your problem? I put a concerted effort into helping you. This is what I get?
And I told you I'm here because an excessive delay in bluetooth is neither explained in the scope nor is it acceptable. For the hundredth time, I can't use a datastream to check for serial symbols when the data stream never gets there on time.
By the way, the asynchronous transmission is only used to check for start byte and end byte in this protocol, according to the manufacturer, they do use timing to define the repeating transmission frames. That's why it repeats every 9 ms for digital and every 14 ms for analog pieces of equipment. Otherwise it would just send in a long, continuous stream with no delays. That is, however, not the scope of my question. My question is, imagine you are sending whatever serial over bluetooth, why is 1 byte taking 4 ms, or 25 bytes taking 30 ms to send? If you can't answer that, maybe someone can. If there's no answer, then there's a reason for the slow throughput. Until someone has told me why, then I can't just not worry about it, or until I find a solution if there is one.
Then, as I already mentioned, you can't use Bluetooth.