I’d like to concur about reading the receive buffer faster than it is filled!
Hopefully there is some end of line character that can be parsed for, but if not, a timeout should be fine like you said.
Curious what baud rate is being used.
Comment on Missing data when communicating over UART
bitfucker@programming.dev 5 months ago
I assume you mean RXD to TX0. As for sporadic packets like that, I’d honestly check for the signal integrity. Maybe somehow the data line is picking up noise high enough to cause disturbance. It could be caused by a lot of things, but the most likely culprit are the connector/cable. Any connection going into/out of pcb should be checked. Or check your timing. Make sure the baud and other config (start, data, stop, parity) are matched. Small drift in baudrate is usually tolerable. UART is designed for async communication after all, meaning that any device may send anytime so CTS and RTS isn’t usually needed provided that it is a hardware UART (not bit banging). You can check out Ben Eater video about it. In short, the TX is usually held high, the RX then can detect a falling edge which is a signal that a packet is starting. The UART hardware then processes the signal according to the config that you give it and is usually able to do a DMA transfer.
ChrysanthemumIndica@discuss.tchncs.de 5 months ago
bvoigtlaender@feddit.org 5 months ago
The Serial on the ESP is set to 115200 as is the default of the module but can be overridden using commands. I should probably double check that. :) However I would assume that having a different baud rate would result in more errors than I am currently experiencing.
bitfucker@programming.dev 5 months ago
Since the posts are about SIM7600, and the example shows, it’s probably AT Command. So always newline delimited (either \r or \r\n)
ChrysanthemumIndica@discuss.tchncs.de 5 months ago
That’s fair, and sort of what I assumed, but I don’t quite have the experience to say for a fact, so much appreciated!
Ironically I’ve only done modem stuff when I was very young and also somehow most of last year. But also maybe I get a little paranoid when it comes to talking to devices, and maybe I’m extrapolating my current i2c woes too far 😅
bvoigtlaender@feddit.org 5 months ago
Thank you so much. That might actually be it. I didn’t had the time to fully implement that yesterday but will be today. I did however put in a
sleep()after waiting for the buffer and reading it to validate your thesis, which results in complete data!! ^^Arduino even has an function for that
readBytesUntil. However in my short testings yesterday in seemed to always stop on new lines, even if I set the char for it to stop on to something really silly. Reading it and implementing that stop on my own worked better. I wanna do it the “official” way though, it would then even respect an timeout set bysetTimeoutI will probably end up having CTS and RTS anyway cause I couldn’t make sure that the module starts to talk all of the sudden.
I hate that the answer to my problems are always the most stupid ones. I kinda wish it would have been signal integrity, but I would probably regret that real fast too. :)
bitfucker@programming.dev 4 months ago
Yeah, CTS and RTS is useful for the module since you may overflow the module buffer (instead of the module overflowing your UART buffer). With proper HW flow control, hopefully your device UART respects the signal and pauses the tx until it is clear again without you having to code the pause yourselves. It can happen when the GSM bandwidth is lower than the UART bandwidth.
The module suddenly talking should also be handled by your device UART gracefully. When your rx buffer is full for whatever reason (not reading it for a long time?), the module won’t be sending anymore data until you read your rx buffer. Theoretically, no data should be lost that way.